small的插件化
最近在看插件化的相关内容，就研究了一下非常火的small插件化（Github地址:https://github.com/wequick/Small）， 这篇文章主要分析small插件化的Sample的主要的开发步骤，和插件化的基本的使用，原理会在后来的文章中持续更新。
1.插件化和组件化
组件化和插件化开发上其实大体思路是差不多，但是还是有本质上的区别。组件化开发就是将一个项目app拆分成多个模块，每个模块都是一个组件，组件化开发过程中相互依赖或单独调试，最终发布的时候是将这些组件合并统一成一个apk。插件化开发也是将一个项目app拆分成多个模块，这些模块包括宿主和插件。本质上插件化开发的每个模块相当于一个apk，而组件化相当于一个个lib。插件化最终发布的时候将宿主apk和插件apk单独打包或者联合打包，而组件化则是把所有的lib打包成一个apk。
2.插件化的作用
①.并发开发 各个模块之间可以单独开发，极大地提高了开发效率
②.动态更新插件或者远端调试 app每次启动回去校验是否有插件更新，有的话，就去服务器上下载最新的插件替换掉已有的。热修复其实是插件化的一个小小的应用。
③.按需下载模块 其实和2的思路一样，也属于动态加载的功能，例如可能一个apk我们对于不同的账号设置了不同的权限，相应的就会有不同的功能模块对于不同的权限人员。
④.可以针对不同的早期设计推出不同的版本，观察用户的使用反馈，来确定最终的版本。
3.small插件化的开发步骤（这两种开发方式Github上都有相关的说明）
（1） 手动创建工程
①. Create Project
File->New->New Project...
②.加入Small编译库
1.加入classpath
classpath 'net.wequick.tools.build:gradle-small:1.0.0-alpha2'
apply plugin: 'net.wequick.small'
2.配置Small DSL （可选）
small {
aarVersion = '1.1.0-beta5'
}
③.创建Moudle
File->New->Module来创建插件模块，需要满足：
模块名形如：app., lib.或者web.*
包名包含：.app., .lib.或者.web.
命名规则如下：
app 宿主工程
app.* 包含Activity/Fragment的组件
lib.* 公共库组件
web.* 本地网页组件
sign 签名文件
为什么要这样？因为Small会根据包名对插件进行归类，特殊的域名空间如：“.app.” 会让这变得容易。
④. Configure UI route
右键app模块->New->Folder->Assets Folder，新建assets目录，
右键assets目录->New->File，新建bundle.json文件，加入：
{
"version": "1.0.0",
"bundles": [
{
"uri": "main",
"pkg": "com.example.mysmall.app.main"
}
]
}
使用uri定位，加载插件中的Activity或者Fragment
⑤.配置apk的签名
⑥.在宿主App中初始化Small
Small.preSetUp(this);
⑦.加载插件
重载宿主Activity的onStart()方法。
Small.setBaseUri("http://example.com/");
Small.setUp(this, new net.wequick.small.Small.OnCompleteListener() {
@Override
public void onComplete() {
Small.openUri("main", LaunchActivity.this);//启动默认的Activity，参考wiki中的UI route启动其他Activity
}
});
（1）使用模板创建工程
①.导入工程模板
②.新建宿主Activity的时候选择@Small模板，修改build.gradle文件引入small
buildscript {
dependencies {
classpath 'net.wequick.tools.build:gradle-small:1.0.0-alpha2'
}
}
apply plugin: 'net.wequick.small'
small {
aarVersion = '1.1.0-beta5'
}
③.新建插件的app，在as中和普通的创建moudle的方式一样
④.gradle进行打包的相关操作]gradlew buildLib -q(准备基础库) gradlew buildBundle -q(打包所有组件)。
⑤在插件的app中加载其他的插件页面 Small.openUri("detail?from=app.home", getContext());
插件之间的通信用本地广播。
4.small到底在做了什么，可以让我们动态的加载看似没有太多联系的apk中的文件？
难道我们所有的apk都被安装了，打开手机的所有应用程序并没有发现有除了宿主之外的其他的apk被安装，打开我们的app工程也就是入口工程，可以看到我们正常开发有所不同的是，文件夹里多了一个smallLibs文件夹，可以看到里面有一个armeabi文件，发现里面是.so文件，看一下文件的后缀名，app_main.so(对应我们工程的app.main),app_home.so(对应我们工程的app.home).....,其实就是通过buildLib和buildBundle来把非宿主的app中的文件打包为.so文件，我们最终安装到手机上的apk其实就是只有宿主的apk和其内部的.so文件，通过加载.so文件来实现加载插件中的文件。但是当我们安装到电脑模拟器的过程中会出现一个异常，如下图：
关于这一点是因为在我们的模拟器上的CPU架构的问题，因为我们创建模拟器的时候会有选择让我们选择是选择armeabi还是x86类型的模拟器，目前手机处理器主要是高通和三星，MTK，华为等，主要用的都是ARM公司的arm架构，而英特尔公司也有自己的手机处理器，他用的是x86的架构，目前很多平板产品在使用。而small产生的.so文件默认是产生在armeabi文件夹的，而我们创建模拟器的过程中，一般都会选择x86架构的，因为我们电脑的CPU都是x86架构的，能让模拟器的速度飞快，但是当我们安装的small的Sample的过程中，则会出错，所以我们的解决方法就是在libs目录下新建一个x86的文件夹，然后把我们aremabi文件夹下的.so文件全部复制到x86文件夹下就可以了。如下图所示我们创建的模拟器时选择架构的问题：
我们自己开发的过程中，通过 gradlew buildLib -q(准备基础库) gradlew buildBundle -q(打包所有组件) 的操作，我们也就可以看到在我们的宿主app的目录下产生一个smallLibs目录，里面的armeabi的文件中就有有我们的非宿主的插件中的文件产生的.so文件。
5.small的动态加载和实现热修复是如何实现的？
我们打开Sample的主页面
可以看到有一个更新的按钮，但是点击后好像并没有什么效果，打开Sample工程中的相关按钮操作的逻辑部分，有一个这样的方法
private void requestUpgradeInfo(Map versions, OnResponseListener listener) {
System.out.println(versions); // this should be passed as HTTP parameters
mResponseHandler = new ResponseHandler(listener);
new Thread() {
@Override
public void run() {
try {
// Example HTTP request to get the upgrade bundles information.
// Json format see http://wequick.github.io/small/upgrade/bundles.json
URL url = new URL("http://wequick.github.io/small/upgrade/bundles.json");
HttpURLConnection conn = (HttpURLConnection) url.openConnection();
StringBuilder sb = new StringBuilder();
InputStream is = conn.getInputStream();
byte[] buffer = new byte[1024];
int length;
while ((length = is.read(buffer)) != -1) {
sb.append(new String(buffer, 0, length));
}
// Parse json
JSONObject jo = new JSONObject(sb.toString());
JSONObject mf = jo.has("manifest") ? jo.getJSONObject("manifest") : null;
JSONArray updates = jo.getJSONArray("updates");
int N = updates.length();
List<UpdateInfo> infos = new ArrayList<UpdateInfo>(N);
for (int i = 0; i < N; i++) {
JSONObject o = updates.getJSONObject(i);
UpdateInfo info = new UpdateInfo();
info.packageName = o.getString("pkg");
info.downloadUrl = o.getString("url");
infos.add(info);
}
// Post message
UpgradeInfo ui = new UpgradeInfo();
ui.manifest = mf;
ui.updates = infos;
Message.obtain(mResponseHandler, 1, ui).sendToTarget();
} catch (Exception e) {
e.printStackTrace();
}
}
}.start();
}
可以看到其内部有一个url，然后我们打开url看一下里面是什么东西
可以看到底部有一个updates数组，然后数组内部是.so文件的地址，然后我们在看一下代码中的下载的部分，下载的核心部分是requestUpgradeInfo（）这个方法。
里面主要是通过http请求获取服务器bundles.json这个文件，然后去解析json.把信息存储到UpgradeInfo里面。mResponseHandler完成回调
然后就是调用upgradeBundles方法。我们跟进去看看，这个方法具体做什么。
这个方法主要是校验服务器上bundles.json的信息，然后开始下载插件和加载插件。插件下载完成后我们就实现了动态的更新操作。
我们开发的过程中怎么实现插件化的动态更新呢，我们可以在我们的原有的工程中直接修改代码，使用small的命令的打包后取出.so文件，然后将.so文件上传到我们的目标服务器地址就可以了，我们的程序就可以实现动态的更新，其实这个.so文件你可以直接解压，发现解压后的格式和我们apk直接解压后格式是一样的。
基本的用法就先到这里，small原理我们团队有不同的人在研究，后续可以更新。
