蚂蚁金服 mPaaS IDEA 插件实践Demo演示

前言

本文深入展开 mPaaS 在 IDEA 插件开发之路上踩过的坑和沉淀的思考，希望能够带来一些参考性：

> 开篇介绍 mPaaS

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

筚路蓝缕以启山林：

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

这是对 mPaaS 刚启动并对外服务的时候，项目组开发资源的真实描摹。

在当时，四五个工程师需要 hold 如此庞大的框架并且支撑对外能力输出。对于一群熟悉 C 端业务的程序员而言，挑战不言而喻。这个时期我们基本面临两个问题：

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

在 Android 端，选择了 IDEA Plugin 作为切入点。

工欲善其事，必先利其器

> 选择 IDEA Plugin

IDEA 作为 Android 开发的工具平台，提升了 Android Coding 的效率和程序员 Coding 的幸福感。 当 mPaaS 团队开始对外提供产品服务的时候，我们希望达成一个愿景就是：simple code and simple build。 IDEA Plugin 无疑是 mPaaS 简化 Android 接入成本的不二选择。

山穷水复

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

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

 ●  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 变化，供参考：

2. 依赖问题解决：对于一个非树状的依赖关系谱来说

在依赖的添加的路上我们经历了「手动编写依赖文件」和「Gradle & IDEA 结合」两个阶段，而我们更希望能够继续演进到第三阶段：工具具备自主提示功能。

目前我们正处于这一阶段，对每一次将要发布的依赖，我们写了一个基于 Dex 产物的依赖分析器，分析 Bundle 之间的依赖关系。这个依赖分析器能够根据实现定义好的依赖切分规则，将所有 Bundle 切分成若干 Bundle 组。如图所示

 ●  2.3. 阶段：Looking Forward

我们希望的终极阶段是： 能够将用户接入体验尽可能地提升，并且工具方面有一部分自主提示的功能。如果大家有好的思路和想法，欢迎和我们一起交流。

Demo Show

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

进一步了解 mPaaS 开发环境配置和应用创建流程，参考文档：

https://tech.antfin.com/docs/2/51725

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

进一步了解图片加密，参考文档：

https://tech.antfin.com/docs/2/85833

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

进一步了解 mPaaS 热修复功能，参考文档：

https://tech.antfin.com/docs/2/85898

灯火阑珊

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

1. Fisrt about API or about Plugin

对于一个蓬勃兴起的开源项目来说，快速迭代和 API 稳定性之间似乎有难以弥合的矛盾。很多人眼中，API 稳定性会导致历史包袱沉重，但是对于 IDEA Plugin 来说，不稳定的 API 带来的是插件碎片化。这个版本可以支持的能力，下一个小版本却又不一定可以。

组件化，容器化盛行的今日，我们是不是可以将每一个 Plugin 作为一个 OSGi 的服务提供出去，保证服务的稳定性，从我的角度理解会比维持接口稳定性简单的多。

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 上。