降Compose十八掌之『神龙摆尾』| Architecture

公众号「稀有猿诉」        原文链接 降Compose十八掌之『神龙摆尾』| Architecture

通过前面的一系列文章，我们已经掌握了足够的Jetpack Compose的开发基础。为了更好的在实际项目中使用Compose，我们还需要了解一下现代应用开发的架构原则，以及使用Jetpack Compose时如何更好的遵循这些原则。这篇文章将聚焦于架构原则这一话题，进行一些探讨和总结。

现代Android应用开发的架构方式

Jetpack Compose是一个声明式的UI框架，用它来开发应用程序，因此根本上仍是在做应用程序开发，所以需要遵循现代应用程序的架构原则。

一提到架构自然会想到Bob大叔的The Clean Architecture，这里面的最主要的核心思想就是分层，把不同的概念按照抽象的层次进行分离，层与层之间有特定的依赖规则，也即只能从控制层往业务逻辑依赖。分层最大的益处就是方便移植和替换，降低维护成本，这也是架构的意义所在。

对于移动应用开发，谷歌也给出比较实用的现代应用架构原则，其中有四个核心原则：

1. 远离系统组件，系统组件（Activity，Service和Fragment等）仅能作为一个入口和必要的依赖对象，以及协调和连接不同的对象。深层次的原因是系统组件实例不可控，系统随时会重新创建实例，所以应该把对系统组件的依赖降到最低；
2. 由数据来驱动UI，且数据最好是不可变的（Immutable data）。这个原则要求把逻辑尽可能的放在数据层而非UI层，UI层就是展示数据层，处理用户事件和UI自己的逻辑，但不应该做的业务逻辑处理。比如说新闻类应用，数据层把一坨列表传过来，UI就展示，如果列表为空，那显示加载错误，用户点击刷新就让数据层刷新数据。但不应该对列表中的数据做更新或者更改，比如说把不同的列表融合为一个，这些都是业务逻辑，应该由数据层来做。这样的好处是能让UI层尽可能的简单，方便移植，方便测试。而且这符合响应式的数据流，可以使用响应式编程范式（MVVM或者MVI）；
3. 单一数据源（Single Source Of Truth），也就是说任何数据都应该只由它的生产者来修改，其他模块只是使用不能修改，因此每一层返回的数据都应该是不可修改类型（Immutable objects）;
4. 单向数据流动（Unidirectional Data Flow），UI层展示数据，获得用户事件，调用业务逻辑层处理事件࿰