簡介：大前端團(tuán)隊(duì)如何選型技術(shù)？如何快速上手？如何高效協(xié)同？讓我們看看快成科技如何解決這一問題。

導(dǎo)言

從 2017 年開始，GMTC“移動技術(shù)大會”就更名為“大前端技術(shù)大會”。發(fā)展至今，混合開發(fā)、原生開發(fā)、前端開發(fā)等概念正在深度融合，組成“大前端”團(tuán)隊(duì)。

大前端團(tuán)隊(duì)如何選型技術(shù)？如何快速上手？如何高效協(xié)同？讓我們看看快成科技如何解決這一問題。

緣起兩地三團(tuán)隊(duì)

快成科技是網(wǎng)絡(luò)貨運(yùn)領(lǐng)域的領(lǐng)軍科技企業(yè)，領(lǐng)域排名市場前三，平臺有?3w+?大宗商品貨主，將貨單發(fā)布到平臺，由?60w+?的卡車司機(jī)接單承運(yùn)，每年產(chǎn)生?120億?的運(yùn)費(fèi)交易額。

以司機(jī)端為例，需要承載從發(fā)單搶單到從進(jìn)出場管理，從在途路徑監(jiān)控到金融白條加油加氣等一系列相互強(qiáng)關(guān)聯(lián)、流程鏈條長的業(yè)務(wù)。這些任務(wù)由兩地三個研發(fā)團(tuán)隊(duì)，共同分工協(xié)作完成。

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

• 在系統(tǒng)框架方面，初始框架是原生 App+HTML5，傳統(tǒng) web 存在啟動白屏和性能響應(yīng)不流暢，大大降低了用戶體驗(yàn)；
  
• 在發(fā)版周期方面，研發(fā)部門多，產(chǎn)品鏈條長，部分企業(yè)需要更多的個性定制化服務(wù)導(dǎo)致發(fā)版期待周期不一致，頻繁的發(fā)包更新不僅降低了運(yùn)營效率，也給客戶帶來了頻繁更新的困擾；
  
• 在體驗(yàn)一致性方面，原生開發(fā)依賴系統(tǒng)框架，因?yàn)樵匦圆煌?#xff0c;而導(dǎo)致各廠商多渠道平臺中差異化凸顯，多平臺性能、體驗(yàn)差別較大；
  
• 在多部門協(xié)作方面，常用開發(fā)語言、前端 JavaScript 框架等不盡相同，不能及時(shí)根據(jù)需求張弛和上線 DDL 來靈活調(diào)配技術(shù)人員協(xié)作開發(fā)。
  

在快成科技業(yè)務(wù)持續(xù)高速發(fā)展的背景下，優(yōu)秀的技術(shù)架構(gòu)是“提質(zhì)增效”的保障，系統(tǒng)重構(gòu)勢在必行。快成的小伙伴們開始尋覓優(yōu)秀的架構(gòu)，解決場景問題。

選型四維度

快成小伙伴針對發(fā)現(xiàn)的問題，討論出四個選型維度：

• 框架成熟度：簡單來說，就是這個新技術(shù)是否靠譜，百億的業(yè)務(wù)壓力，沒有太多的試錯空間；
  
• 遷移成本：如果想得到新技術(shù)帶來的收益，需要我們付出什么代價(jià)，例如新技術(shù)的學(xué)習(xí)成本、原來架構(gòu)的改造成本等；
  
• 社區(qū)氛圍：主要是看跟進(jìn)這個技術(shù)的人夠不夠多、文檔資料是否豐富、遇到問題能否得到幫助等；
  
• 考量基礎(chǔ)上兼顧性能、跨平臺和動態(tài)性。
  

定好技術(shù)選型考量目標(biāo)之后，團(tuán)隊(duì)對常見的跨平臺方案諸如 React Native、Weex、Flutter 和小程序進(jìn)行了一系列的調(diào)研以及 Demo 制作，橫向比較如下：

技術(shù)選型	調(diào)研結(jié)果
React Native 和 Weex	啟動時(shí)間慢、幀率不如原生； 遷移成本較大，開發(fā)者需封裝一層較重的中間層，對研發(fā)人員要求較高。
Flutter	性能和效率至上但是動態(tài)化能力非常有限。
小程序	本身并非一種跨平臺開發(fā)方案，無法利用自身 app 打開，更看重渠道優(yōu)勢。

