Compose 在网易红彩专家端的应用与实践

原创王德宇徐聪网易传媒技术团队

1 引言

        Jetpack Compose是一款用于构建原生Android界面的新工具包。它采用了强大的工具和直观的Kotlin API，以减少代码量并加快Android界面开发速度，从而帮助开发者创建生动而精彩的应用程序。Jetpack Compose的设计和开发始于2018年初，并于2021年7月正式发布了1.0版本。

        Google在开发者大会和各种线上、线下论坛中持续大力宣传该工具包，展示了对其的坚定态度，希望将其作为替代View的新UI解决方案。我们团队在2021年7月首次接触到Jetpack Compose，并进行了一些初步尝试，发现其设计思路为我们带来了全新的解决方案。随后，我们持续关注该技术的发展，并在了解到官方态度后，积极学习相关内容。

        2023年5月，我们团队立项了全新的产品"网易红彩-专家端"，并决定在该项目中大胆尝试使用Jetpack Compose作为主要的UI框架，以优化用户体验、加快界面响应、提高开发效率、跟进最新技术趋势以及提升团队技术能力为目标。我们选择使用Jetpack Compose BOM 2023.01.00稳定版进行开发。于2023年7月，我们成功完成了第一个版本并上线。现在，我将分享整个产品架构方案以及我们在开发过程中遇到的相关问题。

2 Compose 开发范式

2.1 Android架构衍化

        MVC、MVP、MVVM 和 MVI 是业界为了优化代码设计所提出的架构设计模式。这些模式都是围绕着 "如何管理 UI" 这个话题展开讨论，并采用了关注点分离的策略。尽管实现的细节各不相同，但它们都旨在提供更好的代码组织和可维护性。

        MVC 其实是 Android 默认的设计，最开始是没有采用任何模式的状态，不管是视图代码还是表现逻辑全都写在 Activity 里面，很明显这样的代码耦合度非常高，难以进行维护和测试，可读性也不好。

        MVP 为了将 Activity 中的表现逻辑彻底分离出来，在实现细节上，View 和 Presenter 中间会定义一个协议接口 Contract，这个接口会约定 View 如何向 Presenter 发指令和 Presenter 如何 Callback 给 View。这样的架构里 Activity 不再有表现逻辑的部分，Activity 作为 View 的角色只处理和 UI 有关的事情。

        MVVM 模式改动在于中间的 Presenter 改为 ViewModel，在实现细节上，View 和 Presenter 从双向依赖变成 View 可以向 ViewModel 发指令，但 ViewModel 不会直接向 View 回调，而是让 View 通过观察者的模式去监听数据的变化，有效规避了 MVP 双向依赖的缺点。

        MVI 模式的改动在于将 View 和 ViewModel 之间的多数据流改为基于 ViewState 的单数据流。在实现细节上，View 和 ViewModel 之间的多个交互（多 LiveData 数据流）变成了单数据流。无论 View 有多少个视图状态，只需要订阅一个 ViewState 便可以获取所有状态，再根据 ViewState 去响应。当然，实践中应该根据状态之间的关联程度来决定数据流的个数，不应该为了使用 MVI 模式而强行将多个无关的状态压缩在同一个数据流中。

2.2 从 MVVM 迈向 MVI

        由于团队之前项目采用的开发框架是MVVM，而Android Compose 官方主推的开发框架是MVI，在开发过程中总结了一些迁移经验可供参考。

图2-1 MVVM架构图2-2 MVI架构

        MVI 和 MVVM 的总体结构类似，大体上都是ViewModel 向 View层提供状态数据，View层观察状态数据进行更新，并通过调用ViewModel提供的接口进行事件处理。具体实现区别在于：

响应数据

MVVM模式中View通过观察ViewModel中的Flow或LiveData后进行主动UI更新，或者使用DataBinding的形式自动更新。

MVI模式中一般最上层的Compose创建ViewModel，通过将Flow或LiveData转换为State，并将State作为参数向下层Compose传递，通过State实现自动更新。

触发事件

MVVM模式中View一般持有ViewModel，并直接调用ViewModel中的函数进行事件处理。

MVI模式中将触发事件抽象成了意图（Intent），并向上层Compose传递，一般在最上层的Compose中调用ViewModel中的函数进行事件处理。

图2-3 数据向下传递

