Demo Show | 蚂蚁金服 mPaaS IDEA 插件实践

前言

本文将结合上周在 JetBrains 开发者大会分享的《mPaaS IDEA 插件实践》，深刻展开 mPaaS 在 IDEA 插件开发之路上踩过的坑和沉淀的思考，但愿可以带来一些参考性：

• mPaaS 冷启动过程如何经过工具选择优化接入成本
• IDEA Plugin 开发过程当中踩过的坑
• 思考将来 Code&Build 效率的提高

开篇介绍 mPaaS

移动开发平台（Mobile PaaS，简称 mPaaS）是源于支付宝 App 的移动开发平台，为移动开发、测试、运营及运维提供云到端的一站式解决方案，能有效下降技术门槛、减小研发成本、提高开发效率，协助企业快速搭建稳定高质量的移动 App。

筚路蓝缕以启山林

mPaaS 冷启动时的接入成本优化

这是对 mPaaS 刚启动并对外服务的时候，项目组开发资源的真实描摹。 在当时，四五个工程师须要 hold 如此庞大的框架而且支撑对外能力输出。对于一群熟悉 C 端业务的程序员而言，挑战不言而喻。这个时期咱们基本面临两个问题：

• 客户来源从哪里来？
• 如何进一步简化客户接入成本

接下来咱们着重围绕「如何简化客户接入成本」展开讨论，主要为两部分：

• Code
• Build

因此，咱们在 Android 端，选择了 IDEA Plugin 做为切入点。

工欲善其事，必先利其器：选择 IDEA Plugin IDEA 做为 Android 开发的工具平台，提高了 Android Coding 的效率和程序员 Coding 的幸福感。 当 mPaaS 团队开始对外提供产品服务的时候，咱们但愿达成一个愿景就是：simple code and simple build。 IDEA Plugin 无疑是 mPaaS 简化 Android 接入成本的不二选择。

山穷水复

如何克服 IDEA Plugin 开发过程当中踩过的坑

在开发 IDEA Plugin 过程当中，咱们遇到两方面的挑战：

• 遇到全部应用开发过程当中都会遇到的问题，API 接口稳定性
• code everything 和 build erverything 的统一

API 接口稳定性

mPaaS IDEA 插件是基于 Android Studio Android Plugin 之上的一层插件封装。 在基于 Android Studio Plugin 以及 IDEA 开发过程当中，最大的困扰来来自于 API 不稳定、修改频繁， 例如： Gradle build 、Install apk等功能的api在Android studio  2.1x 版本和 3.x 版本实现彻底不一样。（参见后文API变化列表）。

Code Everything and Build Everything

mPaaS 存在若干组件，组件以前的关系如图所示

因此不能采用传统的 maven 树状依赖传递，只能采用依赖图的方式传递依赖。Gradle、Maven 等工具树形依赖显然不能知足要求。

柳暗花明

解决依赖问题

1. 为了兼容不一样的 Android Studio，咱们写 20+ 适配器，只为兼容 Android Studio 新版本的 API

如下仅是部分 API 变化，供参考：

API	3.0.1	3.1.0	3.1.2	3.1.4	3.2	3.2.x
GradleRequest	默认constuctor	默认constuctor	默认constuctor	constuctor with file	constuctor with file	默认constuctor,but but classpath 不一致
Gradle Invoker	Gradle Build invoker	Gradle Build invoker	Gradle Build invoker	Gradle Build invoker	Gradle Build invoker	Gradle Build invoker，classpath 不一致
Import Gradle Project	NewProjectImportGradleSyncListener	NewProjectImportGradleSyncListener	NewProjectImportGradleSyncListener	NewProjectImportGradleSyncListener	GradleSyncListener

2. 依赖问题解决：对于一个非树状的依赖关系谱来讲 在依赖的添加的路上咱们经历了「手动编写依赖文件」和「Gradle & IDEA 结合」两个阶段，而咱们更但愿可以继续演进到第三阶段：工具具有自主提示功能。

• 2.1. 经历过手动编写依赖文件

  这一阶段，就是给一份带有标注的文件，操做依赖文件便可

• 2.2. Gradle & IDEA 结合

  目前咱们正处于这一阶段，对每一次将要发布的依赖，咱们写了一个基于 Dex 产物的依赖分析器，分析 Bundle 之间的依赖关系。

  这个依赖分析器可以根据实现定义好的依赖切分规则，将全部Bundle切分红若干Bundle组。如图所示

• 2.3. Looking forward

  咱们但愿的终极阶段是：可以将用户接入体验尽量地提高，而且工具方面有一部分自主提示的功能。若是你们有好的思路和想法，欢迎和咱们一块儿交流。

Demo Show：

演示如何运用 mPaaS IDEA Plugin 建立工程

进一步了解 mPaaS 开发环境配置和应用建立流程，参考文档： tech.antfin.com/docs/2/5172…

---

演示如何运用 mPaaS IDEA Plugin 生成无线保镖图片

进一步了解图片加密，参考文档： tech.antfin.com/docs/2/8583…

---

演示如何运用 mPaaS IDEA Plugin 接入热修复能力

进一步了解 mPaaS 热修复功能，参考文档： tech.antfin.com/docs/2/8589…

灯火阑珊

如何优化 Code&Build 效率的思考

• 5.1 Fisrt about API or about Plugin

对于一个蓬勃兴起的开源项目来讲，快速迭代和 API 稳定性之间彷佛有难以弥合的矛盾。历史包袱恰是 API 稳定性的产物，不少人眼中，Api稳定性会致使历史包袱沉重，可是对于 IDEA Plugin 来讲，不稳定的 API 带来的是插件碎片化。这个版本能够支持的能力，下一个小版本却又不必定能够。组件化，容器化盛行的今日，咱们是否是能够将每个 Plugin 做为一个 OSGi 的服务提供出去，保证服务的稳定性，从个人角度理解会比维持接口稳定性简单的多。

• 5.2 Code and Build：

Code 和 Build 是工程师的左右手，左手 Code，一行有一行，右手 Build 一次又一次。 IDEA 拥有 Android、Python、Go、Web 和 C/C++ 等众多 IDE 分支，可谓是 Code Everything 的表明。 Gradle 的 Solgan 是 build ererything。 那是否 IDEA 和 Gradle 能够有更加良好的协做方式，在 Build error and error 重重包围下，解放程序员，让程序员花费更多的时间在 Code 上。 让咱们拭目以待。

往期阅读

《开篇 | 模块化与解耦式开发在蚂蚁金服 mPaaS 深度实践探讨》

《支付宝移动端动态化方案实践》

《支付宝客户端架构解析：iOS 容器化框架初探》

《支付宝客户端架构解析：Android 容器化框架初探》

《支付宝客户端架构解析：Android 客户端启动速度优化之「垃圾回收」》

关注咱们公众号，得到第一手 mPaaS 技术实践干货

---

号外！问卷调研

填写你对移动开发的具体需求和痛点吧，帮助咱们进一步优化 mPaaS 的能力！

即日起截止 11.30 晚 18:00，填写提交 mPaaS 开发者调研问卷，即有机会获取限量版蚂蚁 U 型枕 1 个。 咱们将在掘金平台完成问卷填写的用户中抽取 5 位，赠送蚂蚁公仔限量版 U 型枕。