现代化 Android 开发：基础架构

news2024/11/27 5:34:20

作者：古哥E下

Android 开发经过 10 多年的发展，技术在不断更迭，软件复杂度也在不断提升。到目前为止，虽然核心需求越来越少，但是对开发速度的要求越来越高。高可用、流畅的 UI、完善的监控体系等都是现在的必备要求了。国内卷的方向又还包括了跨平台、动态化、模块化。

目前的整体感觉就是，移动开发基本是奄奄一息了。不过也不用过于悲观：一是依旧有很多存量的 App 堪称屎山，是需要有维护人员的，就跟现在很多人去卷 framework 层一样，千万行代码中找 bug。二是 AI 日益成熟，那么应用层的创新也会出现，在没有更简洁的设备出现前，手机还是主要载体，总归是需要移动开发去接入的，如果硬件层越来越好，模型直接跑在手机上也不是不可能，所以对跨平台技术也会是新一层的考验，有可能直接去跨平台化了。毕竟去中台化也成了历史的选择。

因而，在这个存量市场，虽然竞争压力很大，但是如果技术过硬，还是能寻求一席之地的。因而我决定用几篇文章来介绍下，当前我认为的现代化 Android 开发是怎样的。其目录为：

现代化 Android 开发：基础架构（本文）
现代化 Android 开发：数据类
现代化 Android 开发：逻辑层
现代化 Android 开发：组件化与模块化的抉择
现代化 Android 开发：多 Activity 多 Page 的 UI 架构
现代化 Android 开发：Jetpack Compose 最佳实践
现代化 Android 开发：性能监控

Scope

提到 Android 基础架构，大家可能首先想到的是 MVC、MVP、MVVM、MVI 等分层架构。但针对现代化的 Android 开发，我们首要有的是 scope 的概念。其可以分两个方面：

结构化并发之 CoroutineScope：目前协程基本已经是最推荐的并发工具了，CoroutineScope 的就是对并发任务的管理，例如 viewModelScope 启动的任务的生命周期就小于 viewModel 的存活周期。
依赖注入之 KoinScope：虽然官方推荐的是 hilt，但其实它并没有 koin 好用与简洁，所以我还是推荐 koin。KoinScope 是对实例对象的管理，如果 scope 结束，那么 scope 管理的所有实例都被销毁。

一般应用总会有登录，所以大体的 scope 管理流程图是这样的：

我们启动 app，创建 AppScope，对于 koin 而言就是用于存放单例，对于协程来说就是全局任务
当我们登录后，创建 AuthSessionScope, 对于 koin 而言，就是存放用户相关的单例，对于协程而言就是用户执行相关的任务。当退出登录时，销毁当前的 AuthSessionScope，那么其对应的对象实例、任务全部都会被销毁。用户再次登录，就再次重新创建 AuthSessionScope。目前很多 App 对于用户域内的实例，基本上还是用单例来实现，退出登录时，没得办法，就只能杀死整个进程再重启, 所以会有黑屏现象，实现不算优雅。而用 scope 管理后，就是一件很自然而实现的事情了。所以尽量用依赖注入，而不要用单例模式
当我们进入界面后，一般都是从逻辑层获取数据进行渲染，所以依赖注入没多大用了。而协程的 lifecycleScope、viewModelScope 就比较有用，管理界面相关的异步任务。

所以我们在做架构、做某些业务时，首要考虑 scope 的问题。我们可以把 CoroutineScope 也作为实例存放到 KoinScope 里，也可以把 KoinScope 作为 Context 存放到 CorutineScope 里。

岐黄小筑是将 CoroutineScope 放到 koin 里去以便依赖查找

val sessionCoroutineScope = CoroutineScope(Dispatchers.IO + SupervisorJob() + coroutineLogExceptionHandler(TAG))
val sessionKoinScope = GlobalContext.get().createScope(...)
sessionKoinScope.declare(sessionCoroutineScope)

其实我们也完全可以用 CoroutineScope 的 Context 来做实例管理，而移除 koin 的使用。但是 Context 的使用并没有那么便捷，或许以后它可以进化为完全取代 koin。

架构分层

随着软件复杂度的提升，MVC、MVP、MVVM、MVI 等先后被提出，但我觉得目前所有的开发，都大体遵循某一模式而又不完全遵循，很容易因为业务的节奏，很容易打破，变成怎么方便怎么来。所以使用简单的分层 + 足够优秀的组件化，才是保证开发模式不被打破的最佳实践。下图是岐黄小筑的整体架构图：

