快照重计算触发条件：窗口变化、旋转、缩放、属性变更
这一章，我们聊聊快照重计算在什么情况下会被触发。
说白了，就是View的显示状态变了，系统觉得“嗯，之前算的那张快照可能不准了，得重来一次”。你想想看，如果屏幕都旋转了，你还用竖屏时的快照去渲染，那画面肯定对不上。
我刚开始接触这个课题时，也以为只有少数几种情况会触发。后来踩过坑才明白，触发条件比你想象的要多。下面我把常见的触发场景一一列出来。
核心逻辑： 任何可能导致View显示内容与当前快照不一致的变化，都会触发快照重新计算。
窗口变化（Window Resize / Move）
窗口变了，快照就得重算。这是最常见的触发场景。
- 窗口尺寸改变：比如分屏模式下，你的App被拖拽成不同大小。或者用户从竖屏切换到横屏，但这里和屏幕旋转还不完全一样——窗口变化可能不触发Activity重建。
- 位置移动：窗口在屏幕上移动了位置。我记得之前在平板设备上调试一个画板App，用户拖拽悬浮窗位置时，每次都卡一下。查了才发现是快照被频繁重算了。
避坑指南： 窗口变化不一定调用onConfigurationChanged。有些厂商定制的多窗口逻辑，触发的是onWindowAttributesChanged，这也会间接导致快照无效化。
我在项目中遇到过这种情况：一个新闻阅读App，用户拖拽分屏边界时，界面卡成PPT。一看trace，快照重计算占了主线程200多毫秒。说白了，就是每次窗口尺寸微调，都重新计算了整个ListView的快照。
屏幕旋转（Orientation Change）
屏幕旋转了，界面方向变了，快照肯定得重新生成。但这个场景的坑在于“时机”和“频率”。
- 旋转动画期间：如果系统在动画过程中多次触发了快照重算，就容易卡顿。我记得有次在一个视频播放器上遇到过——用户旋转屏幕后，播放器黑了3秒才恢复。查下来是SurfaceView配合快照重算时，出现了双重同步问题。
- 横竖屏切换时的Layout变化：如果你在onSaveInstanceState里保存了快照相关的状态，但onCreate里又恢复了——嗯，这时候快照很可能已经无效了，但还是会被尝试使用，导致闪一下。
注意： 屏幕旋转导致Activity重建时，onPause 和 onResume 之间进行的快照无效化操作，可能会因为渲染线程的异步特性导致旧快照被误用。务必在 onStop 中清理快照引用。
缩放操作（Scale / Pinch）
缩放，尤其是手势缩放，会引发一连串的快照重算。为什么？因为系统的快照缓存是基于特定分辨率计算的。
缩放比例变了，分辨率就变了，旧的就没用了。但这里有个关键细节：不是你每次调用setScaleX都会触发。我测试过，只有在缩放导致View的最终绘制尺寸发生变化时，系统才会触发。
举个具体的例子：如果你用View.setScaleX(0.5f)把一个View缩小到一半，但它的实际layout尺寸没变——系统可能复用旧快照。但如果你把ViewGroup缩小了，里面的子View排列变了，那就会触发子View的快照重新计算。
| 缩放方式 | 是否触发快照重算 | 典型场景 |
|---|---|---|
| View.setScaleX/ScaleY | 部分触发（取决于硬件层） | 动画缩放 |
| ViewGroup缩放导致子View位置改变 | 是 | 图片查看器双指缩放 |
| Window级别缩放（如开发者选项模拟） | 是 | 无障碍缩放 |
| ScrollView/RecyclerView内容缩放 | 触发全部Item | 地图或画布缩放手势 |
属性变更（Property Changes）
属性变更这组，我把它独立出来，因为它有点坑。不是所有属性变更都会导致快照重算，但有些看起来不起眼的变更，却会。
- Layer Type改变：
setLayerType(LAYER_TYPE_HARDWARE)到LAYER_TYPE_SOFTWARE的切换，会强制刷新快照。我曾见过一个输入法应用，每次弹出键盘时闪烁一下，就是因为它动态切换了layerType。 - Alpha值变化：当你对一个View设置透明度时，特别是从1.0变成0.999这种精度变化时——系统其实也会标记为状态改变，触发重算。
- Visibility变化：从GONE变成VISIBLE，或者INVISIBLE变成VISIBLE，都会导致父布局重新计算子View的快照。这个大家应该都懂。
- 背景Drawable替换：比如
setBackgroundColor、setBackgroundDrawable，都会让View觉得自己“变脏了”，得重画快照。
为什么我要强调这些？因为很多开发者只关注了尺寸和旋转，忽略了属性的细微修改。我曾经排查过一个ANR问题，定位到最后是一个View.setAlpha(0.999f)在动画循环中被反复调用，导致每秒触发几十次快照重算。
小技巧： 如果你发现某个属性更改后界面卡顿，可以在adb shell里抓取 dumpsys gfxinfo 看看“invalidation count”是不是飙了。如果数字异常高，那八成是快照在反复失效。
综合场景：窗口变化 + 属性变更同时发生
你说会不会同时触发？会。多窗口模式下，用户一边旋转平板一边改变窗口大小——这时候快照重算的请求可能会叠加。我以前在双屏折叠设备上调试时，发现一次屏幕折叠动作，居然触发了4次窗口重置和2次属性变化，导致快照重算队列堆积，最终主线程被卡死超过5秒，直接ANR。
所以我的建议是：在写代码时，不要假设“快照只会在一个时间点变化一次”。你要有意识地设计防御逻辑，比如在短时间内合并多次快照更新请求，或者延迟到Layout稳定后再触发。
总结触发场景的关键：
- 窗口区域：resize、move、split-screen切换
- 方向：0/90/180/270度旋转
- 缩放：手势缩放、程序化缩放、窗口DPI改变
- 属性：layerType、alpha、visibility、background
记住：这些触发条件不是孤立的。它们可以互相嵌套、叠加，形成链式反应。