技術選型從 HTML5 到小程式，走過逐漸熟悉産品的階段後，即可獲得飛升的研發效能和流暢體驗。
瞰聆資訊科技有限公司是一家專注移動醫療的公司，聚焦于采用移動化的技術手段實作醫療高效協作和精細化靈活管理。業務服務結合國内醫院的實際情況進行創新，緻力于建構國内細分領域最先進的産品和解決方案。
「南京兒醫線上」是瞰聆科技為南京兒童醫院開發的官方就醫 App，支援線上線下一體化就醫體驗。本文介紹了其如何通過接入 mPaaS 小程式進而提升應用體驗性能的故事。
項目背景
瞰聆成立以來，業務大多集中在移動端對外開放。而在 App 發展初期，我們所服務的閱聽人人群以 B 端醫生為主，考慮到醫院端業務量大、場景豐富、産品線廣，同時項目需要支援“微信公衆号”及“支付寶公衆号”。
是以我們采用了「原生 App 作為容器 + HTML5」的技術選型支撐業務開發：App 提供統一的使用者認證體系，線上加載 HTML5 頁面，并對 HTML5 提供相應的 JSSDK。由此，醫療相關的業務我們基本統一使用 HTML5 開發，期望做到一端開發，兩端适配。
然而，跑了一段時間之後，我們發現純 HTML5 開發的方式，性能體驗問題較大。比如，HTML5 頁面在使用者手機上經常出現打不開、一直加載中、卡頓等問題。
當然，面向 toB 類的業務還好，醫生使用者群的體量相對可控，能夠針對性優化解決性能問題。但一旦業務面向 toC，如若我們的 App 持續出現性能問題，随之而來的就是不可控的患者投訴和差評，既影響使用者體驗，也對公司的品牌有所傷害。
評估“南京兒醫線上”App 的使用者體量将持續增長，我們決定不再忍受純 HTML5 開發的模式，重新改造 App，勢必輸出一款能夠滿足消費級市場要求的應用。
接觸 mPaaS 之前，實際上我們也嘗試過其他跨平台的解決方案，如 Cordova、Uni-App、Flutter，甚至還有個人開發者輸出的微信小程式架構 Hera。測試了一段時間之後：
- Cordova 的性能無法滿足要求，相容性也有不少問題；
- Uni-App 傾向于純 HTML5 開發模式，評估後不太适合與原生 App 結合；
- Flutter 現階段生态還有待完善，且對應的學習成本較高，不适合我們團隊。
最終我們把目光投向了小程式。
小程式針對浏覽器核心進行了優化，分離渲染和邏輯執行引擎，再加上對渲染層做了一些優化。除了首次下載下傳需要花一些時間，之後的體驗已經非常接近原生應用。雖然個人開發者的 Hera 架構也提供了我們一些思路，但由于後續開發擴充的東西太多，如擴充 API、HTML5 端 SDK、離線下載下傳政策、渲染優化……很顯然，短時間内我們無法完成。
接入 mPaaS 過程回顧
經過一系列調研之後，我們發現 mPaaS 小程式與我們目前的需求不謀而合，同時也已沉澱了很多大客戶案例。于是我們決定接入測試 mPaaS，通過 mPaaS 小程式來提升 App 性能體驗。
當然，在對接測試過程中，我們确實也踩了不少坑，借助 mPaaS 技術團隊的支援，問題逐一得到解決。而對我們而言，實際上是逐漸熟悉産品、積累經驗的過程。下面列舉一些有代表性的問題，供大家參考：
1.初期對接階段，安卓端遇到加載線上 HTML5/小程式報【網絡不給力，請稍後再試】的問題。調試下來發現有個 RPC 請求報 7001，驗簽未通過。最後提了工單，開發同學提示需求将安裝包上傳至 mPaaS 控制台，并下載下傳新的配置檔案 ‘Ant-mpaas-xxxxx.config’，覆寫原來的配置檔案。（實際上是我們需要将安裝包的簽名做更新，修改其中 ‘base64’ 字段内容）
這個問題反映出由于我們前期沒有熟讀文檔，對問題的判斷以及解決思路不夠清晰，由此走了很多彎路。是以，開發者一定要通讀文檔，了解接入流程，進而能夠更好地提升接入效率。
2.離線包實時更新。mPaaS 離線包預設每隔 30 分鐘自動更新。但我們偶有緊急業務調整或者 Bug 需快速修複，希望使用者打開的時候就能加載最新的包。
基于這個需求，我們自主實作了一個實時更新機制。
大緻思路是啟動的時候即刻檢測是否有離線包更新，如果有，便請求下載下傳，然後重新渲染頁面。（當然這種機制相對消耗流量，也并非正常做法，我們仍在持續優化中。）如果對實作方法感興趣，大家可以參考我同僚的這篇文章：
《mPaaS 內建：基于内嵌 View 形式優化首頁更新》3.鍵盤樣式問題。fixed 定位中的輸入框彈出的鍵盤會把輸入框頂上去，而輸入框内容保持不動（如下圖所示）
經過排查後，核心原因在于一開始我們沒有擷取鍵盤的展開縮起（高度變化）的狀态，對應的解決方案即通過配置屬性即可：enableNative="false"
（原本應該在體重輸入框的，鍵盤彈起後，跑到了下面輸入框）
4.接口僅支援 GET、POST 請求。原因是由于支付寶小程式限制。
目前我們采取的方式是背景接口添加 GET/POST 支援，比如 PATCH/USER，用 POST 便變成 POST/USER/PATCH。
當然，還有個辦法是 App 提供 JSAPI，網絡通信交給 App 來做，前端調用 JSAPI 來實作。
5.iOS 端小程式标題不顯示。這個問題從接入開始，持續到項目近上線最終被解決，具體表現是 iOS 端小程式不顯示預設标題，小程式手動調用 ‘my.setNavigationBar’ 設定的方可顯示。期間我們嘗試了很多方案，雖然定位問題在用戶端，但始終沒有找到問題。
最終通過 mPaaS 開發同學發現其中一個叫 SSZipArchive 的 pod 庫，影響了架構的執行，删掉了這個引用解決了問題。
6.關于依賴庫沖突/報錯問題。
建議大家可以根據 mPaaS 官方文檔，盡量使用 mPaaS 自身的依賴，挨個排查替換即可。
7.多個小程式之間跳轉問題。在實際需求中，有小程式跳 HTML5 再跳小程式等需求。而後我們發現 App 端隻能同時存在一個小程式，無法實作小程式互跳。具體表現即，跳轉小程式之前必須關掉目前小程式，否則跳轉無效。
後來通過提工單，并通過對比文檔發現，有一個參數設定可以實作多個小程式互跳：在建立小程式的時候通過 startTinyAppWithId 方法傳入啟動參數即可實作：@{@"startMultApp":@"YES",@"appClearTop":@NO}
全新的開發體驗
借助 mPaaS 開發同學的幫助，我們的問題最終都得到了解決，項目也成功上線。上線之後，我們對部分家長使用者進行了回訪，家長的評價都是新 App 的體驗非常流暢、好用。
在第一個版本之後，我們又進行了幾次版本疊代。疊代開發過程中，我們的用戶端隻需關注與“HTML5/小程式”的互動接口擴充，HTML5/小程式端更多關注業務開發，需要什麼接口，和用戶端約定一下協定即可，幾乎實作了和用戶端的“分離”開發。
業務開發完成後，可以在支付寶小程式 IDE 上一鍵發版提測，非常友善。上線也隻需在 mPaaS 控制台手動釋出一下版本即可，實作了秒級更新。
接着還有新同僚參與進來開發了醫生端的新業務。基于之前的積累，以及 mPaaS 小程式的開發文檔，大家很快就能上手。幾天時間就開發出了一個線上開處方的應用，mPaaS 大大地提高了我們的研發效率。
綜合來看，mPaaS 幫助我們解決了最為頭疼的性能體驗問題，讓我們可以集中精力進行業務子產品的開發。
當然，mPaaS 帶來的價值還有很多。它不光解放了我們的用戶端，讓用戶端可以專注在 App 容器，不斷豐富平台能力，比如統一 UI 元件庫、身份認證體系、IM 通信、音視訊直播等等；而且統一了我們的前端開發規範，讓我們得以在統一的平台上進行業務開發，形成自己的規範，有利于代碼的沉澱和管理。
「南京兒醫線上」應用界面
未來展望
對瞰聆來說，醫療業務是我們的生命線。
我們隻有不斷地疊代、創新，才能做出真正有價值的産品，滿足使用者和客戶的要求。項目上線才是開始，我們後面要面對的問題還有很多。
基于 mPaaS，後續我們希望進一步接入其他能力，比如移動端日志上傳，幫助我們獲得使用者端 Bug 報錯；比如熱修複，幫助我們實作無感更新。
最後，我們感謝 mPaaS 團隊的無私貢獻，感謝節假日還在幫助我們解決問題的開發同學。mPaaS 還在不斷完善，我們相信 mPaaS 是一個可以依靠的平台，mPaaS 未來一定會更加強大！
特别鳴謝：特别鳴謝：熊晨良、李俊、陳剛、徐精華
END
關于 mPaaS 小程式
源自于支付寶小程式架構，億級線上業務體量的錘煉，安全性媲美支付寶原生能力。不僅面向自有 App 投放小程式，更可快速建構打包，覆寫支付寶、淘寶、釘釘等應用。