闪白切换效果在五大UI框架中的实现与调优

「闪白切换」这个效果，第一次看到的人大多会觉得"不就是闪一下白嘛"，但真到自己动手实现，尤其是在多个 UI 框架之间来回切换时，才会发现每个框架给出的"画笔"完全不一样。Winform 给你的是 GDI+ 的 Graphics，WPF 给你的是保留模式渲染加 Storyboard，WinUI3 和 Avalonia 又各自有一套合成与动画体系，到了 Web 端则完全是 CSS 和 Canvas 的天下。同一个视觉目标，五种技术栈，五种思维方式，这件事本身就值得好好拆一拆。

这篇内容适合三类人看：一是正在做桌面端 UI 动效、想给页面切换加点"呼吸感"的开发者；二是需要在多个框架之间做效果对齐、保证视觉一致性的前端或客户端工程师；三是对动效原理感兴趣、想搞清楚"闪白"到底闪的是什么的手工型玩家。我会把每个平台的实现路径、关键参数、踩过的坑都摊开讲，重点不是给你一段能跑的代码就完事，而是让你明白为什么这个平台要这么写、换个参数会怎样、哪里最容易翻车。

1. 先搞清楚「闪白切换」到底在闪什么

很多人一上来就写代码，结果做出来的效果要么像屏幕坏了闪屏，要么像加载失败的白屏，完全没有那种"顺滑过渡"的高级感。问题出在对效果本身的理解上——闪白切换不是一个孤立的动画，它是一次状态切换的视觉包装。

1.1 效果的本质：用亮度峰值掩盖内容替换

拆开来看，闪白切换包含三个时间阶段：淡入白、白场停留、淡出白。内容替换发生在白场停留的那一小段时间里，因为此时屏幕接近纯白，人眼对内容的突变不敏感，替换就被"藏"起来了。这跟舞台换景时打一下强光是同一个道理——观众的注意力被光吸走，道具组趁机把布景换掉。

所以这个效果的核心参数不是"白有多白"，而是三个阶段的时长配比。我实测下来比较舒服的一组比例是：淡入 120ms、停留 60ms、淡出 180ms。淡出比淡入长，是因为人眼对"变亮"的容忍度高、对"变暗"的感知更细腻，淡出太快会有种"啪一下黑掉"的突兀感。这个比例不是死的，但方向别搞反。

1.2 白场不是纯白：透明度与叠加方式的选择

新手最容易犯的错是直接把一个纯白矩形盖上去，opacity 拉到 1。这样做的结果是切换瞬间整个界面"消失"了，用户会有明显的断层感。正确做法是让白色蒙层的峰值透明度控制在 0.85 到 0.95 之间，留一点点底层内容透出来。这点微弱的透出非常关键，它让大脑认为"还是同一个界面在变化"，而不是"跳到了另一个页面"。

另一个细节是叠加方式。白色蒙层应该是覆盖在内容之上、交互元素之下的独立图层，而不是替换内容本身。在保留模式框架里这很自然，但在立即模式（比如 Winform 的手动绘制）里，你得自己维护这个图层的绘制顺序，否则会出现蒙层被内容盖住、或者蒙层挡住了按钮点击的问题。

1.3 什么场景适合用，什么场景别硬上

闪白切换不是万金油。它适合同级别页面之间的切换，比如标签页切换、列表进入详情、主题切换。这些场景下用户预期内容会变，闪白起到的是"柔化"作用。

不适合的场景也很明确：表单提交后的结果页、需要用户立刻看清内容的错误提示、以及高频切换的场景（比如快速滑动列表）。高频场景下反复闪白会让人眼疲劳，甚至引发不适。我见过有人把它用在轮播图上，每 3 秒闪一次，那体验简直是灾难。判断标准很简单——如果这个切换用户一天要看几十次，就别闪。

2. Winform：用 GDI+ 手动绘制一条时间轴

