本文译自「Breaking the Speed Barrier: How Non-Blocking Splash Screens Cut Android App Launch Time by 90%」，原文链接sankalpchauhan.com/breaking-th...，由Sankalp Chauhan发布于2025年9月28日。
概述
正值佳节期间，我们在每个应用上都能看到精美的启动画面和自定义徽标。在开发这些应用时，每个 Android 开发者都会面临启动画面的困境：用户期望获得美观且品牌化的启动体验，但 Google原生的启动画面 API 却存在明显的局限性。创建自定义 SplashActivity 的常见解决方案看似合理，但却会引入隐藏的性能损失，导致应用运行缓慢且响应迟钝。
为了应对这一挑战，我开发了一个名为EventSplash 的测试库，该库实现了一种非阻塞启动画面方法。完整的实现和基准测试代码可在 GitHub 上获取：fast-splash-experiment
本案例研究通过一项对照实验，比较了传统的基于活动的启动画面和创新的基于视图的启动画面方法，并提供了实证证据。使用保守的同类比较 ，结果显示：页面加载时间缩短 90% ，首次内容绘制时间提升 78% ，完全绘制时间缩短 41%。
我们将探索 Lottie 等复杂动画可能带来的显著优势，同时明确并发处理的利弊权衡和资源成本。
- 首次内容绘制 (FCP)：屏幕上出现第一个有意义内容的时间
- 完全绘制时间 (FPT)：屏幕完全渲染并可交互的时间
- 冷启动：应用在进程未运行时启动（性能影响最大）
- 卡顿：用户认为性能不佳的卡顿或掉帧
- TTID/TTFD：初始显示时间/完全绘制时间（Android 官方指标）
- 内存压力：可用内存极低时的系统状态
- 低内存终止程序 (LMK)：在内存压力下终止进程的 Android 守护进程
- Choreographer.doFrame：Android 的帧协调系统，用于管理动画、输入和绘制
问题声明
Google 原生的 Android 12+ SplashScreen API 性能出色，但自定义选项有限 [1]。它不支持：
- 视频背景
- Lottie 动画
- 复杂的品牌元素
- 促销/活动期间的促销内容
- 自定义过渡效果
这迫使开发者不得不进行自定义实现，通常使用专用的"SplashActivity"。虽然这种方法提供了创作自由，但它会创建一个阻塞序列，从而延迟应用主内容的显示。
为什么传统的闪屏活动会损害性能
Android 文档强调，应用应该针对冷启动进行优化，因为这"也可以提高温启动和热启动的性能"[2]。然而，传统的闪屏实现方式违背了这一原则。
当你使用单独的"SplashActivity"时，系统必须：
- 创建并初始化启动画面 Activity
- 扩展启动画面视图
- 运行启动画面动画直至完成
- 销毁启动画面 Activity
- 创建并初始化主 Activity
- 扩展主内容视图
这种顺序流程意味着你的主内容在启动画面完成之前无法开始加载，这是一个影响用户感知性能的根本架构缺陷。
折腾：探索不同的方法
在最终确定 EventSplash 实现方案之前，我探索了几种方法。了解这些探索为最终的设计决策提供了宝贵的背景，并展示了性能优化的迭代本质。
弃用的方法：半透明 Activity 覆盖
最初的想法是使用带有半透明主题的"SplashActivity"覆盖"MainActivity"。理论上，MainActivity 可以在后台加载，而启动画面则显示在最上面。
启动顺序：
- 应用以具有半透明主题的 SplashActivity 启动
- SplashActivity 显示在 MainActivity 之上，但不会完全遮挡 MainActivity
- 短暂延迟或初始化完成后，SplashActivity 结束，MainActivity 显露出来
弃用原因：
这种方法导致14% 的性能下降。问题在于 Android 处理 Activity 生命周期和渲染的方式。系统并非真正并行启动两个 Activity。相反，它创建了一种顺序依赖关系，GPU 被迫组合两个独立的 Activity 缓冲区，这会在 RAM 和电池方面造成巨大的开销，有时甚至会禁用窗口过渡动画。
正如 Android 文档中关于半透明 Activity 的说明 [3]：
"窗口管理器会保持原先的屏幕表面按 Z 轴顺序排列，并将新的屏幕表面混合在其上方。原先的 Activity 仍然可以通过新窗口中任何透明或部分透明的像素看到。"
正是这种混合操作导致了性能下降。
制胜之道：门控启动画面机制
我最终找到了一种更复杂的方法，它采用了门控启动画面机制。此方法使用"ViewTreeObserver.OnPreDrawListener"来阻止所有 UI 渲染，直到满足特定条件为止。
工作原理：
- 启动时，会立即将
OnPreDrawListener附加到 Activity 的decorView上。 - 监听器的
onPreDraw()方法返回false，从而有效阻止所有绘制操作。 - 监听器仅在所有条件都满足时才返回
true，允许内容渲染。
关键实现：
kotlin
// The gate mechanism
gate.onPreDraw() → returns false = BLOCK all drawing
gate.onPreDraw() → returns true = ALLOW drawing to proceed这种方法完全符合 Android 官方文档中关于延长启动画面在屏幕上停留时间的建议 [1]:
"如果你需要加载少量数据，例如从本地磁盘异步加载应用内设置，可以使用 ViewTreeObserver.OnPreDrawListener 暂停应用以绘制其第一帧。"
EventSplash 库扩展了这一概念，在应用启动时提供对用户可见内容的帧完美控制，防止任何内容闪烁，确保无缝体验。
实验：测量实际影响
测试环境
- 设备：小米 POCO F1，Android 10
- 构建：发布配置
- 方法：每个配置 35 次冷启动，每次运行之间暂停 2 秒
- 指标：自定义 PerfTracker 库，用于测量页面加载时间、FCP 和 FPT
- 脚本 ：通过
perf_loop.sh自动执行可重复性
所有测试代码和脚本均可在 GitHub 代码库
测试的实现方法
- 默认阻塞闪屏 ：简单的
SplashActivity和基本路由（保守的基准） - 默认非阻塞闪屏：EventSplash 库和简单的叠加层
- Lottie 阻塞闪屏：传统方法和复杂的动画
- Lottie 非阻塞闪屏：EventSplash 与 Lottie 动画并行运行
结果：保守的声明，但效果显著潜力
真实对比：默认闪屏性能
为了进行同类比较，我们重点关注在默认的闪屏实现中，阻塞方法只是简单地为了路由目的而扩大 Activity：
| 方法 | 页面加载时间 (毫秒) | FCP (毫秒) | FPT (毫秒) | 用户影响 |
|---|---|---|---|---|
| 默认阻塞 | 366 | 744 | 2,195 | 明显的延迟 |
| 默认非阻塞 | 37 | 164 | 1,295 | 流畅、响应迅速 |
| 提升 | 90% | 78% | 41% | 显著提升 |
Lottie 动画的优势
当我们引入复杂的 Lottie 动画时，架构上的差异会更加明显发音：
| 方法 | 页面加载时间 (毫秒) | FCP (毫秒) | FPT (毫秒) | 备注 |
|---|---|---|---|---|
| Lottie 阻塞 | 2,228 | 2,347 | 3,524 | 包含动画时长 |
| Lottie 非阻塞 | 109 | 312 | 1,467 | 动画并行运行 |
| 提升 | 95% | 87% | 58% | 显著提升 |
理解 Lottie 数值
重要提示 ：Lottie 阻塞数值在设计上包含动画时长，用户必须等待整个动画完成后才能看到任何主要内容。在非阻塞方法中，动画和内容加载并行运行，因此当 Lottie 动画完成时，FPT 通常已经完成或接近完成。
这种并行执行是其关键的架构优势：无需牺牲性能即可获得精美的动画。
性能改进细分
改进图表
回顾：发生了什么
即使与保守的默认启动画面相比，非阻塞方法也实现了90% 的页面加载速度提升次。用户体验从"明显的延迟"转变为"流畅且响应迅速"。
对于像 Lottie 这样的复杂动画，其优势更加显著，因为传统方法迫使用户等待整个动画序列，然后才会出现任何有意义的内容。
原因：技术机制
性能提升源于并行执行 。传统方法顺序 运行启动画面和主内容，而基于视图的方法并发运行它们：
传统（顺序）：
css
Splash Activity → Animation → Destroy → Main Activity → Content Load → Display非阻塞（并行）：
css
Main Activity + Content Load (background)
↓
Splash View (overlay) → Remove overlay → Display loaded content这种架构差异彻底消除了阻塞瓶颈。
深入探究：理解技术实现
传统的 Splash Activity 实现
kotlin
class SplashActivity : ComponentActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
installSplashScreen()
enableEdgeToEdge()
setContent {
Loader { // Blocks until animation completes
startActivity(Intent(this@SplashActivity, MainActivity::class.java))
}
}
}
@Composable
fun Loader(onComplete: () -> Unit) {
val composition by rememberLottieComposition(LottieCompositionSpec.RawRes(R.raw.sale_tags))
val progress by animateLottieCompositionAsState(composition)
// Animation blocks main content loading
if (progress == 1.0f) {
onComplete.invoke()
}
}
}EventSplash：非阻塞实现
kotlin
class EventSplash(
private val activity: ComponentActivity,
private val config: EventSplashConfig,
) {
private val decorView: ViewGroup = activity.window.decorView as ViewGroup
private var composeView: ComposeView? = null
// Gate prevents premature display until main content ready
private val gate = object : ViewTreeObserver.OnPreDrawListener {
override fun onPreDraw(): Boolean {
return if (isReady) {
decorView.viewTreeObserver.removeOnPreDrawListener(this)
true
} else false
}
}
init {
decorView.viewTreeObserver.addOnPreDrawListener(gate)
setupSplashCompose() // Non-blocking overlay
isReady = true
}
private fun setupSplashCompose() {
val view = ComposeView(activity).apply {
layoutParams = ViewGroup.LayoutParams(MATCH_PARENT, MATCH_PARENT)
setContent {
getProvider(config).Content(onFinish = { dismiss() })
}
}
composeView = view
decorView.addView(view) // Overlay on main content
}
}使用情况比较
传统方法:
kotlin
// Requires separate activity, blocks main content
class MainActivity : ComponentActivity() {
// Main content only loads after splash completes
}EventSplash 方法:
kotlin
class MainActivity : ComponentActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
// Non-blocking: splash displays while content loads
EventSplashApi.attachTo(this).with(getSaleConfig()).show()
setContent {
// Main content loads immediately in parallel
MainAppContent()
}
}
}回顾：实现差异
传统方法需要单独的 Activity 生命周期，而 EventSplash 会注入一个与主内容加载过程共存的视图叠加层。
原因：架构优势
- 单一 Activity 上下文：消除 Activity 转换开销
- 并行处理：主内容在启动画面显示时加载
- 减少内存占用：没有重复的 Activity 对象
- 减少 Choreographer.doFrame 循环：减少渲染管线压力
- 优化视图层级：使用单一装饰视图，而非多个独立的 Activity
Choreographer.doFrame 问题
理解帧渲染问题
Android 的渲染系统依赖于 Choreographer.doFrame 来协调动画、输入和绘制 [4]。文档警告：
"如果 Systrace 显示 Choreographer#doFrame 的布局部分工作过多或过于频繁，则意味着你遇到了布局性能问题"
为什么闪屏 Activity 会导致卡顿
传统的闪屏实现会造成多个性能瓶颈：
- 双重布局传递：每个 Activity 都需要单独的视图填充和布局
- 上下文切换开销：操作系统必须管理多个 Activity 上下文
- 内存压力：重复的视图层次结构会消耗额外的 RAM
- 帧时序问题：Activity 转换会触发额外的 doFrame 周期
Perfetto 分析洞察
使用 Perfetto 分析轨迹时，传统的启动画面会显示：
Choreographer.doFrame执行时间延长- 布局膨胀多次峰值
- 垃圾回收压力增加
- 主线程可用性延迟
基于视图的方法通过在整个启动过程中维护单一渲染上下文来消除这些问题。
⚠️ 关键考虑：并发处理并非免费
虽然我们的结果显示性能显著提升，但非阻塞方法也带来了一系列挑战，必须仔细考虑。同时运行启动动画和主内容加载会带来额外的资源压力，而顺序加载方法则不会出现这种压力。
内存压力：主要问题
峰值内存使用量增加：
nix
// Memory usage pattern comparison
Traditional Approach:
Splash: 50MB → 0MB → Main Content: 120MB = Peak: 120MB
Non-blocking Approach:
Splash + Main Content: 50MB + 120MB = Peak: 170MB实际影响：
- 简单的闪屏叠加在并发执行期间会增加 20-50MB 的内存
- Lottie 动画在渲染期间可能会消耗 50-100MB 以上的内存
- 综合峰值使用量可能比顺序加载方法高出 40-70%
- 低端设备（1-2GB RAM）容易受到内存压力的影响
低内存杀手风险
Android 的低内存终止守护进程会监控系统内存，并可能在压力下终止应用 [5]:
"内存压力是指系统内存不足的状态，需要 Android 通过限制或终止不重要的进程来释放内存"
风险因素:
- 启动过程中终止应用进程会导致糟糕的用户体验
- 后台应用被更频繁地终止
- 并发分配导致的内存碎片
- 在预算设备上尤其成问题
CPU 和电池影响
CPU 开销增加：
Choreographer.doFrame处理多个并发操作- 主线程因 UI 工作重叠而变得更加繁忙
- GPU 渲染管线同时处理启动画面和内容
功耗问题 ：研究表明，"智能手机上的 UI 渲染需要强大的 CPU 和 GPU 才能满足用户感知的流畅度，并且这占了相当一部分的功耗"[6]。
设备兼容性挑战
低端设备注意事项:
- 单核或双核处理器难以并行化
- 有限的 RAM 使得内存压力至关重要
- 较慢的存储速度加剧加载延迟
- 优势可能无法转化为低端设备的优势
何时不应使用非阻塞方法
传统方法可能更佳的场景：
- 资源极其受限的设备（< 2GB RAM）
- 电池关键型应用，功耗至关重要
- 简单的启动画面，没有复杂的动画
- 启动处理繁重的应用，已经给应用带来了压力系统
- 遗留代码库，重构风险大于收益
风险缓解策略
自适应实施：
kotlin
class AdaptiveSplashStrategy {
fun chooseSplashApproach(): SplashConfig {
return when {
isLowEndDevice() -> SimpleSplashConfig()
isBatteryLow() -> ReducedAnimationConfig()
isHighPerformanceDevice() -> FullLottieConfig()
else -> DefaultConfig()
}
}
private fun isLowEndDevice(): Boolean {
val activityManager = getSystemService(Context.ACTIVITY_SERVICE) as ActivityManager
return activityManager.isLowRamDevice ||
Runtime.getRuntime().maxMemory() < 256 * 1024 * 1024
}
}内存监控：
kotlin
private fun monitorMemoryPressure() {
val memoryInfo = ActivityManager.MemoryInfo()
activityManager.getMemoryInfo(memoryInfo)
if (memoryInfo.lowMemory) {
// Fallback to simpler splash
simplifyOrDismissSplash()
}
}行业背景和验证
与行业最佳做法保持一致实践
EventSplash 方法符合最新的行业趋势和官方建议。像 Turo 这样的公司通过消除专用的启动活动也取得了类似的效果。正如他们的案例研究 [7] 中所述：
"最初，我们使用专用的 SplashActivity 来运行所有启动工作，然后再将应用路由到 HomeActivity。然而，最新的指南建议不要采用这种方法。因此，我们移除了多余的 SplashActivity，并将所有启动逻辑转移到了根 Activity。"
Turo 使用类似的原理实现了77% 的启动时间缩短。
通过官方文档验证
Android 官方文档明确建议使用"ViewTreeObserver.OnPreDrawListener"进行启动画面管理，[1]，这进一步验证了该方法，而这正是 EventSplash 的核心实现。
最佳实践和常见陷阱
建议✅
- 在性能强大的设备上，使用基于视图的启动画面实现自定义动画
- 根据设备性能实施自适应策略
- 使用真实设备**测量性能，并跨设备层级发布版本
- 监控内存使用情况**并实施内存泄漏预防
- 针对最坏情况进行冷启动优化
- 在低端设备上进行广泛测试**以确保广泛的兼容性
- 为启动画面实施适当的生命周期管理
注意事项❌
- 不要想当然地认为一刀切：设备性能差异巨大
- 不要忽视内存压力：监控并适应系统限制
- 不要在未考虑替代方案的情况下使用单独的 SplashActivity
- 不要用启动画面动画阻碍主内容加载
- 不要忽略 Play 管理中心内的 Android Vitals 指标
- 不要只在高端设备或调试版本上进行测试
- 不要在启动画面中创建复杂的视图层次结构
- 不要在启动画面中执行繁重的操作
- 不要忘记清理启动画面并清除缓存
常见陷阱
- 内存泄漏：未能清除 LottieCompositionCache
- 设备能力假设：未适应低端设备限制
- 生命周期问题：未正确处理 Activity 状态变化
- 动画冲突：闪屏动画干扰主内容
- 测试偏差：仅在快速设备或调试版本上进行测试
- 指标误解：关注动画时长而非用户感知的性能
- 资源监控疏忽：未监控内存和 CPU 使用模式
制定明智的架构决策
决策框架
在选择启动画面方案时，请考虑以下因素：
设备受众特征：
- 你的用户中有多少比例使用低端设备？
- 你支持的最低 RAM 配置是多少？
- 你是否瞄准了拥有廉价设备的新兴市场？
应用特性：
- 你的主要内容加载复杂度如何？
- 你是否对网络依赖性很强？
- 你当前的内存占用是多少？
业务需求：
- 自定义启动动画对你的品牌有多重要？
- 你能实现渐进式增强吗？
- 你的开发和测试能力如何？
推荐策略
渐进式增强方法：
kotlin
EventSplashApi.attachTo(this)
.withFallback(SimpleSplashConfig())
// Low-end devices
.withStandard(ImageSplashConfig())
// Mid-range devices
.withEnhanced(LottieConfig())
// High-end devices
.adaptToDevice()
// Automatic selection
.show()此方法提供：
- 适用于所有设备的基本功能
- 在资源允许的情况下增强体验
- 根据设备性能自动适配
- 在内存压力下优雅降级
见解与建议
非阻塞启动画面方法显著提升性能 （保守测试中页面加载速度提升 90%，复杂动画下最高可达 95%），但也存在一些不足。并发处理会增加峰值内存使用量和 CPU 开销，这在低端设备上可能会造成问题。
关键见解：其优势显著且可衡量，但也伴随着资源成本，必须通过自适应的实施策略进行管理。
诚挚建议：使用非阻塞方法并结合设备感知回退机制。即使是保守估计，也能显示出显著的性能提升，其架构优势也令人信服。然而，该实现必须足够复杂，才能支持所有 Android 设备。
结论
_本案例研究表明，性能优化需要在保持诚实声明的同时平衡相互竞争的约束条件。非阻塞、基于视图的方法提供了显著且可衡量的优势，但成功实施需要深入了解其收益和成本。
通过摆脱传统的"SplashActivity"模式，采用更复杂、更并发的架构，我们可以构建速度更快、响应更灵敏的 Android 应用，并在整个生态系统中可靠地运行。
我们的目标不仅仅是构建更快的应用，而是构建使用体验即时、愉悦的应用，因为最终，性能是用户能够注意到并欣赏的功能。
参考
- 闪屏 | 视图 | Android 开发者
- 应用启动时间 | 应用质量 | Android 开发者
- Android 生命周期速查表 --- 第四部分：ViewModel、半透明 Activity 和启动模式 | 作者：Jose Alcérreca
- 渲染缓慢 | 应用质量 | Android 开发者
- 低内存终止守护进程 (lmkd) | Android 开源项目
- 移动 UI 渲染功耗研究
- Turo 利用 Android 开发者工具和最佳实践将其应用启动时间缩短了 77%
欢迎搜索并关注 公众号「稀有猿诉」 获取更多的优质文章！
保护原创，请勿转载！