boolean hasPrinter = false;
Looper looper = Looper.getMainLooper();
Handler handler = new Handler(looper);
looper.setMessageLogging(hasPrinter ? new Printer() {
    @Override
     public void println(String x) {

     }
} : null);
for (int i = 0; i < 10 * 10000; i++) {
    handler.post(runnable);
}

是的，之前测试过上面的代码，确实会存在内存抖动的情况，比较极端，主要还是因为这里有个字符串拼装。

if (logging != null) {
    logging.println(">>>>> Dispatching to " + msg.target + " " +  msg.callback + ": " + msg.what);
}

暂时没有想到更完美的方案。有什么好的建议吗

TraceCanary 是使用 Looper.getMainLooper().setMessageLogging() 的方式实现卡顿帧率检测的吧？为什么我看有的地方说是使用 Choreographer 的方式实现的呢？是版本差异吗

老版本是用Choreographer，现在是依赖Looper.getMainLooper().setMessageLogging()

@changelcai 这种差异的原因是？

@changelcai 能否解释下，为啥改用Looper.getMainLooper().setMessageLogging()方案； 有啥考虑呢?

@changelcai 能否解释下，为啥改用Looper.getMainLooper().setMessageLogging()方案； 有啥考虑呢?

一直没人回答，小白盲猜一下，可能有几点原因：

1. Choreographer 只是负责ui绘制部分的监听，ui卡顿不一定是绘制卡顿引起的，有可能是主线程耗时操作引起的ui卡顿，比如两次绘制之间有10个msg，Choreographer只能监听到这10个msg造成了卡顿，但是没办法定位到具体是哪个msg导致的卡顿，如果用looper来监听，就可以准确监听到是哪个msg导致的卡顿
2. 静态页面可能导致帧率较低，因此帧率低可能并不真的是卡顿，所以用这个统计出来的不是很准
3. 其次是不同设备帧率标准可能不一样，现在很多设备有120hz、90hz、60hz，模拟器有的是30hz