外观
多屏性能与项目完整回答
1. 快照和模糊会带来哪些成本？怎样优化？
**标准回答：**需要分别计算捕获、存储、模糊处理、上传与合成的成本。未压缩 RGBA 图像的基本内存量约为宽乘高乘 4 字节，额外副本、模糊中间结果和驱动分配还可能增加占用。GPU 合成消耗与图层面积、透明混合、带宽和处理方式有关，不能因为主线程轻了就认为总成本降低。
可以评估缩小过渡图分辨率、只捕获必要区域、复用受控资源、避免每帧重新捕获和重新模糊、在不影响体验的前提下减少中间图层，并为并发转场设置资源上限。每项策略都要看清晰度、首次准备时延和峰值内存的取舍。
**追问：模糊放后台线程就不会卡了吗？**不保证。后台 CPU 工作仍可能与主线程争抢资源；GPU 工作也可能影响渲染。先确定瓶颈与实际实现，再选处理方式，并测量准备阶段和动画阶段。
2. 用 Perfetto 怎样证明跨屏卡顿发生在哪一层？
**标准回答：**按用户输入、系统接收请求、任务迁移、两端准备、动画推进、目标绘制、事务提交和最终呈现拆阶段。为自己的协调逻辑加关联标识和 Trace 区间，结合线程调度、Binder flow、Choreographer、RenderThread 和 SurfaceFlinger 的证据定位等待链。
FrameTimeline 需要区分应用和 SurfaceFlinger 的轨道：应用侧 Actual slice 描述应用完成帧的时间，包括相应 GPU / 提交阶段；SurfaceFlinger 轨道才涉及其合成与呈现链路。不能把任意一个 Actual slice 的结束都称为“按钮已经出现在屏幕上的时刻”。具体字段和 token 关联按 Trace 版本核对。
**追问：需要记录哪些指标？**手势到首个可见反馈、两端准备时长与差值、目标接管时延、异常帧、帧时长分布、取消成功率、峰值内存和资源残留。没有实测数据时，应给出测量方案，不编造稳定 60fps 或某个耗时数字。
3. 冷启动的 380→240ms、1200→700ms，怎样回答才准确？
标准回答：“我参与主导智能座舱应用的冷启动优化，通过 Perfetto 分阶段分析主线程阻塞、首帧绘制和初始化依赖。方案包括 AsyncLayoutInflater、重任务后台化、ViewStub 按需加载、IdleHandler 延后非关键工作，以及调整初始化时序、减少非必要强依赖。项目响应时延从 380ms 降至 240ms，启动完成时延从 1200ms 降至 700ms，降幅分别约 37% 和 42%。”
这两个是项目指标。进一步追问时，必须按真实埋点说清起止事件，不能未经核对就改称 TTID / TTFD。异步和延迟初始化还应验证生命周期、首次交互、初始化顺序及后续功能，避免把启动成本转移成用户第一次点击时的卡顿。
**追问：哪个改动贡献最大？**现有已确认信息没有每项贡献拆分。可以如实解释总体证据和组合方案；若有逐项对照实验，再说明贡献。不能把全部 140ms 都归因于某一个技术。
4. 如何完整回答“你最有代表性的多屏技术难点是什么”？
标准回答：“我负责智能座舱多屏互动模块的设计与交付，涉及多屏同看、跨屏协助、三指移屏和智慧大灯投影流转。跨屏动效的困难是，用户看到的是一个连续移动过程，但底下还涉及任务与窗口状态变化、配置适配、真实画面更新及输入目标切换。我的项目采用窗口快照、模糊图层双层合成和透明度渐变来组织过渡画面，让迁移期间的视觉表现更连续。”
“进一步解释时，我会分别说明过渡图层怎样准备、两端怎样协调、何时让真实窗口接管，以及取消或失败后怎样恢复。排障时，我结合系统日志与 Perfetto 区分任务、输入、应用绘制和合成的问题。项目的实际类名、具体一次故障根因和验证结果，我会按真实代码与记录补充。”
深入追问：如果让你再设计一次，会补哪些能力？“我会评估集中管理的转场会话、transitionId 与配置代次校验、两端就绪屏障、明确的目标接管条件，以及统一的取消与清理路径；为每个阶段补充关联日志和测量点，并覆盖不同刷新率、进程死亡、屏幕断开和连续操作。这些是我提出的完善方向，是否已经采用，要看当前实现。”