有谁知道常用AppFreeze使用指导

Appfreeze现在提供的主要检测能力点

Appfreeze日志主要的查看方向：

1. 

先看一下Reason是什么事件的；根据不同的Reason下面有大致的检测原理和分析样例。

2. 

关注MSG有什么信息，根据MSG的信息看一下大致的方向；

3. 

分析OpenStacktraceCatcher里面的应用栈信息，并且结合流水日志一起确定一下当前在干什么事情；

4. 

看一下PeerBinderCatcher当前进程是否有对端的binder卡住，如果有跟当前进程相关的同步wait，则会有相应的PeerBinder Stacktrace信息——这个是卡住你当前进程的对端进程的栈信息。

5. 

还有整机进程的cpu信息和当前进程的内存信息辅助定位。

三、主线程卡死检测

主要对应Appfreeze事件：THREAD_BLOCK_6S。

THREAD_BLOCK 事件分成一个3s和一个6s事件分成两个时间阶段去抓栈然后进行对比。一般是stage模型的UI线程检测。

1、THREAD_BLOCK原理

主要是通过向主线程中注入检测任务，一定时间内没有执行到移除上报故障。

2、THREAD_BLOCK日志分析

THREAD_BLOCK：是应用主线程线程响应超时，一般是stage模型的UI线程检测。

这里面有EventHandler信息。

就这份日志而言3s时候的队列和6s时候的队列数量一样，有可能EventHandler队列的第一个一直在卡着，可以结合日志看一下当前是在执行什么事情。

这份日志的name没有适配，新的EventHandler 对于没有适配name的情况会默认打上调用的地方的信息，后面建议都写上name方便定位。

这里会有一个3s的栈和6s的栈，观测两个栈的主线程。

就这份日志而言这两份栈一样，大概率是卡在这地方了，可以找一下相应的ability_manager去通过流水日志和栈信息定位。

在3s的时候有PeerBinderCatcher信息，在PeerBinderCatcher处可以看到当前进程去请求874的时候有wait发生。

相应的874是foundation进程，跟我们前面看的ability_manager相对应。可以找其定位一下。

四、生命周期切换超时检测

主要对应Appfreeze事件：

ability级别的生命周期切换超时：LIFECYCLE_TIMEOUT；

APP级别的生命周期切换超时：APP_LIFECYCLE_TIMEOUT；

1、LIFECYCLE_TIMEOUT原理

大致原理：在生命周期切换开始的时候去抛一个超时事件当整个切换流程完成之后移除这个事件，如果在一定时间内没完成移除，则上报故障。

不同生命周期对应的超时时间

2、LIFECYCLE_TIMEOUT日志分析

LIFECYCLE_TIMEOUT 

：是ability的生命周期切换超时。通过MSG发现这是切换前台时超时。

通过栈可以发现有请求media的情况，可以查看一下日志相关请求的情况是否报错和有没有响应慢的情况。

在PeerBinderCatcher处可以看到当前进程去请求5371的时候有wait发生，这里面async是异步的通信，我们默认不关心。

5371正好是media_service与前面的栈呼应上了。

3、APP_LIFECYCLE_TIMEOUT日志分析

APP_LIFECYCLE_TIMEOUT ：是app的生命周期切换超时。这份日志通过MSG发现这是在APP终止的时候超时。

通过栈可以发现都是都是ACE的栈，ACE是UI相关的情况，可以根据流水日志和ACE看相关的信息。

PeerBinderCatcher一般这种没有wait的就是在抓的时刻没有binder通信相关的卡死情况。

五、应用输入超时ANR流程

主要对应Appfreeze事件：APPLICATION_BLOCK_INPUT

1、APPLICATION_BLOCK_INPUT原理

FA模型和stage模型主要的区别在于UI是在主线程还是单独的UI线程。当前图是FA模型异步UI处理。

2、APPLICATION_BLOCK_INPUT日志分析

APPLICATION_BLOCK_INPUT：是用户输入5s没有响应相关操作，根据前面的流程一般都是input跟arkUI交互的时候作用的。

通过栈和流水日志分析，得到是哪些控件有可能超时或者没有响应。

然后可以看一下PeerBinderCatcher是否有跟你应用有关的卡死，这个例子没有。

然后这个例子主要通过栈信息和流水日志结合看。

六、UI线程卡死检测

主要对应Appfreeze事件：UI_BLOCK_6S

UI_BLOCK_6S事件分成一个3s和一个6s事件分成两个时间阶段去抓栈然后进行对比。一般是FA模型的UI线程检测。

（有些老版本里面stage模型也有UI_BLOCK_6S事件，新版本已经没有了）

1、UI_BLOCK_6S原理

大致原理：UI线程往Watchdog进行注册，然后定时向UI线程post task，task在一定时间内没有被执行会上报故障。

2、UI_BLOCK_6S日志分析

UI_BLOCK：是UI线程响应超时，可以通过MSG去查看是哪个线程超时

UI_BLOCK：有两个栈信息，一个3s栈一个6s栈，两个栈可以对比看。

就这份日志而言3s栈和6s栈都是libweb_engine在线程等待，可以根据业务和流水看一下这是卡在什么动作上了。

然后看一下PeerBinderCatcher， PeerBinderCatcher目前只有在3s时刻去抓取，在3s的时刻该应用去请求939这个进程有wait情况。

与此同时在下面会出现PeerBinder Stacktrace的栈信息。告诉你939是render_service，并且有939全部的栈信息。这时可以让939这个进程的人去分析一下。

Ps：如果栈和PeerBinder没有对应明确的信息，这时候需要通过流水日志去看当前时间是执行在哪里，然后进行相应分析。