图2-4 事件向上传递

        MVI模式在MVVM模式的基础上，规定了数据向下传递和事件向上响应的开发范式，并且Compose不再以对象形式提供，而是以函数方式绘制UI，通过调用带有不同参数的同一可组合函数来更新界面，使得向架构模式（如 ViewModel）提供状态变得很容易。

        在MVVM向MVI过渡的过程中，尽管看起来可能很容易，但在实际的开发中并不是一蹴而就的。然而，由于Compose与Android原有框架和组件库的良好兼容性，整个过程非常顺利。在网易红彩-专家端项目的初期，我们采用了Compose + MVVM模式，以快速低成本地引入Compose的使用。除了将UI部分从Android原生改为Compose外，其他业务部分仍然可以复用，只需按照“3.1工程化集成（快速集成）”中的方法更改调用或订阅形式即可。

        Compose + MVVM 模式下，Compose中是持有ViewModel的，随着业务的迭代，可以复用的Compose越来越多，会发现这并不是一个好的选择，因为每个页面的ViewModel不同，会严重的影响到Compose的灵活性。同时由于Compose独有的预览模式，在预览模式中依赖ViewModel的话，过于繁重，且不利于单元测试。所以将ViewModel抽离势在必行，具体做法也很简单，一般Compose会设计两个参数，一个是所需的最小数据，另一个是响应事件的回调函数。在Screen创建ViewModel，并将ViewModel中的数据作为参数传给下级Compose，避免直接传递ViewModel，同时仅在这层调用ViewModel中的函数处理UI交互事件。这样就过渡为Compose + MVI 模式的页面架构。

3 架构实践与应用

        在技术实施业务落地时，任何架构都需要进行工程、组件的调整和整合。在引入Compose技术到网易红彩专家APP的过程中，除了工程化集成外，还面临了路由、WebView等组件应用的挑战。接下来，我们将详细介绍存在的问题以及相应的解决方案。

3.1 工程化集成（快速集成）

3.1.1 支持库的引入：

要使用Compose进行开发，需要引入如下几个支持库

compose相关组件版本，可从官网查看版本信息:

compose_bom = "2023.01.00"

Compose Bom物料平台（链接管理库）:

 platform("androidx.compose:compose-bom:$compose_bom")

kotlin 语言支持：因Compose需使用kotlin语言编写：

'androidx.core:core-ktx: xxx' 

Activity对于Compose支持：Compose依然需要Activity作为载体，所以需要Activity对于Compose支持:

'androidx.activity:activity-compose:xxx' 

Compose UI组件支持：包内提供Compose原生UI组件，如Colunm、Row、BaseTextField等:

'androidx.compose.ui:ui' 

Compose界面及时预览支持：可为Android Studio提供Compose及时预览等特定功能：

'androidx.compose.ui:ui-tooling-preview'

Material Design风格组件包：提供一些基于原生组件封装后的MD风格的组件。如Text :

'androidx.compose.material:material'

ViewModel组件包：提供ViewModel及相关组件

'androidx.lifecycle:lifecycle-viewmodel-compose

3.1.2 Activity 、ComposeView 直接使用，简单举例：

在Activity中使用setContent()方法即可调用Compose View。

例如：

override fun onCreate(savedInstanceState: Bundle?) { 
	super.onCreate(savedInstanceState) 
    setContent { 
      Surface( 
        modifier = Modifier.fillMaxSize(), 
        color = MaterialTheme.colors.background 
      ) { 
        	HomePager() 
         } 
    } 
}

3.1.3 Flow、LiveData和State的切换：

        在Android开发中，ViewModel扮演着重要的角色，它负责管理各种Flow或LiveData，并进行复杂的数据处理操作。页面的更新状态取决于State值的改变。因此，为了实现ViewModel与页面之间的数据交互，我们需要进行Flow与State之间的相互转换。

将 Flow 转换为 State 使用 collectAsState() 方法，该方法可在 compose-runtime 中使用，因此不需要其他依赖项。
将 LiveData 转换为 State 使用 observeAsState() 方法，该方法需要build.gradle 文件中需要以下依赖项：implementation("androidx.compose.runtime:runtime-livedata:1.3.2")

例如：

class My1ViewModel() : ViewModel() {
    val mPageStateLD : LiveData
    val mPageStateFlow :Flow
}

@Compose
fun Page(){
    val mVM: My1ViewModel = viewModel()
    val pageState = mVM.mPageStateFlow.collectAsState()  //将Flow转化为State值
//    val pageState = mVM.mPageStateLD.observeAsState()  //将Livedata转化为State值
    ………………
}

