快成物流科技 x mPaaS | 小程序容器加持下的技術架構「提質增效」

簡介：大前端團隊如何選型技術？如何快速上手？如何高效協同？讓咱們看看快成科

導言

從 2017 年開始，GMTC「移動技術大會」就改名爲「大前端技術大會」。發展至今，混合開發、原生開發、前端開發等概念正在深度融合，組成「大前端」團隊。
大前端團隊如何選型技術？如何快速上手？如何高效協同？讓咱們看看快成科技如何解決這一問題。

緣起兩地三團隊

快成科技是網絡貨運領域的領軍科技企業，領域排名市場前三，平臺有 3w+ 大宗商品貨主，將貨單發佈到平臺，由 60w+ 的卡車司機接單承運，每一年產生 120億 的運費交易額。

以司機端爲例，須要承載從發單搶單到從進出場管理，從在途路徑監控到金融白條加油加氣等一系列相互強關聯、流程鏈條長的業務。這些任務由兩地三個研發團隊，共同分工協做完成。

在 7*24 小時不間斷的客戶服務和每個月 2-3 次發版的高度迭代中，技術框架瓶頸逐漸凸顯，具體包括：

• 在系統框架方面，初始框架是原生 App+HTML5，傳統 web 存在啓動白屏和性能響應不流暢，大大下降了用戶體驗；
• 在發版週期方面，研發部門多，產品鏈條長，部分企業須要更多的個性定製化服務致使發版期待週期不一致，頻繁的發包更新不只下降了運營效率，也給客戶帶來了頻繁更新的困擾；
• 在體驗一致性方面，原生開發依賴系統框架，由於原生特性不一樣，而致使各廠商多渠道平臺中差別化凸顯，多平臺性能、體驗差異較大；
• 在多部門協做方面，經常使用開發語言、前端 JavaScript 框架等不盡相同，不能及時根據需求張弛和上線 DDL 來靈活調配技術人員協做開發。

在快成科技業務持續高速發展的背景下，優秀的技術架構是「提質增效」的保障，系統重構勢在必行。快成的小夥伴們開始尋覓優秀的架構，解決場景問題。

選型四維度

快成小夥伴針對發現的問題，討論出四個選型維度：
• 框架成熟度：簡單來講，就是這個新技術是否靠譜，百億的業務壓力，沒有太多的試錯空間；
• 遷移成本：若是想獲得新技術帶來的收益，須要咱們付出什麼代價，例如新技術的學習成本、原來架構的改形成本等；
• 社區氛圍：主要是看跟進這個技術的人夠不夠多、文檔資料是否豐富、遇到問題可否獲得幫助等；
• 考量基礎上兼顧性能、跨平臺和動態性。
定好技術選型考量目標以後，團隊對常見的跨平臺方案諸如 React Native、Weex、Flutter 和小程序進行了一系列的調研以及 Demo 製做，橫向比較以下：

正在進入技術選型困境的時候，快成物流科技偶然接觸到了源自支付寶技術框架的mPaaS，經過使用 mPaaS 小程序容器，整合 mPaaS 框架、離線包和複用 h5 插件，依託於性能強勁的 web 渲染引擎，完美符合了咱們對技術選型的指望與要求。

動手試試看

選定技術選型以後，在重構初期，針對項目工程創建以及劃分上，咱們同事之間進行了一場激烈的頭腦風暴，最終選定了在多部門協做前提下進行輕量組件化並行開發多個小程序並進行動態下發的方案。
快成團隊從協同、技術等多角度，進行框架的逐步導入。
🎞如需瞭解完整內容詳情，歡迎觀看 CodeHub#5 全程回放

1. 多團隊協同

2. 真實場景測試

真機預覽與調試問題，首先要設置好白名單，設置方式可參考文檔，而後在原生端根據文檔進行相應的配置和代碼書寫，最後須要注意的是 IDE 生成的二維碼須要使用咱們 App 的掃碼能力掃描（可接入 mPaaS 的掃碼組件），用支付寶掃一掃是打不開的。

ScanService service = LauncherApplicationAgent.getInstance().getMicroApplicationContext()
        .findServiceByInterface(ScanService.class.getName());
ScanRequest scanRequest = new ScanRequest();
scanRequest.setScanType(ScanRequest.ScanType.QRCODE);
service.scan(this, scanRequest, new ScanCallback() {
    @Override
    public void onScanResult(boolean success, Intent result) {
        if (result == null || !success) {
            showScanError();
            return;
        }
        Uri uri = result.getData();
        if (uri == null) {
            showScanError();
            return;
        }
        // 啓動預覽或調試小程序，第二個參數爲小程序啓動參數
        MPTinyHelper.getInstance().launchIdeQRCode(uri, new Bundle());
    }
});

3. 核心問題解決
   

在同一小程序不一樣頁面跳轉傳參的時候咱們遇到了大參數傳遞被截斷的問題。
通過分析是小程序對路由跳轉 API 進行了參數攜帶長度的限制，後來咱們選擇使用緩存 my.setStorage 來進行大批量參數的存取使用，這裏須要注意的是同一小程序緩存上限爲 10MB，在合適的地方使用 my.clearStorage 清除緩存尤其重要。

4. 優雅的交互提高

在 UI 開發上，咱們但願小程序頁面更接近於原生，因此咱們進行了小程序的自定義導航欄的開發，這部分是須要原生端來實現的，建議下載官方 Demo 配合文檔來進行開發。
咱們還遇到過一個使人印象比較深入的 UI 問題，在 iOS 設備上進行表單類多 input 組件頁面開發時，會出現輸入錯行的狀況：

經過查閱文檔，發現這是個兼容性問題，對於須要啓動鍵盤的組件，如 input、textarea 等，目前默認使用的是原生鍵盤。

若是鍵盤和組件的交互存在異常，可在組件中添加 enableNative="{{false}}" 屬性，便可恢復到使用 WKWebview 的鍵盤。

同時因爲使用的是系統鍵盤，也就不能使用 mPaaS 提供的數字鍵盤等，鍵盤相關目前再也不專門適配。

將來可期

使用 mPaaS 小程序容器下的「快成司機」界面預覽

隨着技術的不斷演進和升級，看似開發變得愈來愈簡單便捷，減小了重複無心義的工做，實際反而特別考驗開發人員分析定位解決問題的能力，創新能力和學習能力。

但目前 mPaaS 小程序對比支付寶小程序仍是存在必定的差距，在兼容性和 H5 框架上還存在一些小問題，也但願 mPaaS 及小程序框架能不斷演進，將來可期！

原文連接

本文爲阿里雲原創內容，未經容許不得轉載。