Android SurfaceFlinger中的工作线程:threadLoop()

SurfaceFlinger的threadLoop()方法是其工作线程的核心,主要负责Layer的混合与显示。流程包括:handleConsoleEvents处理显示设备状态、handleTransaction更新Layer列表、handlePageFlip准备Layer的frontBuffer、handleRepaint执行混合操作、unlockClients解锁Layer及postFramebuffer切换主表面。这一过程确保了Android系统的流畅显示。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

SurfaceFlinger继承了Thread类,自然也继承了Thread类的threadLoop方法,SurfaceFlinger工作线程的主代码都在threadLoop()方法中。工作线程启动后,基类Thread会循环地调用threadLoop方法,SurfaceFlinger的threadLoop()主要是要完成系统中各个Layer(Surface)进行混合(compose),然后不停地把一帧帧混合好的图像数据传送到显示设备中。

 

threadLoop的流程

                 图一   threadLoop流程

1. handleConsoleEvents

handleConsoleEvent目前没有深入了解,貌似只是处理显示设备进入休眠状态或者从休眠中唤醒时,改变SufaceFlinger的状态,然后threadLoop的后续流程会根据相应的状态来决定是否继续给显示设备传送显示数据。

2. handleTransaction

因为Layer的混合是在线程中进行的,而混合的过程中,应用程序或者系统可能会改变Layer的状态,例如屏幕旋转、增加或删除Layer、某个Layer可见或不可见,为了使这些变动不会破坏当前正在进行的混合动作,SurfaceFlinger维护着两个Layer列表:

  • mCurrentState.layersSortedByZ   ---- 当前系统最新的Layer列表
  • mDrawingState.layersSortedByZ  ---- 本次混合操作使用的Layer列表

handleTransaction就是根据Layer列表的这些状态的变化,计算是否有可见区域内需要更新,并设置状态变量mVisibleRegionsDirty,然后把mCurrentState赋值给mDrawingState,最后释放已经被丢弃(ditch)的Layer

  • 上一次混合过程中,可能应用程序释放了一个Layer,可是mDrawingState正在使用,不能马上销毁,所以要等到本次混合前才能做出销毁的动作。

  • 如果Layer的大小有变化并且可见,Layer的handleTransaction将会重新分配缓冲区,并且冻结SurfaceFlinger后续的混合操作,也就是屏幕的内容本次将不会刷新,直到下一个循环的handlePageFlip阶段才解除冻结。

3. handlePageFlip

该阶段会遍历各个Layer,在每个Layer中,取得并锁住该Layer的frontBuffer,然后利用frontBuffer中的图像数据生成该Layer的2D贴图(Texture),并且计算更新区域,为后续的混合操作做准备。

                                图二   handlePageFlip处理流程

Layer的lockPageFlip()首先通过SharedBufferServer类的成员变量lcblk,调用retireAndLock取得该Layer当前可用的frontBuffer,然后通过reloadTexture方法生成openGL ES的纹理贴图,最后通过unlockPageFlip完成更新区域的Layer坐标到屏幕坐标的变换。

handleRepaint

 handleRepaint真正实现Layer混合的阶段,下图是handleRepaint的处理流程:

                                                     图三  handleRepaint 的处理流程

 

handleRepaint首先重置了openGL的观察矩阵,然后遍历mDrawingState.layersSortedByZ 中的Layer列表,调用每个Layer的onDraw方法,在onDraw方法中,会调用drawWithOpenGL()方法,将在handlePageFlip阶段生成的贴图混合到OpenGL的主表面,最后handleRepaint把需要刷新的区域清除。

unlockClients

unlockClients只是遍历各个Layer并调用各个Layer的finishPageFlip方法。finishPageFlip会进一步调用SharedBufferServer的unlock()方法:(关于SharedBufferSever,请参考本人以下博文的SharedClient 和 SharedBufferStack一节)

 lcblk->unlock( mFrontBufferIndex )会把Layer的frontBuffer解除锁定。

postFramebuffer

 进入postFramebuffer阶段,OpenGL主表面已经准备好了混合完成的图像数据,postFramebuffer只是简单地调用hw.flip(),hw.flip()进一步调用了eglSwapBuffers完成主表面的切换,这样屏幕上的图像就会更新为新的数据。

 

 

