【.com原创稿件】从大团队并肩作战到小团队带头冲锋，高效的研发模式让App本身的整体崩溃率始终保持在0.02%以下。从大团队并肩作战到小团队独领风骚，高效的研发模式让App本身的整体崩溃率保持在0.02%以下。苏宁易购移动开发部本着以用户为中心，以开发者为导向，在现有开源方案的基础上取长补短，自主研发了全新的插件技术——APNP（AndroidPluginAndPlay）2017年初，旨在让研发更敏捷，让发布更灵活，最终满足用户极速体验产品，按需下载，动态更新。需求分析技术的引入来源于实际业务场景的技术需求，插件也是如此。那么是什么原因推动了苏宁易购App的插件化，又是什么让苏宁易购的开发者走上了自主开发插件的道路呢？为什么需要接入苏宁易购APP？发布周期长，产品迭代跟不上市场需求。对于一款电商APP来说，在不同的时间、地点，用户的消费需求千变万化、转瞬即逝，谁能在第一时间满足这些需求，谁就能把握住需求带来的销量。但是传统的App开发周期太长，我们需要更敏捷的发布方案，所以我们做了一个插件，这也是苏宁易购对插件最原始的需求。研发单线，管理协作成本高随着苏宁易购业务的不断扩张和项目参与人数的增加，单线App开发模式的隐患也日益凸显：一方面，从需求分析到研发测试，需要监督的内容越来越多；另一方面，从方案决策到流程审批，协作沟通越来越频繁，成本越来越高。因此，我们需要多线、小团队的研发模式，这进一步印证了外挂。安装量大，运营推广效率低。在需求增加的同时，安装包的体积也在同步扩大。面对费时费流量的安装包下载，新的用户体验和老用户的升级阻力也越来越大。为了解决这个问题，我们需要解包，动态下载，部分更新，所以官方引入了插件。为什么选择自研而不是使用开源方案？没有完美的开源解决方案，但访问问题层出不穷，症状相对难以修复。一方面，掌握源代码本身的成本比较高，另一方面，开源方案本身也存在缺陷。要么从头开始，要么与现有的开源方案脱节，要么对现有项目改造比较大，开发无能为力；或者外挂项目和宿主项目相互依赖，一个小动作牵一发而动全身，成本和风险都非常大。插件方案选择基于以上原因，我们决定开发自己的插件技术，于是APNP应运而生。APNP采用的插件方案是直接加载APK文件（APK格式不变，只是修改了内容）。Android系统应该正常解析和运行任何版本的匹配APK文件，无论APK文件是什么时候生成的；只要我们正确模仿系统加载APK的行为，我们就可以加载任何插件APK文件。由于研发隔离是直接加载APK文件，在APNP的设计方案中，每个插件都是一个单独的项目，也就是说除了最新的集成测试阶段，插件对应的整个软件生命周期都是独立的，不仅降低了管理和协作成本，也促进了插件产品更灵活的发布。接入简单由于是一个独立的项目，无论现有项目如何运作，开发者唯一需要做的就是从现有项目中提取插件项目。核心手段和原理如果直接加载一个原生插件的APK文件，在大多数情况下是行不通的，比如Class预验证异常，ResourceNotFound等。因此，APNP对其中的内容进行了有针对性的修改APK，同时保持APK格式不变。核心手段如下：公共依赖消除。当宿主项目（以下简称Plugin）和宿主项目（以下简称Host）中包含相同的Dependency时，需要移除Plugin中的Dependency。这样一方面可以避免Class预验证异常，另一方面可以减小插件包的大小，提高插件包的下载加载速度.实现方案（下面默认IDE为AndroidStudio）：通过Gradle插件，在Plugin的Transform过程中，剔除所有与Host具有相同Dependency的资源。PackageID修改在Android系统中，App对应的PackageID是固定的，也就是说，如果我们不手动干预，Plugin和Host打包生产的APK文件中，所有ResourceID中的PackageID都是一样，就是（0x7f）。此时如果直接加载PluginAPK，难免会出现资源类型不匹配、显示混乱等异常，所以我们修改PluginAPK的PackageID。（PackageID满足0x01
