启动埋点的意义与挑战
说实话，在Android系统里做性能埋点，第一关不是技术选型，而是先想清楚：你费那么大劲在系统拉起阶段插桩，到底图什么？
启动埋点的核心价值：用最短的时间，回答“系统在哪一步慢了，为什么慢”。
我做过不少启动优化项目，发现如果没有埋点，所有优化都像是闭着眼睛调参数。你猜这里慢了，调一下，重启，再测，重复十次——结果可能是另一块代码在拖后腿。启动埋点就是给你的优化装上“摄像头”。
为什么一定要做启动埋点
先列几个实实在在的理由，都是你在日常性能优化中会遇到的问题：
- 量化冷启动耗时 —— 用户从按下电源键到Launcher第一帧绘制，到底花了多少毫秒？不看数据，你永远不知道。
- 定位瓶颈阶段 —— Zygote启动、SystemServer初始化、ServiceManager挂载、WMS/AMS加载…每个环节耗时多少？哪一步超标了？
- 对比不同ROM/机型 —— 同一个AOSP版本，在小米、OV、三星上跑出来的启动时间可能差一倍。没有埋点，你连哪家改了什么都说不清。
- 监控回归 —— 合入新功能后，启动时间有没有变慢？自动化埋点可以每天拉曲线，一旦超出阈值就报警。
- 给业务方“看得见的证据” —— 产品经理说“加一个自启动插件应该不慢吧”，你把埋点数据拍在桌上，他就不吱声了。
我个人习惯把启动埋点分为三个层次：内核态（boot_kpi）、JVM态（Zygote早期）、SystemServer态（关键服务初始化）。每一层都有不同的挑战。
黑暗启动：埋点系统还没起来，怎么记时间？
这是我最常被问到的问题——“我在SystemServer onCreate里插了桩，但前面从Bootloader到Zygote init的这几百毫秒，到底怎么采？”
说白了，黑暗启动指的是系统核心组件尚未初始化完成、日志框架和埋点基础设施都还没加载的那一段“黑暗期”。你所用的Log.d、systrace、甚至/data目录都不可用。
我记得有一次在某个厂商的预研机上做启动埋点，想测kernel. init到init.rc执行完毕的耗时。但那时候logd还没跑起来，printf输出也没地方落。怎么办？
- 方案一：内核boot marker —— 提前在内核里用
trace_printk打时间戳，然后在init阶段用/proc/bootmarkers读出。这个不依赖用户空间进程。 - 方案二：early mount tmpfs —— 在init.rc早期阶段挂载一个临时文件系统，把时间戳写进文件，等logd启动后再统一读入埋点数据库。
- 方案三：共享内存区域 —— 在bootloader阶段分配一块保留内存，各阶段往里面写结构体，SystemServer起来后解析。但这需要硬件和内核配合，一般大厂才搞。
小经验： 如果你只是做App层的启动优化（比如Launcher冷启动），黑暗启动的影响不大，直接抓onCreate之前的时间即可。但如果是系统级优化（比如减小开机总耗时），那你必须处理黑暗启动段的埋点。
厂商定制：同一个AOSP，千奇百怪的改法
你想想看，Google发布的AOSP是“公版”。但到了各家OEM手里，SystemServer的启动顺序可能被改过，某个Service被提前或者延迟加载，init.rc里多了几十条自定义action。甚至有些厂商在Zygote之前就启动了自研的守护进程。
我在做跨厂商启动性能对比时，遇到过这些问题：
| 厂商定制点 | 对埋点的影响 | 我的应对方式 |
|---|---|---|
| 修改SystemServer线程优先级 | 某些埋点线程被抢占，导致时间戳不准 | 使用高精度时钟(clock_gettime(CLOCK_MONOTONIC))并固定线程优先级 |
| 插入自定义SystemService | 原埋点插桩位置与实际执行顺序偏差 | 动态解析SystemServer的startService列表，用反射插桩 |
| 关闭logd或限制log大小 | 埋点日志被丢包，数据不完整 | 改用kernel trace point + 独立文件回传 |
| 部分设备禁用perf_event | 无法使用内核性能计数器 | 降级使用gettimeofday，精度损失但可接受 |
说白了，厂商定制是启动埋点最大的不确定因素。你不能假设所有设备都按AOSP标准行为运行。我建议在埋点框架中内置一个“设备适配层”，针对不同厂商的build.prop做差异处理。
权限限制：不是你想插就能插
做启动埋点，尤其是想做系统级别的trace时，你会发现被权限墙挡在外面。
- perf_event_open系统调用 —— 需要
CAP_SYS_ADMIN或者/proc/sys/kernel/perf_event_paranoid = -1。普通App没权限。 - 读/proc/self/stat —— Android 10+限制了procfs的访问，非系统进程读不到CPU时间。
- 写/data/local/tmp —— 非root权限写不了，而启动阶段的系统进程又还没设置SElinux上下文。
- logd写入 —— 需要
logd.auditd权限，否则被丢到kernel log里无法统一解析。
我曾经在某个项目里，想在内核init阶段用perf_event测量CPU频率切换延迟，结果发现改系统之后才能通过CTS……最后只能换用trace_printk加sysfs接口来绕。
注意： 在生产环境（用户手机）里，你永远拿不到root权限。所以埋点方案必须设计成：在userdebug/eng包上全量采集，在user包上只采集可控、无权限风险的点（比如通过系统服务回调的时间戳）。
一张图看懂启动埋点的意义与挑战
下面这张图把上面说的内容串了起来。你可以看到启动埋点要做的事，以及黑暗启动、厂商定制、权限限制这三个“拦路虎”分别出现在什么阶段。
这张图里，上半部分是启动埋点的四个收益，下半部分是三个主要挑战，最下面是轻量级的应对思路。你在实际项目中可以拿它作为框架，逐一对照你的设备上遇到了哪些问题。
总结一下我个人的核心建议
- 先定义好“启动完成”的终点 —— 是Launcher onResume？还是SystemServer ready？不同的终点，埋点的位置和意义完全不同。
- 分阶段规划埋点能力 —— 黑暗启动靠内核，系统服务靠反射插桩，App层靠ActivityLifecycleCallback。不要试图用一个方案覆盖所有阶段。
- 做好降级预案 —— 在权限不足或厂商定制严重的设备上，不要硬上，否则埋点本身会拖慢启动。
嗯，启动埋点这件事，听起来简单，做起来全是坑。但如果你能把这三个挑战都稳稳跨过去，后续的性能优化就会变得非常清晰——数据说话，时间在哪，问题就在哪。