黑屏定屏那些事 - 系统机制，分析套路和实战（系统篇）

本文发表于内核工匠公众号，旨在给内核开发的小伙伴分享：

• Android系统层面用户UI交互的设计，从而理解手机黑屏定屏时背后的故事。
• Android系统对黑屏定屏类问题的维测思路，有那些先进的思想，有那些改进的空间。

如果读者恰好有一定的Android系统框架知识，可以直奔每一章节的“重难点以及思考”部分。在写作的过程中也发现，互联网上系统性梳理Android黑屏定屏问题的技术文章不多，借此机会也做一下黑屏定屏的系统性梳理。 不同于跑在后台服务器的Linux商用系统，Android是一个面向亿万消费者的手机操作系统，虽然也是基于Linux，但是，UI交互才是Android的核心，一切都是为了用户体验。

问题背景，项目现状

Android手机用户吐槽分布，黑屏定屏类问题（卡死）占了大部分，是最影响用户体验的TOP问题之一。

黑屏定屏类问题（卡死）一直以来是项目的重点，难点，痛点

黑屏问题分类（部分）

一、黑屏定屏分析-系统机制

1. APP UI**绘制流程**

(1) Choreographer

① 为什么需要VSync？

VSync最初是由 GPU 厂商开发的一种，用于防止屏幕撕裂的技术方案，全称 Vertical Synchronization，该方案很早就已经被广泛应用于 PC 上。我们可以把它理解为一种时钟中断。想要画面流畅显示，刷新频率（Display）和帧率(GPU)需要保持同步。

② Choreographer**是VSync机制的Android实现**

Choreographer是线程单例的。且当前线程要有 Looper，Choreographer 实例化的时候需要传入。所以默认只有UI主线程才带有这个类。

（2）透过Systrace看APP UI绘制流程

VSync信号到了，App才可以开始绘制，如下：

VSync信号到了，SurfaceFlinger才可以开始绘制，如下：

（3）掉帧监控实现

掉帧监控核心思路为，实际绘帧的时间 – 预期绘帧的时间 >一个时钟周期即判定为掉帧。

想去监控系统和自身App掉帧，都可以从这里入手实现。

对应Android核心代码如下，这段代码跑在App UI主线程里面。

https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/view/Choreographer.java#727

(4) 重难点以及思考

VSync信号到了，App才可以开始绘制。那么，VSync信号到了，App就一定会立即执行绘制吗？（重要）

请看看下面这份systrace，明显的定屏卡死。

2. Android ANR

（1）ANR 设计原理

ANR 全称 Application Not Response；Android 设计 ANR 的用意，是系统通过与之交互的组件(Activity，Service，Receiver，Provider)以及用户交互(Input Event)进行超时监控，以判断App进程(主线程)是否存在卡死或响应过慢的问题。

（2） 组件超时分类

系统在通过 Binder 通信向App进程发送上述组件消息或 Input 事件时，在 AMS 或 Input 服务端同时设置一个异步超时监控。针对不同类型事件，设置的超时时长也存在差别，以下是 Android 系统对不同类型的超时阈值设置（默认，各厂商可能修改）：

① Input**超时原理举例**

② Services**启动超时原理举例**

③ Broadcast**超时原理举例**

④ Android ANR**监控机制扩展**

新增ANR类型，窗口切换无焦点监控触发ANR。

（4）重难点以及思考

• Input timeout类型的ANR，还有几种子类型？

No Focus Window01-0211:14:11.223043829848 I am_anr: [0,28512,com.mediatek.camera,953728069,Inputdispatching timed out (Waiting becausenowindow has focusbut there is a focused application that may eventually add awindow when it finishes starting up.)] Waiting Previous Key01-0103:39:02.822866895 I am_anr: [0,17699,com.android.music,411614821,Inputdispatching timed out (Waiting to send key eventbecausethe focused window has not finished processing all of the input events thatwere previously delivered to it.Outbound queuelength:0.Wait queue length: 3.)] 谷歌设计 bg ANR的出发点是什么？一般情况下对用户前台使用无影响。（开放性问题）

1. System server Watchdog

(1) System server Watchdog**业务实现**

System Server中通过Watchdog来检测UI、IO、Fg等线程是否会阻塞 , 也可以检测核心服务（如AMS，WMS，Package等）是否发生死锁。在System Server启动系统服务后 , 初始化Watchdog , 并且启动Watchdog线程。

初始化Watchdog线程时 , 会启动以下线程 , 包含三类任务 :

