導言
從 2017 年開始，GMTC“移動技術大會”就更名為“大前端技術大會”。發展至今，混合開發、原生開發、前端開發等概念正在深度融合，組成“大前端”團隊。
大前端團隊如何選型技術？如何快速上手？如何高效協同？讓我們看看快成科技如何解決這一問題。
緣起兩地三團隊
快成科技是網絡貨運領域的領軍科技企業，領域排名市場前三，平台有 3w+ 大宗商品貨主，将貨單釋出到平台，由 60w+ 的卡車司機接單承運，每年産生 120億 的運費交易額。
以司機端為例，需要承載從發單搶單到從進出場管理，從在途路徑監控到金融白條加油加氣等一系列互相強關聯、流程鍊條長的業務。這些任務由兩地三個研發團隊，共同分工協作完成。
在 7*24 小時不間斷的客戶服務和每月 2-3 次發版的高度疊代中，技術架構瓶頸逐漸凸顯，具體包括：
- 在系統架構方面，初始架構是原生 App+HTML5，傳統 web 存在啟動白屏和性能響應不流暢，大大降低了使用者體驗；
- 在發版周期方面，研發部門多，産品鍊條長，部分企業需要更多的個性定制化服務導緻發版期待周期不一緻，頻繁的發包更新不僅降低了營運效率，也給客戶帶來了頻繁更新的困擾；
- 在體驗一緻性方面，原生開發依賴系統架構，因為原生特性不同，而導緻各廠商多管道平台中差異化凸顯，多平台性能、體驗差别較大；
- 在多部門協作方面，常用開發語言、前端 JavaScript 架構等不盡相同，不能及時根據需求張弛和上線 DDL 來靈活調配技術人員協作開發。
在快成科技業務持續高速發展的背景下，優秀的技術架構是“提質增效”的保障，系統重構勢在必行。快成的小夥伴們開始尋覓優秀的架構，解決場景問題。
選型四次元
快成小夥伴針對發現的問題，讨論出四個選型次元：
- 架構成熟度：簡單來說，就是這個新技術是否靠譜，百億的業務壓力，沒有太多的試錯空間；
- 遷移成本：如果想得到新技術帶來的收益，需要我們付出什麼代價，例如新技術的學習成本、原來架構的改造成本等；
- 社群氛圍：主要是看跟進這個技術的人夠不夠多、文檔資料是否豐富、遇到問題能否得到幫助等；
- 考量基礎上兼顧性能、跨平台和動态性。
定好技術選型考量目标之後，團隊對常見的跨平台方案諸如 React Native、Weex、Flutter 和小程式進行了一系列的調研以及 Demo 制作，橫向比較如下：
| 技術選型 | 調研結果 |
| React Native 和 Weex |
|
| Flutter | 性能和效率至上但是動态化能力非常有限。 |
| 小程式 | 本身并非一種跨平台開發方案，無法利用自身 app 打開，更看重管道優勢。 |
正在進入技術選型困境的時候，快成物流科技偶然接觸到了源自支付寶技術架構的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 及小程式架構能不斷演進，未來可期！
E · N · D