Winform 是这五个平台里最"原始"的，没有内置的动画系统，一切都得自己算。好处是控制力最强，坏处是每一帧都得你亲手画。做闪白切换，本质上是在做一个基于定时器的透明度插值器。

2.1 用 Timer 驱动 + 双缓冲防闪烁

Winform 里做动画绕不开System.Windows.Forms.Timer，它的精度大概在 15ms 左右，对于闪白这种总时长 300ms 出头的效果来说够用了。关键是要开双缓冲，否则每帧重绘都会闪，那就不是"闪白切换"而是"闪屏切换"了。

public class FlashOverlay : Control { private readonly Timer _timer = new Timer(); private int _elapsedMs; private const int FadeInMs = 120; private const int HoldMs = 60; private const int FadeOutMs = 180; private const double PeakOpacity = 0.9; public FlashOverlay() { SetStyle(ControlStyles.OptimizedDoubleBuffer | ControlStyles.AllPaintingInWmPaint | ControlStyles.UserPaint, true); _timer.Interval = 15; _timer.Tick += OnTick; } public void Play() { _elapsedMs = 0; Visible = true; _timer.Start(); } private void OnTick(object sender, EventArgs e) { _elapsedMs += _timer.Interval; if (_elapsedMs >= FadeInMs + HoldMs + FadeOutMs) { _timer.Stop(); Visible = false; return; } Invalidate(); } protected override void OnPaint(PaintEventArgs e) { double alpha = ComputeAlpha(_elapsedMs); using var brush = new SolidBrush( Color.FromArgb((int)(alpha * 255), Color.White)); e.Graphics.FillRectangle(brush, ClientRectangle); } private double ComputeAlpha(int t) { if (t < FadeInMs) return PeakOpacity * t / FadeInMs; if (t < FadeInMs + HoldMs) return PeakOpacity; int outT = t - FadeInMs - HoldMs; return PeakOpacity * (1 - (double)outT / FadeOutMs); } }

这段代码的核心是ComputeAlpha这个分段函数，它把整条时间轴切成三段，每段做线性插值。SetStyle那三行是防闪烁的关键，OptimizedDoubleBuffer让绘制在内存位图上完成再一次性贴到屏幕，AllPaintingInWmPaint避免背景擦除引起的闪烁。

2.2 线性插值够不够？要不要上缓动

上面用的是线性插值，简单直接，但说实话观感偏"机械"。人眼对匀速变化的透明度感知是有点生硬的，尤其是淡出阶段。我后来把淡出段换成了 ease-out 曲线，观感立刻柔和不少：

private double EaseOutCubic(double x) => 1 - Math.Pow(1 - x, 3);

淡出时用EaseOutCubic(1 - outT / FadeOutMs)替代线性，起步快、收尾慢，符合"光逐渐散去"的物理直觉。淡入段我反而保留了线性，因为淡入要快、要果断，缓动会让它显得拖沓。这种"淡入线性、淡出缓动"的非对称处理，是我试了好几版之后定下来的，比两段都用同一种曲线自然得多。

2.3 Winform 里最容易翻车的两个点

第一个坑是控件层级。Winform 没有真正的 Z 轴，控件的叠放顺序由Controls集合的顺序和BringToFront决定。如果你的蒙层控件被某个后添加的控件盖住了，闪白就只闪了一半。解决办法是在Play()里先调BringToFront()，并且确保蒙层是最后添加的。

第二个坑是跨线程访问。如果你的切换逻辑跑在后台线程里，直接操作控件会抛异常。稳妥的做法是用Invoke把Play()封送（marshal）回 UI 线程。我见过有人图省事直接CheckForIllegalCrossThreadCalls = false，那是给自己埋雷，迟早出问题。

3. WPF：Storyboard 是主场，但别滥用

到了 WPF，画风完全变了。WPF 是保留模式渲染，你描述"这个矩形的不透明度从 0 变到 0.9 再变回 0"，框架帮你算每一帧。做闪白切换，最自然的路径就是DoubleAnimationUsingKeyFrames。

