螞蟻金服 mPaaS IDEA 外掛實踐Demo演示
前言
本文深入展開 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 過程中，我們遇到兩方面的挑戰：
● 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 上。
原文釋出時間為：2018-11-28 本文作者：木磊 本文來自雲棲社群合作伙伴“ 安卓巴士Android開發者門戶”，瞭解相關資訊可以關注“ 安卓巴士Android開發者門戶”。