老司机技术周报与T沙龙联合举办了今年2月底的一次线下沙龙活动。林永坚受邀为大家分享，nuomi1基于这次分享视频为大家整理此文，感谢二位！并整理成文字版分享给大家！(ps.阅读原文，获取PPT！)
讲师简介:林永坚（JakeLin），超过十年移动开发经验，曾经是微软WindowPhoneMVP，熟悉iOS、Android等平台。目前在REAGroup担任MobileTechLead，负责公司Customer产品部所有移动产品的开发。并负责移动App的架构，以及项目自动化与工程化建设。开发IBAnimatable和SwiftWeather等开源项目，并编写了iOS开发进阶课程
编辑简介：nuomi1，SwiftwithiOS，果粉/米家粉
正文大家好，我是来自REAGroup的Jake。今天想和大家分享一下MVI范式在JetpackCompose上的应用，希望能给大家一些新的启发。
范式首先讲一下我们为什么要有架构和范式：
代码易于维护；方便代码重用；提高可扩展性；方便团队沟通。随着团队规模越来越大，每个成员在各方面的水平都不一样，没有一定的规范，代码质量将会变得难以控制。团队里如果应用了一定的代码架构和范式，大家就可以很方便地review代码，给代码库做贡献。
当然也不是说这些范式就没有缺点了：
代码层级变多，需要编写更多的代码；学习成本提高，特别是引入响应式编程；缺乏灵活性，只能按照预定的范式进行编写。如果严格按照范式去编写一个简单的页面，需要写网络层、数据访问层、ViewModel层等好几个层级，代码量一下子就上去了，这就会提高维护成本，特别是引入响应式编程之后，学习成本也会提高。但是响应式编程也是一个非常实用的范式，它可以减少很多BUG。另外在新成员加入的时候，按照既定的范式可以很好地维护代码，但是也可能导致无法容易地引入新技术。凡事都具有两面性，需要仔细思考，准确把握。
从UIKit无缝移植到SwiftUI那么范式的好处是什么呢？我们可以把一个层级的内部逻辑完全替换，而不用改动其他层级。
举个例子，我在去年写了一本书，内容是一个仿照朋友圈的app，使用MVVM范式进行编写。通过这种范式，我在UI层可以从UIKit无缝迁移到SwiftUI，而不需要改动其他层级的任何代码。在框架设计比较合理的情况下，引入新技术还是比较方便的。
当然也不是有了框架就一成不变，永远用它。随着技术的更新迭代，我们还需要不断地重构，用更好的方式去实现功能。
MVVM在SwiftUI上重新实现在Swift5.5出来以后，我使用新的框架和技术把朋友圈app重写了。通过对比，可以看到新的结构要比旧的结构好不少，但是分层其实没有太大的变化，还是MVVM的分层。
可以看到，当我们熟悉了一些范式之后，写这两版app其实没有太大区别，不用在整体架构上考虑很多，而是可以花更多的精力在新技术的尝试上，提升生产力。
Android流行范式回到本次分享的主题，我们先来了解一下Android上的流行范式：
MVC-ModelViewControllerMVP-ModelViewPresenterVIPER-ViewInteractorPresenterEntityRoutingMVVM-ModelViewViewModelMVC是iOS比较常见的范式，也有人在Android中使用。Android上比较流行的是MVP和MVVM，而MVVM又是Google所提倡的。
范式有很多种，我们数不过来也学不过来，主要是解决这些问题：
保护原有职位并且创造新的就业；视图与数据的分离；不同功能模块之间的解耦。视图是有生命周期的，如果数据也有了生命周期，就会难以进行单元测试，使得代码质量下降。随着我们把大量的逻辑写在视图里面，视图就会越来越膨胀，维护成本也越来越高。因此我们尽量把视图和数据分离，让数据能够进行独立的单元测试，保证软件质量。
除了视图与数据的解耦，我们还可以接续解耦网络层、数据层、ViewModel层，通过引入依赖注入，可以让app更容易地进行测试。
Google推荐的范式-MVVM来看一下Google推荐的范式MVVM，它的结构和朋友圈app是非常类似的。
这个范式在Android上使用了LiveData和ViewModel这种响应式的数据流的方式来管理生命周期，这样子就解决了Activity/Fragment生命周期导致的问题。而ViewModel由Repository组成，分为本地数据和网络数据，本地数据通过Room来读写SQLite，网络数据通过Retrofit来获取。一旦数据到来，视图就可以自动地更新。
Google更新的推荐范式如果你有