3.1 用关键帧动画描述三段式透明度

<Rectangle x:Name="FlashLayer" Fill="White" Opacity="0" IsHitTestVisible="False" Panel.ZIndex="999"> <Rectangle.Triggers> <EventTrigger RoutedEvent="Loaded"> <BeginStoryboard x:Name="FlashStoryboard"> <Storyboard> <DoubleAnimationUsingKeyFrames Storyboard.TargetProperty="Opacity"> <LinearDoubleKeyFrame KeyTime="0:0:0" Value="0"/> <EasingDoubleKeyFrame KeyTime="0:0:0.12" Value="0.9" EasingFunction="{StaticResource EaseInQuad}"/> <LinearDoubleKeyFrame KeyTime="0:0:0.18" Value="0.9"/> <EasingDoubleKeyFrame KeyTime="0:0:0.36" Value="0" EasingFunction="{StaticResource EaseOutCubic}"/> </DoubleAnimationUsingKeyFrames> </Storyboard> </BeginStoryboard> </EventTrigger> </Rectangle.Triggers> </Rectangle>

关键帧的时间点直接对应前面说的三段配比：0.12s 到峰值、0.18s 结束停留、0.36s 归零。IsHitTestVisible="False"这一行非常重要，它让蒙层不拦截鼠标事件，否则闪白期间用户点哪都没反应。Panel.ZIndex保证它盖在最上层。

3.2 为什么 WPF 里我更推荐代码触发而非 EventTrigger

上面用EventTrigger挂在Loaded上，适合"页面首次加载闪一下"的场景。但实际项目里，闪白往往是由业务逻辑触发的——比如用户点了某个按钮、数据加载完成。这时候用代码控制 Storyboard 更灵活：

