Demo Show | 蚂蚁金服 mPaaS IDEA 插件实践-CSDN博客

前言

本文将结合上周在 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 等工具树形依赖显然不能满足要求。

柳暗花明

解决依赖问题

为了兼容不同的 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

依赖问题解决：对于一个非树状的依赖关系谱来说
在依赖的添加的路上我们经历了「手动编写依赖文件」和「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 效率的思考

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 上。
让我们拭目以待。