将 State 转换为 Flow 需使用 fun snapshotFlow( block: () -> T): Flow 方法，该方法可在 compose-runtime 中使用，因此不需要其他依赖项。

例如：

val num: State<Int> = mutableStateOf(0)  //待转化的State对象
val flow: Flow<Int> = snapshotFlow { num.value } //转化为Flow

将 State 转换为 LiveData 并没有直接的方法支持，可能是因为将 State 转化为LiveData并不是一个常见的需求。不过如果非要如此操作，可以新创建一个LiveData，在State改变的时候进行修改操作。

3.1.4 可以和Android原生无缝使用：

        从Compose与Activity之间的关系，可以看出，Compose其实是依赖于Activity这个容器的，只是由之前使用的是XML现在换成了Compose。那Compose中可不可以使用Android，答案也是肯定的，只需在Compose中调用AndroidView()方法即可轻松达到目的。

例如：

Column {
    AndroidView( 
        factory = { context->
            // 原生 ImageView
            ImageView(context).apply {
                setImageResource(R.mipmap.ic_launcher)
            }
        }
   )
}

3.2 解决混合栈路由

        对于现有项目引入Compose来说，初期可以用Fragment或者Activity 作为Compose的容器，页面中仅有一个ComposeView用来承载UI，然后使用传统的导航方案进行页面导航，从而达到最低成本使用Compose的效果。

        而对于网易红彩-专家端这个全新的项目来说，在立项初期，团队就决定优先使用Compose作为项目的主要UI架构，同时需要兼顾项目中可能会出现的传统View架构的页面（Web页面，原有可复用的页面，支持第三方SDK的页面）。

        为了实现以上需求，团队对页面导航架构进行了整体设计，使用Android Jetpack Navigation进行页面管理，因为它是目前同时支持Compose内部跳转和传统Fragment和Activity跳转的框架，同时也是官方推荐的方案，稳定性和后续维护有充分的保障。

        Android 官方文档给出的建议：https://developer.android.com/jetpack/compose/navigation#interoperability

        如果您想将 Navigation 组件与 Compose 配合使用，有以下两种选择：

使用基于 Fragment 的 Navigation 组件定义导航图。
使用 Compose 目的地在 Compose 中通过 NavHost 定义导航图。只有在导航图中的所有屏幕都是可组合项的情况下，才可以这么做。

        因此，若要构建混合应用，建议使用基于 Fragment 的 Navigation 组件，并使用 Fragment 存储基于 View 的屏幕、Compose 屏幕和同时使用 View 和 Compose 的屏幕。应用中的每个屏幕 fragment 都是一个可组合项的封装容器，下一步是将所有这些屏幕与 Navigation Compose 结合在一起，并移除所有 Fragment。

图3-1 页面堆栈示意图

        按照官方建议，团队对页面跳转架构进行了整体设计，架构图如上图所示。整体思路是：

单Activity多Fragment模式，Fragment之间使用传统的Navigation Fragment进行导航。与传统用xml构建导航图不同，本次项目中使用 Kotlin DSL 以编程方式构建导航，使整个项目尽可能使用Kotlin编写，减少跨语言、跨文件的复杂切换，并支持动态构建导航，提高项目后期可维护性。
同时实现ComposeFragment容器，内部使用Navigation Compose 进行导航，主要API参见使用 Compose 进行导航。
这样在导航过程中就会出现如图所示的页面堆栈。在导航过程中通过识别特殊标识，进行跨堆栈的跳转，如Compose页面跳转到Web页面，跳转链接为Web?url={url}，Web页再跳转到Compose页面，跳转链接为ComposeFragment?route={route}，Web 和 ComposeFragment为跳转容器的识别符，Url和Route是实际页面的参数。

        这种混合栈的设计充分考虑到了当前APP的复杂性，考虑了后续支持Flutter或RN之类的跨平台模块单元或者第三方页面的可能性，可以按此思路进行扩展。 

3.3 遇到的问题及解决方案

3.3.1 WebView嵌套问题

        Compose中可以使用AndroidView Compose函数嵌套Android View，对于普通的View没有问题，所以团队起初的计划是参考Compose Accompanist 中的 WebView wrapper for Jetpack Compose，将离线WebView嵌入到Compose中通过Compose Navigation进行页面切换，甚至和Compose混合使用。

        但是经过实践，团队发现现阶段Compose中嵌入WebView的效果并不好，简单的使用是可以的，但是当WebView被压栈或者移除屏幕再进入时，WebView的恢复效果是有问题的，状态不能被完全保存，到目前为止暂未找到好的方案解决，所以在混合堆栈设计时，把WebView放入到了Fragment中，用原有方案进行处理，如果有混合使用的场景，可能目前还是推荐用原生方案解决。团队也在持续跟进这部分的解决方案，如有伙伴有解决方案也欢迎交流讨论。 

