簡介：大前端團隊如何選型技術？如何快速上手？如何高效協同？讓我們看看快成科技如何解決這一問題。
導言
從 2017 年開始，GMTC“移動技術大會”就更名為“大前端技術大會”。發展至今，混合開發、原生開發、前端開發等概念正在深度融合，組成“大前端”團隊。
大前端團隊如何選型技術？如何快速上手？如何高效協同？讓我們看看快成科技如何解決這一問題。
緣起兩地三團隊
快成科技是網絡貨運領域的領軍科技企業，領域排名市場前三，平台有 3w+ 大宗商品貨主，將貨單發佈到平台，由 60w+ 的卡車司機接單承運，每年產生 120億 的運費交易額。
以司機端為例，需要承載從發單搶單到從進出場管理，從在途路徑監控到金融白條加油加氣等一系列相互強關聯、流程鏈條長的業務。這些任務由兩地三個研發團隊，共同分工協作完成。
在 7*24 小時不間斷的客户服務和每月 2-3 次發版的高度迭代中，技術框架瓶頸逐漸凸顯，具體包括：
- 在系統框架方面，初始框架是原生 App+HTML5，傳統 web 存在啓動白屏和性能響應不流暢，大大降低了用户體驗；
- 在發版週期方面，研發部門多，產品鏈條長，部分企業需要更多的個性定製化服務導致發版期待週期不一致，頻繁的發包更新不僅降低了運營效率，也給客户帶來了頻繁更新的困擾；
- 在體驗一致性方面，原生開發依賴系統框架，因為原生特性不同，而導致各廠商多渠道平台中差異化凸顯，多平台性能、體驗差別較大；
- 在多部門協作方面，常用開發語言、前端 JavaScript 框架等不盡相同，不能及時根據需求張弛和上線 DDL 來靈活調配技術人員協作開發。
在快成科技業務持續高速發展的背景下，優秀的技術架構是“提質增效”的保障，系統重構勢在必行。快成的小夥伴們開始尋覓優秀的架構，解決場景問題。
選型四維度
快成小夥伴針對發現的問題，討論出四個選型維度：
- 框架成熟度：簡單來説，就是這個新技術是否靠譜，百億的業務壓力，沒有太多的試錯空間；
- 遷移成本：如果想得到新技術帶來的收益，需要我們付出什麼代價，例如新技術的學習成本、原來架構的改造成本等；
- 社區氛圍：主要是看跟進這個技術的人夠不夠多、文檔資料是否豐富、遇到問題能否得到幫助等；
- 考量基礎上兼顧性能、跨平台和動態性。
定好技術選型考量目標之後，團隊對常見的跨平台方案諸如 React Native、Weex、Flutter 和小程序進行了一系列的調研以及 Demo 製作，橫向比較如下：
| <span class="lake-fontsize-11">技術選型</span> | <span class="lake-fontsize-11">調研結果</span> |
| <span class="lake-fontsize-11">React Native 和 Weex</span> | <ul><li><span class="lake-fontsize-11">啓動時間慢、幀率不如原生；</span></li><li><span class="lake-fontsize-11">遷移成本較大，開發者需封裝一層較重的中間層，對研發人員要求較高。</span></li></ul> |
| <span class="lake-fontsize-11">Flutter</span> | <span class="lake-fontsize-11">性能和效率至上但是動態化能力非常有限。</span> |
| <span class="lake-fontsize-11">小程序</span> | <span class="lake-fontsize-11">本身並非一種跨平台開發方案，無法利用自身 app 打開，更看重渠道優勢。</span> |
### 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 ** * 
> 版權聲明：本文內容由阿里雲實名註冊用户自發貢獻，版權歸原作者所有，阿里雲開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里雲開發者社區用户服務協議》和《阿里雲開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。
