前言
本文深入展开 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 变化，供参考：
2. 依赖问题解决：对于一个非树状的依赖关系谱来说
在依赖的添加的路上我们经历了「手动编写依赖文件」和「Gradle & IDEA 结合」两个阶段，而我们更希望能够继续演进到第三阶段：工具具备自主提示功能。
● 2.1. 阶段：手动编写依赖文件这一阶段主要是手动编写依赖文件，即输出一份带有标注的文件，操作依赖文件即可。
● 2.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 上。
