架构模型
v 和 m 的职责最好划分，依赖也比较清晰，v单向依赖别人，m被别人单向依赖
p的职责是最不清晰的，所以 mvp mvvm viper 对 p 的职责做了一些规范，这些拆分的职责都是特定 UI 开发场景比较重要的
关于数据映射：视图数据模型--业务数据模型；业务数据模型--源数据模型（如果数据可以直接透传，就没必要做映射了）
-
MVC
- View--viewControl--model
- 把view和model分开，但是view和controller并没有拆分开
- viewControl：将activity中ui控件相关逻辑抽出来(activity只负责生命周期管理和接受系统事件)，因此viewControl与view(activity)生命周期是绑定的，所以通常会将viewControl视为一个view
-
MVP
- View--presenter--model
- presenter承担view和model之间的业务逻辑处理，所以不受view生命周期的限制，因此这三部分做到了分离
-
Viper
- view--interactor--presenter--entity--router
- Presenter：持有router、interactor、view/viewController，桥接视图逻辑和业务逻辑
- Router：处理页面之间的相互通信、提供View之间的跳转功能，减少了模块间的耦合
- Interactor：对应model层，关心所有的数据变化，如数据获取、事件推送
- Entity：定义了 model的一些规范，model 是个数据 facade，从不同的数据源拿到源数据，如数据库、网络层、业务 server 去拿到数据
-
MVVM
- View--viewModel--model
- viewModel：做数据映射，将model拿到的数据模型转换成view需要的视图模型，所以view依赖viewModel和view对应
- 强调UI State数据流驱动ui更新（view监听LiveData）
-
MVI
- 在MVVM的基础上，强调对UI State的集中管理将多数据流变成单数据流，适合多种状态组合成对出现；对于UI所需的某些状态可能是完全相互独立的情况，将这些不同的状态捆绑在一起的代价可能会超过其优势，尤其是当其中某个状态的更新频率高于其他状态的更新频率时。
-
redux
- MVVM的改进版，约束了数据流
如何选择架构模型
-
业务场景的划分
- 业务逻辑驱动
- 视图逻辑驱动
- 数据驱动
-
业务通常具备的点
- 视图逻辑
- 业务逻辑
- 数据流
- 路由：页面切换
-
遵循的原则
- 分治：模块拆解-单一职责
- 依赖管理：分层单向依赖
- 分层：展示层-领域层-数据层
-
好架构的衡量标准
- 各组件独立性：单一职责、解耦
- 可独立测试：没有生命周期的依赖性，只是普通对象
- 便于使用：可读性、可维护性、拓展性
- 需要考虑抽象接口的必要性
