這篇故事圍繞著一款 App 基于 mPaaS 小程序進行改造娓娓展開。作為國內(nèi)校園服務場景最豐富的平臺，笑聯(lián) App 已覆蓋國內(nèi) 130 所高校，服務近百萬高校學生。截止目前，笑聯(lián) App 內(nèi)的 12 個業(yè)務模塊目前已順利實現(xiàn)小程序化。不僅獲得媲美原生應用的用戶體驗，同時有效規(guī)避“發(fā)版周期長”、“無法快速在線修復 Bug”等弊端，實現(xiàn)真正的動態(tài)發(fā)布與更新能力。

項目背景

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

因我們提供的服務類型囊括洗衣機、熱水器、淋浴等多項功能，業(yè)務模塊多元化，并且需滿足每所學校在服務類型、標準方面的個性化設計，笑聯(lián) App 長期堆疊業(yè)務模塊，缺乏規(guī)范的模塊化設計，導致代碼愈發(fā)臃腫，開發(fā)效率低下。

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

我們急需在技術側找到對應的解決思路，一方面簡化業(yè)務模塊之間的耦合，加速日常的開發(fā)速度；另一方面架構上需實現(xiàn)模塊化，找到動態(tài)發(fā)布與更新的解決方式。

我們針對市面上已開放的技術選型做了調(diào)研，F(xiàn)lutter 和 mPaaS 理論上都可以滿足我們當時的選型要求，但 mPaaS 小程序動態(tài)更新的能力跟我們業(yè)務需求相吻合，避免需要頻繁更新整個 App。

接入過程

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

1. Android 接入初期使用 Inside 模式，適用于業(yè)務復雜的 App，尤其是多個業(yè)務模塊并行開發(fā)、迭代且需要多人多團隊協(xié)同。但由于框架中包含一些通用第三方 SDK（如支付寶支付、微信支付、微信分享等），因這些集成的第三方 SDK 自身版本過低或者功能不全，存在一定的解除依賴工作。
   后續(xù) mPaaS 推出 AAR 原生接入模式后，由 Inside 升級至 AAR 在早期還需要技術同學的協(xié)助支持。

目前，mPaaS 已經(jīng)實現(xiàn)針對 AAR 接入模式較好的支持：通過 mPaaS IDE 插件，可以簡單地點擊兩下，便完成小程序能力的接入。而三方 SDK 的沖突，目前配備對應的詳細文檔說明。

1. 作為早期用戶，尤其是不熟悉 mPaaS 技術體系全貌的情況下，初期遇到接入出錯時日志查看不夠方便，不利于研發(fā)團隊快速定位問題。
   關于這塊，我們也和 mPaaS 官方團隊做了交流，目前已將「問題定位」和「排查」作為專項重點跟進治理，我們期待后續(xù)的產(chǎn)品使用及問題自排查可以得到較大的體驗改善。
2. mPaaS 早期依賴的 Gradle 版本較低，笑聯(lián) App 在集成的時候由于 Gradle 版本的兼容問題，使得研發(fā)團隊花費大量的時間定位編譯失敗的原因，后明確是低版本 Gradle 與其他第三方庫的兼容性問題導致，如 ButterKnife。
   不過現(xiàn)在，mPaaS 已經(jīng)完美適配了高版本 Gradle，初期接入過程中遇到的問題大部分已經(jīng)迎刃而解。

價值沉淀

經(jīng)過一段時間的調(diào)試，最終我們成功實現(xiàn) mPaaS 的接入。一鼓作氣，現(xiàn)階段 12 個核心業(yè)務模塊已全部完成改造，以“小程序”的方式嵌入到 App 中。

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

但實際上“mPaaS 小程序”對我們的價值遠不止于此。

首先，借助小程序的開發(fā)標準能夠快速覆蓋 Android/IOS 雙端。小程序的語法并不算難，對于新手而言上手也很快，作為客戶端同學目前可以干兩個人的活（開玩笑）

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

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

另外 mPaaS 提供了獨立的 UC 內(nèi)核，小程序憑借獨立內(nèi)核，針對性的渲染優(yōu)化，其性能相較 html5 已做了明顯優(yōu)化。還有即小程序的這套設計，其實渲染引擎可以無感替換，期待未來 mPaaS 可以結合 Flutter 的繪制引擎，帶來高性能的小程序方案。

再者，基于小程序開發(fā)標準，我們有能力做到豐富笑聯(lián)的生態(tài)。

笑聯(lián) App 中可以嵌入自身業(yè)務相關小程序，也可以開放其他第三方小程序接入笑聯(lián)的功能。像笑聯(lián)是面對高校市場，未來是不是可以結合 mPaaS 開放接口，將小程序開放能力提供給高校開發(fā)者，讓更多高校開發(fā)者參與進來共建生態(tài)？

接入 mPaaS 至今，笑聯(lián)開發(fā)團隊對 mPaaS 極為肯定：

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

關于 mPaaS 小程序：源自于支付寶小程序框架，億級線上業(yè)務體量的錘煉。安全性媲美支付寶原生能力，不僅面向自有 App 投放小程序，更可快速構建打包覆蓋支付寶、淘寶、釘釘?shù)葢谩?/p>