整体架构不算复杂，其实重点是在于组件库，emo 已经有 20 个子库了，然后岐黄小筑有一些对于通用逻辑的抽象与封装，使得逻辑层虽然都集中在 logic 层，但整体都是写模板式的代码，可以面向 copy-paste 编程。

以 BookLogic 为例：


// 通过依赖注入传参， 拿到 db 层、网络层、以及用户态信息的应用
class BookLogic(
    val authSession: AuthSession,
    val kv: EmoKV,
    val db: AccountDataBase,
    private val bookApi: BookApi
) {
    // 并发请求复用管理
    private val concurrencyShare = ConcurrencyShare(successResultKeepTime = 10 * 1000L)

    // 加载书籍信息，使用封装好的通用请求组件
    fun logicBookInfo(bookId: Int, mode: Int = 0) = logic(
        scope = authSession.coroutineScope, // 使用用户 session 协程 scope，因为有请求复用，所以退出界面，再进入，会复用之前的网络请求
        mode = mode,
        dbAction = { // 从 db 读取本地数据
            db.bookDao().bookInfo(bookId)
        },
        syncAction = { // 从网络同步数据
            concurrencyShare.joinPreviousOrRun("syncBookInfo-$bookId") {
                bookApi.bookInfo(bookId).syncThen { _, data ->
                    db.runInTransaction {
                        db.userDao().insert(data.author)
                        db.bookDao().insert(data.info)
                    }
                    SyncRet.Full
                }
            }
        }
    )
    // 类似的模板代码
    suspend fun logicBookClassicContent(bookId: Int, mode: Int = 0) = logic(...)
    suspend fun logicBookExpoundContent(bookId: Int, mode: Int = 0) = logic(...)
    ...
}

//将其注册到 `module` 中去，目前好像也可以通过注解的方式来做，不过我还没采用那种方式：
scopedOf(::BookLogic)

ViewModel 层浮层从 Logic 层读取数据，并可以进行特殊化处理：

class BookInfoViewModel(navBackStackEntry: NavBackStackEntry) : ViewModel() {
    val bookId = navBackStackEntry.arguments?.getInt(SchemeConst.ARG_BOOK_ID) ?: throw RuntimeException("book_id is required!.")

    val bookInfoFlow = MutableStateFlow(logicResultLoading<BookInfoPojo>())

    init {
        viewModelScope.launch {
            runInBookLogic {
                logicBookInfo(bookId, mode).collectLatest {
                    bookInfoFlow.emit(it)
                }
            }
        }
    }
}

Compose 界面再使用 ViewModel：

@ComposeScheme(
    action = SchemeConst.ACTION_BOOK_INFO,
    alternativeHosts = [BookActivity::class]
)
@SchemeIntArg(name = SchemeConst.ARG_BOOK_ID)
@Composable
fun BookInfoPage(navBackStackEntry: NavBackStackEntry) {
    LogicPage(navBackStackEntry = navBackStackEntry) {
        val infoVm = schemeActivityViewModel<BookInfoViewModel>(navBackStackEntry)
        val detailVm = schemeViewModel<BookDetailViewModel>(navBackStackEntry)
        val bookInfo by infoVm.bookInfoFlow.collectAsStateWithLifecycle()
        //...
    }
}

这样整个数据流从网络加载、到存储到数据库、到传递给 UI 进行渲染的整个流程就结束了。

Android 学习笔录

Android 性能优化篇：https://qr18.cn/FVlo89
Android 车载篇：https://qr18.cn/F05ZCM
Android Framework底层原理篇：https://qr18.cn/AQpN4J
Android 音视频篇：https://qr18.cn/Ei3VPD
Jetpack全家桶篇（内含Compose）：https://qr18.cn/A0gajp
Kotlin 篇：https://qr18.cn/CdjtAF
Gradle 篇：https://qr18.cn/DzrmMB
OkHttp 源码解析笔记：https://qr18.cn/Cw0pBD
Flutter 篇：https://qr18.cn/DIvKma
Android 八大知识体：https://qr18.cn/CyxarU
Android 核心笔记：https://qr21.cn/CaZQLo
Android 往年面试题锦：https://qr18.cn/CKV8OZ
2023年最新Android 面试题集https://qr18.cn/CgxrRy
Android 车载开发岗位面试习题：https://qr18.cn/FTlyCJ
音视频面试题锦：https://qr18.cn/AcV6Ap