在前面我们总结了
终于迎来了最后一期版本发布
技术理论源自于：
引入：
implementation 'io.github.xiaolutang:BlockMoonlightTreasureBox:1.0.0'月光宝盒的初始化分为两个部分
- BlcokMonitor初始化
- native监听初始化
//BlcokMonitor 初始化最主要是提供一个 BlockBoxConfig
BlockMonitorFace.init(this)
.updateConfig(new BlockBoxConfig.Builder()
.useAnalyze(true)
.build())
.startMonitor();
//注册native监听 SIGNAL QUIT 信号
SystemAnrMonitor.init(BlockMonitorFace.getBlockMonitorFace());
发出警告信息，并且将主线程的消息独立出来进行聚合
setGapTime: 当主线程处于idel状态超过这个时间后，将生成一条gap信息。如果处于idel状态小于该值则不做单独处理
**setAnrTime:**当主线程消息分发超过这个时间，则判定发生anr
setJankFrame: 可以简单的理解成当View绘制的三大流程耗时超过多少帧就发出警告。 详细逻辑参考：app卡顿系列四 ：今日头条卡顿监控方案落地
**useAnalyze:**是否在桌面生成分析的应用图标。典型的场景是测试版本可以生成，release版本不需要
addAnrSampleListener: 添加监听anr信息。很多ANR的文件都发生在线上，如果只有离线的anr日志，明显不利于我们分析ANR,因此提供了这个接口。
改接口接收的是一个 IAnrSamplerListener
/**
* 区别于ISampleListener 专门采集anr 信息的回调
*/
public interface IAnrSamplerListener extends IMainThreadSampleListener {
/**
* 收集消息队列中未处理的消息
*/
void onMessageQueueSample(long baseTime, String msgId, String msg);
void onCpuSample(long baseTime, String msgId, String msg);
void onMemorySample(long baseTime, String msgId, String msg);
void onMainThreadStackSample(long baseTime, String msgId, String msg);
}
/**
* 这些方法调用都在主线程
* 注意不要搞耗时操作
*/
public interface IMainThreadSampleListener {
/**
* 当前主线程的调度能力
*
* @param start true 发起本次调度 false结束
*/
void onScheduledSample(boolean start, long baseTime, String msgId, long dealt);
/**
* 采集消息队列每次处理的消息 当消息类型是anr的时候，调用者不是主线程
*/
void onMsgSample(long baseTime, String msgId, MessageInfo msg);
void onJankSample(String msgId, MessageInfo msg);
/**
* 消息队列中发生anr的消息已经处理完毕
* */
void messageQueueDispatchAnrFinish();
void onSampleAnrMsg();
}其中需要特别注意的是onSampleAnrMsg和messageQueueDispatchAnrFinish 。 onSampleAnrMsg 意味着接收到了ANR消息，此时可以将相关的信息保存起来（如果后面没有messageQueueDispatchAnrFinish消息，可以用这个作为分析的依据）。当接收到messageQueueDispatchAnrFinish意味着本次ANR消息采集结束。
系统ANR的是通过SIGNAL QUIT信号来进行监听，而这里我们通过自己的注册来代替系统的监听，在消息处理完成后又将信号返还给系统。
但是月光宝盒的定位是对于ANR的消息的补足，为了和其它的一些通过监听SIGNAL QUIT信号来处理ANR的框架兼容，这里通过
SystemAnrMonitor.init(BlockMonitorFace.getBlockMonitorFace())来注册通知BlockMonitor接收到了ANR消息。
public class SystemAnrMonitor {
static {
System.loadLibrary("block_signal");
}
private native void hookSignalCatcher(ISystemAnrObserver observed);
private native void unHookSignalCatcher();
public static void init(ISystemAnrObserver systemAnrObserver){
new SystemAnrMonitor().hookSignalCatcher(systemAnrObserver);
}
}
public interface ISystemAnrObserver {
void onSystemAnr();
}如果使用其它的框架，只需要在监听到系统ANR的时候调用onSystemAnr即可。
虽然IAnrSamplerListener有CPU和Memory信息的收集回调，但是月光宝盒并没有做对应的实现，因为月光宝盒做的是对系统ANR信息的补足，而不是对应的替代。当系统发生ANR的时候配合系统的信息和月光宝盒收集的信息更加方便的分析ANR。
参考项目Test模块，主要测试了三个内容
我们在View的draw方法中休眠500ms来观察日志
@Override
public void draw(Canvas canvas) {
super.draw(canvas);
long start = SystemClock.elapsedRealtime();
if(jank){
SystemClock.sleep(500);
}
long end = SystemClock.elapsedRealtime();
Log.d("JankView","BlockMonitor start "+start + " end "+end + " "+(end - start));
}日志信息：
我们先给消息队列发送一个长耗时的，runnable，然后发送一个前台广播进行测试。最终我们发现产生了两条ANR记录
原因是消息队列的处理某个消息的时候，我们自己先发现ANR 接着、月光宝盒或者是系统触发了ANR结束消息。因为这个结束有两次触发，因此产生了两条消息。
可以看到，发生anr是当前处理消息耗时 wallTime = 10727ms 通过android.os.Hander的实例对象进行消息发送，其中callback为MainActivity中的内部类，消息队列中还有两个消息等待处理，耗时堆栈命中Thread.sleep
第二个日志就不在这个位置进行分析了，因为第一个日志将收集到的信息使用了，第二个没有太多的可用信息，但是通过主线程Looper一旦发现某个主线程任务耗时超过指定ANR时间(默认3s),那么这个方法一定时应该优先被处理的。
我们通过给主线程发送较多的比较耗时的任务，以此来模拟主线程消息队列繁忙
findViewById(R.id.tvTestAnr2).setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
//发送多个不是非常严重耗时消息，模拟消息队列繁忙
for (int i=25;i>0;i--){
mainHandler.post(new Runnable() {
@Override
public void run() {
//500ms
SystemClock.sleep(500);
}
});
}
AnrTestBroadcast.sentBroadcast(MainActivity.this);
}
});结果分析：
这个也就反应了，很多时候可能明明我们没有进行耗时操作，但是从系统侧却发生了ANR。
这个不是太好模拟
参考BlockBoxConfig#Builder
