Android热启动闪屏排查与SplashScreen最佳实践

1. 问题现场：明明冷启动很顺，一热启动就“闪”一下

有一段时间，我在做一款工具类App，冷启动流程一直是正常的：点击图标，启动页出现，1.5秒后进主页，一切按预期走。可后来测试同学提了一个bug，说“App切到后台再切回来，会凭空闪一下启动图，有时候还会闪白一下”。一开始我不太信，因为代码里启动页在冷启动完成后就 finish() 了，理论上跟主界面没有关系。但自己复现了几次，发现确实存在——而且不是偶现，在低端机上几乎是稳定复现。这个问题就是典型的“热启动应用闪屏”：进程还活着，Activity被重新拉到前台，SplashScreen相关的资源或页面被重复触发，视觉上就是用户看到了一次多余的闪屏。

这个现象很容易被误判成“启动图没关闭干净”或者“布局重影”。但排查下来，根因往往在启动页的收场方式、任务栈状态、以及Android系统版本对SplashScreen的处理差异上。如果你最近也在被这个问题困扰，或者马上要接入SplashScreen，建议把这篇看完，我会从冷启动和热启动的底层差异讲起，再把两种主流SplashScreen实现（自定义启动Activity / Android 12系统级SplashScreen）的踩坑点全部摊开，最后给出一份可以直接抄走的排查清单。

这篇文章主要面向Android开发者，但如果你在用Flutter或React Native，最后也会提到原生侧的原因，因为跨端框架的SplashScreen最终也绕不开原生这一层。内容会偏实战，尽量少讲理论废话，多给能落地的东西。

2. 为什么热启动会触发闪屏：先搞懂冷启动和热启动的真实差异

2.1 冷启动、温启动、热启动的状态区分

在Android里，启动方式被分为冷启动、温启动、热启动，但很多开发者在写SplashScreen时只考虑冷启动，根本没有为热启动做任何处理。这是问题频发的根源。

冷启动时，系统要从零创建进程、Application、Activity，屏幕上会先显示系统的启动窗口，你自定义的SplashScreen才有意义。而热启动时，进程和Activity都还在，系统只是把任务栈从后台调到前台，理论上根本不应该出现“完整启动页”。但如果你在Activity的 onCreate、onResume、onWindowFocusChanged 这些生命周期里插入了跟启动相关的逻辑，或者你的SplashActivity还留在任务栈里，那么热启动时这些逻辑就会被再次执行，闪屏就这么来的。

我见过最典型的错误写法：SplashActivity在 onCreate 里启动一个延时任务，2秒后 startActivity(MainActivity)，如果用户在第1秒切到后台，第2秒再切回来，SplashActivity的延时任务要么没执行完又要重新执行，要么已经执行到一半导致页面跳转混乱。这些都是没有区分生命周期场景导致的。

2.2 系统SplashScreen（Android 12+）在热启动时的行为

Android 12开始引入了系统级SplashScreen，也就是点击App图标时由系统统一绘制的那层启动画面。它的触发时机是冷启动和温启动，热启动时系统不会重新走一次完整的启动画面。但这里有个容易被忽略的细节：从后台回到前台时，Android 12+系统会为应用窗口播放一段“入口过渡动画”（splash screen exit animation），动画元素来自你配置的 windowSplashScreenAnimatedIcon 和 windowSplashScreenBackground。

如果开发者把启动图标或背景色配置得很显眼，并且没有单独给热启动场景做区分，用户从后台切回来时，就会看到系统级SplashScreen的图标“闪”了一下。虽然这个过程非常短，但在视觉上仍然可以被感知成闪屏，尤其是在低刷新率屏幕上。

所以，Android 12+下正确做法是：系统SplashScreen只负责冷启动的窗口占位，不要再在它的基础上叠加自定义SplashActivity。如果你需要品牌展示、广告位、版本公告之类的功能，应该放到MainActivity里面用View或Fragment去承载，而不是再封一个启动页Activity。这样系统级的“闪”只会在冷启动时出现，热启动时即使有过渡动画，也只是一次很轻的窗口过渡，不会让用户觉得是闪屏。

2.3 自定义SplashActivity在热启动时的“复活”陷阱

很多老项目还在用自定义SplashActivity，也就是主题里的 android:windowBackground 设成启动图，或者直接是一个全屏的SplashActivity，启动后跳MainActivity。这种方案在冷启动时没什么问题，但热启动时会踩一个非常经典的坑：SplashActivity跳转MainActivity时没有把自己从任务栈里清掉。

