第7章卡顿优化（下）

课程目录第7章卡顿优化（下）

卡顿优化（下）：BlockCanary原理、异步布局、线程优化、消息队列优化

上一章我们聊了卡顿的定位和基础工具。这一章，咱们深入几个实战利器。说白了，就是教你如何用代码“抓”住卡顿，然后从根源上解决它。

BlockCanary：让卡顿“无处遁形”

BlockCanary 这个名字起得好，直译就是“阻塞金丝雀”。在矿井里，金丝雀对毒气敏感，能提前预警。BlockCanary 就是 Android 主线程的“金丝雀”。

它的核心原理是什么？

其实不复杂。它利用主线程的 Looper 来监控。每次 Message 执行前后，Looper 都会回调 Printer。BlockCanary 会记录下这个时间差。如果某个 Message 执行时间超过阈值（比如 2 秒），它就认为发生了卡顿。

这时候，它会做三件事：

抓取主线程堆栈：看看卡住的时候，主线程在干什么。
记录 CPU 状态：是 CPU 忙不过来，还是在等 I/O？
输出日志：把堆栈和时间信息写到文件里。

我个人习惯在 Debug 版本里集成它。线上版本慎用，毕竟监控本身也有性能开销。我曾经在一个项目里，发现某个页面启动总是卡一下。用 BlockCanary 一抓，好家伙，堆栈指向了 SharedPreferences 的 getString() 方法。原来是在主线程读了一个几百 K 的配置文件。

核心代码示例（简化版）：

// 在 Application 中初始化
if (BuildConfig.DEBUG) {
    BlockCanary.install(this, new AppBlockCanaryContext()).start();
}

// 自定义上下文，配置阈值
public class AppBlockCanaryContext extends BlockCanaryContext {
    @Override
    public int getConfigBlockThreshold() {
        return 2000; // 2秒
    }
}

小技巧：BlockCanary 抓到的堆栈，往往不是卡顿的“根因”，而是“结果”。比如堆栈停在 View.onDraw()，那可能是布局太复杂，或者 Bitmap 解码太慢。需要结合上下文分析。

异步布局：用 AsyncLayoutInflater 解放主线程

布局加载，尤其是复杂的 XML 解析和 View 创建，是主线程的“重量级选手”。AsyncLayoutInflater 就是来解决这个问题的。

它的用法很简单：

AsyncLayoutInflater inflater = new AsyncLayoutInflater(context);
inflater.inflate(R.layout.activity_main, parent, new AsyncLayoutInflater.OnInflateFinishedListener() {
    @Override
    public void onInflateFinished(@NonNull View view, int resid, @Nullable ViewGroup parent) {
        // 回到主线程，可以操作 View 了
        setContentView(view);
        // 初始化控件...
    }
});

注意几个坑：

异步加载期间，不能操作 View。因为 View 还没创建好。
回调是在主线程执行的。所以回调里的逻辑要轻量。
它不支持 Fragment 的布局加载。Fragment 的 onCreateView 还是得在主线程。

我记得有一次优化一个列表页。列表项布局嵌套了 5 层，每个 Item 加载要 15ms。用 AsyncLayoutInflater 预加载了下一页的 Item，滑动流畅度提升很明显。说白了，就是把“未来”的工作提前做了。

警告：不要滥用异步布局。如果布局本身很简单（比如只有一个 TextView），异步的开销反而更大。它适合那些“重布局”的场景。

线程优化：别让线程“打架”

线程优化，核心就两件事：减少线程数 和 合理调度。

1. 线程池代替 new Thread

你想想看，每个 new Thread 都会创建一个操作系统线程。线程多了，CPU 光切换上下文就忙不过来了。用线程池可以复用线程，控制并发数。

// 一个合理的线程池配置
ExecutorService executor = new ThreadPoolExecutor(
    2, // 核心线程数
    4, // 最大线程数
    60L, TimeUnit.SECONDS, // 空闲线程存活时间
    new LinkedBlockingQueue<Runnable>(128), // 任务队列
    new ThreadFactory() {
        @Override
        public Thread newThread(Runnable r) {
            Thread t = new Thread(r, "my-task-thread");
            t.setPriority(Thread.NORM_PRIORITY - 1); // 降低优先级
            return t;
        }
    }
);

2. 区分任务类型

CPU 密集型任务（比如图片压缩），线程数最好等于 CPU 核心数。I/O 密集型任务（比如网络请求），线程数可以多一些，因为线程大部分时间在等待。

3. 避免线程饥饿

我曾经遇到过一个 Bug：App 启动后，某个功能一直没反应。查了半天，发现是一个后台线程池的核心线程数设成了 1，而且这个线程被一个死循环占用了。所有任务都在排队，活活饿死了。嗯，这里要注意，线程池的 RejectedExecutionHandler 也要配置好，防止任务被丢弃。

消息队列优化：让主线程“喘口气”

主线程的消息队列，就像一个待办事项列表。如果列表太长，或者某个事项太耗时，UI 就会卡顿。

优化思路一：减少消息数量

比如 View.post() 和 Handler.post()，能少用就少用。特别是循环里 post 的，要检查一下是不是必要的。

优化思路二：拆分耗时消息

如果一个消息执行时间超过 16ms，就要考虑拆分了。比如加载一个列表，不要一次性加载 100 条数据并全部渲染。可以分批次加载，每批 10 条，用 Handler.postDelayed() 间隔 16ms 发送。

// 分批次加载示例
private void loadBatch(final List<Data> dataList, final int index) {
    if (index >= dataList.size()) return;
    int end = Math.min(index + 10, dataList.size());
    for (int i = index; i < end; i++) {
        // 渲染一条数据
        addItem(dataList.get(i));
    }
    // 16ms 后加载下一批
    mHandler.postDelayed(new Runnable() {
        @Override
        public void run() {
            loadBatch(dataList, end);
        }
    }, 16);
}

优化思路三：使用 IdleHandler

IdleHandler 是消息队列的一个“空闲回调”。当主线程没有消息要处理时，就会执行它。适合做那些“不着急”的任务，比如预加载、日志上报。

Looper.myQueue().addIdleHandler(new MessageQueue.IdleHandler() {
    @Override
    public boolean queueIdle() {
        // 主线程空闲时执行
        preloadNextPageData();
        // 返回 false 表示只执行一次
        return false;
    }
});

我个人觉得，IdleHandler 是个被低估的 API。很多“延迟初始化”的工作都可以用它来做，既不影响首屏加载，又能利用空闲时间。

知识体系总览

下面这张图，把本章的核心知识点串了起来。你可以看到，卡顿优化是一个从“监控”到“解决”的闭环。

这一章的内容就到这里。记住，卡顿优化没有银弹。BlockCanary 帮你发现问题，异步布局和线程优化帮你解决问题，消息队列优化帮你预防问题。把这些工具用好，你的 App 就能流畅不少。

📚 课程目录

卡顿优化（下）：BlockCanary原理、异步布局、线程优化、消息队列优化

BlockCanary：让卡顿“无处遁形”

异步布局：用 AsyncLayoutInflater 解放主线程

线程优化：别让线程“打架”

消息队列优化：让主线程“喘口气”

知识体系总览