Jetpack Compose 架构如何选？MVP 、 MVVM 还是 MVI

[](()前期准备：Model层

=======================================================================

其实无论 MVX 中 X 如何变化， Model 都可以用同一套实现。我们先定义一个 DataRepository ，用于从 wanandroid 获取搜索结果。后文Sample中的 Model 层都基于此 Repo 实现

@ViewModelScoped

class DataRepository @Inject constructor(){

private val okhttpClient by lazy {

OkHttpClient.Builder().build()

}

private val apiService by lazy {

Retrofit.Builder()

.baseUrl(“https://www.wanandroid.com/”)

.client(okhttpClient)

.addConverterFactory(GsonConverterFactory.create())

.build().create(ApiService::class.java)

}

suspend fun getArticlesList(key: String) =

apiService.getArticlesList(key)

}

[](()Compose为什么需要架构？

===========================================================================

首先，先看看不借助任何架构的 Compose 代码是怎样的？

不使用架构的情况下，逻辑代码将与UI代码耦合在一起，在Compose中这种弊端显得尤为明显。常规 Android 开发默认引入了 MVC 思想，XML的布局方式使得UI层与逻辑层有了初步的解耦。但是 Compose 中，布局和逻辑同样都使用Kotlin实现，当布局中夹了杂逻辑，界限变得更加模糊。

此外，Compose UI中混入逻辑代码会带来更多的潜在隐患。由于 Composable 会频繁重组，逻辑代码中如果涉及I/O 就必须当做 SideEffect{} 处理、一些不能随重组频繁创建的对象也必须使用 remember{} 保存，当这些逻辑散落在UI中时，无形中增加了开发者的心智负担，很容易发生遗漏。

Sample 的业务场景特别简单，UI中出现少许 remember{} 、LaunchedEffect{} 似乎也没什么不妥，对于一些相对简单的业务场景出现下面这样的代码没有问题：

@Composable

fun NoArchitectureResultScreen(

answer: String

) {

val isLoading = remember { mutableStateOf(false) }

val dataRepository = remember { DataRepository() }

var result: List by remember { mutableStateOf(emptyList()) }

LaunchedEffect(Unit) {

isLoading.value = true

result = withContext(Dispatchers.IO) { dataRepository.getArticlesList(answer).data.datas }

isLoading.value = fals