大项目中使用MVP架构｜青训营笔记
这是我参与「第四届青训营 」笔记创作活动的第4天
以下是通过课程学习记录的笔记，同时搜索各种资料进行补充
经过小组讨论决定，大项目使用mvp架构，便于快速开发
（1）小组的MVP架构
1.1 定义基类融合MVP架构
1.2 具体实现
（2）MVP架构的层级
MVP模式将应用分为三层，并且各个对应的层的职责如下：
- Model层，主要负责数据的提供。Model层提供业务逻辑的数据结构（比如，实体类），提供数据的获取（比如，从本地数据库或者远程网络获取数据），提供数据的存储。
- View层，主要负责界面的显示。View层不涉及任何的业务逻辑处理，它持有Presenter层的引用，当需要进行业务逻辑处理时通知Presenter层。
- Presenter层，对于Presenter层他是连接View层与Model层的桥梁并对业务逻辑进行处理。在MVP架构中Model与View无法直接进行交互。所以在Presenter层它会从Model层获得所需要的数据，进行一些适当的处理后交由View层进行显示。这样通过Presenter将View与Model进行隔离，使得View和Model之间不存在耦合，同时也将业务逻辑从View中抽离。
（3）MVP架构的优点
- 模型与视图完全分离，我们可以修改视图而不影响模型；
- 可以更高效地使用模型，因为所有的交互都发生在一个地方——Presenter内部；
- 我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁；
- 如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）。
（4）存在问题及解决方案
- 若业务剧增可能会造成接口类爆炸，Presenter层的代码难以管理。鉴于本次大项目任务为极简版抖音，网络接口相对简单，业务量不大，使用MVP更容易管理各层
- 可能会造成内存泄漏问题：当用户关闭了View层，但此时Model层仍然进行耗时操作，因为presenter持有view的引用而无法回收view，造成内存泄漏。其实可以重写view中的onDestroy方法，在view销毁时强制回收presenter或者是采用弱引用。