举个例子。SplashActivity执行了 startActivity(intent) 后，如果没有执行 finish()，或者finish时机被写在了延时回调里、回调还没执行App就切后台了，那么SplashActivity就一直躺在返回栈的底部。用户再次切回App时，系统恢复的是栈顶Activity，这个没问题；但如果栈顶Activity因为内存等原因被回收了，系统就可能去重建SplashActivity——因为它在栈里。此时SplashActivity的 onCreate 会再次执行，再次跳转MainActivity，用户看到的就是“闪了一下启动页”，甚至“点击图标后跳来跳去”。

还有另一种情况：SplashActivity在栈里，用户切到后台后任务栈被系统清理，或者在开发者模式里设置了“不保留活动”，热启动时恢复的就是SplashActivity。如果 onCreate 里有倒计时、网络请求、广告SDK初始化，那么这些逻辑会被重复执行一遍，不仅闪屏，还可能导致广告重复弹出、埋点重复上报。

所以自定义SplashActivity方案下，“热启动闪屏”不是某一行代码写错了，而是启动页的生命周期没有跟任务栈的回收恢复机制对齐。这不是偶发问题，是结构性缺陷，需要在设计启动流程时就把热启动场景考虑进去。

3. 最推荐的方案：用系统SplashScreen API，而不是自定义闪屏页

3.1 Android 12+ SplashScreen的配置步骤

如果你的App最低支持版本已经到Android 12（API 31）以上，那没有任何理由继续用自定义SplashActivity，直接用系统SplashScreen API就好。配置方式不复杂，核心分三步。

第一步，创建一个专门用于启动页的主题，继承自系统提供的启动主题。在 values-v31/themes.xml 里定义：

xml复制<style name="Theme.App.Starting" parent="Theme.SplashScreen">
    <item name="windowSplashScreenBackground">@color/splash_bg</item>
    <item name="windowSplashScreenAnimatedIcon">@drawable/splash_icon</item>
    <item name="windowSplashScreenIconAnimationDuration">300</item>
    <item name="postSplashScreenTheme">@style/Theme.App</item>
</style>

第二步，在AndroidManifest里把应用主题换成 Theme.App.Starting：

xml复制<application
    android:theme="@style/Theme.App.Starting"
    ... >

第三步，保持正常启动逻辑即可，不需要写SplashActivity，也不需要 startActivity 跳转，冷启动时系统自动展示启动画面，启动完成后自动过渡到 postSplashScreenTheme 指定的主题。

这里要说一下为什么推荐这种方案：系统SplashScreen对热启动的抑制是系统级的。它在热启动时只播放窗口恢复过渡动画，不会重新创建Activity，不会重新加载布局，也不会触发你写的那一堆启动逻辑。你不再需要担心SplashActivity在任务栈里复活、延时跳转被打断之类的问题。可以说，系统SplashScreen天然规避了热启动闪屏80%的根因。

3.2 兼容库androidx.core:core-splashscreen的用法

如果你的App还要兼容Android 11及以下版本，可以用 androidx.core:core-splashscreen 这个兼容库，它把Android 12的系统SplashScreen行为移植到了低版本。接入后，低版本设备上也能获得一致的启动体验，并且同样天然规避热启动闪屏。

接入方式也比较简单。在 build.gradle 添加依赖：

groovy复制dependencies {
    implementation "androidx.core:core-splashscreen:1.1.0"
}

然后在SplashActivity（或者你的入口Activity）的 super.onCreate() 之前调用 installSplashScreen()：

java复制public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        SplashScreen splashScreen = SplashScreen.installSplashScreen(this);
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
    }
}

installSplashScreen() 必须在 super.onCreate() 之前调用，这样系统才能在你初始化布局前把启动窗口挂上去。如果你有数据加载逻辑，可以通过 setKeepOnScreenCondition 控制启动窗口保留的时长。注意这个条件判断要谨慎，不要在热启动场景里主动设置 true 并一直不设置 false，否则用户从后台切回来时会一直停在启动窗口上，看起来比闪屏更严重。

兼容库支持API 21及以上，也就是Android 5.0以上都能用。我踩过的一个小坑是：如果项目里已经用了自定义的 Theme.SplashScreen 主题，并且低版本上在 windowBackground 里放了一张大图，即使接入了兼容库，低版本设备热启动时仍然会从窗口背景恢复，看起来还是闪一下。所以接兼容库时，要确保项目里所有自定义启动主题都切到 Theme.SplashScreen 派生主题，不要再单独用 windowBackground 做启动图。

