Overview
构建架构的目的
- 可读性和维护性,只有代码容易读懂,才能更加快的理解其中逻辑而去维护(修复bug或者开发新的功能)
- 可扩展性,封装变化需求,可接入新的技术
- 可测试性
方法:分层/模块化
目的:解耦
mvc
MVP
中介模式,wiki解释
面向接口编程,体现了依赖倒置原则,只解决了View层责任不明的问题,但并没有解决代码耦合的问题。
缺点
- 接口太多。
- view 和 presenter 互相持有,耦合严重。
MVVM
由于MVP架构的 V 和 P 层的耦合比较高,所以 MVVM 的核心还是降低它们之间的耦合。
这里就用到了观察者模式的思想。
View 依旧持有 ViewModel ,但是 ViewModel 不再持有 View, 这样能降低一部分的耦合:
- View 产生了事件,通知 ViewModel 去处理,
- ViewModel 观察 View, 如果 ViewModel 的数据更新了,也作出相应的改变
View 产生事件,使用 ViewModel进行逻辑处理后,通知Model更新数据,Model把更新的数据给ViewModel,ViewModel自动通知View更新界面,而不是主动调用View的方法。
优点
- 解耦 View 和 ViewModel
- No interfaces between view and model ?
- 易于测试,事件驱动。
缺点
- 需要为每一个ui 创建观察者
- The code size is quite excessive ?还行吧
Google 推荐的 mvvm 架构
思考🤔这样一个场景:
一个社交应用在分享照片的时候,跳转hop到拍照app,然后拍照app继续hop到文件选择应用,再回来分享。
这一过程中如果被电话或者通知打断,能不能正常恢复?
由于用户可以随时杀死中间的一个app, 所以
you shouldn’t store any app data or state in your app components, and your app components shouldn’t depend on each other.
一些架构设计原则
1.Separation of concerns
分离原则,简称 SoC 好牛批的样子。
就是你的 界面类(Activity/fragment)尽量只写 UI 或者跟系统交互相关的逻辑。记住 Activity/fragment 不属于你,只是你跟系统交互的 glue 类,所以,你懂不?
2.Drive UI from a model
数据 model 驱动 ui ,最好还是持久化 Persistence ,这样就不会受影响(比如系统杀死或者网络差,无网络等)
Google 推荐的架构
如果你遵循了以上的原则,不需要修改哦
看如下 graph (类之间的依赖关系图)
图中所有的箭头都是单向的,例如View层指向了ViewModel层,表示View层会持有ViewModel层的引用,但是反过来ViewModel层却不能持有View层的引用。
假设一个用户资料的界面,这里我们用fragment显示界面,建议使用 fragment arguments 来传递 user id ,因为即使系统销毁你的app 也会保存下来参数。
使用 UserProfileViewModel 这个 viewModel 来响应页面事件逻辑处理
结合viewmodel 和 livedata 可以使 user 数据的变化,前台ui自动更新,而不受系统view 的影响(旋转屏幕,杀死等),
注意这里的 viewmodel 不能持有view,而是view持有 viewmodel 。
组件化
【青霉素】组件化那些事
【知乎】Android 客户端组件化实践
参考
【腾讯Bugly干货分享】一步一步实现Android的MVP框架
The ABC of Modularization for Android in 2021
Why to choose MVVM over MVP — Android Architecture
MVC、MVP、MVVM,我到底该怎么选?- 玉刚说
如何构建Android MVVM 应用框架 - 美团
【胡飞洋】“终于懂了“系列:Jetpack AAC完整解析(四)MVVM - Android架构探索!
[MindOrks] MVC vs MVP vs MVVM architecture in Android
[MindOrks] MVVM Architecture - Android Tutorial for Beginners - Step by Step Guide
[Android doc] Guide to app architecture官网指导,要多看几遍