引言
应用启动性能是用户体验的第一道门槛。从用户点击图标到看到可交互界面，这个过程（TTI, Time To Interactive）每增加 1 秒，用户流失率就会上升约 7%。Android 应用的启动链路涉及 Zygote 进程 fork、Application 初始化、ContentProvider 注册、Activity 创建、视图inflation、以及首帧渲染等多个阶段。本文从启动类型分析、测量工具、Init 内体优化、App Startup 库原理到预加载策略，系统性地阐述 Android 启动优化的完整方法论。
一、冷启动、温启动与热启动
1.1 三种启动类型的完整分解
Android 的启动类型直接影响优化策略的选择。以下是三种启动类型的完整时间线分解：
冷启动（Cold Start）—— 最慢，最复杂
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Zygote fork → Process 创建 → Application() → attachBaseContext()
→ onCreate() → ContentProvider onCreate() × N
→ Activity onCreate() → onStart() → onResume()
→ inflation → 视图构建 → 首帧渲染 (drawFrame)
典型耗时：2000-4000ms（视设备性能而定）
优化空间：最大（因为包含最多的串行阶段）
温启动（Warm Start）—— 中等
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Activity onCreate() → onStart() → onResume()
→ inflation → 视图构建 → 首帧渲染
典型耗时：500-1500ms
优化空间：中等（跳过 Application 和 Provider 初始化）
热启动（Hot Start）—— 最快
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Activity onResume() → 视图重建（若未销毁）→ 首帧渲染
典型耗时：100-300ms
优化空间：最小（系统已持有 Activity 实例）在优化实践中，我们通常聚焦于冷启动阶段，因为它包含了最多的可优化节点。测量工具的选择和阶段分解是优化的第一步。
1.2 首帧时间的定义与 MTTI
启动时间的衡量指标并非单一值，不同的测量方法对应不同的优化目标：
TTID（Time To Initial Display）：首次绘制时间
→ 指标：窗口第一帧被绘制（Activity 的 decorView 首次可见）
→ 测量：adb shell am start -W -n pkg/activity
ActivityTaskManager: Displayed pkg/.MainActivity: +1s 234ms
MTTI（Minimum Time To Interactive）：最小可交互时间
→ 指标：用户可以与界面进行第一次有效交互
→ 测量：Macrobenchmark 中的 waitForIdle()
→ 这是用户真正关心的"启动完成"时刻
FMTTI（First Meaningful Paint Time）：首次有意义内容绘制
→ 指标：品牌 Logo 消失 + 首屏内容出现（不含骨架屏）
→ 测量：依赖自定义 Activity 的 onResume 时机 + ContentProvider 就绪在业务指标上，推荐同时追踪 TTID 和 MTTI——TTID 可以用自动化方式快速测量，MTTI 则反映真实用户体验。
二、测量工具：Systrace、Perfetto、Method Trace
2.1 Perfetto（推荐）与 Systrace
Perfetto 是 Google 推荐的下一代系统追踪工具，相比 Systrace 提供了更强大的 UI 和分析能力。
# 命令行录制（Android 10+）
adb shell perfetto \
-c - --txt \
-o /data/misc/perfetto-traces/boot_trace.perfetto-trace \
<< 'EOF'
buffers: {
size_kb: 63488
fill_policy: RING_BUFFER
}
data_sources: {
config {
name: "linux.ftrace"
ftrace_config {
ftrace_events: "sched/sched_switch"
ftrace_events: "power/suspend_resume"
ftrace_events: "power/cpu_frequency"
ftrace_events: "power/cpu_idle"
ftrace_events: "sched/sched_wakeup"
ftrace_events: "binder_transaction"
ftrace_events: "dalvik_vm_zygote"
ftrace_events: "dalvik_vm_jni"
}
}
}
data_sources: {
config {
name: "android.surfaceflinger.frametimeline"
}
}
duration_ms: 5000
EOF
# 拉取到本地
adb pull /data/misc/perfetto-traces/boot_trace.perfetto-trace .
# 使用 Perfetto UI 打开（https://ui.perfetto.dev）
# 或使用命令行工具分析
python -m perfetto_trace_converter \
--input_format=perfetto \
--output_format=json \
boot_trace.perfetto-trace boot_trace.jsonPerfetto 的核心使用技巧：在启动过程中搜索 ActivityThread → handleBindApplication → ContentProvider.onCreate → Activity.onCreate 的调用链，识别出耗时最长的 ContentProvider 和 Application.onCreate 阶段：
# Systrace（旧版，Python 工具）
python systrace.py \
-a com.example.app \
-b 16384 \
-o boot_trace.html \
dalvik,view,wm,am,app,sched,freq,idle \
--app Startup优化采样
# 关键 HTML 报告中的颜色编码：
# 红色/粉色：CPU 争用（主线程被阻塞）
# 橙色：Binder IPC 调用
# 黄色：系统 API 调用（锁等待）
# 绿色：正常运行
# 分析脚本：找出最耗时的 ContentProvider
grep "ContentProvider.onCreate" boot_trace.html | \
awk -F'[<>]' '{print $3}' | \
sort -t'(' -k2 -n -r | head -102.2 Method Tracing 与自定义打点
对于更精确的 Java/Kotlin 方法级别的分析，使用 Android Studio 的 Method Tracing 或自行注入 Trace 标记：
import android.os.Trace
object StartupTracer {
private const val TAG = "StartupTracer"
inline fun trace(name: String, block: () -> T): T {
return try {
Trace.beginSection(name)
block().also {
Trace.endSection()
}
} catch (e: Throwable) {
Trace.endSection()
throw e
}
}
inline fun traceSection(name: String) {
try {
Trace.beginSection(name)
} catch (e: Throwable) {
// Ignore if tracing not enabled
}
}
fun endSection() {
try {
Trace.endSection()
} catch (e: Throwable) {
// Ignore
}
}
}
// 在 Application 和 Activity 中注入关键路径的打点
class MyApplication : Application() {
override fun attachBaseContext(base: Context?) {
val start = System.currentTimeMillis()
traceSection("Application.attachBaseContext")
super.attachBaseContext(base)
StartupTracer.endSection()
StartupTracer.trace("Application.init") {
initDependencies()
initThirdPartySDKs()
initCrashReporter()
}
}
private fun initDependencies() {
StartupTracer.traceSection("Hilt.init")
Hilt.init(this)
StartupTracer.endSection()
StartupTracer.traceSection("WorkManager.init")
WorkManager.initialize(this, Configuration.Builder()
.setMinimumLoggingLevel(android.util.Log.INFO)
.build())
StartupTracer.endSection()
}
}
class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
StartupTracer.trace("MainActivity.onCreate") {
super.onCreate(savedInstanceState)
StartupTracer.traceSection("inflateLayout")
setContentView(R.layout.activity_main)
StartupTracer.endSection()
StartupTracer.traceSection("setupComposeUI")
setupComposeUI()
StartupTracer.endSection()
}
}
} 使用 android.os.Trace 的好处是打点结果会自动出现在 Perfetto/Systrace 报告中，与系统事件对齐，形成完整的启动链路火焰图。
三、Init 体内耗时代码优化
3.1 Application.onCreate 的典型耗时模式
Application.onCreate 是启动优化的主战场。大型 App 在这里堆积了大量初始化代码，包括 SDK 初始化、插件化加载、数据库预热、网络预连接等：
// ❌ 优化前：所有初始化在主线程同步执行
class MyApplication : Application() {
override fun onCreate() {
super.onCreate()
// 1. Hilt 初始化（必需，但也耗时长）
Hilt.init(this)
// 2. 友盟/极光/神策等推送 SDK（网络 IO）
Analytics.init(this)
PushSDK.init(this)
// 3. 数据库预热（Disk IO）
val db = Room.databaseBuilder(this, AppDatabase::class.java, "app.db").build()
repository.prepopulateData()
// 4. 图片加载器初始化（内存分配 + 线程池创建）
ImageLoader.init(this)
// 5. 插件化框架初始化（ClassLoader + Dex 加载）
PluginManager.loadPlugins()
// 6. 网络预连接
HttpClient.preconnect()
// 总耗时：1500ms+（实测某中型 App）
}
}// ✅ 优化后：分层异步 + 延迟初始化
class MyApplication : Application() {
override fun attachBaseContext(base: Context?) {
super.attachBaseContext(base)
// 1. MultiDex.install 在 attachBaseContext 中提前执行
// （如果 minSdk < 21，这是必需的）
MultiDex.install(this)
}
override fun onCreate() {
super.onCreate()
// 第一优先级：立即初始化（blocking）
StartupTracer.traceSection("critical.init")
Hilt.init(this) // Hilt 必须立即执行，因为 ViewModel 依赖注入
StartupTracer.endSection()
// 第二优先级：后台线程异步初始化
StartupTracer.traceSection("async.init.launch")
applicationScope.launch(Dispatchers.Default) {
StartupTracer.traceSection("DB.init")
val db = getAppDatabase() // Room 单例，惰性初始化
StartupTracer.endSection()
StartupTracer.traceSection("Analytics.init")
Analytics.init(this@MyApplication) // 推送 SDK 通常可异步
StartupTracer.endSection()
StartupTracer.traceSection("ImageLoader.init")
ImageLoader.init(this@MyApplication) // 线程池创建
StartupTracer.endSection()
StartupTracer.traceSection("PushSDK.init")
PushSDK.init(this@MyApplication)
StartupTracer.endSection()
}
StartupTracer.endSection()
// 第三优先级：延迟初始化（首屏渲染完成后再执行）
StartupTracer.traceSection("lazy.init")
applicationScope.launch(Dispatchers.Default) {
delay(3000) // 等待首屏渲染稳定
PluginManager.loadPlugins()
HttpClient.preconnect()
StartupTracer.traceSection("FeatureModules.init")
featureModuleRegistry.initialize()
StartupTracer.endSection()
}
StartupTracer.endSection()
}
private val applicationScope: CoroutineScope by lazy {
// 使用独立的 CoroutineScope，不绑定到 Activity 生命周期
CoroutineScope(SupervisorJob() + Dispatchers.Default)
}
}3.2 ContentProvider 的隐藏成本
ContentProvider 的 onCreate() 在 Application.onCreate() 之前同步执行——这是 Android 启动链路中最隐蔽的性能杀手。很多第三方 SDK 和内部模块通过 ContentProvider 偷偷执行初始化代码：
启动时序（简化）：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Process.start()
→ Application() 构造器
→ bindApplication()
→ LoadedApk.makeApplication()
→ Application.attach()
→ ContentProvider.onCreate() × N ← 这里最危险
→ Application.onCreate()
→ ContentProvider.onCreate()（某些初始化顺序问题）
风险点：
- 每个 ContentProvider 都在主线程同步执行 onCreate()
- 即使 Provider 什么都不做，进程的 classLoader + 反射查找 + 实例化也有固定开销
- 第三方 SDK 可能在这里执行网络请求或数据库操作
- 多个 Provider 的 onCreate() 串行执行，时间成本叠加// ❌ 原来的 ContentProvider 初始化方式
class AnalyticsInitializer : ContentProvider() {
override fun onCreate(): Boolean {
// 在主线程执行，任何耗时操作都会阻塞启动
AnalyticsSDK.init(context!!)
return true
}
}
// AndroidManifest.xml 中需要声明
// 3.3 惰性初始化的最佳实践
核心原则：不在启动路径上的代码，永远不要在启动时执行。使用惰性初始化（Lazy Initialization）配合 Kotlin 的 by lazy 委托是最佳方案：
// 惰性初始化示例
class AppDependencies(
private val context: Context
) {
// 数据库：首次访问时才创建（延迟到首屏渲染稳定后）
val database: AppDatabase by lazy {
Room.databaseBuilder(context, AppDatabase::class.java, "app.db")
.setJournalMode(JournalMode.TRUNCATE) // 减少写入
.build()
}
// 网络：仅在使用时创建
val httpClient: HttpClient by lazy {
HttpClient.Builder()
.connectTimeout(10, TimeUnit.SECONDS)
.build()
}
// 复杂对象：在后台线程延迟加载
val userPreferences: UserPreferences by lazy {
UserPreferences(preferencesDataStore)
}
// 推荐：使用委托到单例
companion object {
@Volatile
private var INSTANCE: AppDependencies? = null
fun getInstance(context: Context): AppDependencies {
return INSTANCE ?: synchronized(this) {
INSTANCE ?: AppDependencies(context.applicationContext).also {
INSTANCE = it
}
}
}
}
}
// Hilt 中的懒加载 Provider
@Module
@InstallIn(SingletonComponent::class)
object AppModule {
@Provides
@Singleton
fun provideDatabase(
@ApplicationContext context: Context
): AppDatabase = Room.databaseBuilder(
context,
AppDatabase::class.java,
"app.db"
).build()
// 如果数据库构建很耗时，可以使用惰性绑定
@Provides
@IntoMap
@ClassKey(Database::class)
fun provideLazyDatabase(
provider: Provider
): Lazy = Lazy { provider.get() }
} 四、App Startup 库深度解析
4.1 App Startup 的工作原理
App Startup 的核心是一个特殊的 ContentProvider——InitializationProvider。它在 Application.onCreate() 之前执行，通过解析 AndroidManifest.xml 中的 <meta-data> 标签，自动发现并调用所有 Initializer 实现：
// androidx.startup.InitializationProvider（框架源码简化）
class InitializationProvider : ContentProvider() {
override fun onCreate(): Boolean {
// 1. 获取所有已注册的 Initializer
val initializers = parseMetaData(context)
// 2. 按依赖关系拓扑排序
val sorted = sortByDependencies(initializers)
// 3. 依次调用 create()
sorted.forEach { initializer ->
initializer.create(context) // 关键：可以异步执行！
}
return true
}
private fun parseMetaData(context: Context): List<WorkableInitializer> {
val providerInfo = context.packageManager
.resolveContentProvider(callerAuthority, PackageManager.GET_META_DATA)
val metaData = providerInfo?.metaData ?: return emptyList()
return metaData.keySet()
.filter { it.endsWith(".initializer") }
.mapNotNull { key ->
val className = metaData.getString(key) ?: return@mapNotNull null
Class.forName(className).newInstance() as Initializer<*>
}
}
}App Startup 相比原生 ContentProvider 的核心优势：可以在 Initializer.create() 中自由选择执行线程（主线程或后台线程），并且支持依赖声明（通过 dependencies() 方法），自动处理初始化顺序。
4.2 依赖管理与并行初始化
App Startup 支持声明依赖关系，实现并行初始化：
// 无依赖的初始化器可以并行执行
class CrashReporterInitializer : Initializer<CrashReporter> {
override fun create(context: Context): CrashReporter {
return CrashReporter.install(context)
}
override fun dependencies(): List<Class<out Initializer<*>>> = emptyList()
}
class LoggerInitializer : Initializer<Logger> {
override fun create(context: Context): Logger {
return Logger.init(context)
}
override fun dependencies(): List<Class<out Initializer<*>>> = emptyList()
}
// 有依赖的初始化器
class AnalyticsInitializer : Initializer<Unit> {
override fun create(context: Context) {
// 仅依赖 CrashReporter（CrashReporter 初始化完成后才执行）
Analytics.setUp(context)
}
override fun dependencies() = listOf(CrashReporterInitializer::class.java)
}
class DatabaseInitializer : Initializer<AppDatabase> {
override fun create(context: Context): AppDatabase {
// 依赖 Logger（需要先初始化日志系统）
return Room.databaseBuilder(
context, AppDatabase::class.java, "app.db"
).build()
}
override fun dependencies() = listOf(LoggerInitializer::class.java)
}
// 最终的初始化并行图：
// [CrashReporter] ──┐
// [Logger] ──┼──→ [Analytics]
// └──→ [Database]
// 只有无依赖的初始化器在同一时间并行执行合理利用依赖声明可以让原本串行的初始化路径变成多条并行流水线，大幅缩短总初始化时间。
4.3 禁用不需要的自动初始化
App Startup 框架自身通过 tools:node="remove" 提供了禁用特定初始化的能力，这在处理第三方 SDK 的强制初始化时非常有用：
<manifest>
<application>
<provider
android:name="androidx.startup.InitializationProvider"
android:authorities="${applicationId}.androidx-startup"
android:exported="false"
tools:node="merge">
<!-- 禁用 Firebase 的自动初始化，改用手动控制 -->
<meta-data
android:name="com.google.firebase.FirebaseInitProvider"
tools:node="remove" />
<!-- 只保留我们需要的初始化器 -->
<meta-data
android:name="com.example.AppInitializers.AnalyticsInitializer"
android:value="androidx.startup" />
<meta-data
android:name="com.example.AppInitializers.LoggerInitializer"
android:value="androidx.startup" />
<meta-data
android:name="com.example.AppInitializers.DatabaseInitializer"
android:value="androidx.startup" />
<!-- 移除所有其他 androidx.startup 初始值 -->
</provider>
</application>
</manifest>使用 AppSettings.initialize(this, false) 可以手动控制 Firebase 等 SDK 的初始化时机，将它们从冷启动路径上完全移除。
五、预加载策略与 MTTI 优化
5.1 首屏数据预加载架构
MTTI（最小可交互时间）的优化核心是"让数据比 UI 更快就绪"。预加载策略需要平衡提前量与内存占用：
// 预加载策略：在用户感知到之前就开始数据请求
class PreloadManager(private val repository: ArticleRepository) {
// 在 Application.onCreate 中启动预加载（首屏数据）
fun preloadHomePage(scope: CoroutineScope) {
scope.launch {
// 使用 Room 的哨兵查询，提前触发数据库就绪
val homeData = repository.getHomePageData()
homeData.collect { data ->
// 数据预存到内存缓存
homePageCache = data
}
}
}
// 在首屏渲染完成后，后台预加载次屏数据
fun preloadSecondaryScreens(scope: CoroutineScope) {
scope.launch {
delay(2000) // 等待首屏稳定
repository.prefetchSearchCache()
repository.prefetchUserProfile()
repository.prefetchNotificationCount()
}
}
}
class MyApplication : Application() {
private val preloadManager = PreloadManager(repository)
override fun onCreate() {
// 立即启动首屏预加载
preloadManager.preloadHomePage(applicationScope)
// 次屏预加载在后台执行，不影响主线程
applicationScope.launch {
delay(5000)
preloadManager.preloadSecondaryScreens(applicationScope)
}
}
}5.2 启动窗口与 Splash Screen API
Android 12 引入了 Splash Screen API，它提供了一个系统级的启动窗口（Starting Window），在应用首帧渲染完成之前显示品牌 Logo，掩盖启动过程中的白屏/黑屏闪烁：
// styles.xml（Android 12 以下兼容）
<style name="Theme.App.Starting" parent="Theme.SplashScreen">
<item name="windowSplashScreenBackground">#FFFFFF</item>
<item name="windowSplashScreenAnimatedIcon">@drawable/ic_launcher_foreground</item>
<item name="windowSplashScreenAnimationDuration">500</item>
<item name="postSplashScreenTheme">@style/Theme.App.Main</item>
</style>
// AndroidManifest.xml
<activity
android:name=".MainActivity"
android:exported="true"
android:theme="@style/Theme.App.Starting">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
// MainActivity
class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
val splashScreen = installSplashScreen() // 必须首行
super.onCreate(savedInstanceState)
// 控制 Splash Screen 的关闭时机
// 在首屏数据加载完成后再关闭
var keepSplash = true
splashScreen.setKeepOnScreenCondition { keepSplash }
lifecycleScope.launch {
// 等待首屏数据就绪
val data = viewModel.homePageData.first()
keepSplash = false // 数据就绪后立即关闭 Splash
}
setContentView(R.layout.activity_main)
}
}Splash Screen API 的关键是配合 setKeepOnScreenCondition——在首屏数据/视图就绪前保持启动窗口覆盖白屏，数据就绪后立即关闭。这种"受控的视觉延迟"比让用户看到加载中的白屏体验好得多。
5.3 MTTI 优化的实战路径
综合所有优化手段，一个完整的 MTTI 优化链路如下：
MTTI 优化四步法：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Step 1：测量（Measurement）
→ Perfetto 录制完整启动链路
→ 标注各阶段耗时：CP 初始化 / App.onCreate / Activity.onCreate / inflate
→ 目标：将 MTTI < 2000ms（中高端设备）
Step 2：分拣（Classification）
→ P0（立即优化）：Application.onCreate 中 > 200ms 的操作
→ P1（本周优化）：ContentProvider onCreate 中 > 50ms 的操作
→ P2（计划优化）：Activity onCreate 中的非关键路径延迟
Step 3：行动（Action）
→ P0 → 异步化 / 惰性化 / 删除
→ P1 → App Startup 替代 + 并行化
→ P2 → 延迟加载 / 缓存预热
Step 4：验证（Verification）
→ CI 集成 Macrobenchmark，基线对比
→ 性能回归告警：MTTI > 基线 15% 时阻断合并// Macrobenchmark 模块：startup-benchmark/AndroidTest.kt
@RunWith(AndroidJUnit4::class)
class StartupBenchmark {
@get:Rule
val benchmarkRule = MacrobenchmarkRule()
@Test
fun coldStartup() = benchmarkRule.measureRepeated(
packageName = "com.example.app",
metrics = listOf(
StartupTimingMetric(),
FrameTimingMetric()
),
compilationMode = CompilationMode.Full(),
iterations = 10,
startupMode = StartupMode.COLD
) {
// 每次测试前重置应用状态
pressHome()
// 启动 Activity 并等待首帧渲染
startActivityAndWait()
// 等待 Compose 渲染稳定（用于 Compose 应用）
waitForIdle()
}
@Test
fun warmStartup() = benchmarkRule.measureRepeated(
packageName = "com.example.app",
metrics = listOf(StartupTimingMetric()),
compilationMode = CompilationMode.Partial(),
iterations = 5,
startupMode = StartupMode.WARM
) {
pressHome()
startActivityAndWait()
}
}
// CI 中集成性能基准对比
// 每次 PR 合并后运行 StartupBenchmark
// 与 main 分支的基准数据对比
// MTTI 回归 > 15% → 自动阻断合并
name: Performance Regression Check
on:
pull_request:
branches: [main]
jobs:
benchmark:
runs-on: pixel-8-pro # 使用固定设备型号，避免硬件差异
steps:
- uses: actions/checkout@v4
- name: Run Startup Benchmark
run: ./gradlew :startup-benchmark:pixel6Api34BenchmarkAndroidTest
- name: Compare with Baseline
run: python3 scripts/compare_benchmark.py六、生产环境最佳实践
6.1 启动优化的工程化 Checklist
启动优化 Checklist：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Application 阶段：
□ Hilt/AppStartup 在主线程必须立即执行
□ 所有第三方 SDK 移到后台线程初始化
□ 所有磁盘 IO（数据库、SharedPreferences）移到后台线程
□ 使用 MultiDex.install() 在 attachBaseContext 提前执行
□ 移除所有不需要在 Application 中初始化的代码
ContentProvider 阶段：
□ 审查所有 ContentProvider.onCreate()，确认耗时
□ 使用 App Startup 的 Initializer 替代自定义 Provider
□ 通过 tools:node="remove" 禁用不必要 SDK 初始化
□ 使用 InitializationProvider 的依赖声明并行化
Activity 阶段：
□ 避免在 onCreate() 中执行耗时操作
□ 优先使用 Compose（比 XML inflate 更快的场景）或优化 inflate
□ 减少 View 层级深度（HierarchyViewer 分析）
□ 使用 Splash Screen API 掩盖加载过程
数据层：
□ 首屏数据预加载（后台线程，数据比 UI 先行）
□ 使用 Room 的 WAL 模式减少启动时的写锁争用
□ 只加载首屏必要数据，按需加载次屏数据
持续监控：
□ Macrobenchmark 集成到 CI，每次 PR 自动测量 MTTI
□ 设置性能基准线，回归 15% 阻断合并
□ 灰度监控：真实用户 TTID/MTTI 上报（Firebase Performance）6.2 监控与报警体系
// 使用 Firebase Performance Monitoring 自动追踪启动时间
class MyApplication : Application() {
override fun onCreate() {
super.onCreate()
// Firebase Performance 自动收集：
// - Application onCreate() 耗时
// - Activity onCreate() 耗时
// - 首帧渲染时间（TTID）
if (!BuildConfig.DEBUG) {
// 生产环境自动启用
FirebasePerformance.getInstance().isPerformanceCollectionEnabled = true
}
}
}
// 自定义启动阶段性能追踪
object StartupMetrics {
private val traceMap = mutableMapOf<String, Trace>()
fun startTrace(name: String) {
if (!BuildConfig.DEBUG) {
traceMap[name] = FirebasePerformance.getInstance().newTrace(name)
traceMap[name]?.start()
}
}
fun stopTrace(name: String, attributes: Map<String, String> = emptyMap()) {
traceMap[name]?.let { trace ->
attributes.forEach { (k, v) -> trace.putAttribute(k, v) }
trace.stop()
traceMap.remove(name)
}
}
fun recordMetric(name: String, milliseconds: Long) {
if (!BuildConfig.DEBUG) {
FirebasePerformance.getInstance().newTrace("metric_$name")
.also { it.start(); it.stop() }
}
}
}
// 使用
StartupMetrics.startTrace("db_init")
val db = getDatabase()
StartupMetrics.stopTrace("db_init", mapOf("db_version" to db.version.toString()))总结
Android 启动优化是一个系统性工程：从 ContentProvider 替身（App Startup）到 Application 异步初始化，从数据预加载到 Splash Screen 视觉掩盖，每个环节都有可量化的优化空间。关键方法论是"测量 →分拣 → 行动 → 验证"的四步循环，配合 Perfetto 的精细化测量和 Macrobenchmark 的自动化回归检测，构建持续健康的启动性能基线。
四篇文章到此完结：从 Jetpack Compose 的编译原理与高性能渲染、多模块架构与 Gradle 构建优化、Kotlin Flow 响应式编程，到 Android 应用启动优化，我们覆盖了 Android 高级工程师/架构师必备的核心技术能力。希望这些内容对你的实际项目有所启发。