Android开发热门前沿知识，这几点常常被忽略，你敢说你都知道？

1. Android架构设计模式

• MVC架构设计模式：MVC全名是Model View Controller，是模型(model)-视图(view)-控制器(controller)的缩写。
• MVP架构设计模式：MVC全名是Model View Persenter，MVP由MVC演变而来，是如今主流的开发模式。
• MVVM架构设计模式：MVVM全名是Model-View-ViewModel，它本质上就是MVC的改进版。

各类模型的主要目的都是是分离视图（View）和模型（Model），即将UI界面显示和业务逻辑进行分离。

1.1 架构设计模式-MVC

(1) 定义：在android开发过程当中，比较流行的开发框架曾经采用的是MVC框架模式。

• M（Model）层：实体模型，处理业务逻辑。如：数据库操做，网络操做，I/O操做，复杂操做和耗时任务等。
• V（View）层：处理数据显示。在Android开发中，它通常对应着xml布局文件。
• C（Controller）层：处理用户交互。在Android开发中，它通常对应着Activity/Feagment。android中主要经过activity处理用户交互和业务逻辑，接受用户的输入并调用Model和View去完成用户的需求。

(2) 特色

• 低耦合
• 可重用易拓展
• 模块职责划分明确

(3) 实例

android自己的设计结构符合 MVC 模式。

(4) MVC优缺点

• MVC的优势：MVC模式经过Controller来掌控全局，同时将View展现和Model的变化分离开
• MVC也有局限性：View层对应xml布局文件能作的事情很是有限，因此须要把大部分View相关的操做移到Controller层的activity中。致使activity至关于充当了2个角色(View层和Controller层)，不只要处理业务逻辑，还要操做UI。一旦一个页面的业务繁多复杂的话，activity的代码就会愈来愈臃肿和复杂。

1.2 架构设计模式-MVP

MVP是从经典的MVC模式演变而来，它们的基本思想有相通的地方:Controller/Presenter负责逻辑的处理，Model提供数据，View负责显示。在Android开发中，MVP的具体实现流程是当Presenter接收到View的请求，便从Model层获取数据，将数据进行处理。处理好的数据再经过View层的接口回调给Activity或Fragment。这样MVP可以让Activity或Fragment成为真正的View，只作与UI相关的事而不处理其余业务流程。

(1) 定义

• M（Model）层：实体模型，处理业务逻辑。如：数据库操做，网络操做，I/O操做，复杂操做和耗时任务等。
• V（View）层：负责View的绘制以及与用户交互。在Android开发中，它通常对应着xml布局文件和Activity/Fragment。
• P（Presenter）层：负责完成Model层和View层间的数据交互和业务逻辑。

(2) 实例

(3) MVC和MVP的区别

MVP中的View并不直接使用Model，它们之间的通讯是经过Presenter来进行的，全部的交互都发生在Presenter内部，而在MVC中View会直接从Model中读取数据而不经过Controller

• MVC和MVP的最大区别：MVC的Model层和View层可以直接交互；MVP的Model层和View层不能直接交互，需经过Presenter层来进行交互。
• Activity职责不一样：Activity在MVC中属于Controller层，在MVP中属于View层，这是MVC和MVP很主要的一个区别。能够说Android从MVC转向MVP开发也主要是优化Activity的代码，避免Activity的代码臃肿庞大。
• View层不一样：MVC的View层指的是XML布局文件（或用Java自定义的View）；MVP的View层是Activity（或Fragment）
• 控制层不一样：MVC的控制层是Activity（或Fragment）；MVP的控制层是Presenter，里面没有不少的实际东西，主要负责Model层和View层的交互。

(4) MVP优缺点

• MVP的优势以下:

模型与视图彻底分离，咱们能够修改视图而不影响模型；项目代码结构清晰，一看就知道什么类干什么事情；咱们能够将一个Presenter用于多个视图，而不须要改变Presenter的逻辑，这个特性很是的有用，由于视图的变化老是比模型的变化更频繁 ；协同工做(例如在设计师没出图以前能够先写一些业务逻辑代码)