正在進(jìn)入技術(shù)選型困境的時(shí)候，快成物流科技偶然接觸到了源自支付寶技術(shù)框架的mPaaS，通過使用 mPaaS 小程序容器，整合 mPaaS 框架、離線包和復(fù)用 h5 插件，依托于性能強(qiáng)勁的 web 渲染引擎，完美符合了我們對技術(shù)選型的期望與要求。

動手試試看

選定技術(shù)選型之后，在重構(gòu)初期，針對項(xiàng)目工程建立以及劃分上，我們同事之間進(jìn)行了一場激烈的頭腦風(fēng)暴，最終選定了在多部門協(xié)作前提下進(jìn)行輕量組件化并行開發(fā)多個小程序并進(jìn)行動態(tài)下發(fā)的方案。

快成團(tuán)隊(duì)從協(xié)同、技術(shù)等多角度，進(jìn)行框架的逐步導(dǎo)入。

🎞如需了解完整內(nèi)容詳情，歡迎觀看 CodeHub#5 全程回放

1. 多團(tuán)隊(duì)協(xié)同

2. 真實(shí)場景測試

真機(jī)預(yù)覽與調(diào)試問題，首先要設(shè)置好白名單，設(shè)置方式可參考文檔，然后在原生端根據(jù)文檔進(jìn)行相應(yīng)的配置和代碼書寫，最后需要注意的是 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; } // 啟動預(yù)覽或調(diào)試小程序，第二個參數(shù)為小程序啟動參數(shù) MPTinyHelper.getInstance().launchIdeQRCode(uri, new Bundle()); } });

3. 核心問題解決

在同一小程序不同頁面跳轉(zhuǎn)傳參的時(shí)候我們遇到了大參數(shù)傳遞被截?cái)嗟膯栴}。

經(jīng)過分析是小程序?qū)β酚商D(zhuǎn) API 進(jìn)行了參數(shù)攜帶長度的限制，后來我們選擇使用緩存 my.setStorage 來進(jìn)行大批量參數(shù)的存取使用，這里需要注意的是同一小程序緩存上限為 10MB，在合適的地方使用 my.clearStorage 清除緩存尤為重要。

4. 優(yōu)雅的交互提升

在 UI 開發(fā)上，我們希望小程序頁面更接近于原生，所以我們進(jìn)行了小程序的自定義導(dǎo)航欄的開發(fā)，這部分是需要原生端來實(shí)現(xiàn)的，建議下載官方 Demo 配合文檔來進(jìn)行開發(fā)。

我們還遇到過一個令人印象比較深刻的 UI 問題，在 iOS 設(shè)備上進(jìn)行表單類多 input 組件頁面開發(fā)時(shí)，會出現(xiàn)輸入錯行的情況：

通過查閱文檔，發(fā)現(xiàn)這是個兼容性問題，對于需要啟動鍵盤的組件，如 input、textarea 等，目前默認(rèn)使用的是原生鍵盤。

如果鍵盤和組件的交互存在異常，可在組件中添加 enableNative="{{false}}" 屬性，即可恢復(fù)到使用 WKWebview 的鍵盤。

同時(shí)由于使用的是系統(tǒng)鍵盤，也就不能使用 mPaaS 提供的數(shù)字鍵盤等，鍵盤相關(guān)目前不再專門適配。

未來可期

使用 mPaaS 小程序容器下的「快成司機(jī)」界面預(yù)覽

隨著技術(shù)的不斷演進(jìn)和升級，看似開發(fā)變得越來越簡單便捷，減少了重復(fù)無意義的工作，實(shí)際反而特別考驗(yàn)開發(fā)人員分析定位解決問題的能力，創(chuàng)新能力和學(xué)習(xí)能力。

但目前 mPaaS 小程序?qū)Ρ戎Ц秾毿〕绦蜻€是存在一定的差距，在兼容性和 H5 框架上還存在一些小問題，也希望 mPaaS 及小程序框架能不斷演進(jìn)，未來可期！

E · N?· D

---

原文鏈接：https://developer.aliyun.com/article/784227?

版權(quán)聲明：本文內(nèi)容由阿里云實(shí)名注冊用戶自發(fā)貢獻(xiàn)，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權(quán)保護(hù)指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進(jìn)行舉報(bào)，一經(jīng)查實(shí)，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的快成物流科技 x mPaaS | 小程序容器加持下的技术架构“提质增效”的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。