Taro 已經(jīng) 100% 支持轉(zhuǎn)換京東小程序，受到了很多同學(xué)的關(guān)注。當(dāng)中有歡呼雀躍的聲音：“一鍵轉(zhuǎn)換為京東小程序，終于可以準(zhǔn)時(shí)下班啦”。也有對 Taro 不太了解的同學(xué)提出了一些疑問：“轉(zhuǎn)換的效果如何？”、“轉(zhuǎn)換后代碼的性能是否達(dá)標(biāo)？” 等等。

針對各種疑問，我們從性能與開發(fā)體驗(yàn)的角度切入，把京東小程序原生開發(fā)與 Taro 開發(fā)進(jìn)行了一番對比。

性能對比

針對性能的問題，我們分別測試了 Taro 空項(xiàng)目的包大小和 Taro 在長列表中的表現(xiàn)。因?yàn)榘笮?huì)影響小程序的首次加載速度，而長列表則是常常出現(xiàn)性能瓶頸的場景。

Taro 空項(xiàng)目包大小

目前各小程序都有對主包的大小進(jìn)行限制，如京東小程序限制為 5M、微信小程序限制為 2M。這是因?yàn)槌醮芜M(jìn)入的速度對于用戶的體驗(yàn)非常地關(guān)鍵，而主包體積越大下載的時(shí)間就最長。因此小程序框架的大小也成為了開發(fā)前框架選型的重要參考指標(biāo)之一，倘若框架體積過大，就會(huì)壓縮業(yè)務(wù)邏輯的可用空間。

下列圖片分別是 Taro 運(yùn)行時(shí)框架壓縮前后的大小，可以看到壓縮后僅為84k，對主包空間的影響十分小。

壓縮前：

壓縮后：

長列表渲染表現(xiàn)

benchmark 介紹

我們參照 js-framework-benchmark 編寫了一份 benchmark，測試對比了 Taro 代碼與原生代碼在長列表場景下的渲染表現(xiàn)。

測速指標(biāo)

• 初始化：從進(jìn)入頁面開始到完成 40 個(gè)商品的渲染。

• 創(chuàng)建：頁面 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：

開始：事件響應(yīng)函數(shù)的頂部。

結(jié)束：setState 回調(diào)函數(shù)的頂部。

原生小程序：

開始：事件響應(yīng)函數(shù)的頂部。

結(jié)束：setData 回調(diào)函數(shù)的頂部。

其它

benchmark 倉庫：Github

Taro 版本：1.3.21

測試機(jī)型：魅藍(lán) note

測試方法：每組測試 10 條數(shù)據(jù)，去除其中最大值與最小值后求平均值

測試結(jié)果

因?yàn)樵诰〇|小程序與微信小程序中，setData 的 callback 的觸發(fā)時(shí)機(jī)稍有不同，所以分開列出。

操作Taro jd原生京東小程序

初始化	150	123
創(chuàng)建	87	85
部分更新	125	235
交換	140	213
選中	131	155

操作Taro weapp原生微信小程序

初始化	1155	1223
創(chuàng)建	500	408
部分更新	167	307
交換	252	309
選中	193	178

經(jīng)測試發(fā)現(xiàn)，列表的長度會(huì)對增加操作的耗時(shí)產(chǎn)生影響：列表越長，增加操作的耗時(shí)越久。因此不能簡單地對 N 次增加操作求平均增加耗時(shí)。這里我們選擇使用折線圖來展現(xiàn)出隨增加操作次數(shù)的變化，渲染耗時(shí)的變化趨勢。

測試結(jié)論

創(chuàng)建

在創(chuàng)建時(shí)，Taro 會(huì)對數(shù)據(jù)做一些處理，因此會(huì)比原生稍慢。

初始化

初始化與創(chuàng)建相比，差別是引入了頁面構(gòu)造耗時(shí)。即初始化耗時(shí) = 頁面構(gòu)造耗時(shí) + 創(chuàng)建操作耗時(shí)。

Taro 在頁面初始化、創(chuàng)建操作時(shí)都會(huì)對數(shù)據(jù)進(jìn)行處理，因此整個(gè)初始化耗時(shí)會(huì)比原生稍慢。

那為什么微信小程序中 Taro 初始化耗時(shí)更短呢？在 benchmark 中 Taro 和原生分別在 componentWillMount 和 onLoad 渲染列表，而 Taro 使用 Component 構(gòu)造頁面，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ì)先對將要 setData 的數(shù)據(jù)和當(dāng)前 data 的數(shù)據(jù)做一次 diff，這能夠大大減少 setData 的數(shù)據(jù)量，加快渲染速度。對比兩個(gè)折線圖可以得知，數(shù)據(jù)量越大，diff 的優(yōu)化收益也越大。

Taro 對小程序的性能優(yōu)化

setData

在小程序中，性能的問題主要在于單次 setData 數(shù)據(jù)量過大和頻繁調(diào)用 setData 上。Taro 利用 diff 解決了單次 setData 數(shù)據(jù)量過大的問題，而對于頻繁調(diào)用 setData 也有解決的辦法。

