Android插件化平台功能设计

前言

之前搞过一波插件化，但没考虑到太多功能，只是简单的接入了一个应用尝试。现在，相关的插件化技术已经比较成熟了，所以重新整理一下，打算做一个插件化平台出来。有很多第三方插件化技术方案，去年对比过了一下：Atlas、VirtualAPK、RePlugin三者的体验感受。根据公司业务类型和接入难度，我们决定采用360的RePlugin来设计这个插件化平台。

插件化平台的初衷

那我们要做的这个插件化平台，究竟有什么用，最终能解决我们什么样的业务需求。首先，我们先来说说我们公司的业务情况。我们有很多的业务模块，比如：起名解名、看手相、紫微命盘等等。这些都是小模块，能单独运行。然后主应用例如：灵机妙算、顺历，会按需接入这些小业务模块。目前，我们的做法是把这些业务小模块打成aar的形式，然后主应用去接入。
有什么弊端呢？
一、每个业务小模块更新内容升级的话，主应用必须得重新打包，再发上传，如果接入的主应用多了，这得浪费很多资源和时间。
二、随着内置的业务小模块多了，主应用的apk体积越来越大，有些业务小模块对用户来说不是需要的。
三、有新的业务小模块完成，必须要主应用接入才能使用，不能通过在线下发。
四、业务小模块版本很难统一，因为每个主应用接入的版本可能不一样，要维护多个版本的插件。
针对这些问题，我们的插件化平台，要做的功能，其实主要就是两点：插件的版本管理、外置插件的下载使用。

插件化平台功能点

1、类似应用市场的一个插件版本管理

插件版本管理

如上图，我们的插件化平台类似一个应用市场，对内置插件或者已下载的插件，可以直接点击打开；对版本低的插件，会有升级的提示，点击就会下载新的插件版本进行安装；对未下载的插件，可以点击安装。因为插件的信息都是由后台统一下发的，在管理后台（下篇文章会重点介绍）里面配置好主应用的构建版本和所需要下发的插件信息版本，就能获得一个插件的list数据。然后把这份list数据和RePlugin里面获取已安装的插件信息对比，就能得出“打开”、“升级”、“安装”，三种状态，然后针对这三种状态做不同的点击处理。

2、插件的分类和标签

插件分类和标签

每个插件都会有一个分类字段"type"和标签"lableText"，分类的例如"new"、"hot"，客户端可以根据这个字段来显示不同的布局。标签的例如"新版"。

3、插件的测试模式

插件上线前，肯定要进行测试，那怎么进行测试是比较方便并且准确的呢？有2种方案：
一、每个插件都有一个字段"isTest"来区分，如果下发的插件值为"true"，那就证明是测试模式，那程序里面加个逻辑处理（例如判断 L.Debug，线上版的值是false，开发版的值是true），线上版不进行处理，完全忽略，开发版才对这个插件进行处理。
二、配置一个专属的测试应用APPID，每个主应用都会带一个请求参数"APPID"，然后管理后台根据这个来下发不同的配置数据。比如线上版的"APPID"为2000，可以配置一个专属测试的"APPID"为1000。等插件测试通过了，再去修改线上版的插件配置。
第一种的话，要兼容的逻辑比较多，第二种就相当于两个应用，数据不会影响，先测试通过，再配置到正式服。基于我们公司的情况，我们决定用第二种方案。

4、插件的数据统计

当前插件有多少个用户下载或者升级，客户端可根据这个数据进行热度的排序。

5、插件的版本回退

版本回退也是会遇到的，RePlugin里面貌似没降级的处理，鉴于我们公司的开发仔贼牛逼，就算插件遇到问题，也能短时间内修复，并且上传一个新版本下发更新，所以，我们暂不考虑做版本回退的功能。如果发现线上插件有bug，马上在后台配置修改，下发为上一个版本的插件，这样防止未安装或未更新的用户继续安装更新插件。同时，让开发仔尽快修复，并且发布新的插件，待测试通过再配置新的插件下发更新。

插件数据信息

管理后台，我们在下一篇再说，我们先看看下发的插件信息：

        [
           {
                "name":"起名解名",
                "describe":"一个起名的插件",
                "icon":"http://www.icon.com/qiming.jpg",
                "iconText":"热门",
                "version":120,
                "path":"http://www.path.com/path.apk",
                "packageName":"oms.mmc.qimingjieming",
                "plugName":"qiming",
                "activityName":"oms.mmc.qimingjieming.MainActivity",
                "type":"hot",
                "apkSize":"5.2",
                "number":123
            }
        ]

插件信息，最外层是一个数组。因为RePlugin区分构建版本，就是主应用的构建版本和插件的构建版本要一致（有一点偏差貌似也行，但为了统一管理，保持一致吧）。在请求接口的时候，先把主应用的构建版本传上去，后台返回该构建版本下的插件列表。下面是插件信息的详细解析：

字段名	示例	描述
name	起名解名	插件名称
describe	一个起名的插件	插件的描述，在一些布局大的地方可以显示
icon	http://www.icon.com/qiming.jpg	插件的图标
iconText	热门	插件的标签，显示在图标右上角
version	120	插件的版本，用来判断是否升级
path	http://www.path.com/path.apk	插件的下载地址
packageName	oms.mmc.qimingjieming	插件的包名
plugName	qiming	插件的别名，可以用包名或者别名打开插件
activityName	oms.mmc.qimingjieming.MainActivity	插件的主页面，打开插件时需要传入
type	hot	插件的分类，根据不同的分类显示在不同的布局
apkSize	5.2	插件的体积，M做单位
number	123	插件的安装或升级用户数，可根据此值排序

插件化平台功能点大概就是这样，欢迎留言评论。下一篇将会介绍管理后台的功能和原型。

附上实现的demo

安装应用 更新应用