• 检测线程Looper是否阻塞(IO任务等) ，一般是通过post一个消息的方式。
• 检测服务是否阻塞 (IMS、AMS等) ，一般是通过获取一下服务的持锁。
• watchdog里面是android.fg负责监控ss binder是否耗尽的。是众多handler checker列表之一。（重要）

Watchdog里面维护了一个HandlerChecker数组，对所有对象的监控都是透过一个个HandlerChecker，这个HandlerChecker里面又可以添加若干Monitors，具体每一次检测实际通过调用这些Monitors达成。Watchdog检测的核心业务流程如下

核心代码如下https://android.googlesource.com/platform/frameworks/base/+/refs/heads/master/services/core/java/com/android/server/Watchdog.java#610

HandlerChecker里面有一个重要成员变量mCompleted，用来标记每次检测的完成情况，如下

核心代码如下

https://android.googlesource.com/platform/frameworks/base/+/refs/heads/master/services/core/java/com/android/server/Watchdog.java#228

(2) 重难点以及思考

• Half watchdog监控（30s），也要重视起来，告警。

如果system server 的 watchdog子线程自身卡死了，又该怎么办？（重要）

4. Message handler**机制**

（1）Message handler**架构实现**

• Handler : Handler 主要是用来处理 Message，App可以在任何线程创建 Handler，只要在创建的时候指定对应的 Looper 即可，如果不指定，默认是在当前 Thread 对应的 Looper。

• Looper : Looper 可以看成是一个循环器，其 loop 方法开启后，不断地从 MessageQueue 中获取 Message，对 Message 进行 Delivery 和 Dispatch，最终发给对应的 Handler 去处理。

• MessageQueue：MessageQueue 就是一个 Message 管理器，队列中是 Message，在没有 Message 的时候，MessageQueue 借助 Linux 的 ePoll 机制，阻塞休眠等待，直到有 Message 进入队列将其唤醒。

• Message：Message 是传递消息的对象，其内部包含了要传递的内容，最常用的包括 what、arg、callback 等。

• Looper上面挂的Handler可以有多个。Message和Callback都会进入消息队列。

  Looper里面循环获取下一条消息的核心代码，如下，

  https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/os/Looper.java#161

  

  (2) 日志里面看消息队列超时

  

  解析关键消息耗时打印日志，如下

  这个消息执行用了5961 ms，在App 的UI主线程一个消息执行这么久，就要重点怀疑了。此类执行耗时在技术层面有可能触发ANR，在用户层面一般会发生短时间卡死。

  10-2308:58:35.921655 10519 10519 E ANR_LOG : Blockedmsg = {when=-5s961ms what=159 target=android.App. ActivityThread$Hobj=ClientTransaction TopResumedActivityChangeItem,} cost = 5961 ms 日志解读 cost （重要）：消息本身执行用了多久。 计算msg.target.dispatchMessage(msg)的执行时间。如下 https://android.googlesource.com/platform/frameworks/base/+/master/cor e/java/android/os/Looper.java#201

When（重要）：

如果when=0就表示这条message是在期望的时间去执行的，没有被延迟执行，如果是when为负值表示没有在期望的值执行，延迟执行了，一般是前面有耗时的message挤压导致的。

计算公式，msg.when （消息设置的期望被执行时间）- now （消息实际执行时间）

What：消息的类型，如果是message类型，就是handleMessage里面的各个case。如果是callback类型，这个值一般为0。

Target：消息被Looper分发到的目的地。一般是各个handler，message创建的时候传入。

（3）重难点以及思考

现在的消息耗时监控机制有何弊端？（重要）

举例，如下发生ANR时候报告的当前执行消息，并不是真正耗时长的消息。

5. Input**子系统**

(1) Input**子系统业务流程全景**

Input子系统软件设计层级架构，如下

Input事件数据流向图，如下

(2) 通过systrace看Input业务流程

System Sever侧

例如如下，就发生了iq堆积，用户感受就是点不动。

App侧

(3) 重难点以及思考

• 是不是所有发到App头上的input事件，都会加入到App主线程的MessageQueue里面去处理？（重要）

input事件的处理不一定都会加入到Looper消息里面,有一些在poll的时候，JNI里面处理了,详情参考NativeInputEventReceiver实现。

• Input timeout ANR监控，是否能够覆盖input事件处理全流程？

不能，从TP中断事件到系统框架阶段，监控不到。App收到该Input事件后进行自定义处理，也监控不到。

6. 窗口管理服务（WMS）

本节并不重点介绍窗口管理服务（WMS）业务本身，而是重点说明窗口管理服务（WMS）在App UI显示过程做的事情，服务于我们的主题：黑屏定屏问题的业务梳理。

