30、Jetpack性能优化：启动优化、内存优化、包体积优化与Compose性能

性能优化，说白了就是让App跑得更快、更稳、更小。很多开发者觉得这是项目后期才做的事，但我个人的经验是——越早考虑，后面越省心。今天我们就来聊聊Jetpack体系下的四个核心优化方向：启动、内存、包体积，还有Compose的性能调优。

一、启动优化：别让用户等太久

启动速度是用户对App的第一印象。我记得有一次，一个启动耗时3秒的App，用户反馈里“打开慢”占了30%。后来我们优化到1.2秒，差评直接少了一半。

1.1 启动流程与瓶颈

App启动分三阶段：

• 冷启动：进程创建 → Application初始化 → Activity创建
• 温启动：部分缓存还在，但Activity需要重建
• 热启动：Activity从后台切回，几乎无延迟

冷启动是优化的重点。为什么？因为用户每次杀进程后再打开，都得走一遍完整流程。你想想看，如果Application里塞了一堆第三方SDK初始化，那启动能不慢吗？

1.2 具体优化手段

优化项	做法	效果
懒加载初始化	将非必要的SDK放到使用时再初始化	减少Application耗时
异步启动任务	使用Startup库或自定义线程池	并行化初始化流程
减少布局层级	使用ConstraintLayout或Compose	加速首帧渲染
预加载数据	在闪屏页加载必要数据	减少白屏时间

1.3 使用Jetpack Startup库

Jetpack Startup可以帮你管理初始化顺序和依赖。它通过ContentProvider自动执行，但注意——ContentProvider本身也有开销，别滥用。

// 定义一个初始化任务
class MyInitializer : Initializer<Unit> {
    override fun create(context: Context) {
        // 在这里做初始化
        Log.d("Startup", "初始化完成")
    }

    override fun dependencies(): List<Class<out Initializer<*>>> {
        // 如果有依赖其他Initializer，在这里声明
        return emptyList()
    }
}

二、内存优化：别让App“吃”太多

内存优化说白了就是防止OOM和减少GC卡顿。Android给每个App分配的内存是有限的，尤其是低端机，动不动就杀后台。

2.1 常见内存问题

• 内存泄漏：Activity、Fragment、大对象无法释放
• 内存抖动：频繁创建和回收对象，导致GC频繁触发
• 图片内存：大图加载未压缩，直接撑爆堆内存

2.2 使用LeakCanary和Profiler

LeakCanary是检测内存泄漏的神器。我习惯在debug版本里开启，release版本关掉。Profiler则用来分析堆转储，看看哪些对象占用了大量内存。

// 在Application中初始化LeakCanary
if (LeakCanary.isInAnalyzerProcess(this)) {
    return
}
LeakCanary.install(this)

2.3 图片优化

图片是内存大户。我建议：

• 使用Glide或Coil，它们会自动处理缓存和缩放
• 避免直接加载原图，先采样压缩
• 使用Bitmap.Config.RGB_565代替ARGB_8888，内存减半

三、包体积优化：小一点，再小一点

包体积直接影响下载转化率和安装成功率。尤其是在海外市场，用户流量贵，包太大没人愿意下。

3.1 资源优化

• 删除未使用的资源：使用shrinkResources true
• 图片压缩：使用WebP格式，比PNG小30%以上
• 多语言只保留常用语言：比如只保留中文和英文

3.2 代码优化

• 启用minifyEnabled true和proguardFiles，混淆并移除无用代码
• 使用R8替代ProGuard，压缩率更高
• 避免引入大库：比如只用Retrofit就别带OkHttp的完整包，用okhttp-bom统一版本

android {
    buildTypes {
        release {
            minifyEnabled true
            shrinkResources true
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }
}

3.3 动态交付

使用Android App Bundle和Dynamic Delivery，用户只下载需要的部分。比如只下载对应屏幕密度的资源，包体积能再减20%。

四、Compose性能：别让声明式UI拖后腿

Compose虽然写起来爽，但性能坑也不少。你想想看，每次状态变化都重新组合，如果没优化好，卡顿是必然的。

4.1 重组范围控制

Compose的核心是重组。但重组不是全量重绘，而是只更新变化的部分。怎么控制？用remember和derivedStateOf。

@Composable
fun MyScreen(viewModel: MyViewModel) {
    val data by viewModel.data.observeAsState()
    // 只有data变化时，才会重组这个Text
    Text(text = data ?: "加载中")
}

4.2 避免不必要的重组

• 使用key参数帮助Compose识别稳定项
• 将大组件拆分成小组件，减少重组范围
• 使用remember缓存计算结果

4.3 使用Layout Inspector分析

Android Studio的Layout Inspector可以查看Compose的重组次数。如果某个组件频繁重组，说明状态管理有问题。

五、知识体系总览

下面这张图总结了本章的核心优化路径。你可以把它当作一个检查清单，每次优化时对照着看。

六、总结

性能优化没有银弹。启动、内存、包体积、Compose，每个方向都有对应的工具和套路。我个人习惯是：先用量化工具找到瓶颈，再针对性地优化。别一上来就大刀阔斧地改，容易改出问题。

嗯，最后提醒一句：优化完一定要回归测试。我曾经优化启动速度，结果把某个第三方SDK的初始化顺序搞乱了，导致推送功能失效。上线后用户收不到通知，那叫一个惨。