第20章性能优化

课程目录第20章性能优化

20、性能优化：布局层级优化、内存泄漏检测与卡顿分析

性能优化这个话题，说实话，是Android开发里最绕不开的坎儿。尤其是TV端和大屏设备，屏幕大、分辨率高，用户对流畅度的容忍度反而更低。你想想看，一个4K电视上，界面卡顿一下，那感觉就像在看幻灯片。

我个人习惯把性能优化分成三个层面：布局、内存、卡顿。这三个问题往往互相纠缠，但解决思路各有侧重。今天咱们就一个一个掰开揉碎了讲。

布局层级优化：少即是多

布局层级优化，说白了就是让View树变浅。为什么？因为Android的绘制流程是深度优先遍历，每多一层嵌套，就多一次measure和layout的计算。在大屏上，这种开销会被放大。

我在项目中遇到过这样一个案例：一个TV主界面，用LinearLayout嵌套了七八层，结果在4K分辨率下，页面加载要等两秒多。后来用ConstraintLayout重写，层级从8层降到3层，加载时间直接砍到600毫秒。

  核心原则：能用ConstraintLayout解决的，就别用多层嵌套。能用RelativeLayout解决的，就别用LinearLayout。

具体怎么做？我总结了几个实战技巧：

使用ConstraintLayout：它用扁平结构替代了多层嵌套。一个ConstraintLayout可以搞定以前需要三四个LinearLayout才能实现的布局。
ViewStub延迟加载：有些布局不是一开始就需要显示的，比如弹窗、详情面板。用ViewStub占位，等需要时再inflate，能减少首屏渲染压力。
Merge标签：当你用include引入布局时，如果父布局是FrameLayout或LinearLayout，可以用merge标签去掉多余的根节点。
避免过度绘制：在开发者选项里打开「显示过度绘制区域」，红色区域越多，说明性能越差。常见的优化手段是去掉不必要的背景色。

// 一个典型的优化案例：用ConstraintLayout替代多层嵌套
// 优化前：LinearLayout嵌套了4层
<LinearLayout>
    <LinearLayout>
        <TextView />
        <LinearLayout>
            <ImageView />
            <TextView />
        </LinearLayout>
    </LinearLayout>
</LinearLayout>

// 优化后：一个ConstraintLayout搞定
<androidx.constraintlayout.widget.ConstraintLayout>
    <TextView app:layout_constraintTop_toTopOf="parent" />
    <ImageView app:layout_constraintTop_toBottomOf="@id/textView" />
    <TextView app:layout_constraintTop_toBottomOf="@id/textView" />
</androidx.constraintlayout.widget.ConstraintLayout>

小技巧：在Android Studio里，可以用Layout Inspector查看当前页面的View树深度。如果超过5层，就该考虑优化了。

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

内存泄漏这东西，平时不声不响，等用户用久了，突然卡顿、闪退，你才知道出事了。尤其是在TV设备上，内存本来就比手机紧张，泄漏一点就很容易触发OOM。

我曾经在一个TV项目里，发现用户连续换台20分钟后，应用必崩。查了半天，原来是某个Fragment在销毁时没有取消网络请求的回调，导致Activity一直被持有。嗯，这种坑踩过一次就记住了。

常见的泄漏场景，我列了个表：

泄漏场景	原因	解决方案
静态变量持有Activity	单例或静态集合中保存了Activity引用	使用ApplicationContext，或用弱引用
匿名内部类	匿名Runnable持有外部类引用	改为静态内部类+弱引用
Handler未清理	Handler中的Message持有Activity引用	在onDestroy中移除所有回调
未取消的注册	BroadcastReceiver、观察者模式未解注册	在onDestroy中取消注册
资源未关闭	Cursor、FileInputStream等未关闭	使用try-with-resources或finally块

检测工具方面，我强烈推荐LeakCanary。它能在内存泄漏发生时自动弹出通知，告诉你哪个对象泄漏了、引用链是什么。集成方式很简单：

// 在build.gradle中添加依赖
debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.12'

// 然后什么都不用做，LeakCanary会自动初始化
// 当发生泄漏时，通知栏会弹出提示

注意：LeakCanary只应该在debug版本中使用。release版本一定要排除掉，否则会影响性能。

卡顿分析：找到掉帧的元凶

卡顿的本质是什么？说白了就是掉帧。Android要求每16.6ms完成一帧的绘制，如果超过这个时间，用户就会感觉到卡顿。在大屏上，这个阈值更敏感，因为画面大，任何微小的抖动都会被放大。

我习惯用Systrace来分析卡顿。它能精确地告诉你每一帧里，CPU、GPU、渲染管线都在干什么。具体操作步骤：

打开开发者选项，开启「GPU渲染模式分析」
用adb命令抓取trace文件：adb shell atrace --async_start -b 16000 gfx input view
操作应用，模拟卡顿场景
停止抓取：adb shell atrace --async_stop -z > trace_output.atrace
用Chrome浏览器打开chrome://tracing，加载trace文件

分析时重点关注几个指标：

Frame的生命周期：如果一帧的绘制时间超过16.6ms，就是掉帧
主线程耗时：看有没有长时间占用主线程的操作，比如网络请求、大文件读写
布局渲染：measure/layout/draw三个阶段，哪个阶段耗时最长
过度绘制：同一像素被绘制多次，浪费GPU资源

  实战经验：我在一个TV直播应用里发现，每次切换频道时都会卡顿300ms。用Systrace一查，原来是切换频道时在主线程里做了大量的字符串拼接和JSON解析。后来把这些操作丢到子线程，卡顿直接消失了。

除了Systrace，还有几个工具也很有用：

Profiler：Android Studio自带的性能分析工具，可以实时查看CPU、内存、网络
BlockCanary：检测主线程卡顿的开源库，能精确到哪个方法耗时最长
自定义Looper监控：通过设置Printer，打印主线程的耗时操作

// 一个简单的卡顿监控实现
public class BlockDetector {
    private static final long BLOCK_THRESHOLD = 2000; // 2秒
    
    public static void start() {
        Looper.getMainLooper().setMessageLogging(msg -> {
            if (msg.toString().contains(">>>>> Dispatching to")) {
                // 开始执行
                startTime = System.currentTimeMillis();
            } else if (msg.toString().contains("<<<<< Finished to")) {
                // 执行结束
                long cost = System.currentTimeMillis() - startTime;
                if (cost > BLOCK_THRESHOLD) {
                    Log.w("BlockDetector", "主线程卡顿：" + cost + "ms");
                    // 这里可以dump堆栈信息
                }
            }
        });
    }
}

避坑指南：我曾经在TV上遇到过一种奇怪的卡顿——界面滑动时一卡一卡的，但CPU和内存都很正常。后来发现是焦点切换导致的。TV端用遥控器操作，焦点频繁切换时，如果焦点动画太复杂，就会掉帧。解决办法是把焦点动画简化，或者用硬件加速。

最后说一句，性能优化不是一锤子买卖。我建议在项目初期就建立性能监控体系，把LeakCanary、BlockCanary这些工具集成到CI流程里。每次提交代码，自动跑一遍性能测试，有问题早发现早解决。等用户反馈了再修，那就晚了。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

20、性能优化：布局层级优化、内存泄漏检测与卡顿分析

布局层级优化：少即是多

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

卡顿分析：找到掉帧的元凶