private void PlayFlash() { var sb = (Storyboard)FindResource("FlashStoryboard"); sb.Begin(FlashLayer, true); // true 表示可被后续调用打断重来 }

Begin的第二个参数isControllable设为true很关键。闪白效果经常会被连续触发（用户快速点两下），如果不可控，第二次调用会排队等第一次播完，观感就是"卡了一下才闪"。设为可控后，新调用会立即接管，从当前状态重新开始，响应更跟手。

3.3 WPF 的性能陷阱：别让动画触发重排

WPF 里有个经典误区：用Width/Height/Margin做动画。这些属性变化会触发布局重算（measure/arrange），在复杂界面上会明显掉帧。闪白切换只动Opacity，这是渲染层的属性，不触发重排，性能上是安全的。

但还有个更隐蔽的坑——Opacity动画和Effect叠加。如果你给蒙层加了DropShadowEffect或BlurEffect，动画期间 GPU 合成压力会陡增。闪白蒙层本来就不需要阴影，老老实实一个纯色矩形最省。我踩过这个坑，加了模糊效果后低端机上直接掉到 20 帧，去掉就恢复了。

4. WinUI3：合成动画与 Composition 的正确姿势

WinUI3 的动画体系和 WPF 是两套东西。WPF 的 Storyboard 是 XAML 层的抽象，WinUI3 虽然也支持 Storyboard，但官方更推荐用Composition API，因为它跑在合成线程上，不占用 UI 线程，性能更好。

4.1 用 Compositor 创建透明度关键帧动画

private void PlayFlash(UIElement target) { var compositor = ElementCompositionPreview.GetElementVisual(target).Compositor; var visual = ElementCompositionPreview.GetElementVisual(target); var animation = compositor.CreateScalarKeyFrameAnimation(); animation.InsertKeyFrame(0f, 0f); animation.InsertKeyFrame(0.33f, 0.9f, compositor.CreateCubicBezierEasingFunction( new Vector2(0.4f, 0f), new Vector2(1f, 1f))); animation.InsertKeyFrame(0.5f, 0.9f); animation.InsertKeyFrame(1f, 0f, compositor.CreateCubicBezierEasingFunction( new Vector2(0f, 0f), new Vector2(0.6f, 1f))); animation.Duration = TimeSpan.FromMilliseconds(360); visual.StartAnimation("Opacity", animation); }

这里的关键帧位置用的是归一化比例（0 到 1），而不是绝对时间。0.33 对应 120ms/360ms，0.5 对应 180ms/360ms，和前面的配比完全一致。用比例的好处是改总时长时不用重算每个关键帧的绝对时间，只改Duration就行。

CreateCubicBezierEasingFunction的两个控制点，其实就是 CSS 里cubic-bezier()的那四个数。淡入用(0.4, 0, 1, 1)是偏 ease-in 的曲线，淡出用(0, 0, 0.6, 1)是偏 ease-out 的曲线，和 WPF 里用的缓动思路一脉相承。

4.2 Composition 动画为什么更稳

WinUI3 的 Composition 动画跑在独立的合成线程上，即使 UI 线程被业务逻辑占满，动画依然流畅。这对闪白切换特别重要——切换往往伴随着数据加载、页面构建这些重活，如果动画和这些抢 UI 线程，就会出现"闪到一半卡住"的尴尬。

代价是 Composition 动画的调试没那么直观。Storyboard 你能在 XAML 里一眼看到时间轴，Composition 动画是纯代码构建的，出问题只能靠日志和肉眼。我的经验是先在纸上把关键帧时间点算清楚再写代码，别边写边调，那样很容易把比例算乱。

4.3 蒙层元素的创建时机

WinUI3 里有个容易忽略的点：ElementCompositionPreview.GetElementVisual要求元素已经加载到可视化树里。如果你在页面构造函数里就调PlayFlash，visual 可能还是空的。稳妥做法是等Loaded事件之后再操作，或者干脆把蒙层做成页面里的常驻元素，只在需要时改它的Opacity，避免动态创建销毁带来的时机问题。

5. Avalonia：跨平台下的动画一致性

Avalonia 的定位是"跨平台的 WPF"，动画 API 确实和 WPF 很像，但细节上有不少差异。做闪白切换，Avalonia 支持 XAML 的Storyboard，也支持代码里用Animation类，我倾向于后者，因为跨平台场景下代码控制更容易做条件分支。

5.1 用 Animation 类构建可复用的闪白

public static Animation CreateFlashAnimation() { return new Animation { Duration = TimeSpan.FromMilliseconds(360), Easing = new CubicEaseInOut(), Children = { new KeyFrame { Cue = new Cue(0.0), Setters = { new Setter(OpacityProperty, 0.0) } }, new KeyFrame { Cue = new Cue(0.33), Setters = { new Setter(OpacityProperty, 0.9) } }, new KeyFrame { Cue = new Cue(0.5), Setters = { new Setter(OpacityProperty, 0.9) } }, new KeyFrame { Cue = new Cue(1.0), Setters = { new Setter(OpacityProperty, 0.0) } } } }; }

Cue就是归一化的时间点，和 WinUI3 的思路一致。Avalonia 的Animation对象是可以复用的，定义一次，多个控件RunAsync都行，这点比 WPF 每次Begin要新建 Storyboard 实例要省事。

5.2 跨平台渲染后端带来的差异

Avalonia 在不同平台上可能跑在不同的渲染后端上（Skia 是主流），这意味着同样的透明度动画，在 Windows 和 Linux 上的实际观感可能有细微差别，主要是帧率和合成时机的差异。我的做法是把总时长稍微放宽一点，比如从 360ms 放到 380ms，给低帧率环境留点余量，避免在性能较弱的设备上动画被"截断"。

另一个跨平台注意点是高 DPI 缩放。Avalonia 的坐标是逻辑像素，透明度动画不受影响，但如果你在蒙层上还叠加了其他视觉元素（比如一个图标），要确保它们在各种缩放比例下都对齐。纯色蒙层就没这个烦恼，这也是我建议蒙层保持"纯色、无内容"的原因之一。

5.3 Avalonia 里触发动画的推荐写法

var animation = CreateFlashAnimation(); await animation.RunAsync(flashLayer);

用await等待动画完成，可以在闪白结束后紧接着做内容替换，时序上非常干净。这比用定时器猜"大概闪完了"要可靠得多。如果你的切换逻辑是"闪白 → 换内容 → 淡出"，那更要把内容替换放在await之后、淡出之前——但注意，闪白动画本身是一整段，内容替换应该发生在白场停留期间，所以更精细的做法是把动画拆成淡入和淡出两段，中间await一下再换内容。

6. Web：CSS 才是闪白切换的最优解

Web 端做闪白切换，选择很多：CSS transition、CSS animation、Web Animations API、Canvas 手绘。我的结论很明确——优先用 CSS animation，它跑在合成线程上，性能好，代码也最简洁。

6.1 一个 keyframes 搞定三段式

@keyframes flash-switch { 0% { opacity: 0; } 33% { opacity: 0.9; } 50% { opacity: 0.9; } 100% { opacity: 0; } } .flash-overlay { position: fixed; inset: 0; background: #fff; pointer-events: none; opacity: 0; z-index: 9999; } .flash-overlay.playing { animation: flash-switch 360ms cubic-bezier(0.4, 0, 0.6, 1) forwards; }

pointer-events: none对应 WPF 里的IsHitTestVisible="False"，保证蒙层不挡交互。inset: 0是top/right/bottom/left: 0的简写，铺满视口。forwards让动画结束后保持最后一帧（opacity 0），避免闪回。

触发方式是在 JS 里加类名，动画结束后移除：

function playFlash(callback) { const overlay = document.querySelector('.flash-overlay'); overlay.classList.remove('playing'); void overlay.offsetWidth; // 强制重排，重置动画 overlay.classList.add('playing'); overlay.addEventListener('animationend', () => { overlay.classList.remove('playing'); callback && callback(); }, { once: true }); }

void overlay.offsetWidth这行是精髓——它强制浏览器重排，让动画能够重新开始。不加这行，连续调用playFlash时第二次不会重新播放，因为类名没变、动画状态没重置。这个技巧在 Web 动效里非常常用，值得记牢。

6.2 内容替换的时机控制

闪白切换的精髓是"在白场期间换内容"。用 CSS animation 的话，可以在animationstart之后用setTimeout在 150ms 左右（白场中段）执行替换：

function switchWithFlash(swapContent) { const overlay = document.querySelector('.flash-overlay'); overlay.classList.add('playing'); setTimeout(swapContent, 150); // 白场停留期间替换 overlay.addEventListener('animationend', () => { overlay.classList.remove('playing'); }, { once: true }); }

150ms 这个值对应的是淡入结束（120ms）之后、淡出开始（180ms）之前的窗口。这个窗口很窄，只有 60ms，所以setTimeout的精度要够。现代浏览器的定时器精度足够，但如果你的替换逻辑本身耗时较长（比如要渲染一个大列表），就要考虑把替换提前，或者用requestAnimationFrame配合。

6.3 Web 端的两个性能注意点

第一，别用background-color动画代替opacity。颜色动画会触发重绘（repaint），而 opacity 动画只触发合成（composite），性能差一个数量级。有人图省事直接动画background: rgba(255,255,255,0)到rgba(255,255,255,0.9)，在低端设备上会明显卡顿。

第二，蒙层用position: fixed而非absolute。fixed 定位的图层更容易被提升为独立的合成层，动画期间不会引起整个页面的重排。如果蒙层是absolute且父容器有复杂的布局，动画时可能连带触发父级的重排，得不偿失。

7. 五个平台横向对比：同一效果的参数映射表

把五个平台的实现放在一起看，会发现它们其实是同一套逻辑的不同表达。下面这张表是我整理的关键参数映射，做跨平台效果对齐时直接照着填就行。

这张表里最值得说的是"时间表达"这一行。Winform 和 WPF 用绝对时间，改总时长要重算每个关键帧；WinUI3、Avalonia、Web 用归一化比例，改总时长只改一个数。做跨平台对齐时，我建议统一用归一化比例来设计，最后再换算成绝对时间，这样参数管理最清晰。

另一个跨平台差异是缓动的默认行为。WPF 的LinearDoubleKeyFrame是纯线性，WinUI3 的InsertKeyFrame不传缓动也是线性，但 Web 的 CSS animation 默认是ease（不是 linear）。这个差异很容易导致"同样的参数，Web 上看起来更柔和"的错觉。对齐时务必在 CSS 里显式写linear或统一的cubic-bezier，别依赖默认值。

8. 实测中反复踩到的几个共性问题

跨五个平台做同一个效果，踩的坑有一半是共通的。这部分我按"问题现象 → 根因 → 处理方式"的结构整理，都是实打实调试出来的经验。

8.1 连续触发导致动画叠加或卡顿

现象：用户快速点击切换按钮，闪白效果要么叠加成一片死白，要么第二次点击没反应。

根因：大多数动画系统默认是"排队"而非"打断"。WPF 的 Storyboard 不设isControllable就会排队，Web 的 CSS animation 不加类名重置就不会重播，Winform 的 Timer 如果没重置_elapsedMs就会从上次的位置继续。

处理方式统一为"先重置再播放"：Winform 里Play()开头把_elapsedMs归零；WPF 里Begin(..., true)；Web 里先remove类名再强制重排再加回；WinUI3 和 Avalonia 里先StopAnimation再StartAnimation。这个模式在所有平台都适用，记住"重置优先"就不会错。

8.2 蒙层挡住了本该能点的元素

现象：闪白期间用户点按钮没反应，闪白结束后才恢复。

根因：蒙层默认参与命中测试（hit testing）。WPF 的Rectangle默认IsHitTestVisible=true，Web 的 div 默认接收指针事件，Winform 的控件默认接收鼠标消息。

处理方式：WPF 设IsHitTestVisible="False"，Web 设pointer-events: none，Winform 重写WndProc忽略鼠标消息或干脆把蒙层设为Enabled=false，WinUI3 和 Avalonia 同样设IsHitTestVisible=false。这一条是硬性要求，漏了就是功能性 bug。

8.3 高刷新率屏幕上的"过快"观感

现象：在 120Hz 或 144Hz 屏幕上，闪白效果显得特别急促，几乎看不清。

根因：动画时长是按 60Hz 的直觉调的，高刷屏上帧数翻倍，同样的时长内帧更多，人眼感知到的"变化速度"其实没变，但因为帧更密，过渡显得更"锐利"，主观上觉得快。

处理方式：不要按帧数调时长，按毫秒调。高刷屏上适当把总时长拉长 10% 到 15%，比如 360ms 调到 400ms 左右，观感会更接近 60Hz 屏幕上的体验。这个调整是主观的，建议在目标设备上实际看一遍再定。

8.4 深色主题下的"闪白"变成了"闪瞎"

现象：应用切到深色主题后，闪白效果刺眼得不行。

根因：白色蒙层在深色背景上对比度极高，峰值 0.9 的白色在深色主题下几乎是纯白一片。

处理方式：蒙层颜色跟随主题。深色主题下把蒙层换成深灰（比如#1a1a1a）或者降低峰值透明度到 0.6 左右，效果就从"闪白"变成"闪暗"，观感柔和很多。这个细节很多实现都忽略了，但在支持主题切换的应用里是必须处理的。我在一个项目里就是因为没做主题适配，深色模式下被用户吐槽"像闪光弹"。

9. 参数调优的实操方法论

效果做出来只是第一步，调到位才是真功夫。这部分分享我调这个效果时用的方法，不涉及具体平台，是通用的。

9.1 用"慢放"定位问题帧

正常速度下 360ms 的动画，人眼很难判断哪一段不自然。我的做法是临时把总时长放大 10 倍（3.6 秒），慢放观察每个阶段的过渡。这时候淡入是否太陡、白场是否太长、淡出是否拖沓，一目了然。定位到问题段之后，再按比例缩回正常时长微调。

这个方法在五个平台上都适用，因为改的都是时长参数。Winform 改常量，WPF 改 KeyTime，WinUI3 改 Duration，Avalonia 改 Duration，Web 改 animation-duration。慢放调完再恢复，比在正常速度下反复试错效率高得多。

9.2 峰值透明度的"临界点"测试

0.9 这个峰值不是拍脑袋定的。我的测试方法是：从 1.0 开始，每次降 0.05，观察"内容是否还能隐约透出"。降到 0.85 左右时，底层内容的轮廓开始可辨；降到 0.8 时，透出已经比较明显，切换的"隐藏感"就打折扣了。所以 0.85 到 0.9 是甜点区，具体取哪个值看你的内容复杂度——内容越复杂，越要往 0.9 靠，避免透出太多造成视觉混乱。

9.3 时长配比的"黄金比例"验证

前面给的 120/60/180 是我在多个项目里验证过的配比，比例大约是 2:1:3。这个比例的逻辑是：淡入要快（占 1/3），白场要短（占 1/6），淡出要缓（占 1/2）。如果你觉得效果"不够明显"，优先加白场时长；觉得"太拖沓"，优先减淡出时长。淡入时长我建议不要低于 100ms，否则会有"啪一下"的突兀感。

调参这件事没有标准答案，但有个原则：每次只改一个参数，改完立刻看效果。同时改多个参数，你永远不知道是哪个起了作用。我早期就是贪快，一次调三个数，结果调了半天反而离目标越来越远。

10. 一些不那么"技术"但很关键的经验

最后聊几个偏经验层面的东西，都是文档里不会写、但实际做项目时绕不开的。

蒙层要"常驻"而非"动态创建"。五个平台里，动态创建蒙层元素都会带来时机问题——创建到显示之间有一帧的空窗，动画可能从错误的状态开始。把蒙层做成页面里的常驻元素，初始opacity: 0或Visibility: Collapsed，需要时改状态，稳定得多。代价是每个页面多一个空元素，但这点开销完全可以接受。

动画结束的回调要防重入。闪白结束往往要触发后续逻辑（比如真正切换页面），如果回调里又有可能触发新的闪白，就会形成递归。加一个isAnimating标志位，动画期间忽略新的触发请求，是最简单的防护。这个标志位在五个平台都需要，别指望框架帮你管。

别在动画里做重活。闪白期间应该是"什么都不做"的，内容替换要足够轻量。如果替换逻辑本身要几百毫秒（比如加载远程数据），那闪白就失去了意义——用户会看到白场结束后内容还在转圈。正确做法是数据先准备好，闪白只负责视觉过渡。这个顺序搞反了，效果再精致也没用。

测试要在真实设备上做。模拟器和高端开发机上的表现，和用户的实际设备可能差很远。低端安卓机、老款笔记本、高刷显示器，这三种设备上的观感差异很大。我习惯在至少一台低端设备上过一遍，确认动画不卡、不截断，才算完成。

这套东西做下来，你会发现「闪白切换」表面是个视觉特效，骨子里是对时间、透明度、图层顺序的精确控制。五个平台给了五套工具，但底层逻辑是同一套。把归一化时间、峰值透明度、缓动曲线这三个核心参数吃透，换任何平台都能快速复现。真正拉开差距的，是那些踩过坑才知道的细节——重置优先、交互穿透、主题适配、常驻元素，这些才是让效果从"能跑"到"好用"的关键。