Android类加载机制

要说Android的类加载机制 ，就离不开 类加载器ClassLoader，它是一个抽象接口

下面这个图还是比较好表达了类加载流程，但如果不看我红色画的线，就会感觉有点乱，需要注意是采用的是双亲委派模式，class加载要先一层层询问是否加载过没有就传到它的上层加载，加载不到的开始往下传，是否可以加载，最后都没能加载的not found

上图涉及了3个类 DexClassLoader，PathClassLoader，BootClassLoader。我们看看他们的源码：
首先是DexClassLoader，下图可以看出DexClassLoader继承于BaseDexClassLoader，BaseDexClassLoader继承于ClassLoader。可以加载未安装的dex文件以及包含dex的压缩文件(apk,dex,jar,zip)

PathClassLoader ，下图可以看出PathClassLoader也继承于BaseDexClassLoader。通常用来加载已安装apk的dex文件。

而BaseClassLoader 继承于ClassLoader

最后是BootClassLoader,它继承于ClassLoader

双亲委派的作用

1.防止同一个.class文件重复加载

2.对于任意一个类确保在虚拟机中的唯一性.由加载它的类加载器和这个类的全类名一同确立其在Java虚拟机中的唯一性
3.保证.class文件不被篡改,通过委托方式可以保证系统类的加载逻辑不被app自定义的同类名来篡改.

了解这些，是我们做热修复我推荐腾讯的tinker框架tinker的github地址，插件化框架我推荐360家的和small框架。插件化并不是每个引用都适合，像淘宝京东，美团平台级别的app的有多条业务接入，他们要考虑兼容性，稳定性等，权衡利弊选择框架（市面上有多个大厂的框架了），如果我们只是很简单的app，就必要大动干戈了，不够油钱呢，美团技术团队这篇文章就讲了他们考虑的：美团插件化之路。以后有时间了再更新插件化，热修复相关的文章。通常我们在手机看到，app即使热修复了，最后还是要全量更新版本，因为一个是安装包热修复后变大，还有热修复之后的应用性能，稳定兼容性上还是不如整体包安装的应用。也包括热修复也不能保证100%的设备终端都能修复，标的都是99%等。