Android 架构 - 概览

一、概念

目的	解耦、复用、可读性、健壮性、提高并行开发效率。
架构划分原则	纵向划分模块、横向划分层级、解耦通信。

二、项目架构（模块划分）

1.1 单工程模式（小型应用）

通常我们写项目会进行分包处理，根据界面或功能的不同将代码文件存放在对应的包中，这对于小型APP来说开发非常便捷方便。随着后期业务复杂增多，一个大型项目的代码量是及其庞大的，这会带来一系列的问题。

• 可读性下降：各种业务代码混杂在一个模块内，失去层次感。
• 维护成本上升：开发人员需要了解各个业务避免改动影响其它业务，定位问题需要在多个业务代码中寻找和跳转。
• 开发效率低：修改了一个小功能却需要重新 Build 整个项目才能看到结果，耗费时间。
• 不利于多人协同开发：一个业务的bug可能阻断其它业务的开发调试，开发风格不同难以分割相互影响，版本管理中容易出现冲突和代码覆盖问题，相互之间有沟通成本。
• 耦合高复用性差：分包约束性太差容易相互调用，业务难以抽离被新项目复用，后期更改起来麻烦。

模块化	随着 AndroidStudio 工具的推出，支持多个 module 开发提出了模块化的概念。将一个复杂的项目按照业务拆分为多个模块进行独立管理，例如【首页】【消息】【直播间】。
组件化
插件化

1.2 模块化（业务解耦）

        随着 AndroidStudio 工具的推出，支持多个 module 开发提出了模块化的概念。

        将一个复杂的项目按照业务拆分为多个模块进行独立管理，例如小红书的【首页 module_Home】【购物 module_shop】【消息 module_msg】【我 module_me】，通常还有一个基础模块【公共 module_common】 提供 BaseActivity、图片加载、网络请求等功能。

        在各个业务功能比较独立的情况下是比较合理的，但多个模块中肯定会有页面跳转、数据传递、方法调用等情况，所以必然存在复杂的依赖关系，即模块间有着高耦合度。 高耦合度加上代码量大，就极易出现问题。

• 模块多，编译一次太久。
• 改了一行代码或是调了一点UI，就要编译整个项目。
• 合代码经常发生冲突。
• 被人改了自己模块的代码，或是做一个需求发现还要去改动很多别人模块的代码。
• 别的模块已经有类似功能，自己要用只能复制一份再改。
• 代码职责不明确，这个不是我负责的我不管。
• 只做了一个模块的功能，但改动点很多需要完整回归测试。
• 做了需求，但导致别的模块出现bug。

 1.3 组件化（功能重用）

        组件化是基于可重用的目的，将应用按功能拆分成多个独立的组件，提升复用减少耦合。对单个功能进行开发，多个功能组件起来就是一个业务组件，多个业务组件组合起来就是一个应用。

        在打包时（集成模式）是一个引用库（Library）集成到项目中，在调试时（组件模式）是一个应用（Application）能单独编译运行，但还是依附于整个项目中。

模块化	组件化
将应用按业务拆分	将应用按功能拆分

1.4 插件化（频繁更新） 

	组件化	插件化
单位	module	apk
独立性	在打包时是一个引用库（Library）集成到项目中，在调试时是一个应用（Application）能单独编译运行，但还是依附于整个项目中。	一个插件就是一个独立完整的APP，可以整合进更大的应用中，可以动态下载更新（动态加载、热更新、热修复）。
通信方式	根据一套统一的注册路由系统来统一实现跨组件通信。	不同插件是不同的进程。

三、代码分层（层级划分）

参考文章：移动架构这么多，如何一次搞定所有

M层（Model 数据层）	负责数据的存取计算。
V层（View 视图层）	负责UI的显示更新。
X层（C、P、VM、I 逻辑层）	负责业务逻辑，区别在于通信方式。

3.1 无分层

业务代码全写在 UI 中造成臃肿，耦合度高，难以单元测试，而 Activity/Fragment 又有生命周期问题，配置变更会销毁重建导致数据丢失。

3.2 MVC（Model-View-Controller）

解耦技术	分层。
解决了无分层中的什么	将业务逻辑从 UI 中抽离出来，C负责业务，M负责数据。
通信方式	网上有很多版本写法，也说明前期无规范很乱。

3.3 MVP（Model-View-Presenter）

解耦技术	接口隔离（多态）。
解决了MVC中的什么	不再是直接使用对方实例（强耦合），而是将对方实例时向上转型成接口类型，调用接口里的方法。
通信方式	V中创建P和M实例，通过构造把V和M传给P（V有生命周期问题，P持有V和M，注意释放P和M避免内存泄漏），V持有P调用业务逻辑，P持有M获取数据，P持有V更新界面。

3.4 MVVM（Model-View-ViewModel）

不考虑不被推荐使用的 DataBinding，V和VM双向绑定，一方变更会自动触发另一发更新，不便于追踪测试，且xml中写逻辑降低可读性。

解耦技术	ViewModel、DataBinding、ViewBinding、LiveData。
解决了MVP中的什么	VM具有生命周期感知，解决繁琐的UI重建导致的数据持久化问题和资源释放。LiveData基于观察者模式，解耦P持有V手动处理界面更新时机，变为V自己管理订阅取消来单项通信（响应式），由此消除了接口泛滥（大量回调模板代码）。
通信方式	V调用VM中的方法，VM处理完业务会更新状态，状态的变化会使订阅者V自动更新UI。VM持有M获取数据。

3.5 MVI（Model-View-Intent）

解耦技术	唯一可信数据源、事件驱动、密封接口、数据类。
解决了MVVM中的什么	Compose向外发送用户事件属于副作用，受重组影响需要在协程中完成，V只能发送已定义好的事件通知VM处理（不再是随便调用VM中的业务方法直接更新状态，事件隔离实现状态可控），通过Channel保证并发安全。VM中有很多 LiveData 且相互之间可能存在逻辑关联，改为将这些分散的状态以属性的形式整合进同一个数据类中，创建实例通过 mutableStateof() 包裹成为状态，VM处理完业务会更新该状态（通过 copy() 更新对应属性），状态的变化会自动更新V（实例变了会被观察到，可组合项读取的那个属性如果没变的话会跳过重组）。
通信方式	V发送事件，VM处理完业务会更新状态，状态的变化会使订阅者V自动更新UI。VM持有M获取数据。