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 型枕。