（1）APP UI**显示流程中的窗口管理服务**

预备知识，App生命周期

不同于老的Android版本，现在版本的App生命周期由WMS来维护。

预备知识，App端和WMS的交互。本质还是binder call实现，如下

(2) 无焦点窗口

为什么要重点关注无焦点窗口类问题？因为此类问题一直是黑屏定屏的TOP问题，上一节预备知识，也是为了服务于说明该问题。

添加窗口业务流程如下，先AddView，然后再updateView

上图中 (2) 步执行完成，WMS端窗口可以获得焦点；图中 (3) 步执行完成，inputflinger可以获得焦点（此时input ANR监控会取消）。可以获得焦点并不是说一定会有焦点，因为请求size为0时候还是没有焦点的。

systrace里面呈现，请结合1.1.1.2章节App UI显示流程配合使用。

App的onResume调用完成之后会在eventlog中打印wm_on_resume_called，然后界面进行Relayout Window，其中包含了performSurfacePlacement刷新界面和更新焦点updateFocusedWindow（会从top到bottom遍历canReciveKey为true的界面），将焦点切换到新的上面，此时WMS的windowstate已经获取了焦点，将window state状态往SurfaceFlinger传递，在SurfaceFlinger中传入InputDispatcher将ANR超时时间重置。

跟踪一下窗口刷新的关键堆栈，

ViewRootImpl.performTraversals -->

ViewRootImpl.scheduleTraversals-->

ViewRootImpl.mTraversalRunnable.run -->

ViewRootImpl.doTraversal -->

ViewRootImpl.performTraversals -->

ViewRootImpl.relayoutWindow -->

Session.relayout -->

WindowManagerService.relayoutWindow{

1.updateFocusedWindowLocked//更新焦点

2.performSurfacePlacement//刷新界面

}

窗口焦点切换核心业务在updateFocusedWindowLocked方法里面，关键代码，

https://android.googlesource.com/platform/frameworks/base/+/master/services/core/java/com/android/server/wm/DisplayContent.java#3564

updateFocusedWindowLocked的设计含义是，WMS准备绘制该窗口了，所以先把焦点给到该窗口头上，WMS侧给Input侧同步一次当前系统的焦点变化信息。

(3) 重难点以及思考

焦点成功切换到新窗口，发生如下打印，

WindowManager:Changing focus from null to Window{新窗口}

是否就意味着该窗口可以参与用户UI交互了？（重要）

参考楼上无焦点窗口一节，可以得到答案。

7. 小结

Android黑屏定屏类问题是影响用户体验的TOP问题，一直是各项目的重点，难点和痛点。但也一直缺乏系统性梳理，互联网上这方面专业性，成体系的技术文章不多。本文从Android系统框架业务实现，技术架构，技术重难点解读三个维度，由浅入深，先业务介绍，再代码呈现，期间穿插Systrace和日志的直接实操动作，每个章节最后的“重难点以及思考”，更是把对业务和架构设计的思考进行升华。其实这些重点和思考，都是项目开发和工程实践中多次踩过的坑，尤其值得重视。希望不同知识基础的读者，能够各取所需，对Android黑屏定屏问题，有一个系统性的认识。

本文重点在于系统业务和架构实现的赋能，后续会呈现黑屏定屏这块更多套路打法和实战，敬请期待。

参考文档

https://zhuanlan.zhihu.com/p/183707752

https://blog.csdn.net/lixiong0713/article/details/111928413

https://www.jianshu.com/p/996bca12eb1d

https://source.android.google.cn/devices/tech/debug/systrace?hl=zh-cn

https://mp.weixin.qq.com/s/ApNSEWxQdM19QoCNijagtg

https://mp.weixin.qq.com/s/fWoXprt2TFL1tTapt7esYg

https://www.jianshu.com/p/5e8c0cb1a58e

https://www.jianshu.com/p/4de667937d98

https://blog.csdn.net/XuJiaoJie/article/details/79094392

https://blog.csdn.net/qq_24531461/article/details/83657773

https://mp.weixin.qq.com/s/ApNSEWxQdM19QoCNijagtg

https://mp.weixin.qq.com/s/_Z6GdGRVWq-_JXf5Fs6fsw

https://baijiahao.baidu.com/s?id=1716273243946679911&wfr=spider&for=pc

https://www.jianshu.com/p/b3a1ea7923e7

https://www.jianshu.com/p/6c8dec7d6c21

https://blog.csdn.net/yun_hen/article/details/78428767

https://blog.csdn.net/chi_wy/article/details/111473959

https://blog.csdn.net/ff5102154/article/details/71519723