京东小程序 Taro 开发对比原生开发测评
Taro 已經(jīng) 100% 支持轉(zhuǎn)換京東小程序，受到了很多同學(xué)的關(guān)注。當(dāng)中有歡呼雀躍的聲音：“一鍵轉(zhuǎn)換為京東小程序，終于可以準(zhǔn)時(shí)下班啦”。也有對(duì) Taro 不太了解的同學(xué)提出了一些疑問(wèn)：“轉(zhuǎn)換的效果如何？”、“轉(zhuǎn)換后代碼的性能是否達(dá)標(biāo)？” 等等。
針對(duì)各種疑問(wèn)，我們從性能與開(kāi)發(fā)體驗(yàn)的角度切入，把京東小程序原生開(kāi)發(fā)與 Taro 開(kāi)發(fā)進(jìn)行了一番對(duì)比。
性能對(duì)比
針對(duì)性能的問(wèn)題，我們分別測(cè)試了 Taro 空項(xiàng)目的包大小和 Taro 在長(zhǎng)列表中的表現(xiàn)。因?yàn)榘笮?huì)影響小程序的首次加載速度，而長(zhǎng)列表則是常常出現(xiàn)性能瓶頸的場(chǎng)景。
Taro 空項(xiàng)目包大小
目前各小程序都有對(duì)主包的大小進(jìn)行限制，如京東小程序限制為 5M、微信小程序限制為 2M。這是因?yàn)槌醮芜M(jìn)入的速度對(duì)于用戶的體驗(yàn)非常地關(guān)鍵，而主包體積越大下載的時(shí)間就最長(zhǎng)。因此小程序框架的大小也成為了開(kāi)發(fā)前框架選型的重要參考指標(biāo)之一，倘若框架體積過(guò)大，就會(huì)壓縮業(yè)務(wù)邏輯的可用空間。
下列圖片分別是 Taro 運(yùn)行時(shí)框架壓縮前后的大小，可以看到壓縮后僅為84k，對(duì)主包空間的影響十分小。
壓縮前：
壓縮后：
長(zhǎng)列表渲染表現(xiàn)
benchmark 介紹
我們參照 js-framework-benchmark 編寫(xiě)了一份 benchmark，測(cè)試對(duì)比了 Taro 代碼與原生代碼在長(zhǎng)列表場(chǎng)景下的渲染表現(xiàn)。
測(cè)速指標(biāo)
-
初始化：從進(jìn)入頁(yè)面開(kāi)始到完成 40 個(gè)商品的渲染。
-
創(chuàng)建：頁(yè)面 onLoad 后創(chuàng)建 40 個(gè)商品。
-
增加：往已創(chuàng)建了 40 個(gè)商品的列表中每次增加 20 個(gè)商品。
-
部分更新：在 400 個(gè)商品中更新每第 10 個(gè)商品的名稱。
-
交換：在 400 個(gè)商品中交換其中兩個(gè)商品的位置。
-
選中：點(diǎn)擊商品圖片，改變商品名稱的字體顏色。
計(jì)時(shí)點(diǎn)
Taro：
開(kāi)始：事件響應(yīng)函數(shù)的頂部。
結(jié)束：setState 回調(diào)函數(shù)的頂部。
原生小程序：
開(kāi)始：事件響應(yīng)函數(shù)的頂部。
結(jié)束：setData 回調(diào)函數(shù)的頂部。
其它
benchmark 倉(cāng)庫(kù)：Github
Taro 版本：1.3.21
測(cè)試機(jī)型：魅藍(lán) note
測(cè)試方法：每組測(cè)試 10 條數(shù)據(jù)，去除其中最大值與最小值后求平均值
測(cè)試結(jié)果
因?yàn)樵诰〇|小程序與微信小程序中，setData 的 callback 的觸發(fā)時(shí)機(jī)稍有不同，所以分開(kāi)列出。
| 初始化 | 150 | 123 |
| 創(chuàng)建 | 87 | 85 |
| 部分更新 | 125 | 235 |
| 交換 | 140 | 213 |
| 選中 | 131 | 155 |
| 初始化 | 1155 | 1223 |
| 創(chuàng)建 | 500 | 408 |
| 部分更新 | 167 | 307 |
| 交換 | 252 | 309 |
| 選中 | 193 | 178 |
經(jīng)測(cè)試發(fā)現(xiàn)，列表的長(zhǎng)度會(huì)對(duì)增加操作的耗時(shí)產(chǎn)生影響：列表越長(zhǎng)，增加操作的耗時(shí)越久。因此不能簡(jiǎn)單地對(duì) N 次增加操作求平均增加耗時(shí)。這里我們選擇使用折線圖來(lái)展現(xiàn)出隨增加操作次數(shù)的變化，渲染耗時(shí)的變化趨勢(shì)。
測(cè)試結(jié)論
創(chuàng)建
在創(chuàng)建時(shí)，Taro 會(huì)對(duì)數(shù)據(jù)做一些處理，因此會(huì)比原生稍慢。
初始化
初始化與創(chuàng)建相比，差別是引入了頁(yè)面構(gòu)造耗時(shí)。即初始化耗時(shí) = 頁(yè)面構(gòu)造耗時(shí) + 創(chuàng)建操作耗時(shí)。
Taro 在頁(yè)面初始化、創(chuàng)建操作時(shí)都會(huì)對(duì)數(shù)據(jù)進(jìn)行處理，因此整個(gè)初始化耗時(shí)會(huì)比原生稍慢。
那為什么微信小程序中 Taro 初始化耗時(shí)更短呢？在 benchmark 中 Taro 和原生分別在 componentWillMount 和 onLoad 渲染列表，而 Taro 使用 Component 構(gòu)造頁(yè)面，componentWillMount 其實(shí)是在 attached 生命周期中觸發(fā)。因?yàn)樵谖⑿判〕绦蛑?attached 比 onLoad 早觸發(fā)得多，所以會(huì)出現(xiàn)如此現(xiàn)象。
選中
因?yàn)?Taro 只是把回調(diào)函數(shù)包裝了一層，處理了事件參數(shù)和 this 等，所以和原生的速度相當(dāng)。
部分更新、交換、增加
Taro 的速度會(huì)優(yōu)于原生。原因是 Taro 會(huì)先對(duì)將要 setData 的數(shù)據(jù)和當(dāng)前 data 的數(shù)據(jù)做一次 diff，這能夠大大減少 setData 的數(shù)據(jù)量，加快渲染速度。對(duì)比兩個(gè)折線圖可以得知，數(shù)據(jù)量越大，diff 的優(yōu)化收益也越大。
Taro 對(duì)小程序的性能優(yōu)化
setData
在小程序中，性能的問(wèn)題主要在于單次 setData 數(shù)據(jù)量過(guò)大和頻繁調(diào)用 setData 上。Taro 利用 diff 解決了單次 setData 數(shù)據(jù)量過(guò)大的問(wèn)題，而對(duì)于頻繁調(diào)用 setData 也有解決的辦法。
Taro 的 setState 遵循 React 規(guī)范，不同于 setData 的同步更新，它會(huì)異步地去更新視圖。因此假設(shè)開(kāi)發(fā)者在單次事件循環(huán)中多次調(diào)用 setState，最后也只會(huì)在下一個(gè)事件循環(huán)中進(jìn)行一次 setData。
跳轉(zhuǎn)預(yù)加載
小程序由 A 頁(yè)面跳轉(zhuǎn)到 B 頁(yè)面的過(guò)程中，從 A 頁(yè)面發(fā)起跳轉(zhuǎn)到 B 頁(yè)面觸發(fā) onLoad，有著 300~400 毫秒的延時(shí)。Taro 提供了 componentWillPreload 鉤子，鉤子會(huì)在發(fā)起跳轉(zhuǎn)后立即執(zhí)行。開(kāi)發(fā)者可以盡早地在鉤子里做一些數(shù)據(jù)拉取的工作，相比在 onLoad 觸發(fā)后再去拉取數(shù)據(jù)就能夠節(jié)省 300~400 毫秒的延時(shí)。
shouldComponentUpdate & Taro.PureComponent
開(kāi)發(fā)者的 Class Component 可以繼承 Taro.PureComponent，這樣組件在更新前會(huì)對(duì)新舊 props 和新舊 state 各做一次淺對(duì)比，避免不必要的更新。當(dāng)然開(kāi)發(fā)者可以自己實(shí)現(xiàn) shouldComponentUpdate，通過(guò)手動(dòng)控制新舊 props 和新舊 state 的對(duì)比，決定是否更新組件。
Taro.memo
如果開(kāi)發(fā)者書(shū)寫(xiě)的是函數(shù)式組件，則可以利用 Taro.memo 實(shí)現(xiàn) shouldComponentUpdate 的相同功能。
開(kāi)發(fā)體驗(yàn)對(duì)比
語(yǔ)法
京東小程序的原生語(yǔ)法和微信小程序相仿，都是類 MVVM 語(yǔ)法，沒(méi)有接觸過(guò)小程序的開(kāi)發(fā)者有一定學(xué)習(xí)成本。另外樣式語(yǔ)法為 css 的子集，其中自適應(yīng)尺寸單位為 rpx，這樣意味著如果我們需要 css 預(yù)處理器時(shí)需要手動(dòng)配置工作流，并且在編寫(xiě)樣式時(shí)處處注意尺寸單位的轉(zhuǎn)換。
目前 Taro 遵循 React 語(yǔ)法（將來(lái)會(huì)支持所有 Web 前端框架），JSX 令我們的代碼更加靈活。因此擁有 React 開(kāi)發(fā)經(jīng)驗(yàn)的開(kāi)發(fā)者可以馬上上手 Taro 的開(kāi)發(fā)工作。在樣式方面 Taro 支持在創(chuàng)建項(xiàng)目時(shí)選擇是否使用 css 預(yù)處理器，選擇后會(huì)自動(dòng)配置相應(yīng)的工作流。對(duì)于樣式單位 Taro 也會(huì)把用戶編寫(xiě)的 px 數(shù)值自動(dòng)轉(zhuǎn)換成對(duì)應(yīng)的 rpx 數(shù)值，開(kāi)發(fā)者無(wú)需再分心處理各平臺(tái)的樣式單位。
項(xiàng)目結(jié)構(gòu)
原生開(kāi)發(fā)中，頁(yè)面和組件各由4個(gè)文件（js、jxml、jxss、json）所組成，代碼管理相對(duì)麻煩。
Taro 中頁(yè)面和組件均由一份 js 文件和一份樣式文件組成，創(chuàng)建與維護(hù)十分容易。
開(kāi)發(fā)生態(tài)
微信小程序經(jīng)過(guò)不斷迭代，相繼推出了插件系統(tǒng)和支持引用 npm 包的功能。但京東小程序暫不支持前兩者，京東小程序社區(qū)也還沒(méi)打造起來(lái)，開(kāi)發(fā)生態(tài)資源十分匱乏。
Taro 中不但能自由引用 npm 包，而且還大量支持 React 社區(qū)中沉淀的優(yōu)秀工具和庫(kù)，如 react-redux、mobx-react 等。
開(kāi)發(fā)輔助
京東小程序原生開(kāi)發(fā)不支持 Typescript，只能在 IDE 的編輯器中有自動(dòng)補(bǔ)全功能，編碼效率不高，同時(shí)也容易出錯(cuò)。
Taro 完美支持 Typescript，自帶代碼智能提示和代碼實(shí)時(shí)檢查功能，能讓開(kāi)發(fā)效率大大提升。
寫(xiě)在最后
看到這里大家可能會(huì)問(wèn)，Taro 性能真的優(yōu)于原生嗎？其實(shí)并不然，針對(duì)每個(gè)場(chǎng)景，我們都可以用原生寫(xiě)出性能最佳的代碼。但是這樣做工作量太大，實(shí)際項(xiàng)目開(kāi)發(fā)中需要掌握效率與優(yōu)化之間的平衡。Taro 的優(yōu)勢(shì)在于能讓我們?cè)跁?shū)寫(xiě)更有效率的代碼、擁有更豐富的生態(tài)的同時(shí)，還帶來(lái)了不錯(cuò)的性能。
最后，歡迎大家來(lái)使用 Taro 開(kāi)發(fā)各端應(yīng)用，有任何開(kāi)發(fā)問(wèn)題或合作意愿請(qǐng)聯(lián)系 taro@jd.com，我們會(huì)第一時(shí)間回復(fù)。
相關(guān)鏈接
- Taro 官方網(wǎng)站
- Taro 文檔
- Taro 論壇
歡迎關(guān)注凹凸實(shí)驗(yàn)室博客：aotu.io
或者關(guān)注凹凸實(shí)驗(yàn)室公眾號(hào)（AOTULabs），不定時(shí)推送文章：
總結(jié)
以上是生活随笔為你收集整理的京东小程序 Taro 开发对比原生开发测评的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 计算摄影——风格迁移
- 下一篇： double+zookeeper