why——插件化需求背景
带着目的看源码——插件化实现原理
特点介绍：极少的反射，几乎入侵的静态代理
烂大街的C/S架构——android系统的C/S架构
系统framework中提供了大量的S，而framework层底层是linux内核，以及各种硬件驱动，linux内核一切皆文件,framework中的S负责将底层功能包装成可被调用的接口，比如AMS,PMS，应用层可以通过Ibind调用S的接口从而可以为所欲为操纵底层为其所用。
插件化无处不在——android系统的插件化机制
系统的应用层宿主是launcher，系统内置app是内置插件，用户安装的app是外置动态插件，可安装卸载。
一切皆文件——linux内核
android中的一切皆文件，class也是文件，文件就是路径，classloader加载是对应apk中的能被android虚拟机识别的二进制文件路径，那class是靠什么查找的呢？那就要提下一个知识点了。
双亲委派机制——classloader
根据android系统的插件化机制，系统的入口app launch提供了一个classloader，每次启动应用时会产生一个新的classloader，这个classloader加载了当前app的class，那么如何做到当前app能够查找到系统的class,这就是android的classloader的双亲委派机制发挥作用的关键处，根据系统源码我们发现，classloader的findclass方法会优先遍历launch提供的class，查找不到时会再次查找当前app的classloader中的class,这就是classloader的双亲委派机制，根据这个思路，我们可以重写launch的classloader的findclass方法，优先从原有的classloader中查找，查找不到再查找我们自己插件中的class
欺上瞒下——普通class和android组件
普通的java class只要能被查找到就能使用open jdk的能力，而android 组件比如activity则还需要被系统触发多个生命周期方法，其实就是我们所说的回调，那组件class还需要和系统建立关联，这里的原理可以用四个字概括：欺上瞒下。主要有两个方法，一是宿主预埋，二是占坑，欺骗过系统的检查位置后掉包，欺上瞒下，上指的是系统，下指的是我们的插件，我们知道activity的生命周期回调是由X类操作的，通过简单的继承重写反射替换，我们可以做到activity占坑，同理也可以做到其他组件比如service的占坑，从性价比角度考虑，service的占坑实现过程需要的反射以及兼容处理较为复杂，暂时只实现了activity的占坑处理
无痛入侵——静态代理低入侵解决插件资源识别
这里我们仍然行的是欺上瞒下的勾当，我们将插件的资源和宿主的资源合并成新的实例，在关键的组件方法中使用静态代理进行掉包动作，插件拿到的是我们掉包过的资源实例，这里会有一个新的问题，就是资源id冲突，这个分开再讲
小试牛刀——游戏SDK的插件化的应用
保障运行的内置插件
随时更新的动态插件，
游戏SDK的插件化设计与实践