• MVP也有不足之处:

接口过多，必定程度影响了编码效率。必定程度上致使Presenter的代码量过大。为了下降Presenter中业务繁多的问题，Google又推出了MVVM，试图经过数据驱动来减小Presenter的代码量。

1.3 架构设计模式-MVVM

(1) 定义

• M（Model）层：仍然是实体模型（可是不一样于以前定义的Model层），主要负责数据获取、存储和变化，提供数据接口供 ViewModel 层调用。
• V（View）层：对应Activity/Feagment 和xml布局文件 ，负责View的绘制以及与用户交互 说明：View层仅能操做UI（数据绑定来实现 UI 更新）；不能作任何和业务逻辑有关的数据操做
• VM（ViewModel）层：负责完成Model层和View层间的数据交互和业务逻辑 说明：ViewModel层仅能作和业务逻辑有关的数据操做；不能作UI相关的操做

2. android插件化

插件化来由：随着业务的增多，业务逻辑代码愈来愈多，apk包也逐渐增大，不利于维护和升级。经过插件化开发可将功能模块解耦，不一样的维护团队仅维护某模块的业务，同时当app升级时可仅对某功能模块进行升级而不需总体升级。

2.1 插件化要解决的问题—如何动态加载apk

(1) android类加载器及区别

类加载器做用：java字节码经过类加载器加载到java虚拟器。

• PathClassLoader：仅能加载文件目录下的apk。
• DexClassLoader：能够加载apk文件中的字节码(从dex实体jar文件中加载java字节码)。主要用于动态加载和代码热更新等。

(2)反射：java中的反射使咱们在运行时得到这个类的属性、方法和class内部的信息机制，最重要的是咱们能够在运行时实例化这个对象调用方法，这也是java反射的最大优势。

(3) 实现动态加载apk

什么是动态加载apk：android中有一个速度程序会主动到指定的sd卡中去加载apk，并经过代理activity去执行。

实现：须要一个代理activity去执行apk中的activity，主要经过反射去得到它的属性和方法，从而进行apk的调用。

实现原理：类加载器（加载类）+反射（获取属性和方法）+动态代理（执行）

如：

ProxyActivity.png

2.2 插件化要解决的问题—如何加载资源

经过android中ServiceManager类的隐藏方法来加载资源。

2.3 插件化要解决的问题—如何加载代码

使用java中的类加载机制，可是android和java也有一点不同，android比java多了组件和生命周期，因此并非类加载进来就能使用(不能管理生命周期)。

3. Android热更新(在线热修复技术)

(1) 热更新流程

• 检测到线上严重的crash（参考：app检测crash并发送日志到服务器的实现）
• 线上版本拉出bugfix分支并在分支上修复问题
• jenkins构建及生成补丁
• app在合适时机经过推送或主动拉取补丁文件
• 将bugfix代码合并到master上

热更新流程.png

(2) 热更新主流框架

• Dexposed
• AndFix
• NuWa

(3) 热更新原理

• Android类加载机制（类加载器）

PathClassLoader类：用来加载系统类DexClassLoader：用来加载dex文件、jar文件包和apk包等

• 热修复机制（原理）

原理：在ClassLoader中建立一个dexElements数组，根据线上的crash定位找到对应的类文件，而后把这个类文件修复完成后打包成一个dex文件并放到dexElements数组的最前方。那么当ClassLoader遍历dexElements数组（加载数组中的dex文件）时，由于ClassLoader会优先加载最前方的dex文件，因此不会加载线上有crash的dex文件，只会加载修复完的dex文件，从而完成热修复过程。

热修复机制原理.png

4. Android进程保活

(1) 进程保活概念

进程保活：让进程在内存中永远存在且没法杀死，就算被杀死也能保活。进程被杀死的缘由：人为地调用kill；被第三方安全软件杀死。