3.3 为什么系统SplashScreen天生规避热启动闪屏

核心原因在于：系统SplashScreen不是“页面”，而是窗口级别的启动背景。它不参与Activity的生命周期，不进入返回栈，也不存在“被恢复”“被重新创建”的概念。冷启动时，系统绘制它；启动完成后，系统移除它。热启动时，窗口恢复动画只涉及系统窗口的透明度、位移等层面，不触发你代码里的任何逻辑。

而自定义SplashActivity本质上是一个Activity，它回到前台、被系统回收、被重建，都会走生命周期回调。只要你在生命周期回调里写了一点跟启动相关的逻辑，热启动就有概率触发它。即便是最精简的写法（onCreate 里启动一个Intent跳MainActivity，然后 finish()），在任务栈状态异常时也可能出现无法预测的重复跳转。

从架构角度看，系统SplashScreen把“启动展示”这件事从应用代码里剥离出去了，让应用代码只关注“启动后做什么”，这本身就比“自己用Activity模拟启动页”合理得多。所以但凡你还能改动启动流程，我都建议优先选择系统SplashScreen，而不要去自己维护一套SplashActivity的兼容逻辑。用一句不太严谨的话总结：系统SplashScreen是一张车票，用完之后就作废了；自定义SplashActivity是一扇门，你随时可能推开它走进来，但你根本不想走进来。

4. 如果你仍用自定义SplashActivity：三个绕不开的处理细节

4.1 场景一：SplashActivity在返回栈里复活

有些项目因为历史原因没法立刻废弃SplashActivity，那就必须处理它“复活”的问题。最基础的一个要求是：跳转MainActivity后，立即 finish() 掉SplashActivity，并且要保证 finish() 是在跳转动作里同步执行，而不是放在延时回调或异步回调里。

java复制public class SplashActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_splash);
        startActivity(new Intent(this, MainActivity.class));
        finish();
    }
}

这样写之后，SplashActivity这个页面不在返回栈里留存，最基础的“恢复时回到启动页”问题就解决了。但要注意，仅仅 finish() 还不够，如果MainActivity的启动模式被设置成了 singleTask，并且SplashActivity是在 onCreate 里同步跳转的，那么当用户从MainActivity按返回键时，系统会去找返回栈里有没有可用的MainActivity实例。由于SplashActivity已经被移除了，一般不会再把启动页弹出来。

我遇到过另一种复杂情况：SplashActivity被某些推送SDK或第三方SDK隐式启动。比如推送点击时，SDK用 startActivity 拉起了一个Intent，但这个Intent被系统匹配到了SplashActivity，导致应用从后台回到前台时直接显示SplashActivity。这种场景下，即使在 onCreate 里 finish() 也会闪一下。解决办法是给SplashActivity添加过滤条件，或者在 onCreate 开头判断是否有跳转目标，如果没有就结束自己。

4.2 场景二：延迟跳转导致热启动重复进入MainActivity

如果你的SplashActivity里有倒计时逻辑，比如“2秒后进入主页”，热启动闪屏的风险就特别高。因为延时任务默认在Activity对应的Handler里排队，切后台不一定能取消，而切回来时 onCreate 可能已经再次执行了。两个Handler任务都在跑，最终就会触发两次跳转。

处理办法有两种。第一种：把延时跳转从Activity生命周期里拆出去，全局只执行一次。比如用一个静态变量或 SharedPreferences 标记是否已经完成过启动跳转，第二次创建SplashActivity时直接跳MainActivity并 finish()。

java复制public class SplashActivity extends AppCompatActivity {
    private static final String KEY_SPLASH_DONE = "splash_done";

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        if (isSplashDone()) {
            goMain();
            return;
        }
        setContentView(R.layout.activity_splash);
        setSplashDone(true);
        new Handler(Looper.getMainLooper()).postDelayed(this::goMain, 2000);
    }

    private void goMain() {
        startActivity(new Intent(this, MainActivity.class));
        finish();
    }
}

