ANR高级经验2:No Focused Window类型ANR的各种案例汇总

背景

在上一篇关于NO Focused ANR相关详细指导分析文章
ANR高级经验分享：No Focused类型ANR详细步骤

发布后的得到广大网友的一致好评，还有许多大厂的技术Leader也帮忙转发，所以接着上一篇文章继续来分享一些公司里面实战分析过的这类No Focused ANR的案例，希望各位vip学员有了这些案例后可以加快大家对这类疑难ANR的分析定位。
这类ANR问题的分析方法和案例在马哥课程和相关blog有进行讲解，大概方法汇总如下：
events日志分析部分
dumpsys SF中焦点窗口显示情况
dumpsys window中焦点窗口是否计算正常
检查应用生命周期，看是窗口否显示
检查其他性能卡顿相关日志

平时马哥也是基于上面的方法去分析对应的No Focused Window ANR问题，在工作过程中其实遇到的No Focused ANR其实也是非常非常多的类型，绝不是简单的一两种案例那么简单哈，在工作中积累了这块的ANR类型应该有多达20+种不同原因和类型，当然这里的20+种也不代表真的全部覆盖，只是这里提供给大家一些处理的经验，应该也可以覆盖%90以上的No Focused Window ANR问题。

Not Focused Window类型ANR各种案例汇总

有焦点Activity没有焦点Window （最常见的类型）

这里主要又可以分为2类，一类是dumpsys window发现对应的DRAW_STATE不正常，一类是DRAW_STATE正常，但是焦点计算异常。

窗口状态异常

DRAW_STATE处于NO_SURFACE状态

一般这种应用没有创建窗口绘制内容的的SurfaceControl或销毁了窗口，比如从app是否调用wms的relayout等情况去排查。

DRAW_STATE处于DRAW_PENDING状态
应用在绘制前卡住，或拦截了绘制，这块主要排查app的draw方法相关执行分析为啥卡住

还有一种是因为app自身有GlSurfaceView，触发多线程同步问题

DRAW_STATE处于COMMIT_DRAW_PENDING状态

这类COMMIT_DRAW_PENDING问题，一般就说明当前的app已经绘制完成，但system_server层面出现一些逻辑等异常，导致没有把这个STATE变成READY_TO_SHOW。
所以一般这种情况都是由wms显示框架工程师进行排查进一步原因，以前也遇过案例就是
公司相关业务人员框架修改导致deferLayout后没有调用continueLayout影响WMS流程（分屏、小窗曾导致）。

DRAW_STATE处于READY_TO_SHOW
状态
这种问题也是一样，一般由wms显示框架工程师进行排查进一步原因，虽然最后原因不一定systemserver的，以前也遇过案例就是

属于同一个Activity的多个窗口，有一个没完成绘制，这种最经典就是桌面有负一屏时候，负一屏是一个独立的Window，一般这个Window还是其他app进行绘制。
也有activity过渡动画超时，查出原生bug，时序问题。

窗口焦点计算后无法焦点

这种一般主要到窗口焦点计算地方进行打印和调试追查原因，看一下是啥原因会导致最后没有焦点。
具体案例比如：应用窗口属性设置错误，或者有一些框架需求修改了焦点计算逻辑导致。

SurfaceFlinger中发现焦点窗口不显示

因为最后焦点的设置是要InputDispatcher中识别有就是有，但是InputDispatcher数据又是从SF中进行的设置，不是以前的WMS直接设置，所以你如发现出现ANR时候发现dumpsys window等都正常，但dumpsys input就是没有焦点窗口，那么就需要考虑到SF中进行排查。
这块也有遇到相关案例：
0大小窗口（创建一个大小为0的PopupWindow），导致实际不显示
窗口被遮挡（第三方应用创建一个有焦点的窗口，但位于屏幕之外）

InputDispatcher自身原生逻辑有bug

在SF阶段也排查发现焦点图层窗口正常后，但InputDispatcher还是没有对应焦点窗口，这个时候，大家可以可以去input源码中进行排查，也有遇到过input中对于这块焦点变化处理有时序问题的情况。
比如：
应用界面显示较晚，input中并发时序问题，焦点窗口设置后未触发再次计算

其他

上面No Focused Window ANR是一些可以归类的都归类了，也有很多是不可以归类的：

具体有如下一些案例：

底层问题导致Render线程卡住，绘制耗时

锁屏逻辑异常，导致锁屏时，应用可见可操作

一些公司的性能优化策略，导致Activity启动被拦截，上一个Activity报ANR

第三方频繁crash，导致框架卡顿

CPU调度策略限核，导致算力不足，导致应用和框架都耗时

原文地址：
https://mp.weixin.qq.com/s/siXDo1qEZTCyql2F0RmZnA

更多framework手把手教你实战干货，请关注下面“千里马学框架”