用 Hermes 三個(gè)月我最大的感受是如果你剛上手就急著啃源碼、調(diào)參數(shù)那基本都是白費(fèi)勁。很多人跟我一樣一開始聽說 Hermes 是移動(dòng)端 JavaScript 引擎立刻去翻官方文檔結(jié)果被一堆底層概念砸暈然后就開始到處問“Hermes 怎么調(diào)優(yōu)”。其實(shí)入門階段的重點(diǎn)根本不在這。我剛?cè)腴T時(shí)也走過一段彎路集合、Promise、異步這些特性都去試了一遍直到第三個(gè)月回頭看才發(fā)現(xiàn)真正讓我把 Hermes 用明白的是四件事——搞懂它的定位、學(xué)會(huì)集成配置、掌握調(diào)試剖析、記清兼容邊界。這篇就把我的學(xué)習(xí)路線整理出來給準(zhǔn)備入門的你做個(gè)參照。1. 先學(xué)第一件事搞懂 Hermes 的定位再?zèng)Q定怎么學(xué)1.1 Hermes 不是普通 JS 引擎先忘掉瀏覽器那套很多人會(huì)本能地把 Hermes 當(dāng)成一個(gè)“跑得更快的 JavaScript 引擎”然后直接用瀏覽器引擎的思路去理解它。這個(gè)誤區(qū)會(huì)直接影響你后面所有學(xué)習(xí)節(jié)奏。我用了一個(gè)月才繞出來Hermes 從設(shè)計(jì)目標(biāo)上就不是為了跟桌面瀏覽器搶性能它是為移動(dòng)端準(zhǔn)備的核心目標(biāo)是降低內(nèi)存占用、縮短啟動(dòng)耗時(shí)、讓低端機(jī)能跑得更穩(wěn)。如果把傳統(tǒng)瀏覽器引擎比作“現(xiàn)場(chǎng)開火的廚房”那 Hermes 更像是“預(yù)制菜生產(chǎn)線”。它在應(yīng)用打包階段就把 JavaScript 源碼編譯成字節(jié)碼運(yùn)行時(shí)不再需要一遍遍解析源碼、做各種動(dòng)態(tài)優(yōu)化。這意味著你寫代碼時(shí)可以享受 JavaScript 的語法便利但真正在設(shè)備上跑的是已經(jīng)加工好的字節(jié)碼。想明白這一點(diǎn)你才會(huì)懂為什么 Hermes 會(huì)犧牲某些動(dòng)態(tài)能力去換啟動(dòng)速度和內(nèi)存穩(wěn)定。我剛開始就把注意力放在“怎么寫出更快的 JS 函數(shù)”上后來發(fā)現(xiàn)這是本末倒置。Hermes 的瓶頸往往是引擎策略和應(yīng)用架構(gòu)共同決定的單獨(dú)摳某個(gè)函數(shù)語法收益極低。與其糾結(jié)微優(yōu)化不如先建立正確的心理模型它在做什么、不做什么、為什么這么做。1.2 摸清三個(gè)核心概念字節(jié)碼、無 JIT、GC 策略入門 Hermes 不需要背一堆術(shù)語但下面三個(gè)概念必須有自己的理解否則后面調(diào)優(yōu)時(shí)你根本不知道指標(biāo)代表什么。第一是字節(jié)碼。Hermes 的構(gòu)建流程會(huì)把.js文件預(yù)編譯成.hbc字節(jié)碼設(shè)備運(yùn)行的是這段字節(jié)碼。好處是免去了運(yùn)行時(shí)逐行 parse 的開銷所以冷啟動(dòng)快代價(jià)是代碼熱更新時(shí)必須保證引擎和字節(jié)碼版本匹配不能像以前那樣隨便替換一個(gè) JS 文件就完事。我在第二個(gè)項(xiàng)目里剛開始做熱更新方案就因?yàn)檫@個(gè)版本匹配問題吃過虧。第二是無 JIT。Hermes 故意不做即時(shí)編譯(JIT)這在移動(dòng)端反而是優(yōu)勢(shì)。JIT 雖然能提升長時(shí)間運(yùn)行時(shí)的計(jì)算性能但它需要預(yù)熱期還會(huì)額外占用內(nèi)存。Hermes 的策略是“我不要峰值性能我要平穩(wěn)且可預(yù)期的表現(xiàn)”。所以你寫代碼時(shí)不要刻意追求“讓 JIT 更容易優(yōu)化”的寫法而要考慮“盡量少造臨時(shí)對(duì)象、少觸發(fā) GC”。第三是 GC 策略。Hermes 使用分代垃圾回收對(duì)象分配和回收模式跟瀏覽器有差異。剛開始你用 Chrome DevTools 的經(jīng)驗(yàn)去分析 Hermes 內(nèi)存問題會(huì)發(fā)現(xiàn)很多結(jié)論對(duì)不上。比如在瀏覽器里看似無害的閉包引用在 Hermes 里可能因?yàn)榇H晉升導(dǎo)致老年代快速膨脹。你得重新學(xué)習(xí)它的 GC 行為而不是套舊經(jīng)驗(yàn)。這三個(gè)概念串起來你就能看懂 Hermes 的設(shè)計(jì)哲學(xué)用預(yù)編譯和確定性換取可預(yù)期的性能。它不適合作為“萬能引擎”但非常適合移動(dòng)端這種資源受限的環(huán)境。1.3 為什么“先學(xué)定位”能讓你少走彎路我見過不少人一上來就去調(diào) Hermes 的 GC 參數(shù)結(jié)果越調(diào)越差。原因很簡單他們不知道問題出在引擎層還是業(yè)務(wù)層。如果不懂 Hermes 的定位你很容易把業(yè)務(wù)代碼的鍋算到引擎頭上或者反過來。舉個(gè)例子我第三個(gè)練習(xí)項(xiàng)目里有個(gè)列表滑動(dòng)卡頓的問題。一開始我懷疑是渲染層更新太慢把列表項(xiàng)拆了一堆組件毫無效果。后來用引擎自帶的分析工具抓了一次采樣發(fā)現(xiàn)卡頓的根源是列表滾動(dòng)時(shí)頻繁創(chuàng)建大字符串導(dǎo)致 GC 頻繁觸發(fā)。這個(gè)結(jié)論靠“猜”是猜不出來的只有理解了 Hermes 的 GC 行為和內(nèi)存分配模型才知道該往哪個(gè)方向查。所以我建議入門第一周只看官方文檔里的架構(gòu)和高層設(shè)計(jì)不要碰參數(shù)調(diào)優(yōu)。你的目標(biāo)是回答幾個(gè)問題Hermes 和傳統(tǒng)引擎的核心差異是什么它的字節(jié)碼產(chǎn)物如何產(chǎn)生和使用GC 大概在什么條件下觸發(fā)當(dāng)你能用自己的話解釋清楚再進(jìn)入下一階段。2. 先學(xué)第二件事掌握 Hermes 的集成與配置2.1 開啟 Hermes 前先檢查你的工程環(huán)境第二件事往往被忽略因?yàn)楹芏嗳艘詾?Hermes 是“默認(rèn)就能跑”結(jié)果真機(jī)上打開后一堆詭異問題。我個(gè)人的教訓(xùn)是先把工程環(huán)境理順再談開啟。第一步確認(rèn)你使用的跨平臺(tái)框架版本是否支持 Hermes以及默認(rèn)是否開啟。不同版本的默認(rèn)值不一樣有些新工程創(chuàng)建時(shí)已經(jīng)開啟舊工程則需要手動(dòng)打開。第二步檢查依賴管理器里的 Hermes 引擎版本是否和框架版本匹配。版本不匹配是啟動(dòng)崩潰的高頻原因。第三步確認(rèn)你的構(gòu)建環(huán)境支持生成字節(jié)碼尤其是 Windows 和 macOS 上可能要走不同的二進(jìn)制路徑。這里給一個(gè)常見的 Android 工程配置示例注意不同版本寫法可能不同android { defaultConfig { // 常規(guī)配置 } } // 開啟 Hermes def enableHermes true if (enableHermes) { // 引入 Hermes 引擎依賴 implementation(hermes-engine) { exclude group: com.facebook, module: jsc } }iOS 工程一般在依賴描述文件里開啟開啟后執(zhí)行依賴安裝命令。這一步做完以后最好先跑一個(gè)沒有任何業(yè)務(wù)邏輯的空白頁面確認(rèn)引擎能正常啟動(dòng)。我見過有人一上來就開著 Hermes 接一堆原生模塊最后根本分不清是引擎問題還是模塊沖突問題。2.2 集成后必須調(diào)整的 4 個(gè)配置細(xì)節(jié)集成只是開始想讓 Hermes 真正發(fā)揮作用下面 4 個(gè)配置細(xì)節(jié)一定要處理。第一個(gè)是區(qū)分 debug 和 release 模式。很多版本的 Hermes 在 debug 模式下不會(huì)啟用完整的字節(jié)碼路徑而是為了方便調(diào)試采取降級(jí)策略。所以你測(cè)試性能時(shí)必須用 release 模式不然你會(huì)發(fā)現(xiàn)線上和本地?cái)?shù)據(jù)完全對(duì)不上。我第一次測(cè)啟動(dòng)時(shí)間就是在 debug 模式下測(cè)的數(shù)字很好看上線后直接被打臉。第二個(gè)是內(nèi)存相關(guān)配置。Hermes 對(duì)內(nèi)存占用比較敏感如果應(yīng)用頁面比較重可以考慮在原生層申請(qǐng)更大的堆空間但這個(gè)方案要謹(jǐn)慎使用。我的經(jīng)驗(yàn)是先用引擎自帶的內(nèi)存分析工具找到大頭再?zèng)Q定是否需要調(diào)堆。無腦調(diào)大會(huì)讓系統(tǒng)更容易殺你的進(jìn)程得不償失。第三個(gè)是包體積評(píng)估。Hermes 引擎本身會(huì)帶來幾十 MB 的 so 文件但另一方面字節(jié)碼比原始 JS 源碼更緊湊還能省掉一部分運(yùn)行時(shí)解析代碼。所以打包后體積是變大還是變小取決于你的 JS 代碼量占比。集成后記得跑一次完整的打包對(duì)比別憑感覺判斷。第四個(gè)是 sourcemap 配置。Hermes 運(yùn)行時(shí)出錯(cuò)時(shí)你拿到的堆棧往往定位到編譯后的字節(jié)碼或壓縮后的 JS必須配合 sourcemap 才能還原成源碼位置。很多線上錯(cuò)誤監(jiān)控平臺(tái)都支持上傳 sourcemap但需要你在構(gòu)建腳本里配置好產(chǎn)物路徑。我之前漏配了這一步線上一個(gè)崩潰查了兩天才定位到原因。配置項(xiàng)建議說明debug/release 分環(huán)境開著 Hermes 做 release 測(cè)試debug 模式可能走降級(jí)路徑原生堆內(nèi)存先分析再調(diào)整盲目調(diào)大可能影響存活率包體積對(duì)比集成后跑一次完整打包引擎體積與字節(jié)碼節(jié)省互相抵消sourcemap構(gòu)建時(shí)生成并上傳沒有它線上堆棧沒法定位2.3 集成時(shí)最容易忽略的坑集成 Hermes 的“坑”和集成普通依賴不是一回事最常見的問題出現(xiàn)在多架構(gòu)支持和代碼壓縮環(huán)節(jié)。多架構(gòu)支持這塊很多跨平臺(tái)框架打包時(shí)會(huì)針對(duì)不同 CPU 架構(gòu)生成不同的 so 文件。如果你只在模擬器上測(cè)試很容易漏掉真機(jī)上的某些架構(gòu)包導(dǎo)致用戶設(shè)備崩潰或閃退。建議在集成說明里把架構(gòu)列表列清楚至少保證常見真機(jī)架構(gòu)都有覆蓋。代碼壓縮環(huán)節(jié)Hermes 自身的字節(jié)碼生成和第三方壓縮工具需要配合好。有些壓縮工具會(huì)改寫函數(shù)名或變量名如果 Hermes 在字節(jié)碼生成前拿到的是已經(jīng)壓縮過的代碼可能影響產(chǎn)物穩(wěn)定性。更常見的是混淆規(guī)則沒配置完整運(yùn)行時(shí)發(fā)現(xiàn)某些類被移除了。我的習(xí)慣是每改一次混淆規(guī)則就在所有目標(biāo)架構(gòu)上跑一遍冒煙測(cè)試省得發(fā)版后出丑。還有一個(gè)容易被忽略的點(diǎn)熱更新。如果你所在項(xiàng)目使用熱更新方案務(wù)必確認(rèn)熱更新產(chǎn)物也經(jīng)過 Hermes 字節(jié)碼生成流程而不是直接從舊版 JS 路徑加載。兩個(gè)版本加載路徑不一致輕則功能異常重則直接啟動(dòng)崩潰。3. 先學(xué)第三件事學(xué)會(huì) Hermes 的調(diào)試與性能分析3.1 調(diào)試模式連不上先檢查這幾處Hermes 支持主流的調(diào)試協(xié)議你可以像調(diào)試普通 JavaScript 一樣打斷點(diǎn)、看變量但第一次連不上是常態(tài)。我碰到最多的原因有三個(gè)。第一設(shè)備或模擬器沒有和調(diào)試端口建立正確連接。有些調(diào)試協(xié)議需要你在啟動(dòng)參數(shù)里顯式開啟 inspect 能力或者通過代理工具轉(zhuǎn)發(fā)端口。如果你發(fā)現(xiàn)控制臺(tái)能打印日志卻打不了斷點(diǎn)大概率是這一步?jīng)]做對(duì)。第二調(diào)試協(xié)議版本不兼容。Hermes 的不同版本對(duì)調(diào)試協(xié)議的支持細(xì)節(jié)有差異如果調(diào)試器版本和引擎版本差距太大就會(huì)出現(xiàn)“連接成功但沒反應(yīng)”的情況。建議統(tǒng)一升級(jí)到較新的穩(wěn)定版本并保證調(diào)試工具也更新到對(duì)應(yīng)版本。第三release 模式下默認(rèn)不開放調(diào)試。這是最容易踩的坑很多人帶著 release 包去連調(diào)試器發(fā)現(xiàn)根本連不上。這其實(shí)是正?，F(xiàn)象因?yàn)?release 模式走的字節(jié)碼路徑做了大量優(yōu)化不會(huì)像 debug 模式那樣保留完整調(diào)試符號(hào)。你要調(diào)試就切到開發(fā)模式你要驗(yàn)證性能就用 release 模式。兩者不要混著來。真機(jī)調(diào)試還涉及網(wǎng)絡(luò)權(quán)限和端口規(guī)則我的一般順序是先跑模擬器確認(rèn)調(diào)試鏈路通再切真機(jī)最后加業(yè)務(wù)代碼。這樣能快速隔離是環(huán)境問題還是代碼問題。3.2 用性能剖析定位卡頓而不是瞎猜在 Hermes 上做性能調(diào)優(yōu)最忌諱“感覺慢就亂改”。我見過有人把列表組件從函數(shù)組件改成類組件、給事件處理函數(shù)加一堆 memo折騰一宿根本沒解決。正確做法是用采樣剖析器抓數(shù)據(jù)讓調(diào)用棧說話。Hermes 的采樣剖析器會(huì)在運(yùn)行時(shí)定期記錄當(dāng)前調(diào)用棧導(dǎo)出后可以通過可視化工具查看每個(gè)函數(shù)的耗時(shí)占比。我會(huì)重點(diǎn)看三個(gè)指標(biāo)總耗時(shí)高的函數(shù)、自身耗時(shí)Self Time高的函數(shù)、GC 相關(guān)的時(shí)間占比。其中 Self Time 高尤其重要它代表這個(gè)函數(shù)自己執(zhí)行時(shí)消耗的時(shí)間不包含子函數(shù)最能體現(xiàn)熱點(diǎn)。舉個(gè)例子我之前的頁面首屏渲染慢一直以為是網(wǎng)絡(luò)請(qǐng)求導(dǎo)致的。后來用剖析器一看發(fā)現(xiàn)請(qǐng)求返回后有一段對(duì)數(shù)組做深拷貝的邏輯在 Hermes 里被反復(fù)執(zhí)行了幾百次。問題根本不在網(wǎng)絡(luò)層而在這段拷貝代碼。把代碼改成惰性處理之后首屏?xí)r間直接降了 40%。這種結(jié)論靠感覺永遠(yuǎn)得不出。內(nèi)存方面也一樣Hermes 支持堆快照分析。當(dāng)你懷疑某個(gè)界面有內(nèi)存泄漏時(shí)先做一個(gè)操作前快照再做一個(gè)操作后快照對(duì)比對(duì)象數(shù)量和保留大小。重點(diǎn)關(guān)注那些“應(yīng)該被回收但還在增長”的對(duì)象。很多時(shí)候泄漏點(diǎn)不止一個(gè)要反復(fù)對(duì)比幾次才能定位干凈。問題類型推薦工具關(guān)注指標(biāo)啟動(dòng)慢采樣剖析器函數(shù)總耗時(shí)、字節(jié)碼加載耗時(shí)渲染卡頓采樣剖析器 幀率監(jiān)控Self Time 高的函數(shù)、GC 時(shí)間內(nèi)存泄漏堆快照對(duì)比對(duì)象數(shù)量增長、保留大小網(wǎng)絡(luò)等待抓包 業(yè)務(wù)日志請(qǐng)求耗時(shí)、線程等待時(shí)間3.3 實(shí)測(cè)技巧給 GC 壓力做“減法”Hermes 的性能問題很大一部分根源在 GC。每次垃圾回收都會(huì)造成暫停暫停期間界面可能掉幀。所以與其在業(yè)務(wù)邏輯里做微優(yōu)化不如從源頭上減輕 GC 壓力。我總結(jié)了三個(gè)最有效的“減法”。第一減少循環(huán)體內(nèi)的臨時(shí)對(duì)象創(chuàng)建。不要在高頻循環(huán)里拼接字符串或創(chuàng)建對(duì)象字面量盡量把它們提到循環(huán)外復(fù)用。第二避免過深的閉包鏈。閉包很容易讓對(duì)象存活時(shí)間延長導(dǎo)致老年代壓力變大。能用普通函數(shù)表達(dá)的邏輯就別用閉包包一層。第三謹(jǐn)慎使用大數(shù)據(jù)結(jié)構(gòu)。比如一個(gè)非常大的數(shù)組如果只是讀取可以設(shè)計(jì)成更緊湊的結(jié)構(gòu)不要在渲染期間頻繁生成副本。這些技巧看起來簡單但實(shí)際執(zhí)行時(shí)需要結(jié)合 Hermes 的工具一起看。我每做完一個(gè)優(yōu)化都會(huì)重新跑一次剖析器確認(rèn) GC 時(shí)間占比下降而不是只看幀率是否變好。幀率是一個(gè)綜合結(jié)果GC 時(shí)間才是更底層的指標(biāo)。4. 先學(xué)第四件事記住 Hermes 的兼容性邊界少填坑4.1 哪些 JS 特性在 Hermes 里不可用Hermes 不是完整兼容所有 ECMAScript 規(guī)范的引擎這一點(diǎn)必須在入門時(shí)就記住。很多人把瀏覽器里的代碼直接搬過來上線后報(bào)錯(cuò)才回頭查兼容性非常浪費(fèi)時(shí)間。我踩過比較典型的有三類。第一類是Proxy和部分ReflectAPI。Harmes 出于性能和實(shí)現(xiàn)復(fù)雜度考慮沒有提供完整的Proxy支持依賴Proxy的響應(yīng)式庫或觀察者模式就要尋找替代方案。第二類是Intl默認(rèn)構(gòu)建不包含完整的國際化能力需要啟用專門的 Intl 變體或引入相應(yīng)的降級(jí)方案。第三類是某些較新的正則特性例如后行斷言等在部分版本上表現(xiàn)不一致。如果你要寫復(fù)雜正則建議先在目標(biāo)環(huán)境里做一次快速驗(yàn)證。這些差異并不代表 Hermes 很弱它只是做了取舍。入門階段你應(yīng)該建立一張“本環(huán)境特性檢查表”把項(xiàng)目里可能涉及的新特性和第三方依賴列出來跑一遍真機(jī)測(cè)試。我把這個(gè)過程寫成了一個(gè)小腳本每次升級(jí) Hermes 版本就跑一遍能提前發(fā)現(xiàn)回歸項(xiàng)。特性在 Hermes 中的狀態(tài)替代方案Proxy不可用改用事件訂閱或普通對(duì)象配合 setterReflect部分方法不可用對(duì)不可用方法做能力檢測(cè)后降級(jí)Intl默認(rèn)不啟用啟用 Intl 變體或引入輕量 polyfill高級(jí)正則斷言可能不支持改寫正則或用字符串函數(shù)替代4.2 寫好兼容層一套代碼多引擎運(yùn)行很多項(xiàng)目不會(huì)只用 Hermes可能還需要在別的引擎上運(yùn)行所以代碼要寫成“盡量不依賴引擎私有行為”的樣子。這里最核心的一條原則永遠(yuǎn)不要直接調(diào)用內(nèi)部全局對(duì)象除非你明確知道自己在做什么。Hermes 運(yùn)行時(shí)會(huì)暴露一些內(nèi)部對(duì)象比如HermesInternal它可以拿來輔助檢測(cè)運(yùn)行時(shí)信息但業(yè)務(wù)代碼依賴它就會(huì)出問題。我建議所有能力檢測(cè)都走標(biāo)準(zhǔn)方式必要的時(shí)候再做一次降級(jí)。例如判斷Proxy是否可用就用typeof Proxy ! undefined而不是去查引擎名。寫兼容層還有一個(gè)常用技巧把差異封裝成一個(gè)小模塊。不管是格式化、日期處理還是國際化都先走統(tǒng)一的接口內(nèi)部再根據(jù)環(huán)境選擇不同實(shí)現(xiàn)。這樣即使未來某天換了引擎業(yè)務(wù)代碼不需要大改。下面是一個(gè)簡化示例const hasProxy typeof Proxy ! undefined; function createReactiveObject(target) { if (hasProxy) { return new Proxy(target, { set(obj, key, value) { obj[key] value; // 觸發(fā)更新 return true; }, }); } // 降級(jí)實(shí)現(xiàn)用自定義事件模擬 const listeners []; const wrapped Object.assign({}, target); // ... 簡化邏輯 return wrapped; }這段代碼的核心思想不是“區(qū)分引擎”而是“區(qū)分能力”。能力檢測(cè)比引擎檢測(cè)更穩(wěn)定因?yàn)橐姘姹靖驴赡芨淖兡芰α斜淼芰κ欠翊嬖谑窍鄬?duì)客觀的事實(shí)。4.3 兼容性檢查清單分享一份我現(xiàn)在每次集成 Hermes 前都會(huì)跑的檢查清單雖然簡單但能省下大量線上排查時(shí)間。先檢查第三方依賴。把項(xiàng)目里所有用到了較新 JS 特性的庫列出來逐一確認(rèn)它們是否支持 Hermes 環(huán)境尤其注意狀態(tài)管理、響應(yīng)式、日期處理這類庫。再檢查圖形和動(dòng)畫相關(guān)代碼這些地方很容易用到高級(jí)正則和復(fù)雜對(duì)象操作。最后檢查自己的業(yè)務(wù)代碼凡是用了 Proxy、Reflect、Intl、較新數(shù)組方法的地方都要在真機(jī) release 模式下跑一遍。還有一個(gè)容易忽視的細(xì)節(jié)真機(jī)上的結(jié)果才是最終結(jié)果。模擬器的引擎版本、系統(tǒng) API 和真機(jī)不一定完全一致所以所有兼容性驗(yàn)證都要基于 release 包在真機(jī)上執(zhí)行。我現(xiàn)在每次發(fā)版前都會(huì)在至少一臺(tái)低端機(jī)和一臺(tái)中端機(jī)做回歸測(cè)試不只在最高配置設(shè)備上跑。如果你正在入門 Hermes我建議按上面這 4 個(gè)順序來不要看到底層文章就一頭扎進(jìn)去。先用一個(gè)星期把定位和配置搞透再用兩周時(shí)間反復(fù)做調(diào)試和剖析慢慢你會(huì)發(fā)現(xiàn)自己能看懂很多性能報(bào)告了。最后再補(bǔ)一句每次 Hermes 版本升級(jí)我都會(huì)把變更日志里標(biāo)注的破壞性改動(dòng)先手動(dòng)測(cè)一遍這個(gè)習(xí)慣幫我省了好幾次線上事故。希望這些經(jīng)驗(yàn)對(duì)你有用。