前言
用本篇文章理论知识和架构原则实践了一个 wanAndroid 项目，其中全部采用 kotlin 编写并抛弃了 Rxjava，因为 kotlin 可以完全替代他，本项目中汇总了业界知名的架构文章和一些项目帮你彻底理解架构。后续本项目将持续更新，并完善 wanAndorid 的所有功能。还会用 23 种设计模式在项目中实践，彻底理解设计模式在业务场景中的使用。
一、什么是架构
1.1 架构介绍
架构究竟是什么？如何更好的理解架构。我们知道中国文字博大精深可以说从文字的组成就能理解其含义。架构也不例外 “架构” 是由 “架” 、“构” 组成。
架：建造、搭设、支撑。 简称：整体结构
构：屋宇、供人居住的木、砖瓦构筑物。 简称：组件
整体结构和组件的组合就形成了架构。以 Android 架构为例子一个 APP 通常是有 class（类）组成，而这些 class 之间如何如何组合、相互之间如何发生作用，则是影响这个 APP 本身的关键点。细分的话可以分为类、接口（连接器）、任务流。所谓类就是组成架构的核心 “砖瓦”，而接口则是这些类之间通讯的路径、通讯的机制、通讯的期望结果。任务流则是描述系统如何使用类和接口完成某一项需求比如：一次网络请求。 上面介绍架构中提到了房屋、木头、砖瓦可见架构和建筑有着彼此的联系。
1.2 建筑学
上世纪 60 年代已经设计软件架构这个概念了，到了 90 年代软件架构这个概念才开始流行起来。而计算机的历史开始于上世纪五十年代相比建筑历史就非常短暂了，建筑工程从石器时代就开始了。人类在几千年的建筑设计实践中积累了大量的经验和教训，建筑设计基本上包含两点，一是建筑风格，二是建筑模式。独特的建筑风格和恰当选择的建筑模式，可以使它成为一个独一无二的建筑。
下图的照片显示了古代玛雅建筑：Chichen-Itza，九个巨大的石级堆垒而上，九十一级台阶（象征着四季的天数）夺路而出，塔顶的神殿耸入云天。所有的数字都如日历般严谨，风格雄浑。难以想象这是石器时代的建筑物。
英国首相丘吉尔说，我们构造建筑物，建筑也构造我们，英国下议院的会议厅较狭窄，无法使所有的下议院议员面向同一个方向入座，而必须分成两侧入座。丘吉尔认为，议员们入座的时候自然会选择与自己政见相同的人同时入座，而这就是英国政党制的起源。
二、架构设计目的
几乎所有的软件设计理念都可以在浩瀚的建筑学历史中找到。许多人认为 “形式必须服从功能”（你认同这种观点吗？欢迎在评论区留下你的看法）。而好的设计既有形式又有功能。比如我们的北京大兴国际机场大兴机场以航站楼为核心向四周延展从空中俯瞰就像是一只展翅欲飞的凤凰，以航站楼核心区为中心，分别向东北、东南、中南、西南、西北五个方向伸出了五条指廊，通往北京大兴国际机场的飞行区。这种从中心向四面八方延伸的设计，使航站楼中心点到最远端登机口的距离只有 600 米左右，旅客步行前往最多只需 8 分钟。
建筑的设计又有一定的目的性，而软件架构设计也同理。软件架构目的性大致可分为可扩展性、可定制化、可伸缩、可维护性：
1. 可扩展性： APP 必须能够在用户的 UV/PV 数量快速增加的情况下，保持软件合理的性能。只有这样在快速的从 0 到 1 的需求迭代中才能后顾无忧。
2. 可定制化： 在同一个软件系统中可能面向的用户群体是不同的、多样的，需要满足根据用户群的不同和市场需求的不同进行定制化。比如一个 APP 中某些功能只针对特定用户开放。
3. 可伸缩性： 在新技术出现的时候，一个软件系统应当允许接入新技术，从而对现有系统进行功能和性能的扩展。
4. 可维护性： 软件系统的维护包括两方面，一是修复现有的 bug，二是将新的迭代需求开发到现有系统中去。一个易于维护的系统可以有效地降低人力和物力。
三、实践一个 APP：玩 Android
针对上面对架构的介绍，相信已经从陌生走向熟悉了。但是最重要的还是实践，伟大的毛主席曾经说过 你要想知道梨子的滋味，就要亲口尝一下。因此借用了 wanAndoird 开放 API 简单实现一个 APP 并概括上述架构的关键点，主要的功能点如下：
首页是热搜文章的分类列表
项目页面主要包括完整项目
文章、项目点击可以查看详情
不知道还有没有印象上文提到了架构 “形式必须服从功能” 当然这不是权威的定义，可以作为参考。我们先不管是形式服从功能还是功能服从形式，可以结构化思维理解下这句话，架构大致可分为：形式、功能所以我们依次按照此两点进行搭建 wanAndroid 项目。
3.1 架构 - 形式
从形式本身而言包括两部分。一是事物外在的形状，二是内在的结构、组合方式。实际上，这两者为同一。内容如何内在组合，对外就自然有某种表现的形状。
我们打开项目的第一眼接触到和看到的就是我们项目的目录结构，更清晰更简洁的目录结构可以使我们更快的上手项目。这里主要分为两部分核心模块、业务功能模块：
核心模块主要有以下职责：
- Dagger 依赖注入处理。
- 扩展功能：各种 utils。
- 基础层的抽象：BaseActivity、BaseViewModel 等
- 第三库处理、网络异常处理等
业务功能模块主要有以下好处：
- 高内聚性
- 清晰的功能结构
- 模块化
- 功能隔离并封装
在主 APP 下进行了 core、features 的划分，业务模块并没有按照模块化的形式进行多 moudle 拆分而是聚合在 features 下，以包的形式进行了聚合，这样做的好处如下：
- 更快的编译速度
- 减少 maven 库的依赖冲突
- 通用功能的重用性
- 包的内聚力
可以看到我们并没有采用按照业务 module 进行模块化划分，因为我之前接触过一个项目拆分了 40 多个 module 可想而知项目一旦庞大起来坏处也就是暴露出来：
- 编译一次项目高达 7/8 分钟
- 项目中的 moudle 依赖纵横交错
当然我并不反对多 module 模块化的存在，因为任何模式都有利有弊，这取决于当前的项目的业务来抉择使用那种形式。此外项目中全部采用 kotlin 编写：
-
build.gradle.kts.kts 也是官方推崇的可以使 gradle 更加简化 -
buildSrc来处理 gradle 依赖
3.2 架构 - 功能
在玩 Android 中的业务点功能点主要有文章、项目获取，而这些功能点大部分都离不开网络请求和回调处理。这里不再描述 MVC、MVP、MVVM 的区别和如何选择，但是我可以说明一点是任何架构模式都没有最好、最优，只有最适合当前业务的才是好架构。现在 google 官方推崇的架构主要是 MVVM 所有我们主要说下 MVVM。更详细的可以查看官网文档：
MVVM 架构模式满足上文我们描述符合的架构设计的目的，同时也准守了官方给定的架构原则，架构原则大致有两点如下。可能光看这两个定义可能不太容易理解。所有我们用结构化思维的方式理解下，关注点分离就是将复杂问题做合理的分解，再研究分解的侧面，最后合成整体的解决方案。因此我们在 Activity 或 Fragment 不应该做业务逻辑而是把功能点拆分成需要最小的最优解，最后合并成整体方案。比如 mvvm 我们衍生出 ViewModel、LiveData、Model 等。
- 关注点分离 Activity 或 Fragment 中的代码应是处理界面和操作系统交互的逻辑应使这些类尽可能保持精简，这样可以避免许多与生命周期相关的问题。
- 通过模型驱动界面 模型是负责处理应用数据的组件。它们独立于应用中的 View 对象和应用组件，因此不受应用的生命周期以及相关的关注点的影响
MVVM 中每个组件仅依赖于其下一级的组件如：activity-->viewMoudle-->Repository。这时候你可能有疑惑，如果是单向依赖那网络请求的回调怎么处理？这里引出一个概念 “响应式编程” 结合 liveData 做处理其内部是观察者模式，并且关联视图的声明周期如：Activity、Fragment 或 Service。使用 LiveData 的好处如下：
- 不会发生内存泄漏 观察者会绑定到 Lifecycle 对象，并在其关联的生命周期遭到销毁后进行自我清理。
- 不会因 Activity 停止而导致崩溃 如果观察者的生命周期处于非活跃状态（如返回栈中的 Activity），则它不会接收任何 LiveData 事件。
- 不再需要手动处理生命周期 界面组件只是观察相关数据，不会停止或恢复观察。LiveData 将自动管理所有这些操作，因为它在观察时可以感知相关的生命周期状态变化。
3.3 UseCase
UseCase 是 Clean 架构中的一个概念，其中主要用于 UI 和数据层的连接同时也会进行 IO 的切换，这里可以看到本项目抛弃了 Rxjava 因为他完全可以用 Kotlin 来替代。
abstract class UseCase<out Type, in Params> where Type : Any {
abstract suspend fun run(params: Params): Either<Failure, Type>{
operator fun invoke(params: Params, onResult: (Either<Failure, Type>) -> Unit = {}) {
val job = GlobalScope.async(Dispatchers.IO) { run(params) }
GlobalScope.launch(Dispatchers.Main) { onResult(job.await()) }
}
class None
}
3.4 一个完整网络请求流程
- View：一个网络请求的发送并订阅，处理 UI 数据。
- ViewModel：为 View(Activity/Fragment) 提供数据，并处理业务逻辑。
- LiveData：具有生命周期可观察的数据存储器类，LiveData 存储在 ViewModel 中
- UseCases：用于连接 ViewModel 和 Model，并更新 LiveData。
- Model：可以从网络、数据库或其他 API 获取数据
四、总结
我们可以体会到从架构理论定义到实践的过程相信你有了自己的理解和见解，但这只是一种实现方式，如果在满足架构设计目的和架构原则的情况下你有更好的实践方式或者有任何和架构项目的疑问点都可迎在评论区讨论。这里我也有个疑问点就你认同形式必需服从功能？欢迎留下你的见解。
后续本项目将持续更新，并完善 wanAndorid 的所有功能。还会用 23 种设计模式在项目中实践，彻底理解设计模式在业务场景中的使用，欢迎持续关注。当其他的平台如后端、前端架构的搭建都是殊途同归的。但是我还是有几点建议：
- 业务决定架构
- 不要过度设计
- 面向接口编程
- 形式需服从功能
更多Android进阶学习知识、学习笔记欢迎在我的github中查看！