第二种：不做倒计时跳转，而是把SplashActivity当作一个空跳板，在 onCreate 里立即跳转MainActivity，品牌展示、广告等全部放在MainActivity的启动后流程中。这个方案更简单，也更接近系统SplashScreen的设计思路。我实际测试下来，这种方式对热启动闪屏的规避效果接近100%，因为SplashActivity根本不停留，也就不存在“热启动回到一个还在等倒计时的页面”这种事。

如果你实在需要在Splash页展示品牌或广告，建议控制在3秒内，并且要在 onPause 或 onStop 里取消延时任务、暂停所有异步操作。注意不要在 onDestroy 里去更新UI，那个时机可能已经有新的接口数据回来了，容易出并发问题。

4.3 场景三：启动逻辑里的异步等待被中断

有些SplashActivity会等待某些初始化完成后再跳转，比如热更新检查、登录态刷新、广告配置拉取。这些异步任务在冷启动时没问题，但在热启动恢复时会变得不可控。最典型的现象是：任务已经执行完，回调里写了 startActivity，但由于Activity被系统销毁过，Context已经失效，回调里拿到的Activity实例不是当前显示的实例，跳转就会失败或者重复。

针对这类问题，我建议把异步任务从SplashActivity里移出去，放到Application或一个独立的启动管理器里。Activity只负责观察状态并展示进度，不负责真正执行任务。这样热启动时，Activity重建后只需要查询当前状态，如果初始化已经完成就直接跳转，如果还没完成就继续等。这样至少能保证不会因为异步回调的时机问题导致闪屏或重复跳转。

这里可以用一个简单的观察者模式，或者直接用LivaData、StateFlow之类的方案。在SplashActivity里只是 observe 一个全局状态。状态一变化再跳MainActivity。这个改动看着变大，但它是把启动逻辑彻底从生命周期中解耦的唯一可靠做法。因为它不依赖Activity是否存活、是否被重建，也天然避免了“热启动时回调里拿到旧Activity”的经典问题。

4.4 一个通用的“启动页收场”模板

综合上面三个场景，如果你非要自己维护SplashActivity，我给你一个经过多轮验证的模板。这个模板不能保证覆盖所有业务，但可以避免90%以上的热启动闪屏问题。

java复制public class SplashActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        // 场景1：应用已经完成过启动跳转，直接去MainActivity
        if (isLaunchFinished()) {
            goMainAndFinish();
            return;
        }
        // 场景2：因任务栈恢复重建，但已经不在冷启动流程中
        if (savedInstanceState != null) {
            goMainAndFinish();
            return;
        }
        setContentView(R.layout.activity_splash);
        setLaunchFinished(true);
        // 场景3：有倒计时的话，在onStop里取消
        handler.postDelayed(this::goMainAndFinish, SPLASH_DURATION);
    }

    private void goMainAndFinish() {
        if (isFinishing() || isDestroyed()) {
            return;
        }
        Intent intent = new Intent(this, MainActivity.class);
        intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP | Intent.FLAG_ACTIVITY_SINGLE_TOP);
        startActivity(intent);
        finish();
    }

    @Override
    protected void onStop() {
        super.onStop();
        handler.removeCallbacksAndMessages(null);
    }
}

这个模板里最容易被忽略的是 savedInstanceState != null 这个判断。热启动时，如果SplashActivity之前被系统回收过，onCreate 会带着非空状态被重新执行。此时如果继续展示启动页，就会闪一下；如果你判断状态并直接跳转，用户感知到的就是“直接回到了主界面”，没有任何多余展示。这个判断简单但极其有效，它相当于给Activity加了一道结界：凡是恢复重建的实例，一律不再走启动展示流程。

5. 热启动闪屏排查清单与常见误判

5.1 按症状快速定位原因

开发中遇到问题，第一步永远是定位。我把热启动闪屏的常见症状整理成了一张速查表，你按照症状去找对应原因，能省不少排查时间。

对照这个表格，大部分情况都能判断个大概。如果还不行，建议先做一遍“最小复现”：把SplashActivity的跳转逻辑精简到只有 startActivity + finish()，再测试热启动。如果这时候不闪屏了，说明问题出在你额外添加的启动逻辑上，可以逐步加回来定位。

5.2 容易被误判的“白屏/黑屏”问题

热启动闪屏和白屏、黑屏经常会被混为一谈，但它们的原因完全不同。白屏通常发生在冷启动和热启动的过渡阶段，本质是系统窗口的背景色。如果你的launch theme里没有设置 windowBackground 或 windowSplashScreenBackground，系统会使用默认白色背景，屏幕恢复时就会出现白屏。

