埋点基础：埋点类型、事件模型、埋点上报链路
做锁屏渲染优化，你得先搞懂埋点到底在挖什么。很多人以为埋点就是往代码里塞几句日志，其实没那么简单。我刚开始做埋点的时候，就吃过“数据丢了都不知道”的亏。这次咱们就把埋点的三大核心——类型、事件模型、上报链路——逐个拆开。
埋点类型：你在记录啥？
埋点类型说白了就是“你感兴趣的事件种类”。不同类型对应不同的业务诉求，设计错了后面分析全白搭。我在项目里见过最典型的错误是：把曝光埋点当点击埋点用，结果PV和UV对不上。
| 埋点类型 | 触发时机 | 典型字段 | 我在项目中踩过的坑 |
|---|---|---|---|
| 曝光埋点 | 元素进入可视区 | 元素ID、曝光时长 | 锁屏组件频繁重绘导致重复曝光 |
| 点击埋点 | 用户主动交互 | 点击坐标、动作类型 | 快速连续点击只记录最后一次 |
| 页面停留埋点 | 进入/离开页面 | 停留时长、页面路径 | App退到后台时长也被计入 |
| 自定义事件埋点 | 业务逻辑触发 | 自定义参数 | 命名不规范，数据治理时哭都来不及 |
一个小习惯：我给每个埋点都加一个
eventVersion 字段，方便后续做字段变更兼容。不然上线第二天发现字段名写错了，只能全量补数据，那叫一个痛苦。
事件模型：怎么组织这个“事件”？
事件模型是埋点的骨架。一个好的模型，应该能描述“谁、在什么时候、干了什么、结果怎样”。我一般用五元组：{userId, deviceId, eventName, timestamp, extra}。你想想看，如果少了 deviceId，锁屏渲染的性能差异就分不清是用户机型导致的，还是代码版本导致的。
举个实际例子——锁屏上滑加速动画的埋点：
{
"eventName": "lock_screen_slide_up",
"timestamp": 1680000000000,
"userId": "u_abc123",
"deviceId": "d_iphone14",
"extra": {
"slideDuration": 320, // 毫秒
"startFps": 55,
"endFps": 60,
"pageName": "main_lock"
}
}
注意：我曾经把一个字段从
slideDuration 改成 duration，没通知数据分析师，结果所有日报全部飘红。事件模型一旦定下来，千万别随意改字段名，要改就加版本号。事件模型的另一层是触发策略。我习惯把埋点触发点分成三类：
- 同步触发：用户点击后立刻记录，适合交互反馈类。
- 异步触发：动画结束或渲染完成后再记录，适合性能类。
- 条件触发：只有满足某些条件（如耗时 > 500ms）才上报，用来控制采样率。
你想想看，锁屏渲染动画如果同步触发曝光，那埋点本身都可能拖慢动画。我在优化锁屏时，把性能埋点全部改成异步延迟上报，帧率才恢复过来。
埋点上報链路：从客户端到数据仓库
链路就是埋点数据的“物流路线”。很多同学只关心客户端怎么发，忽略了中间环节。我个人习惯把链路画成一张流程图——看清楚了每一步，才知道优化点在哪。
这张图我画了很久——你注意看，客户端先采集事件，存到本地队列，然后批量打包，最后通过网络请求送到服务端。服务端做去重、校验、清洗，最后入库。每一个环节都可能成为性能瓶颈。
重点：锁屏渲染场景下，埋点上报绝不能阻塞主线程。我踩过的一个大坑是：用同步
XMLHttpRequest 上报，导致锁屏滑动掉帧。后面改成了 sendBeacon + 离线队列，帧率从45fps回到60fps。
链路中的“暗坑”
光画图还不够，实际跑起来才见真章。我总结几个常见问题：
- 数据重复：网络重试导致同一条埋点被插入多次。解决思路是服务端用
eventId做幂等。 - 时序错乱：锁屏动画结束时间早于开始时间？因为客户端本地时间被用户改了。我的做法是用服务端时间戳覆盖，或记录两个时间戳。
- 丢数据：App崩溃时队列里的埋点没来得及发。我在项目里加了
dispatch_before_terminate钩子，但也不是100%可靠。最后还是靠服务端补数接口。
嗯，到这里埋点基础就讲得差不多了。你记住一点：埋点本质是给产品装上“眼睛”，但它自己也会消耗资源。锁屏这种高性能诉求场景，更是要精打细算——该采的采，不该采的别碰。