3. 基线配置文件缺失的典型场景归纳

说实话，我在排查基线配置问题的时候，发现不少同学一上来就盯着代码看。但其实，大部分崩溃的根源都在「构建过程」里。你想想看，基线配置文件是编译期生成的，只要构建环境、依赖或配置变了，它就有可能「消失」。

我个人习惯先把可能出问题的场景列出来，然后逐个排除。下面这张图我经常拿来培训新人，帮你快速定位漏洞在哪里。

下面我挑几个最容易中招的场景详细说说。

3.1 配置变更类

这类场景出现的频率最高。说白了，就是你的构建脚本变了，但基线配置没跟着改。

3.2 依赖变化类

依赖更新是家常便饭，但基线配置里的类名、方法签名和依赖库是绑死的。只要第三方 SDK 改了启动路径，旧的 prof 文件就废了。

• 第三方 SDK 更新：比如友盟/推送/热修复 SDK 改了初始化入口。我记得有一次微信登录 SDK 升级后，启动流程里多了一个同步任务，我们之前的 Baseline Profile 没覆盖到，线上直接 ANR。
• 自定义启动库：你写了自定义的启动框架，某个版本优化了初始化顺序。这时候一定要重新生成 prof。我曾经因为只改了库内部代码，忘了跑 prof 生成任务，结果灰度用户启动白屏持续 3 秒。
• 依赖传递变化：Gradle 依赖传递规则更新，导致某些底层类被移除了。你的 prof 里还引用着已经被清理的类，R8 编译时直接报错。

3.3 环境差异类

这类问题最隐蔽，因为你本地怎么测都是好的，一到 CI 或者用户手里就崩。

1. CI/CD 和本地环境不一致：比如 CI 用的是 Gradle 8.5 缓存，本地是 8.4，不同的 Gradle 版本对 baselineProfiles 的生成路径理解不同。我记得有次 Jenkins 节点上有个任务只缓存了编译中间产物，没亮出 prof 文件，发布时直接挂了。
2. 多模块缓存污染：你的项目有 20 多个模块，某个模块的缓存里有旧的 prof，但主模块依赖了新的。Gradle 构建判定「缓存命中」时用了旧的，新配置没生效。
3. 本地 / 仓库差异：有人通过远程仓库依赖了另一个团队发布的 AAR，那个 AAR 里自带了 baseline.prof，但和你项目的启动流程对不上。两个 prof 冲突，运行时直接选了一个错的。

3.4 一个典型的排查案例

去年我们 App 改造成 Baseline Profile 后，线上突然报了个启动崩溃。崩溃堆栈指向 com.xxx.startup.Initializer，说反射调用找不到 initialize() 方法。所有开发机都正常，只有线上灰度用户出问题。

我的排查思路是这样的：

1. 先看构建日志 —— 发现 AGP 版本号是 8.0.2，但 prof 生成任务没有执行。
2. 对比 build.gradle 发现，有同事在升级 AGP 时把 baselineProfile 插件移到了 dependencies 块外面，导致任务没注册。
3. 补上插件之后重新生成 prof，问题解决。

你想想看，如果不是先画出那张场景分类图，我可能还在代码里翻来覆去找 null 呢。

3.5 快速自查清单

为了方便你快速定位，我整理了一个 checklist。每次出现启动崩溃时，先过一遍：

拿下这个清单，你至少能解决 90% 的「基线配置缺失」问题。剩下的那 10% 可能是 Android Framework 的 bug，但那是另一门课了。