這篇故事圍繞着一款 App 基於 mPaaS 小程序進行改造娓娓展開。
做爲國內校園服務場景最豐富的平臺,笑聯 App 已覆蓋國內 130 所高校,服務近百萬高校學生。
截止目前,笑聯 App 內的 12 個業務模塊目前已順利實現小程序化。不只得到媲美原生應用的用戶體驗,同時有效規避「發版週期長」、「沒法快速在線修復 Bug」等弊端,實現真正的動態發佈與更新能力。
開篇先作個自我介紹,笑聯 App 目前已經是國內提供校園服務場景最豐富的平臺,目前已覆蓋 130 所高校,服務近百萬高校學生。 安全
因咱們提供的服務類型囊括洗衣機、熱水器、淋浴等多項功能,業務模塊多元化,而且需知足每所學校在服務類型、標準方面的個性化設計,笑聯 App 長期堆疊業務模塊,缺少規範的模塊化設計,致使代碼愈發臃腫,開發效率低下。微信
與此同時,隨着業務的持續擴張,任一需求的迭代均須要從新發版審覈,很顯然如此繁瑣的發版工期已沒法知足高頻更新的業務須要。架構
咱們急需在技術側找到對應的解決思路,一方面簡化業務模塊之間的耦合,加速平常的開發速度;另外一方面架構上需實現模塊化,找到動態發佈與更新的解決方式。框架
咱們針對市面上已開放的技術選型作了調研,Flutter 和 mPaaS 理論上均可以知足咱們當時的選型要求,但 mPaaS 小程序動態更新的能力跟咱們業務需求相吻合,避免須要頻繁更新整個 App。ide
回顧 mPaaS 的接入過程,笑聯做爲早期用戶,和 mPaaS 技術團隊創建了深刻合做的革命友誼:一方面對於 mPaaS 總體的技術體系有了更全面的瞭解,另外一方面雙方協做,針對「產品接入、功能豐富」作了不少改進工做。模塊化
Android 接入初期使用 Inside 模式,適用於業務複雜的 App,尤爲是多個業務模塊並行開發、迭代且須要多人多團隊協同。性能
但因爲框架中包含一些通用第三方 SDK(如支付寶支付、微信支付、微信分享等),因這些集成的第三方 SDK 自身版本太低或者功能不全,存在必定的解除依賴工做。微信支付
後續 mPaaS 推出 AAR 原生接入模式後,由 Inside 升級至 AAR 在早期還須要技術同窗的協助支持。優化
目前,mPaaS 已經實現針對 AAR 接入模式較好的支持:經過 mPaaS IDE 插件,能夠簡單地點擊兩下,便完成小程序能力的接入。而三方 SDK 的衝突,目前配備對應的詳細文檔說明。
關於這塊,咱們也和 mPaaS 官方團隊作了交流,目前已將「問題定位」和「排查」做爲專項重點跟進治理,咱們期待後續的產品使用及問題自排查能夠獲得較大的體驗改善。
不過如今,mPaaS 已經完美適配了高版本 Gradle,初期接入過程當中遇到的問題大部分已經迎刃而解。
通過一段時間的調試,最終咱們成功實現 mPaaS 的接入。一氣呵成,現階段 12 個核心業務模塊已所有完成改造,以「小程序」的方式嵌入到 App 中。
引入 mPaaS 小程序,雖過程有坎坷,仍然要多謝 mPaaS 的技術同窗及時答覆與支持,最終一個個問題都獲得了相應的解決。
但實際上「mPaaS 小程序」對咱們的價值遠不止於此。
首先,藉助小程序的開發標準可以快速覆蓋 Android/iOS 雙端。小程序的語法並不算難,對於新手而言上手也很快,做爲客戶端同窗目前能夠幹兩我的的活(開玩笑)
從研發效率的提高角度來看,小程序技術棧的引入確實給咱們帶來了不少改善。做爲客戶端開發,不用疲於在需求的高頻迭代中,給本身更多的時間去思考去沉澱客戶端自己的移動中臺能力,利用 mPaaS 小程序提供的自定義擴展機制,反哺給小程序來使用。
其次,mPaaS 小程序使用了 Web 能力來進行 UI 渲染加 JSCore 處理邏輯。在渲染邏輯上,和純原生開發的頁面相比還有一點點差距,但換來的是強大的動態性以及一端開發雙端適配的研發效能提高。
另外 mPaaS 提供了獨立的 UC 內核,小程序憑藉獨立內核,針對性的渲染優化,其性能相較 HTML5 已作了明顯優化。還有即小程序的這套設計,其實渲染引擎能夠無感替換,期待將來 mPaaS 能夠結合 Flutter 的繪製引擎,帶來高性能的小程序方案。
再者,基於小程序開發標準,咱們有能力作到豐富笑聯的生態。
笑聯 App 中能夠嵌入自身業務相關小程序,也能夠開放其餘第三方小程序接入笑聯的功能。像笑聯是面對高校市場,將來是否是能夠結合 mPaaS 開放接口,將小程序開放能力提供給高校開發者,讓更多高校開發者參與進來共建生態?
接入 mPaaS 至今,笑聯開發團隊對 mPaaS 極爲確定:
<p style="text-align:center"> 👉關於 mPaaS 小程序👈源自於支付寶小程序框架億級線上業務體量的錘鍊安全性媲美支付寶原生能力不只面向自有 App 投放小程序更可快速構建打包覆蓋支付寶、淘寶、釘釘等應用</p>