這篇故事圍繞著一款 App 基於 mPaaS 小程式進行改造娓娓展開。
作為國內校園服務場景最豐富的平臺，笑聯 App 已覆蓋國內 130 所高校，服務近百萬高校學生。

截止目前，笑聯 App 內的 12 個業務模組目前已順利實現小程式化。不僅獲得媲美原生應用的使用者體驗，同時有效規避“發版週期長”、“無法快速線上修復 Bug”等弊端，實現真正的動態釋出與更新能力。

專案背景

開篇先做個自我介紹，笑聯 App 目前已是國內提供校園服務場景最豐富的平臺，目前已覆蓋 130 所高校，服務近百萬高校學生。

因我們提供的服務型別囊括洗衣機、熱水器、淋浴等多項功能，業務模組多元化，並且需滿足每所學校在服務型別、標準方面的個性化設計，笑聯 App 長期堆疊業務模組，缺乏規範的模組化設計，導致程式碼愈發臃腫，開發效率低下。

與此同時，隨著業務的持續擴張，任一需求的迭代均需要重新發版稽核，很顯然如此繁瑣的發版工期已無法滿足高頻更新的業務需要。

我們急需在技術側找到對應的解決思路，一方面簡化業務模組之間的耦合，加速日常的開發速度；另一方面架構上需實現模組化，找到動態釋出與更新的解決方式。

我們針對市面上已開放的技術選型做了調研，Flutter 和 mPaaS 理論上都可以滿足我們當時的選型要求，但 mPaaS 小程式動態更新的能力跟我們業務需求相吻合，避免需要頻繁更新整個 App。

接入過程

回顧 mPaaS 的接入過程，笑聯作為早期使用者，和 mPaaS 技術團隊建立了深入合作的革命友誼：一方面對於 mPaaS 整體的技術體系有了更全面的瞭解，另一方面雙方協作，針對“產品接入、功能豐富”做了很多改進工作。

Android 接入初期使用 Inside 模式，適用於業務複雜的 App，尤其是多個業務模組並行開發、迭代且需要多人多團隊協同。

但由於框架中包含一些通用第三方 SDK（如支付寶支付、微信支付、微信分享等），因這些整合的第三方 SDK 自身版本過低或者功能不全，存在一定的解除依賴工作。

後續 mPaaS 推出 AAR 原生接入模式後，由 Inside 升級至 AAR 在早期還需要技術同學的協助支援。

目前，mPaaS 已經實現針對 AAR 接入模式較好的支援：透過 mPaaS IDE 外掛，可以簡單地點選兩下，便完成小程式能力的接入。而三方 SDK 的衝突，目前配備對應的詳細文件說明。

關於這塊，我們也和 mPaaS 官方團隊做了交流，目前已將「問題定位」和「排查」作為專項重點跟進治理，我們期待後續的產品使用及問題自排查可以得到較大的體驗改善。

mPaaS 早期依賴的 Gradle 版本較低，笑聯 App 在整合的時候由於 Gradle 版本的相容問題，使得研發團隊花費大量的時間定位編譯失敗的原因，後明確是低版本 Gradle 與其他第三方庫的相容性問題導致，如 ButterKnife。

不過現在，mPaaS 已經完美適配了高版本 Gradle，初期接入過程中遇到的問題大部分已經迎刃而解。

經過一段時間的除錯，最終我們成功實現 mPaaS 的接入。一鼓作氣，現階段 12 個核心業務模組已全部完成改造，以“小程式”的方式嵌入到 App 中。

引入 mPaaS 小程式，雖過程有坎坷，仍然要多謝 mPaaS 的技術同學及時答覆與支援，最終一個個問題都得到了相應的解決。

但實際上“mPaaS 小程式”對我們的價值遠不止於此。
首先，藉助小程式的開發標準能夠快速覆蓋 Android/iOS 雙端。小程式的語法並不算難，對於新手而言上手也很快，作為客戶端同學目前可以幹兩個人的活（開玩笑）

從研發效率的提升角度來看，小程式技術棧的引入確實給我們帶來了很多改善。作為客戶端開發，不用疲於在需求的高頻迭代中，給自己更多的時間去思考去沉澱客戶端本身的移動中臺能力，利用 mPaaS 小程式提供的自定義擴充套件機制，反哺給小程式來使用。

其次，mPaaS 小程式使用了 Web 能力來進行 UI 渲染加 JSCore 處理邏輯。在渲染邏輯上，和純原生開發的頁面相比還有一點點差距，但換來的是強大的動態性以及一端開發雙端適配的研發效能提升。

另外 mPaaS 提供了獨立的 UC 核心，小程式憑藉獨立核心，針對性的渲染最佳化，其效能相較 HTML5 已做了明顯最佳化。還有即小程式的這套設計，其實渲染引擎可以無感替換，期待未來 mPaaS 可以結合 Flutter 的繪製引擎，帶來高效能的小程式方案。

再者，基於小程式開發標準，我們有能力做到豐富笑聯的生態。

笑聯 App 中可以嵌入自身業務相關小程式，也可以開放其他第三方小程式接入笑聯的功能。像笑聯是面對高校市場，未來是不是可以結合 mPaaS 開放介面，將小程式開放能力提供給高校開發者，讓更多高校開發者參與進來共建生態？

接入 mPaaS 至今，笑聯開發團隊對 mPaaS 極為肯定：

站在開發者的角度來看，mPaaS 結構清晰，語法簡潔明瞭，API 介面充足（還可以在客戶端中自定義介面?）。開發成本低、效率高發布簡單，一套程式碼覆蓋雙端，不用去考慮複雜的適配問題，甚至無需顧慮打包、稽核等繁瑣流程。
站在使用者的角度來講，小程式帶來的“即開即用”體驗，其效果幾乎與原生相同。不用單獨安裝，客戶端拋去小程式所實現的功能後，體積小，大大節省了使用者的手機儲存空間。
站在公司角度來看，引入 mPaaS 後，我們已具備能力將 App 打造出生態。目前 App 擴充套件性非常高，將來有其他的業務，可以繼續開發成小程式嵌入到 App 中，甚至在將來，還會像支付寶一樣，可以把其他合作伙伴的小程式接入到我們的 App 中。

?關於 mPaaS 小程式?
源自於支付寶小程式框架
億級線上業務體量的錘鍊
安全性媲美支付寶原生能力
不僅面向自有 App 投放小程式
更可快速構建打包覆蓋支付寶、淘寶、釘釘等應用