卡顿检测方法：掉帧、耗时、内存泄漏

做安全UI卡顿分析，第一步不是优化，而是找问题在哪。我刚开始带团队时，大家一碰上卡顿就凭感觉猜：是不是动画太复杂？是不是数据量太大？结果修来修去，根源根本没找到。后来我总结了一套检测三板斧——掉帧、耗时、内存泄漏。这三件事搞清楚了，卡顿原因基本就浮出水面。

掉帧检测：盯着屏幕刷新的节奏

掉帧，说白了就是屏幕该刷新的时候没刷新。Android系统每一帧有16.6ms的绘制时间窗口（60fps），超过这个时间就会跳帧。我习惯用Choreographer来抓掉帧数据，它每帧都会回调一个时间戳，对比一下就知道了。

// 使用Choreographer检测掉帧
Choreographer.getInstance().postFrameCallback(new Choreographer.FrameCallback() {
    long lastFrameTime = 0;
    @Override
    public void doFrame(long frameTimeNanos) {
        if (lastFrameTime != 0) {
            long diff = (frameTimeNanos - lastFrameTime) / 1000000; // 转为毫秒
            if (diff > 16.6f) {
                Log.w("JankDetect", "掉帧： " + diff + "ms");
            }
        }
        lastFrameTime = frameTimeNanos;
        Choreographer.getInstance().postFrameCallback(this);
    }
});

为什么用Choreographer？因为它直接监听Vsync信号，比手动打点更准确。嗯，注意要在主线程注册，并且及时取消，否则会导致泄漏。

耗时检测：揪出锁住UI的元凶

掉帧只是结果，耗时才是原因。我常遇到的情况是：某个安全操作（比如加密一段数据）直接在主线程里执行，瞬间卡个几百毫秒。检测方法很简单——用Trace打标签，配合systrace或Perfetto工具。

我在一个金融App里排查过：每次点击「加密发送」按钮，界面就僵住半秒。用Trace一抓，发现里面有个doFinal()调用占了300ms。我当时的反应是：「这种活儿怎么能放主线程？」后来改成协程+线程池，卡顿立刻消失。

// 使用Trace标记耗时操作
Trace.beginSection("EncryptOperation");
try {
    byte[] encrypted = cipher.doFinal(plainText);
} finally {
    Trace.endSection();
}
// 然后通过systrace采集，直接看CPU time

内存泄漏检测：看不见的慢性杀手

掉帧和耗时往往是一次性的，但内存泄漏会让你越用越卡。我曾经维护过一个老项目，每次打开安全键盘后退出，内存就涨一点，反复操作几次直接OOM。查了半天，发现是加密上下文(Cipher)对象被匿名内部类持有了Activity引用。

检测手段三个：LeakCanary（自动检测）、Android Profiler（手动快照）、Dump Heap（深挖引用链）。我最常用LeakCanary，集成简单，捕获后直接给出泄漏路径。

综合检测流程：一张图说清楚

这三件事不是孤立的。我建议的流程是：先用掉帧检测定位到「卡顿发生的界面和时机」，然后用耗时检测找到「具体哪个函数拖了后腿」，最后用内存泄漏检测确认「是不是有对象持续占着资源」。下面这张图总结了整个逻辑：

我自己的经验是：不要只依赖一种检测手段。比如掉帧检测只能告诉你「这里卡了」，但耗时检测才能告诉你「是加密函数慢还是动画重绘慢」。内存泄漏则是隐形的，可能你开了10次安全键盘才卡，不用LeakCanary很难发现。

好了，这一章我们就把检测方法讲清楚了。你想想看，如果你的App里也遇到了安全UI卡顿，是不是可以按这三步走一遍？