第二讲：埋点技术基础——什么是埋点，为什么需要埋点
这一讲我们聊聊埋点。说白了，埋点就是在代码里“埋”下一个记录仪，用来捕捉系统运行时的关键状态。
不夸张地说，SystemServer 就像手机的大脑。你想啊，大脑什么时候开始干活、启动时有没有卡壳、中间有没有报错——这些信息如果不记录下来，排查问题只能靠猜。
我个人习惯把埋点看作“系统日志的升级版”。普通日志太啰嗦，运行时打印一大堆，真正出问题时反而被淹没了。埋点不一样——每个埋点都带着明确的目的：这个时间点发生了什么？花了多久？成功还是失败？
埋点的核心定义
埋点，本质就是“在代码的逻辑关键节点插入一段数据采集逻辑”。它采集什么？通常是三类信息：
- 时间戳——什么时候发生
- 状态标识——成功、失败、异常
- 上下文数据——当前模块、关键参数、执行耗时
举个最朴素的例子：你在 SystemServer.java 的 startBootstrapServices() 里加一行日志，把启动时间打出来——这就算最简单的埋点了。
为什么需要埋点？
你想想看，SystemServer 初始化阶段是不可逆的。一旦跑过去，问题就再也复现不了了。没有埋点，事后只能看 dmesg 或者 logcat 的海洋，靠经验拼凑真相。
我遇到过无数次这种情况：用户报告手机开机卡顿，但 logcat 早就被覆盖了。如果当时在关键服务启动前后埋了时间点，用 Spark 或者 Perfetto 一拉，哪个服务超时一目了然。
埋点解决了三个核心痛点：
| 痛点 | 传统做法 | 埋点做法 |
|---|---|---|
| 问题定位 | 看海量日志，人工搜关键词 | 埋点直接标记异常节点与耗时 |
| 性能分析 | 凭感觉判断哪个服务慢 | 埋点精准记录起止时间，可量化 |
| 稳定性监控 | 崩溃了才知道出问题 | 埋点可捕捉“准崩溃”状态，提前预警 |
说白了，埋点让系统启动过程从“黑盒”变成了“透明化”。
两种主流埋点方式
在 Android 系统层面，埋点主要分两类：
- 日志埋点：用 Slog.i / Slog.d 等 API，配合系统日志服务写入 logd。适合调试和本地分析。
- 统计埋点：用 MetricsLogger / EventLog 等接口，将数据写入统计缓冲区。适合增量分析和线上监控。
我记得一个坑：早期在某厂商项目中，我们在 SystemServer 里大量使用 Slog.wtf 做埋点，结果触发了 ANR 守护线程的判断逻辑，导致系统误判为死锁。后来我改成用 EventLog 写结构化数据，才把这个隐患解决掉。
埋点的三大要素
不管用什么方式，好的埋点一定包含三样东西：
- 触发时机——确切知道在哪个逻辑节点插入。比如“bindService 之后”、“handleMessage 收到 BOOT_COMPLETED 时”。
- 关注指标——记录什么？是耗时？是返回值？还是异常码？
- 数据接收方——埋点的数据最终流向哪里？是 logcat？是 statsd？还是自己的文件？
这里要特别提醒：不要在短时高频调用处加埋点，比如循环内的每次调用。我以前在某个 handler 的 handleMessage 里加了时间点记录，结果每 1ms 触发一次，直接淹没了正常日志。
一个简单示例
// 在 SystemServer.java 中
private void startBootstrapServices(@NonNull TimingsTraceAndSlog t) {
t.traceBegin("StartInstaller");
// 埋点1：开始安装服务
long startTime = SystemClock.elapsedRealtime();
Installer installer = new Installer(context);
ServiceManager.addService("installer", installer);
// 埋点2：记录耗时
long elapsed = SystemClock.elapsedRealtime() - startTime;
SystemProperties.set("sys.installer.start.elapsed", String.valueOf(elapsed));
t.traceEnd();
}
看到了吧？这个埋点干了三件事：标记了起始时间、记录了总耗时、把耗时写入属性供后续分析。就这么简单。
埋点的设计原则
我在项目中总结了几条原则，分享给你：
- 一码一意：一个埋点只记录一个关注指标，不要一个点里塞五六个参数。
- 避免副作用：埋点代码不能影响主流程，不能抛出异常破坏启动。
- 可开关：线上环境建议用 FeatureFlag 控制埋点是否开启，避免性能损耗。
- 带上上下文：记录耗时的同时，最好附带当前的服务状态或版本号。
嗯，这里要注意：埋点不是越多越好。我见过同事在 SystemServer 的每个方法里都加了 traceBegin/traceEnd，结果 trace 文件膨胀到几 GB，连抓取都成了问题。你想想看，埋点本身也是开销。
下面这张图可以帮你理解埋点的整个体系结构：