快照机制概述：从创建到销毁，一张“截图”的前世今生
快照这玩意儿，说白了就是系统在某个瞬间给屏幕内容拍了一张“照片”。别小看这张照片，它背后牵动着WMS、SurfaceFlinger、还有咱们开发者最头疼的ANR。我个人习惯把快照理解成“画面的一道保险”——有了它，动画或者窗口切换时就算中间帧丢了，至少还能拿快照顶一下，不至于黑屏。
快照的生命周期——一个完整的闭环
快照不是凭空产生的，它走完四个阶段才算一个完整周期：创建 → 传递 → 使用 → 销毁。每个阶段出问题，都可能引发卡顿甚至ANR。
| 阶段 | 核心动作 | 关键角色 | 我踩过的坑 |
|---|---|---|---|
| 创建 | 抓取当前帧的Buffer或Layer状态 | SurfaceFlinger | 曾经遇到过创建快照时GPU还在渲染上一帧，结果拿到的是半截画面 |
| 传递 | 将快照数据从SF发往WMS或App进程 | Binder + SharedMemory | 大快照走Binder很容易撑爆缓冲区，嗯，后来改了共享内存才解决 |
| 使用 | WMS用它做窗口动画回退，App用它做过渡 | WMS / App | 我见过最离谱的是快照在动画链路上被反复拷贝了三次 |
| 销毁 | 释放Buffer、清理引用 | SurfaceFlinger | 引用没解干净导致SurfaceFlinger内存暴涨，最后触发系统杀进程 |
关键点： 快照的生命周期必须被严格管理。一旦某个环节阻塞——比如创建时等GPU fence超时，或者传递时Binder线程池满了——就会卡住整个动画线程，进而引发ANR。
快照的创建与销毁
创建时机：到底什么时候拍快照？
SurfaceFlinger不是随便就拍照的。我翻了源码，发现快照的创建主要发生在两个场景：
- 窗口启动/退出动画 —— 系统需要保留动画开始前的界面状态，万一用户取消操作，得能平滑恢复。
- 屏幕旋转或Configuration变化 —— 重建窗口期间，快照作为占位图保证用户看不到空白。
创建过程大致是这样：
// 伪代码示意
snapshot = new Snapshot()
snapshot.captureLayerState(layerHandle) // 捕获Layer层级关系
snapshot.captureBuffer(bufferHandle) // 抓取GPU渲染好的Buffer
snapshot.waitForFence() // 等待渲染完成信号（这一步最慢！）
snapshot.shareWithWMS() // 通过SharedMemory传出去为什么说 waitForFence() 最慢？因为如果GPU繁忙，这个等待可能超过16ms。我记得有一次在低端机上，一个复杂的启动动画因为快照创建耗时50ms，直接导致后续的触摸事件被延迟处理，用户点不动屏幕——没错，这就是ANR的源头之一。
销毁时机：别让快照成为“僵尸”
快照用完后必须销毁。但Android的引用计数机制有时候并不靠谱。销毁的触发条件：
- 动画完成 —— WMS告诉SurfaceFlinger“可以释放了”。
- 窗口销毁 —— 对应的Activity或Window被移除。
- 超时 —— 系统有一个兜底机制，超过一定时间没被使用的快照会被强制回收。
我曾经遇到一个线上Bug： 某个三方App频繁启动退出Activity，每次都会创建快照，但WMS和SF之间的回调出现了race condition，导致快照引用计数永远不为0。结果SF里积压了数百个快照，每个快照持有几十MB的GraphicBuffer，内存直接爆炸，系统杀进程。定位过程很痛苦，最后是靠抓dumpsys SurfaceFlinger里的snapshot列表才发现的。
快照在WMS / SurfaceFlinger中的作用
这两个模块是快照的核心玩家。说白了：WMS负责“想不想拍”，SurfaceFlinger负责“怎么拍和怎么扔”。
WMS端：快照的“调度员”
WMS不直接处理图形数据，它管理窗口状态。当WMS决定发起一个过渡动画时，它会先向SurfaceFlinger请求一个快照，然后把快照作为动画的起始帧。如果动画中途被取消，WMS再用这个快照做回退。
我在项目里优化过一个场景：快速切换两个全屏Activity，WMS在极短时间内连续请求了两次快照。SurfaceFlinger还没处理完第一个请求，第二个就来了，结果两个请求互相覆盖，最终回退时显示的是错误画面。解决方式很简单——在WMS层加了个去重逻辑，同一窗口的连续快照请求只保留最后一个。
SurfaceFlinger端：快照的“生产者与消费者”
SurfaceFlinger是真正的干活人。它内部的SnapshotManager维护着所有活跃快照。每个快照包含：
- Layer栈的冻结状态 —— 哪些Layer可见、层级顺序、透明度。
- 图形Buffer的引用 —— 实际像素数据，很大。
- 时间戳 —— 用于判断过期。
快照被使用时，SurfaceFlinger会把它当作一个普通的Layer来合成到屏幕上。但要注意：快照本身是一个“静态”的Buffer，如果HWC（硬件合成器）不支持直接合成静态Buffer，就会fallback到GPU合成，带来额外的CPU/GPU负载。
小技巧： 如果你在logcat里看到类似 SF: Snapshot capture took 35ms 的日志，别忽视。这往往意味着你的App在某个窗口动画中导致了GPU负载异常。我曾经把这个耗时从35ms优化到8ms，方法是减少动画期间的View层次深度，让GPU更快完成上一帧的渲染。
总结——一张图看懂快照出了事会怎样
上面这张SVG基本把快照在WMS和SF之间的流转画清楚了。你看，从WMS发起创建，到SF捕获、传共享内存、再回到WMS使用、最后SF合成到屏幕——每一个环节都可能成为瓶颈。
我个人做ANR排查时，遇到快照相关的案例，第一件事就是去看logcat里有没有“SF: Snapshot capture”的耗时日志。如果超过16ms，立马抓一份dumpsys SurfaceFlinger，看snapshot的count和每个快照的创建时间戳。绝大多数情况下，问题出在创建阶段的fence等待上——说白了就是GPU太忙或者渲染管线卡住了。
嗯，记住一句话：快照不是免费的午餐。每一次快照的背后都是CPU/GPU的协作和Binder通道的带宽占用。优化得快，动画丝滑；优化不当，ANR敲门。