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