题目重点：设计设备端log/telemetry接口，解释业务调用、schema、离线缓存、上传和采样。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练重点是Quest设备上的可复用日志API而非完整互联网日志仓库；事件类型、离线、电量与帧率预算需先问。
- 遥测不是业务账本；允许按策略丢低优先事件，安全/计费关键事件需另设可靠合同。用户身份最小化、采集字段受控。
解题路线
- 接口emit(eventName,schemaVersion,attributes,priority)采用已注册typed schema，自动填eventId/session/deviceTime/monotonicOffset/appVersion。禁止调用方任意记录大对象或敏感文本，size上限在边界拒绝/截断有明确标记。
- 主线程emit仅校验和入有界队列，后台批处理序列化/压缩；队列满按priority与采样策略丢弃，记录dropCount，不阻塞渲染线程等网络。高频事件聚合指标而非每帧全部上传。
- 离线使用有额度的环形文件/批次journal，batchId/sequence与checksum验证；重启恢复已完成写入批，坏尾截断按协议处理。超过存储预算保留最新/高优先事件并披露缺口。
- 上传TLS鉴权，批ACK去重与重试，删除本地批只在协议确认后。device clock可能跳，服务器保留receivedAt并用session monotonic顺序辅助，不把设备时间当全球总序。
- schema新增字段向后兼容，版本不识别的事件可拒绝或存raw待解析，不能静默按错误类型聚合。监测emit耗时、frame impact、丢失率、上传字节与电量。
手动走一遍
设备离线积1万低优先操作事件，重连一次批上传比1万HTTP请求省开销。batch ACK丢失后重发同batchId，服务器去重；若队列满丢了300条，dropCount需显示而不是报告“日志完整”。
规模与取舍
emit目标常数工作但属性大小B需O(B)校验/复制；队列内存按上限、磁盘按quota。上报流量=采样事件率×bytes，压缩比与电量必须真实设备量测，不宣称零开销。
易错点与追问
容易失分的边界
- 在UI线程同步flush会影响交互与帧率。
- 无限缓存离线日志可能挤满设备磁盘。
- 把遥测至少一次投递说成每条业务事件恰好一次，没有去重和缺口口径。
继续深挖
- 如何动态调整sampling？配置带版本，事件记录实际采样率以便估计，关键指标不能被未知采样污染。
- 崩溃最后几秒可能丢日志，怎样权衡更频繁fsync与性能？按优先级和证据用途定预算。