黑屏的原理相同，一般是主题设置成黑色或深色引起的。在比较老的华为、OPPO机型上，系统会强制使用深色启动背景，如果App没有适配深色模式，热启动恢复时窗口背景会闪成黑色。针对这种情况，可以在 values-night/themes.xml 里给启动主题单独设置浅色背景。注意 values-night 里的配置会让系统在深色模式下自动选用，如果你想让启动页无论深浅色都保持一致，可以用 forceDarkAllowed=false 规避系统强制深色。

另外还有一个我踩过的坑：如果MainActivity的布局加载很重，比如在 onCreate 里做了大量网络请求、数据库查询、列表初始化，那么热启动时即使没有SplashScreen，用户也会觉得App“卡了一下”。这种“假闪屏”其实不是闪屏，而是首页渲染时间太长。真正的解决办法是优化首页加载，而不是在SplashScreen上做文章。

5.3 实测中的一些独家经验

最后分享几条我在处理这个问题的过程中总结的实战经验，这些在官方文档里一般不会写。

第一，热启动闪屏出现频率最高的场景不是“用户主动按Home键再切回来”，而是“用户从App跳到微信/支付宝，几分钟后再回来”。因为在第三方App拉起后，当前App进程很可能被系统做了一定程度的整理，Activity状态更容易变化，恢复时机也更不可预测。所以复现问题时，建议模拟“切到其他重型App再切回来”这个路径，而不是简单地按Home再点图标。

第二，低端机上的热启动闪屏概率远高于高端机。原因很简单：低端机内存紧张，后台进程更容易被回收，Activity被重建的概率更高。如果你在开发机上测不出来，试着开一下开发者选项里的“不保留活动”，再测一遍热启动。它会让所有Activity在离开屏幕后立即销毁，能在几秒内复现出很多极端情况下的闪屏问题。

第三，如果项目接入了热修复、插件化框架，SplashScreen的坑会更多。因为这些框架经常要接管Application的创建流程，甚至会在Activity创建前加载补丁，容易把启动时间拉长，导致系统SplashScreen展示时间异常。这时候优先排查框架是不是在热启动时又重新执行了初始化流程。

第四，用adb命令排查启动时间时，adb shell am start 测的是冷启动，不能用来验证热启动闪屏。正确做法是用 am start -W 加 Intent.FLAG_ACTIVITY_SINGLE_TOP 模拟热启动，或者直接手动切后台再切回来，别偷懒，手工测才是最真实的。

第五，Flutter和React Native项目里如果出现了热启动闪屏，原因基本都在原生侧。我之前帮过一个RN项目排查，最后发现是 react-native-splash-screen 的 SplashScreen.show() 被写在了Activity的 onResume 里，只要App一回前台就重新显示启动图。Flutter项目常见的坑则是 flutter_native_splash 插件的冷启动背景配置在热启动时被当成恢复背景，导致启动图闪一下。这类跨端问题，不要只在Dart/JS层找原因，打开Android原生的MainActivity看一眼生命周期调用，往往几分钟就能定位。

6. 最后说点个人体会

做SplashScreen热启动适配这件事，看起来是一个很小的点，但它牵扯到启动架构、生命周期设计、任务栈管理，甚至跨端框架的原生调用，排查起来并不轻松。我自己的感受是：能交给系统的就不要自己实现，系统SplashScreen的概念就是专门解决这种“启动展示”和“业务启动逻辑”耦合的问题，强行用Activity模拟只会给自己埋坑。

如果你现在还在维护一个老旧的SplashActivity，也别急着推翻重写，先按第四章的模板把启动标记、savedInstanceState 判断、延时任务取消这三件事做掉，热启动闪屏大概率就能消掉。等以后版本迭代有空窗期了，再考虑迁移到系统SplashScreen方案。毕竟启动页这个功能，长期来看一定是系统层来越统一越省心。

我在实际测试中还有一个习惯：每次改完启动相关逻辑，都会在“不保留活动”模式下跑一遍全流程，再手动切换后台10次左右。如果你也能养成这个习惯，很多生命周期边界问题根本不会到你手里。最后再分享一个小技巧：给启动主题单独起一个名字 Theme.App.Starting，哪怕它跟主主题只有一行 postSplashScreenTheme 的差别，也能让排障的人一眼看懂哪些配置是针对启动页的。这个习惯帮我省了不少沟通成本，你也不妨试试。