android插件化 small rules

为什么要用small：

1:解决65535的问题，不再依赖multidex，拆分dex变的可控

2:small提供了一套插件间的解藕和通信方案，使得独立开发各个模块变得更加容易

3:解藕后，各个业务模块可以独立更新

4:低入侵性，即使后来改用其他的插件化方案也不需要更改代码结构－－切换方案弹性更大

1: bundle.json 

用来配置需要被加载的插件

{
  "uri": "account",
  "pkg": "com.***.***.appaccount",
  "rules": {
    "login": "JumpLoginActivity"
 },
  "type": "lib"
}

 

uri: 为插件之间跳转的链接，可以随便定义

pkg:  模块的包名

rules：定义插件须向外暴露的activity的名字

type：定义插件［lib ｜app］，两者之间没有清晰的界限（如果只是定义utils类，做成lib插件，如果是业务模块，页面较多，做成app插件），

          如果不加type属性，url需按照模块名命名lib.* , app.*否则会造成模块加载失败

 

2:如果插件需要被依赖，则不能做成app.*  ,  如果需要被依赖做成lib.*插件；

 

3:公共库放到宿主工程，即module  app 

 

4:所有插件签名必须一致，否则会造成插件加载失败

 

5:跳转规则

 

Small.openUri("uri/rule",context); 用于 跳转到其他插件的activity

Small.createObject("[ fragment |  fragment-v4]" , uri , context) ;   用于加载其他插件的fragment  

 

6:关于更新

 small支持模块动态更新（但不是热更新），通过应用切到后台的方式来kill掉进程来达到模块重新加载－（看起来像热更新，但不是），其实是应用重启了，使用的时候应该注意保存应用状态。

 不建议使用，我们自己做的时候可以考虑其他策略。

 

http://wequick.github.io/small/upgrade/bundles.json （升级json格式）

 

"updates": [
    {
      "pkg": "net.wequick.example.small.app.about",
      "url": "http://wequick.github.io/small/upgrade/libnet_wequick_example_small_app_about.so"
    }
  ]

对应的包的so下载下来后，会在应用重启后重新被加载。

 

 因为涉及到模块之间的依赖 ，即各个插件间不同版本的依赖 （moduleA v3 版本 依赖 moduleB v4版本，   升级后moduleA v4版本依赖 moduleB v6版本 ），以及app版本号的不同，策略之间的相互配合及各种未考虑的情况可能会导致升级失败。（可以先使用简单的升级策略）

 

 

坑：

1: 不要将百川openaccount sdk放到 插件中

 原因：openaccount sdk中通过反射的方式获取资源（获取到到是宿主的id），从而导致获取不到插件中的资源。

2: 宿主不要依赖任何 插件

原因：compile是将依赖编译成aar，而small在编译的时候会将插件以application的方式编译成so，导致依赖错误。

3: app.*不能被依赖，即不能 compile project（":app.*"）