Android 性能：真正导致应用变慢的东西（以及实际的处理方法）

Source: Dev.to

正确认识 “Android Performance”

很多文章都在谈 performance，常见的做法是：

• 避免对象分配
• 优化细碎代码

👉 但在真实的 App 中，80 % 的性能问题来源于：

• 主线程被阻塞
• 内存泄漏
• 启动过于沉重
• UI 渲染效率低下

如果测不到数据 → 优化只能是猜测。

常见错误

• 在主线程调用 API
• 在 ViewModel 中进行耗时的 JSON 解析
• 不断膨胀复杂的布局
• 在 onCreate 中处理广告 / SDK

正确做法（Kotlin）

viewModelScope.launch(Dispatchers.IO) {
    val data = repository.loadData()
    withContext(Dispatchers.Main) {
        _uiState.value = data
    }
}

原则

• 主线程 = 渲染 UI
• 所有 IO / 计算 → 放到后台

导致启动慢的因素

• 过早初始化 SDK（广告、统计）
• 不必要的 ContentProvider
• 在首屏就膨胀复杂布局

优化策略

• 延迟初始化
• 懒加载 SDK
• 正确使用 SplashScreen API

lifecycleScope.launch {
    delay(300)
    initAds()
}

👉 用户会感觉 App 打开更快，虽然逻辑仍在后面加载。

常见泄漏

• Context 被单例持有
• 回调未 unregister
• Fragment 在 Adapter 中被引用

最佳实践

• 不持有 Activity context
• 需要时使用 WeakReference
• 在 onDestroyView 中清除引用

override fun onDestroyView() {
    super.onDestroyView()
    binding = null
}

📌 LeakCanary 是内部生产环境构建中必备的工具。

Layout (XML)

问题

• 布局层级过深

解决方案

• 使用 ConstraintLayout
• 扁平化层级结构
• 配合 DiffUtil 与规范的 ViewHolder

Compose

问题

• 重组次数过多

解决方案

• 状态提升（State hoisting）
• 使用 rememberSaveable
• 避免在 Composable 中创建对象

广告是常见的卡顿来源

问题

• 在主线程加载广告
• UI 未稳定时展示广告

广告最佳实践

• 预加载广告
• 不在 Application.onCreate 中初始化广告
• 仅在 UI 空闲时展示广告

if (ad.isLoaded && lifecycle.currentState.isAtLeast(Lifecycle.State.RESUMED)) {
    ad.show(activity)
}

推荐使用的工具

• Android Profiler
• Layout Inspector
• Systrace / Perfetto
• Firebase Performance

📌 只有在看到以下不佳数据时才 优化：

• 主线程未被阻塞
• 启动时间 < 2 秒
• 没有内存泄漏
• UI 滑动流畅
• 广告不导致卡顿

Performance 并不是写出 “更聪明” 的代码，而是基于真实数据进行测量、分析和优化。