backtrace: 04-04 17:53:38.728913 14617 14617 F DEBUG : #00 pc 000000000009dd44 /apex/com.android.runtime/lib64/bionic/libc.so (abort+180) (BuildId: a87e89fc2c0a5753053f536add4d7ae1) 04-04 17:53:38.728971 14617 14617 F DEBUG : #01 pc 000000000009fc9c /apex/com.android.runtime/lib64/bionic/libc.so (__fortify_fatal(char const*, ...)+124) (BuildId: a87e89fc2c0a5753053f536add4d7ae1) 04-04 17:53:38.729030 14617 14617 F DEBUG : #02 pc 00000000000a1c54 /apex/com.android.runtime/lib64/bionic/libc.so (fcntl+516) (BuildId: a87e89fc2c0a5753053f536add4d7ae1) 04-04 17:53:38.729057 14617 14617 F DEBUG : #03 pc 00000000000090e0 /vendor/lib64/libaedv.so (receive_file_descriptor+72) (BuildId: c7aa26ebc81fe81ae163fa3a8c82a4e9) 04-04 17:53:38.729084 14617 14617 F DEBUG : #04 pc 000000000000a87c /vendor/lib64/libaedv.so (raise_error+892) (BuildId: c7aa26ebc81fe81ae163fa3a8c82a4e9) 04-04 17:53:38.729109 14617 14617 F DEBUG : #05 pc 000000000000b6d0 /vendor/lib64/libaedv.so (aee_system_report+376) (BuildId: c7aa26ebc81fe81ae163fa3a8c82a4e9) 04-04 17:53:38.729135 14617 14617 F DEBUG : #06 pc 000000000000b794 /vendor/lib64/libaedv.so (aee_system_exception+132) (BuildId: c7aa26ebc81fe81ae163fa3a8c82a4e9) 04-04 17:53:38.729192 14617 14617 F DEBUG : #07 pc 00000000000fa85c /vendor/lib64/hw/hwcomposer.mt6768.so (android::SWWatchDog::Recipient::onHang(unsigned long const&, int const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, long const&, long const&, long const&)+316) (BuildId: 857b71c842e13d7bffdbf4b1f3fd8f58) 04-04 17:53:38.729236 14617 14617 F DEBUG : #08 pc 00000000000facec /vendor/lib64/hw/hwcomposer.mt6768.so (android::SWWatchDogTimer::threadLoop()+468) (BuildId: 857b71c842e13d7bffdbf4b1f3fd8f58) 04-04 17:53:38.729265 14617 14617 F DEBUG : #09 pc 00000000000faacc /vendor/lib64/hw/hwcomposer.mt6768.so (void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, android::SWWatchDogTimer::SWWatchDogTimer()::'lambda'()> >(void*)+44) (BuildId: 857b71c842e13d7bffdbf4b1f3fd8f58) 04-04 17:53:38.729291 14617 14617 F DEBUG : #10 pc 000000000010ba80 /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+208) (BuildId: a87e89fc2c0a5753053f536add4d7ae1) 04-04 17:53:38.729317 14617 14617 F DEBUG : #11 pc 000000000009f690 /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: a87e89fc2c0a5753053f536add4d7ae1) 04-04 17:53:38.745596 14617 14617 F DEBUG : dump_environment.......
04-08
<think>好的,我现在需要帮用户分析他们提供的backtrace日志。首先,我要仔细阅读这个日志,看看里面有哪些关键信息。用户之前问过关于cold和powerkey的内容,现在转到了backtrace,可能是在调试或遇到了系统崩溃的问题。 首先,backtrace显示了一个崩溃的堆栈跟踪,时间戳是04-04,看起来是Android系统的日志。崩溃发生在libc.so的abort函数,这表明程序调用了abort导致异常终止。接下来是__fortify_fatal,这可能是因为检测到缓冲区溢出或其他安全错误,触发了Fortify保护机制。 然后看到fcntl函数调用,这里可能涉及文件描述符的操作,比如设置非阻塞模式或加锁,但操作失败导致崩溃。接下来是libaedv.so中的函数,像是接收文件描述符和处理错误,这可能和Android的异常报告系统有关,比如生成错误报告或记录崩溃信息。 再往下是hwcomposer.mt6768.so中的SWWatchDog相关函数,SWWatchDog应该是软件看门狗,用于监控硬件合成器的响应。如果在规定时间内没有收到响应,看门狗会触发异常,导致系统报告问题。这里的堆栈显示onHang方法被调用,说明系统检测到某个操作超时,可能硬件合成器没有及时响应,导致看门狗超时,进而触发崩溃。 我需要考虑用户可能的背景。他们可能是开发者或测试人员,遇到了系统崩溃,特别是与硬件合成器或看门狗相关的问题。用户可能想了解崩溃原因以及如何解决。 接下来,我应该分析可能的原因:比如硬件合成器驱动的问题、系统资源不足(如内存泄漏导致无法及时响应)、线程阻塞或死锁。另外,看门狗的超时设置是否合理,或者是否有第三方模块冲突。 对于建议部分,需要指导用户检查相关日志,更新驱动或系统补丁,检查资源使用情况,调整超时设置,或联系硬件厂商。用户可能需要更具体的步骤来诊断和解决问题,比如如何获取更多日志或进行压力测试。 需要注意的是,用户提供的日志中有MT6768芯片组的信息,这可能联发科的处理器,所以可能需要检查该芯片组的特定驱动或已知问题。此外,libaedv.so可能和异常处理框架有关,需要确认其版本或是否存在兼容性问题。 最后,要提醒用户如果无法解决,需要联系设备制造商提供更多支持,并提供更详细的环境信息,比如系统版本、复现步骤等。确保回答结构清晰,分点列出可能的原因和解决步骤,帮助用户逐步排查问题。</think>以下是您提供的 `backtrace` 日志分析,分步骤解读关键信息: --- ### **1. 整体定位** 此日志是 **Android系统崩溃时的堆栈跟踪**(可能由系统服务或硬件驱动触发),主要涉及以下模块: - **`libc.so`**:C标准库的崩溃(如内存越界、断言失败)。 - **`libaedv.so`**:Android异常处理框架(可能用于生成错误报告)。 - **`hwcomposer.mt6768.so`**:联发科MT6768芯片的硬件显示合成器驱动。 --- ### **2. 关键堆栈帧解析** #### **#00: `abort+180`(libc.so)** - **原因**:程序主动调用 `abort()` 终止,通常由以下情况触发: - 内存越界(如堆栈溢出、缓冲区溢出)。 - `assert` 断言失败。 - 未捕获的异常。 #### **#01: `__fortify_fatal`(libc.so)** - **Fortify安全机制**:检测到内存操作违规(如 `strcpy` 未检查长度),触发致命错误。 #### **#02: `fcntl+516`(libc.so)** - **文件描述符操作**:可能尝试对无效的文件描述符(FD)进行操作(如设置非阻塞模式、加锁失败)。 #### **#03-#06: `libaedv.so` 相关函数** - **Android异常诊断服务**: - `receive_file_descriptor`:接收文件描述符(可能用于传递崩溃日志)。 - `raise_error` 和 `aee_system_report`:生成系统错误报告。 #### **#07-#09: `hwcomposer.mt6768.so`** - **硬件合成器看门狗(SWWatchDog)**: - **`onHang`**:检测到硬件合成器(HWC)响应超时。 - **`threadLoop`**:监控线程循环中检测到异常。 - **可能原因**:显示合成器未及时响应(如GPU卡死、显存不足、驱动阻塞)。 --- ### **3. 崩溃根源推测** 综合堆栈信息,**崩溃直接原因**可能是: 1. **硬件合成器(HWC)超时**:显示合成线程未在规定时间内完成操作,触发看门狗超时。 2. **内存操作违规**:`libc` 的 `fortify` 机制检测到非法内存访问(如数组越界)。 --- ### **4. 可能关联因素** | 因素 | 具体表现 | |---------------------|-------------------------------------------------------------------------| | **硬件驱动问题** | MT6768显示驱动(`hwcomposer.mt6768.so`)存在缺陷或与系统版本不兼容。 | | **系统资源不足** | 显存/内存泄漏导致合成器无法分配资源,或线程阻塞(如死锁)。 | | **第三方模块冲突** | 第三方显示服务或Overlay与硬件合成器交互异常。 | | **超时阈值不合理** | 看门狗(`SWWatchDog`)设置的超时时间过短,无法适应高负载场景。 | --- ### **5. 调试建议** #### **步骤1:检查相关日志** - **查看 `dmesg`**:确认内核层是否有显存/GPU错误(如 `GPU page fault`)。 - **搜索 `hwcomposer` 日志**:过滤 `adb logcat | grep hwcomposer`,观察超时前的操作记录。 #### **步骤2:资源监控** - **内存/显存使用**:通过 `adb shell dumpsys meminfo` 和 `adb shell dumpsys gfxinfo` 检查泄漏。 - **线程状态**:使用 `adb shell ps -t` 查看合成器线程是否阻塞(状态为 `D` 或 `S`)。 #### **步骤3:驱动更新与降级** - 联系芯片厂商(如联发科)获取更新的 `hwcomposer.mt6768.so` 驱动。 - 若为系统升级后出现,尝试回退到旧版本系统。 #### **步骤4:调整看门狗参数** - **修改超时阈值**(需内核权限): ```bash adb shell "echo 5000 > /sys/class/hwcomposer/watchdog_timeout_ms" ``` - **临时禁用看门狗**(仅调试用): ```bash adb shell "echo 0 > /sys/class/hwcomposer/enable_watchdog" ``` --- ### **6. 扩展知识:hwcomposer 的作用** - **功能**:Android硬件合成器(HWC)负责将多个图层(如状态栏、应用界面)合并输出到屏幕。 - **超时后果**:若HWC未及时完成合成,系统会触发看门狗,强制重启显示服务(SurfaceFlinger)。 --- 若需进一步分析,请提供以下信息: 1. 设备型号及Android版本。 2. 崩溃前用户操作(如启动特定应用、切换屏幕)。 3. 完整的 `dmesg` 或 `logcat` 日志。
评论 8
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值