1. 基线配置基础：什么是 Baseline Profile，为什么需要它

先问你一个问题：你的 App 启动时，是不是偶尔会卡一下？或者滚动列表时突然掉帧？

嗯，这种体验其实很常见。根本原因在于，Android 系统在冷启动或首次加载时，很多代码还是“解释执行”的——边走边翻译，速度自然慢。而我今天要讲的 Baseline Profile，就是专门用来解决这个痛点的。

1.1 它到底是什么东西

Baseline Profile 是一份预生成的“热点代码清单”。说白了，就是告诉系统：“喂，这部分代码用户启动时马上要用，你先帮我编译好，别等到运行时再临时翻译。”

这份清单会被打包进 APK，系统在安装 App 时就能提前把清单里的关键路径编译成机器码。这样一来，用户第一次打开 App 就享受到接近 AOT（预编译）的速度，而不是每次都要 JIT 边跑边编译。

1.2 为什么需要它——血的教训

我记得刚负责一个电商 App 的性能优化时，冷启动耗时足足 3.2 秒。用户投诉说“点开 App 还要等转圈”。我当时试了各种代码裁剪、懒加载，效果都有限。后来才发现，问题出在——每次冷启动都有大量 class 需要解释执行，尤其是首页的布局、网络框架、图片库的初始化。

Baseline Profile 就是为这类场景设计的。它的收益非常直接：

• 启动速度：一般能提升 30%～60%，有些场景甚至翻倍。
• 首帧渲染：把耗时较长的类和方法提前编译，避免卡顿。
• 滚动流畅度：列表滑动时频繁调用的函数被提前优化，减少掉帧。
• 包体积：Profile 文件本身很小，一般几十 KB 到几百 KB，几乎没有副作用。

1.3 基本原理：AOT 与 JIT 的“中间人”

Android 运行时分为三个流派：解释器、JIT 编译器、AOT 编译器。解释器最慢，JIT 运行时边跑边编译也挺好，但首次执行成本高；AOT 安装时全量编译，最快，但包体积和安装时间都暴涨。Baseline Profile 走的是“精准局部 AOT”路线：

1. JIT 采集阶段：在用户实际使用过程中，JIT 会记录哪些代码被频繁执行（热点代码），生成一份 profile 文件。
2. 规则筛选：开发者通过 baseline-prof-gradle-plugin 或手动编写规则，把真正关键的方法、类提取出来。
3. 打包部署：最终产物 baseline.prof 或 baseline.profm 放进 APK 的 assets 目录。
4. 安装时编译：系统在安装 App 时，根据这份清单直接执行 dex2oat 提前编译。
5. 运行时继承：用户使用时，这些方法已经编译成机器码，解释器和 JIT 都不需要再介入。

这个过程，我习惯把它叫作“用空间换时间，用规则换温度”。

1.4 工作流程全貌

下面这张图可以帮你快速建立整体印象：数据源从哪来、规则怎么形成、最终怎么落地。你可以把它当作整章的地图。

从上图你能看到，整个流程其实是个闭环。但这里我要特别强调一下采集阶段：你必须在真实用户场景下运行足够长的时间，才能覆盖大部分关键代码路径。我曾经遇到一个项目，只在调试机上跑了几分钟就导出 profile，结果线上部分功能反而更慢——因为编译了不该编译的方法，浪费了系统资源。

1.5 实际收益对比表

为了让你更直观地理解效果，我列个对比：

你看，几乎没有代价，就能换来 50% 以上的启动速度提升。这也是为什么我强烈建议每一个中大型 App 都接入 Baseline Profile 的原因。

1.6 举个实际例子

假设你要优化一个社交 App 的首页。首页包含大量 RecyclerView 列表、图片加载、网络请求。你发现冷启动时，默认是边滑动边去解释执行 Adapter 里的 onCreateViewHolder 和 onBindViewHolder。这时候，你只需要在 Baseline Profile 规则里加上：

# 示例规则（baseline-prof-gradle-plugin 语法）
-keepclass com.example.social.*ViewHolder {
    <init>;
}
-keepclass com.example.social.MainActivity {
    onCreate;
    onResume;
}
-keepclass com.example.image.loader.ImageLoader {
    displayImage;
    preload;
}

这样，当用户安装 App 时，系统就已经把 ViewHolder 的构造、MainActivity 的生命周期、图片加载的核心方法全部编译了。用户看到的效果就是：一点击图标，几毫秒就跳出首页，而不是先转圈再出现列表。

嗯，这其实是我之前优化一个千万级用户 App 时最立竿见影的手段。你想想看，几百 KB 的配置文件，换来的可能是次日留存率提升 1~2 个百分点。

1.7 你可能会踩的坑

我曾经在一台低端机上测试，profile 打包后安装耗时增加了 3 秒。后来发现是因为我把整个框架库的代码都写进了规则里。所以请大家记住一个原则：只包含真正的热点，不要贪多。通常建议覆盖以下三类就够了：

• 冷启动过程中调用的所有类和方法
• 页面首帧渲染依赖的 UI 组件初始化和布局 inflate
• 用户点击后最频繁触发的功能（如“点赞”、“评论”按钮的回调）