进程保活并不是是一种流氓手段，在不少场景下咱们须要一个常驻进程来为用户提供服务，如：

• 接收屏幕开关的系统广播：由于广播接收者不支持静态注册，必须在进程中动态注册广播接收者来接收，若是没有常驻进程，那么锁屏应用没法为用户正常提供服务。
• 定位服务：须要在后台维护一个长链接，以便及时地将信息（推送的信息/定位信息等）传达给用户。

缺点：进程保活在内存，无论如何优化，或多或少都会增长性能的开销。因此需在进程保活和内存消耗之间寻找平衡点来为用户进程保活。

(2) android进程优先级和回收策略

android进程优先级：前台进程 > 可见进程 > 服务进程 > 后台进程 > 空进程

android进程的回收策略：主要依靠LMK ( Low Memory Killer )机制来完成。LMK机制经过 oom_adj 这个阀值来判断进程的优先级，oom_adj 的值越高，优先级越低，越容易被杀死。

拓展：LMK ( Low Memory Killer ) 机制基于Linux的OOM（Out Of Memery）机制，经过一些比较复杂的评分机制，对进程进行打分，将分数高的进程断定为bad进程，杀死并释放内存。LMS机制和OOM机制的不一样之处在于：OOM只有当系统内存不足时才会启动检查，而LMS机制是定时进行检查。

(3) android进程保活方案

• 利用系统广播拉活 在发生系统事件时，系统会发出相对响应的广播(经常使用的广播事件如：开机、网络状态变化、文件或sd卡的卸载等)，咱们能够在mainfest.xml文件中静态注册广播监听器

缺点（没法拉活的情形）：广播接收者被管理软件或系统软件经过自启动管理等功能禁用的场景下是没法接受广播的，从而没法自启动进行系统拉活；系统广播事件是不可控制的，只有在发生事件时才能进行拉活，没法保证进程被杀死后当即被拉活。

• 利用系统Service机制拉活 将Service中的onStartCommand()回调方法的返回值设为START_STICKY，就能够利用系统机制在Service挂掉后自动拉活。

拓展：onStartCommand()的返回值代表当Service因为系统内存不足而被系统杀掉以后，在将来的某个时间段内当系统内存足够的状况下，系统会尝试建立这个Service，一旦建立成功就又会回调onStartCommand()方法。

缺点（没法拉活的情形）：Service第一次被异常杀死后会在5s内重启，第二次会在10s内重启，第三次会在20s内重启，若Service在短期内被杀死的次数超过3次以上系统就会不惊醒拉活；进程被取得root权限的管理工具或系统工具经过强制stop时，经过Service机制没法重启进程。

• 利用Native进程拉活 思想：利用Linux中的fork机制建立一个Native进程，在Native进程能够监控主进程的存活，当主进程挂掉以后，Native进程能够当即对主进程进行拉活。

在Native进程中如何监听主进程被杀死：可在Native进程中经过死循环或定时器，轮询地判断主进程被杀死，可是此方案会耗时耗资源；在主线程中建立一个监控文件，而且在主进程中持有文件锁，在拉活进程启动后申请文件锁将会被阻塞，一旦成功获取到锁说明主进程挂掉了。

如何在Native进程中拉活主进程：主要经过一个am命令便可拉活。说明：android5.0后系统对Native进程增强了管理，利用Native进程拉活的方式已失效。

• 利用JobScheduler机制拉活

说明：android在5.0后提供了JobScheduler接口，这个接口可以监听主进程的存活，而后拉活进程。

• 利用帐号同步机制拉活（已失效）

说明：android系统的帐号同步机制会按期同步帐号信息，这个方案主要是利用帐号同步机制进行进程拉活。不过最新的android版本对帐号同步机制作了改动，该方法可能再也不生效。

文章不易，若是你们喜欢这篇文章，或者对你有帮助但愿你们多多，点赞，转发，关注 哦。文章会持续更新的。绝对干货！！！