博客

为什么要用架构？

没有良好架构的 Android 应用，业务逻辑往往散布在 Activity/Fragment 中，导致这些类变成数千行的”上帝类”，难以测试和维护。MVVM 是 Google 官方推荐的架构模式，配合 Architecture Components 可以大幅提升代码质量。

MVVM 三层结构

• Model：数据层，负责从网络、数据库等数据源获取数据。通常包含 Repository 模式。
• View：UI 层，由 Activity/Fragment/Composable 组成，负责展示数据和接收用户输入。
• ViewModel：持有 UI 状态，处理业务逻辑，作为 View 和 Model 之间的桥梁。

实战代码

Model 层

data class User(val id: Int, val name: String, val avatar: String)

class UserRepository {
    private val api = RetrofitClient.userApi
    private val dao = AppDatabase.instance.userDao()

    suspend fun getUser(id: Int): User {
        // 先返回缓存，再请求网络
        val cached = dao.getUser(id)
        return try {
            val remote = api.getUser(id)
            dao.insertUser(remote)
            remote
        } catch (e: Exception) {
            cached ?: throw e
        }
    }
}

ViewModel 层

class UserViewModel(
    private val repository: UserRepository
) : ViewModel() {

    private val _uiState = MutableStateFlow(UserUiState())
    val uiState: StateFlow = _uiState.asStateFlow()

    fun loadUser(id: Int) {
        viewModelScope.launch {
            _uiState.update { it.copy(isLoading = true) }
            try {
                val user = repository.getUser(id)
                _uiState.update { it.copy(user = user, isLoading = false) }
            } catch (e: Exception) {
                _uiState.update { it.copy(error = e.message, isLoading = false) }
            }
        }
    }
}

data class UserUiState(
    val user: User? = null,
    val isLoading: Boolean = false,
    val error: String? = null
)

View 层

@AndroidEntryPoint
class UserFragment : Fragment() {
    private val viewModel: UserViewModel by viewModels()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        viewModel.uiState
            .flowWithLifecycle(viewLifecycleOwner.lifecycle)
            .onEach { state -> render(state) }
            .launchIn(viewLifecycleOwner.lifecycleScope)

        viewModel.loadUser(1)
    }

    private fun render(state: UserUiState) {
        binding.progressBar.isVisible = state.isLoading
        state.user?.let { binding.nameText.text = it.name }
        state.error?.let { showToast(it) }
    }
}

核心原则

1. 单一数据源：每种数据类型只有一个可信来源（通常是 Repository）。
2. 单向数据流 (UDF)：数据从 ViewModel 流向 View，事件从 View 流向 ViewModel。
3. ViewModel 不持有 View 引用：避免内存泄漏，使用 StateFlow/LiveData 通信。
4. 依赖注入：使用 Hilt/Koin 管理依赖，方便测试。

推荐技术栈

• 网络：Retrofit + OkHttp + Kotlin Coroutines
• 数据库：Room
• DI：Hilt（基于 Dagger）
• 状态：StateFlow / LiveData
• 测试：JUnit + MockK + Turbine

为什么性能优化如此重要？

根据 Google 的研究，如果应用启动时间超过 5 秒，用户放弃率会急剧上升。一个流畅的应用不仅提升用户体验，还直接影响应用商店的评分和留存率。

一、应用启动优化

冷启动 vs 温启动 vs 热启动

• 冷启动：应用进程被杀死后重新启动，耗时最长。
• 温启动：Activity 被销毁但进程还在，可能是 trimMemory 导致的。
• 热启动：Activity 仍驻留在内存中，最快。

优化手段

1. 延迟初始化：将非首屏必须的第三方 SDK 放到 IdleHandler 或协程中延迟加载：

   Looper.myLooper()?.queue?.addIdleHandler {
       HeavySdk.init()
       false // 只执行一次
   }

2. 启动主题优化：使用 windowBackground 设置一个占位背景，避免白屏。
3. 减少 Application.onCreate 的工作：只做最必要的初始化。

二、内存优化

常见内存泄漏场景

• 静态变量持有 Activity 引用
• 非静态内部类 / 匿名类隐式持有外部类引用
• Handler 消息未处理完
• 未取消的协程 / RxJava 订阅
• 单例持有 Context 引用（应该用 ApplicationContext）

检测工具

• Android Studio Memory Profiler
• LeakCanary：自动检测内存泄漏并给出引用链
• MAT (Memory Analyzer Tool)：分析 hprof 文件

// LeakCanary 集成（仅需一行）
dependencies {
    debugImplementation "com.squareup.leakcanary:leakcanary-android:2.12"
}

三、渲染优化

关键指标：16ms 帧

60fps 意味着每帧只有 16ms 的时间。任何超过这个时间的操作都会导致丢帧（jank）。

优化技巧

• 减少布局层级：使用 ConstraintLayout 替代嵌套的 LinearLayout。
• 使用 ViewStub：对不常显示的 View 延迟初始化。
• 避免过度绘制：在开发者选项中开启”显示过度绘制区域”。
• RecyclerView 优化：使用 setHasFixedSize(true)、DiffUtil、预取。
• 图片加载：使用 Glide/Coil，避免直接在 UI 线程解码位图。

总结

性能优化不是一蹴而就的。建议先通过 Profiler 找到瓶颈，再针对性优化。务必在优化前后做好数据对比，验证效果。