Taro 的 setState 遵循 React 規(guī)范，不同于 setData 的同步更新，它會(huì)異步地去更新視圖。因此假設(shè)開發(fā)者在單次事件循環(huán)中多次調(diào)用 setState，最后也只會(huì)在下一個(gè)事件循環(huán)中進(jìn)行一次 setData。

跳轉(zhuǎn)預(yù)加載

小程序由 A 頁面跳轉(zhuǎn)到 B 頁面的過程中，從 A 頁面發(fā)起跳轉(zhuǎn)到 B 頁面觸發(fā) onLoad，有著 300~400 毫秒的延時(shí)。Taro 提供了 componentWillPreload 鉤子，鉤子會(huì)在發(fā)起跳轉(zhuǎn)后立即執(zhí)行。開發(fā)者可以盡早地在鉤子里做一些數(shù)據(jù)拉取的工作，相比在 onLoad 觸發(fā)后再去拉取數(shù)據(jù)就能夠節(jié)省 300~400 毫秒的延時(shí)。

shouldComponentUpdate & Taro.PureComponent

開發(fā)者的 Class Component 可以繼承 Taro.PureComponent，這樣組件在更新前會(huì)對新舊 props 和新舊 state 各做一次淺對比，避免不必要的更新。當(dāng)然開發(fā)者可以自己實(shí)現(xiàn) shouldComponentUpdate，通過手動(dòng)控制新舊 props 和新舊 state 的對比，決定是否更新組件。

Taro.memo

如果開發(fā)者書寫的是函數(shù)式組件，則可以利用 Taro.memo 實(shí)現(xiàn) shouldComponentUpdate 的相同功能。

開發(fā)體驗(yàn)對比

語法

京東小程序的原生語法和微信小程序相仿，都是類 MVVM 語法，沒有接觸過小程序的開發(fā)者有一定學(xué)習(xí)成本。另外樣式語法為 css 的子集，其中自適應(yīng)尺寸單位為 rpx，這樣意味著如果我們需要 css 預(yù)處理器時(shí)需要手動(dòng)配置工作流，并且在編寫樣式時(shí)處處注意尺寸單位的轉(zhuǎn)換。

目前 Taro 遵循 React 語法（將來會(huì)支持所有 Web 前端框架），JSX 令我們的代碼更加靈活。因此擁有 React 開發(fā)經(jīng)驗(yàn)的開發(fā)者可以馬上上手 Taro 的開發(fā)工作。在樣式方面 Taro 支持在創(chuàng)建項(xiàng)目時(shí)選擇是否使用 css 預(yù)處理器，選擇后會(huì)自動(dòng)配置相應(yīng)的工作流。對于樣式單位 Taro 也會(huì)把用戶編寫的 px 數(shù)值自動(dòng)轉(zhuǎn)換成對應(yīng)的 rpx 數(shù)值，開發(fā)者無需再分心處理各平臺(tái)的樣式單位。

項(xiàng)目結(jié)構(gòu)

原生開發(fā)中，頁面和組件各由4個(gè)文件（js、jxml、jxss、json）所組成，代碼管理相對麻煩。

Taro 中頁面和組件均由一份 js 文件和一份樣式文件組成，創(chuàng)建與維護(hù)十分容易。

開發(fā)生態(tài)

微信小程序經(jīng)過不斷迭代，相繼推出了插件系統(tǒng)和支持引用 npm 包的功能。但京東小程序暫不支持前兩者，京東小程序社區(qū)也還沒打造起來，開發(fā)生態(tài)資源十分匱乏。

Taro 中不但能自由引用 npm 包，而且還大量支持 React 社區(qū)中沉淀的優(yōu)秀工具和庫，如 react-redux、mobx-react 等。

開發(fā)輔助

京東小程序原生開發(fā)不支持 Typescript，只能在 IDE 的編輯器中有自動(dòng)補(bǔ)全功能，編碼效率不高，同時(shí)也容易出錯(cuò)。

Taro 完美支持 Typescript，自帶代碼智能提示和代碼實(shí)時(shí)檢查功能，能讓開發(fā)效率大大提升。

寫在最后

看到這里大家可能會(huì)問，Taro 性能真的優(yōu)于原生嗎？其實(shí)并不然，針對每個(gè)場景，我們都可以用原生寫出性能最佳的代碼。但是這樣做工作量太大，實(shí)際項(xiàng)目開發(fā)中需要掌握效率與優(yōu)化之間的平衡。Taro 的優(yōu)勢在于能讓我們在書寫更有效率的代碼、擁有更豐富的生態(tài)的同時(shí)，還帶來了不錯(cuò)的性能。

最后，歡迎大家來使用 Taro 開發(fā)各端應(yīng)用，有任何開發(fā)問題或合作意愿請聯(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)室公眾號（AOTULabs），不定時(shí)推送文章：

總結(jié)

以上是生活随笔為你收集整理的京东小程序 Taro 开发对比原生开发测评的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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