Demo Show | mPaaS IDEA 外掛實踐

摘要： 本文將結合上週在 JetBrains 開發者大會分享的《mPaaS IDEA 外掛實踐》，深入展開 mPaaS 在 IDEA 外掛開發之路上踩過的坑和沉澱的思考，希望能夠帶來一些參考性： mPaaS 冷啟動過程如何通過工具選擇優化接入成本 IDEA Plugin 開發過程中踩過的坑 思考未...

本文將結合上週在 JetBrains 開發者大會分享的《mPaaS IDEA 外掛實踐》，深入展開 mPaaS 在 IDEA 外掛開發之路上踩過的坑和沉澱的思考，希望能夠帶來一些參考性：

mPaaS 冷啟動過程如何通過工具選擇優化接入成本 IDEA Plugin 開發過程中踩過的坑 思考未來 Code&Build 效率的提升

[img_mPaaS Introduction]

篳路藍縷以啟山林

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 建立工程

ofollow,noindex">

進一步瞭解 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 技術實踐乾貨

號外！問卷調研

填寫你對移動開發的具體需求和痛點吧，幫助我們進一步優化 mPaaS 的能力！

即日起截止 11.30 晚 18:00，填寫提交mPaaS 開發者調研問卷，即有機會獲取限量版螞蟻 U 型枕 1 個。

我們將在掘金平臺完成問卷填寫的使用者中抽取 5 位，贈送 螞蟻公仔限量版 U 型枕 。

問卷地址請戳：t.cn/E2RZJ3r