插件化备忘
一、 概述
当一个软件项目开发结束并交互使用后，需要添加一些新的功能，我们通常希望在不修改原有的应用程序情况下，将新添加的功能植入到系统中，这就是所谓的插件化，新增加的功能模块就叫插件。插件化能大大的降低模块间的耦合性，有利于各模块的独立维护，加快项目的维护更新。这里记录了下，主流的集中语言，实现插件化的方法。
二、 Java、Net和c/c++ 动态加载方式
1. Java
Java的动态加载主要是靠classloader实现的.顾名思义，ClassLoader就是用来Load Class的，当一个Class被加载的时候，这个Class所引用到的所有Class也会被加载，而且这种加载是递归的，也就是说，如果A引用到B，B 引用到C，那么当A被加载的时候，B也会被加载，而B被加载的时候，C也会加载。如此递归直到所有需要的Class都加载好。特别注意ClassLoader双亲委派机制：ClassLoader总是先请求其父ClassLoader查找Class在自身查找Class。具体参考：http://yiminghe.iteye.com/blog/267959
所以可以实现ClassLoader来实现Class的动态加载，不过java已经提供了现成的ClassLoader实现类：URLClassLoader可以加载URL所指定的jar。
示例：
有一个plugin.jar里面有一个实现IPlugin接口的类com.test.TestPlugin
ClassLoader loader = new URLClassLoader(new URL[]{new URL("file://jar路劲\plugin.jar")}); Class<?> pluginCls = loader.loadClass("com.test.TestPlugin"); IPlugin plugin = (IPlugin)pluginCls. newInstance(); plugin.load();
PS：这只是范例代码还有很多注意点，比如jar中不能包含IPlugin接口，确保URLClassLoader的parent中包含IPlugin。如何导出jar，就不叙述了。上诉就是java的动态加载，在这基础上添加插件管理，版本控制（如在zip文件结构中打入插件信息，在android那块会具体说明）。
2. Net
Net的代码是以exe与dll的组织形式发布的，而我们常用的插件加载形式为exe和dll。果开发进程级别的插件可以考虑以exe的形式组织插件（java也一样），你可以以创建，终止进程的方式，随意加载，卸载所需插件。不过这种方式要多考虑多进程通信方面的问题，这里不讨论这种形式，主要关注进程内dll形式的插件实现使用的方法。先看下net的一些基本概念，如应用程序域，程序集。
应用程序域：
应用程序域是一种边界，它由公共语言运行库围绕同一应用程序范围内创建的对象建立（即，从应用程序入口点开始，沿着对象激活的序列的任何位置）。应用程序域有助于将在一个应用程序中创建的对象与在其他应用程序中创建的对象隔离，以使运行时行为可以预知。在一个单独的进程中可以存在多个应用程序域。在net中加载到应用程序域中的dll是不能卸载，我们可以每次创建一个新的应用程序域加载dll，完成逻辑后卸载这个应用程序域。
应用程序集：
一个.NET应用程序可以由多个程序集拼装而成的。程序集，简单来说，就是一个以公共语言运行库（CLR）为宿主的、版本化的、自描述的二进制文件。尽管显示中.NET程序集和以往Win32二进制文件（包括遗留的COM服务对象）的文件扩展名（*.exe或*.dll）完全相同，但是两者的内部构成几乎完全不同。程序集可以促进代码重用、确定类型边界、可版本化的单元、自描述的、可配置的。
Net主要靠Assembly实现dll的动态加载， Assembly由多个加载dll的static方法，这边只关注加载指定路径下dll的方法LoadFile
示例：
有一个plugin.dll 里面有一个实现IPlugin接口的类Test.Plugins.TestPlugin
Assembly assembly = Assembly.LoadFile("dll的路径\plugin.dll"); Type type = Assembly.GetType("Test.Plugins.TestPlugin"); IPlugin plugin = Activator. CreateInstance(type) as IPlugin; plugin.Load();
PS：如果单纯这样加载的dll实在默认的应用程序域，无法被卸载的，如果需要卸载dll可以新建一个应用程序域去加载，不用时卸载这个应用程序域。
3. c/c++
c/c++就没有标准的动态加载的实现方式了，依平台而定这边记录了下Liunx与windows。程序有两种链接方式，一种是静态链接，一种是动态链接。了解c/c++的动态加载前，先看下这两个概念。
所谓静态链接就是在编译链接时直接将需要的执行代码拷贝到调用处，优点就是在程序发布的时候就不需要的依赖库，也就是不再需要带着库一块发布，程序可以独立执行，但是体积可能会相对大一些。（所谓库就是一些功能代码经过编译连接后的可执行形式。）
所谓动态链接就是在编译的时候不直接拷贝可执行代码，而是通过记录一系列符号和参数，在程序运行或加载时将这些信息传递给操作系统，操作系统负责将需要的动态库加载到内存中，然后程序在运行到指定的代码时，去共享执行内存中已经加载的动态库可执行代码，最终达到运行时连接的目的。优点是多个程序可以共享同一段代码，而不需要在磁盘上存储多个拷贝，缺点是由于是运行时加载，可能会影响程序的前期执行性能。
Windows下是以dll形式的（和net的dll有一定的区别），而liunx则是以so的形式。虽然Windows和Liunx的API有一点差异，但是大体的机制还是一致。都是分加载动态链接库，查找指定符号地址，调用指定过程，完成释放动态链接库。
下面先来看下windows的，windows提供了多个API来实现动态加载动态链接库和调用里面的方法。
LoadLibrary 加载指定的动态链接库获得对应的模块句柄（还有其他高级版本）
GetProcAddress 按照指定的符号名称在加载的动态链接库中查找函数地址
FreeLibrary 释放加载的动态链接库
示例：
有一个动态链接库plugin.dll,里面有一个插件接口IPlugin、一个插件实现类TestPlugin和一个导出函数int CreatePlugin(IPlugin** outPlugin)
typedef int (*CreatePlugin)(IPlugin** outPlugin); HMODULE handle = LoadLibrary(L"dll所在目录\plugin.dll"); if (handle == nullptr) { printf_s("load dll fail"); return -1; } CreatePlugin create = (CreatePlugin)GetProcAddress(handle, "CreatePlugin"); if (create == nullptr) { printf_s("get proc address fail"); return -1; } IPlugin* plugin = nullptr; Int res = create(&plugin); if (res!=0 || plugin == nullptr) { printf_s("load plugin fail"); return -1; } plugin->Load(); FreeLibrary(handle);
PS：一般dll都是导出函数，所以都是先导出指定函数，作为创建导出类的入口点，后续类的创建都依赖这个入口点。Dll如何实现函数如何导出这里就不说了。
说完windows我们在看下liunx，其实和加载调用过程和windows差不多的，liunx提供了：
dlopen 按指定模式加载指定路径下的动态库。
dlsym按照指定的符号名称在加载的动态链接库中查找函数地址
dlclose 关闭释放动态链接库
示例：
和windows一样的情况，有一个动态链接库plugin.so,里面有一个插件接口IPlugin、一个插件实现类TestPlugin和一个导出函数int CreatePlugin(IPlugin** outPlugin)
typedef int (*CreatePlugin)(IPlugin** outPlugin); void* handle = dlopen("so所在目录/plugin.so", RTLD_LAZY); if (handle ==NULL) { printf("load dll fail"); return -1; } CreatePlugin create = (CreatePlugin)dlsym(handle, "CreatePlugin"); if (create == NULL) { printf("get proc sym fail"); return -1; } IPlugin* plugin = NULL; Int res = create(&plugin); if (res!=0 || plugin == NULL) { printf("load plugin fail"); return -1; } plugin->Load(); dlclose(handle);
PS:liunx和windows动态加载动态库的流程还是很相似的，但是由于平台的差异，中间还是有许多细节需要注意的，这边只记录大体的流程，细节后续的在讨论。
三、 Android与Windows Phone插件化
Android插件化
看完上面这些，我们再来看看，两个移动平台的情况，首先看下android，由于android的上层开发一般性基于java（那些游戏引擎暂时除外），所以动态加载和java还是基本上一样的，但是由于Dalvik与java虚拟机的差异，实质还是有一些差距，流程上大致是一致。
Dalvik虚拟机和java虚拟机的差异致使，无法直接加载class文件，必须将class转化为dex，Dalvik才能去加载。所以在开发插件的步骤上我们要多一步jar到dex的转化。在动态加载的api上，android提供两个加载dex的类DexClassLoader和PathClassLoader。
DexClassLoader顾名思义就是加载Dex的ClassLoader,它可以加载dex文件或包含dex的jar和apk（dex必须是classes.dex这样命名并在根目录下），但是实际使用时发现有些机型无法加载直接dex形式，所以使用时建议用jar或apk形式。
PathClassLoader看名字可能认为它就是加载指定路径下的模块，实际上PathClassLoader加载的路径已经被限定死，只能加载/data/app路径下的dex。所以一般情况下，都是使用DexClassLoader实现插件机制。
示例：
有一个plugin.jar里面有一个实现IPlugin接口的类com.test.TestPlugin
ClassLoader loader = (IPlugin) new DexClassLoader("jar所在的目录/plugin.jar","dextop目录","so的查找目录",父ClassLoader); Class<?> pluginCls = loader.loadClass("com.test.TestPlugin"); IPlugin plugin = (IPlugin)pluginCls. newInstance(); plugin.load();
到这里android初步的插件化是可以实现了，可是在使用的时候，会发现这样插件化，无法支持android的res机制，每次实现插件里面的UI只能靠code实现，真心不是一般的烦。那接下我来看下，有什么办法能将res也集成到插件里面。
首先我们先分析下，无法使用res的原因，android项目在编译的时候会res进行一次编译，对资源进行优化，并为每一个res下的资源都生成一个对应的id。在使用的时候靠这个id在运行时android会靠这个id和资源映射表arsc找到相应资源，所这样造成我们在开发插件时，及时把res放到jar，android也无法按照id找到对应资源。这里的关键是Resource对象，在应用的那个Resource里面是找不到插件内带的那些资源的，所以如果我们能构造一个和插件里面res关联的Resource，那么利用这个Resource(其实还包括Theme)我们就能顺利访问到插件里的资源。
那如何创建插件的Resources呢，这里有两个方法：
1.直接构造Resources我们可以看下Resources的定义可以发现它有这么一个构造Resources(AssetManager, DisplayMetrics, Configuration)这里可以看出创建Resources所需要的三个参数，先看下后面两个参数这两个参数一个和显示分辨率相关一个是单纯的配置，自然我们可以直接使用app的Resources里的这两个参数，那么AssetManager呢，这个就与资源相关了，显然我们要创建一个与插件的资源相关联的的AssetManager,那我们在看下AssetManager的定义可以发现一个主要的方法addAssetPath(String)，看它的实现，这个String应该是对应资源所在的apk路径（即插件位置）这样我们就能构建一个自己的AssetManager了。
现在三个参数都全了，是不是可以构建出插件的Resources了，拿到这个Resources我们就能访问里面的大部分资源了，对了时大部分资源，不是全部，这个后续会说明的，接下来先讲下下一个方法。
2.通过某个方法直接加在apk获得这个apk的Context，那样我能就能拿到所有与这个Context相关的资源。这里我们可以观察activity的启动过程，可以发现当某个apk中的组件第一被加载的时候都会去查找这个组件所在的Application是否已经被创建，如果没有被创建都会，先加载apk创建Application，这里android以Package Name为标识查找Application，查看这部分源码我们会发现Application是由LoadedApk创建的，而LoadedApk是从ActivityThread的getPackageInfo开头的几个方法里，再仔细浏览的话，发现有个getPackageInfoNoCheck方法，需要获得一个applicationinfo为参数（还有别的参数，这个4以下与以上不同），于似乎我们只要拿到Apk的ApplicationInfo就能创建Application并获得Resources，实际上也很接近了。
但是是还有些问题要解决，如果我们直接PackageManager().getPackageArchiveInfo获得PackageInfo获得里面的ApplicationInfo，进行上述操作，会坑爹发现报了个某某路劲没有访问权限的错误，这是由于LoadedApk在makeApplication时候，需要加载apk里的dex，这时所指定的dexopt路径是应用是没有权限访问。是不是感觉到这里就坑了，只能默默的回去继续看源码，看着这茫茫的代码晕了一段时间后，会发现LoadedApk在创建加载dex前会判断mClassLoader是不是为null，如果不是就不会去加载dex，现在好了我们只要自己去加载dex，再通过反射去设置mClassLoader这一步就过了。
再拿到这个Application后，其实我们基本是用它的Resources，而不是直接用这个Application去创建View，由于这个Application是未安装的，如果你用这个Application创建EditText它去访问剪切板服务就GameOver了。
Windows Phone
过完android，再来看下Windows Phone，由于Windows Phone生态系统的性质，微软为了杜绝未经审核的应用在商店上线，防止恶意的程序对Windows Phone的破坏，动态加载这部分API是被严格限制的。
先来看下Windows Phone 下的net，实际上和PC上的net一样也是由Assembly的Load方法进行动态加载，不过Windows Phone公开了一个带AssemblyName参数的重载，只能加载应用安装目录和GAC下的DLL流程上和net基本没差。
再看下Windows Phone下的win32 API，Windows Phone的win32有公开动态加载动态库的API但是也和net一样做了限制LoadLibrary被LoadPackagedLibrary取代，只能加载安装目录下的动态库，而另外两个API与PC的一致。
到这里可以发现微软已经隐藏了所有可以加载外部代码的API，那就没办法加载外部的代码了吗，如果我们去查看Windows Phone的System32下的dll会发现，其实答案是否定的，还是有办法加载的，虽然说微软只公开的LoadPackagedLibrary，但是LoadLibrary还是存在的，这里我们就看看怎么去访问这个未公开的LoadLibrary。
在这之前我们先看几个和后续操作有关的结构体
//线程环境块 typedef struct _TEB { //BYTE fill[0x30]; x86 NT_TIB nt_tib; PVOID EnvironmentPointer; CLIENT_ID id; PVOID ActiveRpcHandle; PVOID ThreadLocalStoragePointer; PEB* currentPEB; }TEB; //进程环境块 typedef struct _PEB { // BYTE fill[0x0c]; x86 BYTE Reserved1[2]; BYTE BeingDebugged; BYTE Reserved2[1]; PVOID Reserved3[2]; PEB_LDR_DATA* ldr; }PEB; //进程加载的模块信息 typedef struct _PEB_LDR_DATA { // BYTE fill[0x1c]; x86 ULONG Length; BOOLEAN Initialized; PVOID SsHandle ; LIST_ENTRY InLoadOrderModuleList; LIST_ENTRY InMemoryOrderModuleList; MODULE_LIST_ENTRY* initModuleList; }PEB_LDR_DATA; //模块链表实体 typedef struct _MODULE_LIST_ENTRY { struct _MODULE_LIST_ENTRY* Flink; struct _MODULE_LIST_ENTRY* Blink; DWORD* baseAddress; }MODULE_LIST_ENTRY;
在这几个结构体里面就包含了我要找的LoadLibrary所在的模块句柄，既PEB的ldr这个链表里面。所以只要我们能获得PEB就能在ldr里面找的已经加载的模块，那怎么获得PEB，看TEB我们可以发现TEB里面包含PEB那又变成获得TEB，而获得TEB的API是公开的NtCurrentTeb，有了这个就好办了
HMODULE NativeInterop::getKernelModule() { TEB* teb = NtCurrentTeb(); return (HMODULE) teb->currentPEB->ldr->initModuleList->Flink->baseAddress; }
这样就获取到LoadLibrary的所在模块的句柄了，不过这是默认这个模块加载顺序确定的情况下，所以建议在加载模块名称的判断来确定模块位置。