3.3.2 Compose Navigation默认路由不支持参数识别

NavHost(navController = navController, startDestination = route) {mainGraph(navController)}

这是创建导航路径的代码，其中startDestination是默认页面，但是这个页面不支持参数识别。

例如收藏页的路由为：

"favorite?index={index}"，startDestination = "favorite?index={index}"

以上的写法是可以正常跳转的。但是当编码为：

startDestination = "favorite?index=2"

此时跳转将报错 ：

java.lang.IllegalArgumentException: navigation destination favorite?index=2 is not a direct child of this NavGraph。

因为这里没有进行参数识别，只作为字符串匹配，暂不清楚是Google的bug还是有意为之。

解决方案：

NavHost(navController = navController, startDestination = "StartDestination"{mainGraph(navController)}
LaunchedEffect(key1 = Unit) {
  if (navController.currentBackStackEntry?.destination?.route == "StartDestination" && route != null) {
    navController.navigate(route) {
      popUpTo("StartDestination") {
          inclusive = true
       }
    }
  }
}

startDestination设置为默认的加载页，然后再跳转到指定页面，弹出默认页面即可。

3.3.3 Compose 没有做出对等实现的子View

        SurfaceView 和 TextureView 这两个类，它们是用于高速刷新的内容的，比如视频播放或者相机的取景器界面。在写 Compose 代码的时候如果想用到它俩的效果，是找不到对应的 Compose 组件，而是需要老老实实去用原生的 SurfaceView 或者 TextureView。这是因为SurfaceView 和 TextureView 的核心并不是 View，而是 Android 所提供的一套跟 Surface类相关的显示系统。所以如果项目中有类似的需求还是需要使用原生实现后，通过AndroidView Compose函数嵌套进行实现。 

4 架构对比与评价

        Compose究竟带来什么改变？对于传统命令式的视觉体系的View开发，会带来哪些提升？对于开发者来说，将会增加多少便捷？团队根据业务实际情况，选取了Android引用从开发到用户实际应用的6个技术指标做了一次细致的对比，以评估Compose带来的相关收益。

4.1 对比说明

        根据团队重新构建的两个Android移动应用项目，使用相同的Api版本、Gradle版本等，我们进行了多次实验并记录了数据。在实验中，项目A使用传统View开发页面，而项目B使用Compose开发页面。为确保公平性，我们在同一台设备上进行实验。

        根据具体的对比项，我们采取了两种对比方式。一种是取平均值对比，即对每次实验的数据进行平均，然后进行对比。另一种是直接对比，即将每次实验的数据进行直接对比。

        通过对比实验结果，我们可以得出关于传统View开发页面和Compose开发页面的结论。请注意，由于数据的具体性质，我们无法在此提供具体的对比结果。

4.2 对比列表

4.2.1 控件对比——代码量，理解难易度

        代码量和理解难易度对于开发效率和质量至关重要。代码量的多少直接影响了开发工作的效率。例如，在使用Kotlin语言开发Android应用后，开发者能够避免许多需要处理空指针的操作，以前需要多行代码的"if else"语句现在只需一个简单的"?"符号。而在理解难易度方面，Compose允许大部分页面结构都能在一个方法内完成，无需频繁切换文件。相比之下，传统开发方式中，每个层级都可能对应一个对象，每个对象背后都有一个类，这对于项目的阅读来说是一个巨大的挑战。这将直接影响到修改老需求的效率，以及新员工接手项目的速度。

      以渲染【专家App-收入列表】的相同元素为例，Compose使用常用的LazyColumn控件。在传统View开发中，使用与之类似的RecyclerView + Adapter + Viewholder实现。

图4-1 测试数据页面

Compose实现：

LazyColumn(...) {
    items(list) { model -> 
        SchoolItem(model)
    }
}

传统View开发实现：

...
recycleView.adapter = mAdapter
...
mAdapter.notifyDataSetChanged()

	Compose	传统View开发
代码行数	140	213
文件数	1	5
阅读难易度（主观）	易	难

表4-1 功能实现对比

小结：

        通过上述数据不难发现，在开发同一列表需求时，使用Compose只需要一个文件，共140代码；而使用传统View开发的话，需要编写3个kotlin文件（MainActivity、Adapter、ViewHolder）和2个布局文件，共213行代码。其次，从主观的角度来说，编写这个列表控件，Compose的确会比传统View开发简单很多。首先是思维方式，不用过多的考虑很多控件的配置因素，通过一个顺向的思维，就可以用这个控件把需求搭建好。

图4-2 Compose和传统View开发的对比

        如图4-1所示，通过对比开发一个列表类需求Compose和传统View开发的过程，我们可以明显地看出它们之间的差异。在Compose下，从数据到页面的推导过程非常简洁明了。而在传统View开发下，我们需要先设计Adapter，Adapter需要ViewHolder，ViewHolder需要对应的Xml文件。然后，我们需要逆向思考，一步一步地将它们关联起来。这个过程明显没有Compose的单向开发方式简洁。

        实际的开发工作中，如果我们已经熟练掌握了Compose的基础知识，我们相信开发效率将会提高30%至50%。甚至在复杂的需求实现上，提升的效果可能更加显著。

4.2.2 编译与运行时间对比——Run、Debug、Release

        编译和真机运行的速度对于开发和测试的运行、打包时间具有重要影响。团队内部深刻认识到这一点。在实际工作中，团队负责的项目具有一定的复杂度，因此在编译运行这类大型项目时，不同电脑的编译运行时间存在显著差异，甚至可高达5-10分钟。因此，减少编译运行时间对于提高工作效率至关重要。

        为了确保控制变量，我们需要使用同一台电脑来运行前两步所搭建的工程。同时，我们还需要确保每次打包运行之前都进行Clean工程操作。

图4-3 运行、打包时间对比

小结：

        根据这一回合的对比结果表明，使用Compose开发的应用在编译运行效率方面确实优于使用传统View开发的应用。然而，需要注意的是，这个项目的体量较小，只有两个页面和三个模块。因此，对于一个功能完善的产品而言，是否能够更好地展现出Compose的编译优势？

4.2.3 包对比——包体容量、总方法数

        根据Google Play进行的调研显示，应用的包体容量和总方法数对应用安装包的大小产生直接影响。在80M以内的范围内，无论应用的品质如何，渠道方面都能够完全接受。然而，在80M至120M之间的范围内，只有具备优秀的应用品质(IP、宣传、盈利能力)的应用才能够得到渠道的青睐。对于超过120M的应用，建议采取分包的方式进行处理。这样的做法有助于减小应用的安装包大小，进一步提升用户对于下载、安装和升级应用的意愿程度。

        将上一回合编译运行好的Debug安装包和Releas安装包进行对比。

Debug：

图4-4 Debug包容量对比

图4-5 Debug方法数量对比

Release：

图4-6 Release包容量对比

图4-7 Release包方法数量对比

小结：

      这轮的对比结果显示，Compose在安装包容量和方法数方面表现出色，超过了传统View开发。这一结果也解释了为什么上一回合Compose的编译速度优于传统View开发。

4.2.4 启动时间对比——冷启动

        App的启动时间对用户的体验至关重要。较短的启动时间可以提供流畅的打开体验，从而增加用户的粘度。因此，降低启动时间是提高用户留存率的重要策略之一。

        继续在已经搭建好的两个工程上进行实验。在冷启动的各阶段，添加Log输出时间。然后打包安装到手机（Google Pixel 4）上，运行3次并分别汇总、记录时间。

图4-8 冷启动时间对比

小结：

      这个回合Compose全败。在冷启动这个项目上，Compose确实不如传统View开发的App，而且差距还是有一些。这个源于Compose必须依托于在Activity上运行。与原生使用Activity层直接渲染的传统应用相比，这种建构方式，会导致冷启动的加载时间较长。但是长多少，有没有阈值，这个问题很重要，也影响着用户粘度。这里抛出一个疑问，感兴趣的小伙伴们可以深入地去研究下。

4.2.5 同页面运行时间对比——同机型本地数据、图片

        同启动时间相同，流畅的页面渲染速度，同样影响着用户对这个App的体验感受。但是加载一个页面，会受到诸多因素的影响，比如用户的网络状况，渲染的数据量，手机硬件的性能等。

        在对前几回合的包进行修改时，我们需要在同一页面的不同关键节点处添加Log输出时间。为了保证对比的公平性，我们采取控制变量，我们需要在相同机型、相同网络环境以及加载渲染相同数据量的状态下，运行3次。这样可以确保我们所得到的结果更加准确可靠。

图4-9 页面渲染时间对比

小结：

        在最后一回合的对比中，Compose应用在页面渲染速度上战胜了传统View开发的应用。这一成果可以归功于Compose的声明式编程基础和弱生命周期的加持。相比之下，Compose在页面加载渲染方面避免了过多的方法调用，从而取得了胜利。这个结果是符合情理的。

4.3 小结

      基于六方面的诸多指标对比，我们可以相对全面地评估了Compose与传统View开发的差异。从控件到页面的完整性，从打包到运行的各个环节，我们进行了全面的比较。然而，需要强调的是，这次评测结果并不意味着在现阶段使用Compose一定比传统的View开发更优越。我们的结果仅仅基于目前一些量化指标的对比。同时，我们也不得不提到，经过多年的风蚀雨涿，传统View开发在稳定性和经验方面无疑超过了Compose。作为一项新技术，Compose还有很长的发展路程，需要开发者不断地发现问题、解决问题，并不断完善优化它。

5 总结和展望

        经过学习了解Compose到实践使用Compose编写原生“网易红彩-专家App”，到目前已经接近一年的时间，在落地过程中，虽然遇到部分难点与挑战，在详细了解相关设计后及架构后，实现逻辑整体比原有使用View实现更加简洁，总体感受过渡十分的平滑。Compose充分发挥了Kotlin优点和语言特性，同时Jetpack各种组件库也对Compose做了很好的兼容，整个项目完全使用Kotlin语言编写，提高了开发过程中的关注度，开发效率也得到了很好的提升。让我们再次回顾Android近几年的发展史。

2015年Android Studio 替代Eclipse，短短几年内成为主流开发工具。
2017年Google大会谷歌宣布官方正式支持将 Kotlin 作为 Android 开发的 First-Class（一等公民）语言，目前主流开发均使用Kotlin。
2018年AndroidX库推出，替换android.support库，后者已停止更新。
2022年2月Jetpack Compose 1.1 稳定版发布。
2022年10月Compose Multiplatform 1.2 推出。

        目前Google使用 Jetpack Compose 重构了其 Play Store 应用商店，同时正在逐步重写 Android 14 的设置应用，代号为“Spa”，目前已重构了部分页面，其中包括与应用、通知和语言偏好相关的页面。

        从Google推进新技术的迭代历史可以发现，Jetpack Compose必定会在未来两到三年内逐步替代原有的View开发模式，成为Android的主流开发工具库。同时 Compose的多端生态已初具雏形。JetBrains 推出了 Compose Multiplatform，目前支持Android、Windows、macOS、Linux、Web。并且正在进行iOS的支持，已经进入实验阶段，可以在提供的示例中看到效果。通过对Dome的阅读，会发现整体的设计思路和Flutter很相似，不过使用KMM+Compose-jb 实现的，顶层的UI依赖库完全是Android Compose，在Android端用Compose写的页面绝大多数可以做到平滑迁移。团队认为KMM+Compose-jb 对Android开发者来说是非常友好的，虽然还有很长的路要走，但是未来可期。 

        对于Android开发者而言，学习Compose的成本很低，而且是Google技术迭代的趋势。同时后期还有着很高的超额收益，使用Compose Multiplatform进行多平台开发，不需要像Flutter那样还需要额外学习Dart语言。所以，是时候开始学习实践Android Compose 了！

6 参考链接

Jetpack Compose 官方文档：https://developer.android.com/jetpack/compose/documentation?hl=zh-cn
书籍：《Jetpack Compose 从入门到实战》
书籍：《深入理解Kotlin协程》
网络课程：《Jetpack Compose：从上手到进阶再到高手》https://edu.rengwuxian.com/p/t_pc/goods_pc_detail/goods_detail/course_2Dpw6101YdL7bHFs5LFpYyzSUS6
文章：《Android UI 架构演进：从 MVC 到 MVP、MVVM、MVI》https://www.jianshu.com/p/10ed3252221d
文章：《Compose1.0 即将发布，你准备好了吗？》https://blog.csdn.net/chuyouyinghe/article/details/117416475
文章：《对应用架构的理解与 MVI 介绍》https://zhuanlan.zhihu.com/p/465405412

继续滑动看下一个