一、Android MVC、MVP以及MVVM框架模式
MVC开发框架
- View：对应于布局文件和自定义View,负责将用户的请求通知Controller，并根据model更新界面；
- Controller：对应于Activity、Fragement,负责处理业务逻辑接收用户请求并更新model；（而事实上我们的Activity同时承担着MVC3种角色，代码动不动就上千行！）
-
Model：数据模型，负责数据处理相关的逻辑，封装应用程序状态，响应状态查询，通知View改变。
MVC
MVP开发框架
- View 对应于Activity，负责View的绘制以及与用户交互
- Model 依然是数据模型，负责数据处理相关的逻辑和实体模型
-
Presenter 负责完成View于Model间的交互，处理业务逻辑
MVP
MVP框架的优点：
①Model层和View层充分解耦。
②复杂的任务被分成细小的任务，并且很容易解决。越小的东西，bug越少，越容易debug，更好测试。
③在MVP模式下的View层将会变得简单，简单直观。
④后台任务不再和Activity联系在一起，这既不会导致内存泄露(OOM)，也不依赖于Activity的重建。
⑤Persnter层负责处理业务逻辑，这样业务逻辑就被剥离了出来，不在担心需求的不停变更，可以使开发者更专注解决问题。
⑥可以直接单元测试Persenter层，以致于无需实现和View层和Model层。
MVP框架的缺点：
需要写很多类，原本一个类可以完成的事，现在需要写6个！
MVVM开发框架
- MVVM可以算是MVP的升级版，将 Presenter 改名为 ViewModel。关键在于ViewModel和Model的双向绑定，当View有用户输入后，ViewModel通知Model更新数据，同理Model数据更新后，ViewModel通知View更新。
- MVVM的出现还是为了解决View层和Model层之间的解耦，实现了充分解耦。
- MVVM相比MVP，很大程度上解决了MVP的缺点
-
Android Google在2015年提出的DataBinding Library技术，使得ViewModel和Model之间的双向绑定更加容易。IOS上如果要实现类似功能，使用KVO也可实现。
MVVM
MVVM框架的优点
①继承了MVP框架的所有优点
②书写更加方便，不必创建很多个类。使得视图层，业务逻辑层，数据模型层，层次结构更加清晰。
③再Model层和View层充分解耦的同时，还实现了数据和视图的双向绑定，数据变化时，视图自动更新。这个特性很有用，对于一些实时性较高的应用来说无疑是最佳的解决方案。例如炒股的一些APP。
MVVM框架在Android工程上的实现的基本要求
①开发工具目前只支持Android Stduio，很显然eclipse已经被Google淘汰。
②Android Studio需要1.3版本以上
③Gradle版本需要2.2以上版本
④Android plugin for gradle 1.3.0及以上版本
二、Android组件化开发和插件化开发技术
Android组件化开发
1、什么是组件化开发？
所谓组件化开发就单独的业务模块抽取出来。每一个模块是一个module，正常一个App中可以有多个module，但是一般只会有一个module是设置为application的，其他均设置为library，组件化开发就是要每个module都可以运行起来，因此在开发期间每个module均设置为application，发布时再进行合并。
2、为什么要使用组件化开发？
① Android项目中代码量达到一定程度，编译将是一件非常痛苦的事情，短则一两分钟，长则达到五六分钟。组件化开发可以有效降低代码模块的耦合度，使代码架构更加清晰，同时模块化的编译可以有效减少编译时间，当然总的编译时间是不会减少的，只是App模块化之后开发某个模块时，只需要编译特定模块，可以快速编译调试。
②组件化实现了业务的解耦和重用。
组件化开发模式的演变
（1） 单工程开发模式
该种开发模型已经有了明确的模块划分,并且通过逻辑上的分层呈现出较好结构,该模型最为我们所熟悉,通常用于早期产品的快速开发,团队规模较小的情况下，随着产品的迭代,业务越来越复杂,随之带来的是项目结构复杂度的极度增加,此时我们面临着几个问题:
- 实际业务变化非常快但是工程之前的业务模块耦合度太高,牵一发而动全身.
- 对工程所做的任何修改都必须要编译整个工程
- 功能测试和系统测试每次都要进行.
- 团队协同开发存在较多的冲突.不得不花费更多的时间去沟通和协调,并且在开发过程中,任何一位成员没办法专注于自己的功能点,影响开发效率.
- 不能灵活的对工程进行配置和组装.比如今天产品经理说加上这个功能,明天又说去掉,后天在加上.
（2）主工程多组件开发模型
在"单工程"模型的基础上,将业务层中的各业务抽取出来,封装成相应的业务组件,将基础库中各部分抽取出来,封装成基础组件,而主工程是一个可运行的app,作为各组件的入口(主工程也被称之为壳程序).这些组件或以jar的形式呈现,或以aar的形式呈现.主工程通过依赖的方式使用组件所提供的功能.
优点：
①每个成员可以专注自己所负责的业务,并不影响其他业务,同时借助稳定的基础组件,可以极大减少代码缺陷,因而整个团队可以以并行开发的方式高效的推进开发进度.
②原有的业务不需要再次进行功能测试,可以专注于发生变化的业务的测试,以及最终的集成测试即可.
缺点：
到现在为止,我们已经有效解决了"单工程开发模型"中一些问题,对于大部分团队来说这种已经可以了,但是该模型仍然存在一些可以改进的点:每次修改依赖包,就需要重新编译生成lib或者aar.比如说小颜同学接手了一个项目有40多个组件,在最后集成所有组件的时候,小颜同学发现其中某组件存在问题,为了定位和修改该组件中的问题,小颜同学不断这调试该组件.由于在该模型下,组件不能脱离主工程,那么意味着,每次修改后,小颜同学都要在漫长的编译过程中等待.更糟糕的是,现在离上线只有5小时了,每次编译10分钟,为改这个bug,编译了20次,恩....什么也不用干了,可以提交离职报告了
（3）主工程多子工程开发模型
不难发现,该种开发模型在结构上和"主工程多组件"并无不同,唯一的区别在于:所有业务组件不再是mouble而是作为一个子工程,基础组件可以使moudle,也可以是子工程,该子工程和主工程不同:Debug模式下下作为app,可以单独的开发,运行,调试;Release模式下作为Library,被主工程所依赖,向主工程提供服务.
优点：
①在该种模型下,当小颜同学发现某个业务组件存在缺陷,会如何做呢?比如是基础组件2出现问题,由于在Debug模式下,基础组件2作为app可以独立运行的,因此可以很容易地对该模块进行单独修改,调试.最后修改完后只需要重新编译一次整个项目即可。
②不难发现该种开发模型有效的减少了全编译的次数,减少编译耗时的同时,方便开发者进行开发调试。
③对测试同学来说,功能测试可以提前,并且能够及时的参与到开发环节中,将风险降到最低。
Android插件化开发
插件化和组件化开发略有不用，插件化开发时将整个app拆分成很多模块，这些模块包括一个宿主和多个插件，每个模块都是一个apk或者Dex包（组件化的每个模块是个lib，尽管调试时是一个应用，打包时还是作为lib处理），最终打包的时候将宿主apk和插件apk分开或者联合打包。
1、为什么会产生插件化开发模式？
我们知道一个APK包只有一个classes.dex文件，但dex文件最大的方法数为65535。
如果一个应用的业务逻辑十分庞大，例如淘宝、京东。很显然如果只有一个APK文件是远远不够的。那么有什么解决方法，有如下几个：
- 用 H5、React Native、Flutter 代替部分逻辑
- 删无用代码
- 买付费版的 Proguard
- 另外还有一个就是插件化模式。
2、插件化的优点
- 模块解耦
- 应用可以实现动态升级（热更新，差异包更新）
- 可以动态修复线上应用Bug，而无需重新构建版本，再次升级。
- 高效并行开发
- 按需加载相应模块，内存占用率更低
- 节省流量升级
3、Android插件化基础知识
- Android进程间通信（IPC）binder机制
- APP打包流程
- APP安装流程
- APP启动流程
- 资源加载机制
- Gradle脚本
4、Android插件化实现目前的技术流派
- 动态替换
- 静态代理
- Dex合并（Dex合并就是Android热修复的思想）
5、目前比较流行的第三方插件化框架
- 360的插件化框架：https://github.com/Qihoo360/DroidPlugin
- 阿里的插件化框架：https://github.com/alibaba/atlas
- 百度任玉刚：https://github.com/singwhatiwanna/dynamic-load-apk
- Google亲儿子：Android App Bundles