項目升級到 React Native 0.70 那天我以為換到 Hermes 就是改一行開關的事。結(jié)果兩輪真機跑下來啟動時間確實好看了但團隊的接入姿勢五花八門有人開著遠程 JS 調(diào)試上線有人 iOS 的 Podfile 忘開 Hermes還有人在問題排查時對著十六進制調(diào)用棧發(fā)呆。后來我把這些散落的經(jīng)驗收斂成了一個工程化項目名字就叫oh-my-hermes核心目標不是做一個“Hermes 插件市場”而是把 Hermes 的接入、驗證、調(diào)優(yōu)、排錯沉淀成一套可復用的基線。本文就把這個項目里最有價值的部分拆開講Hermes 到底強在哪oh-my-hermes由哪幾塊組成接入和驗證的完整路徑以及我在切換之后踩過的調(diào)試深坑。適合正在做 React Native 性能優(yōu)化、或準備從 JSC 切到 Hermes 的團隊參考。1. Hermes 到底解決了什么問題聊oh-my-hermes之前得先把 Hermes 這個引擎本身講透。很多團隊把它當成“RN 自帶的提速開關”其實它背后是一套完全不同的移動端 JS 引擎設計哲學。1.1 從 JSC 切換到 Hermes 的本質(zhì)變化在 React Native 早期版本里Android 和 iOS 默認用的是 JavaScriptCore簡稱 JSC。它是 WebKit 的 JS 引擎設計目標是服務于瀏覽器功能完整但有個問題它把“解析和編譯 JS 代碼”這件事放在運行時做。用戶每次冷啟動 App都要經(jīng)歷下載 JS bundle、解析源碼、編譯成字節(jié)碼、再執(zhí)行。這一步的開銷在低端 Android 機上非常明顯經(jīng)常是白屏幾秒的元兇。Hermes 的思路完全不同。它犧牲了瀏覽器場景的通用性完全為移動端裁剪在構建階段就把 JS 源碼預編譯成字節(jié)碼App 啟動時直接加載字節(jié)碼執(zhí)行省掉了解析和編譯這兩個最耗時的階段。同時Hermes 刻意不做 JITJust-In-Time 實時編譯因為移動端內(nèi)存金貴JIT 雖然能讓長駐頁面越跑越快但會顯著拉高內(nèi)存水位而絕大多數(shù)移動 App 的頁面存活周期遠沒有長到能吃滿 JIT 紅利。1.2 移動 JS 引擎的取舍邏輯不理解的人會覺得“不做 JIT 是不是性能倒退”。但如果從移動端的真實約束看這個選擇非常合理JIT 需要預熱冷啟動階段根本來不及吃滿收益。JIT 需要額外的內(nèi)存存放編譯產(chǎn)物和 profiling 數(shù)據(jù)這在桌面端無所謂在手機上就是實打?qū)嵉膲毫?。移?App 的 JS 代碼量遠小于網(wǎng)頁解釋執(zhí)行加預編譯字節(jié)碼的差距完全可以通過優(yōu)化業(yè)務代碼結(jié)構拉平。去掉 JIT 后JS 引擎的內(nèi)存行為更可預測GC 停頓更容易優(yōu)化。Hermes 的 GC 也專門做了確定性優(yōu)化。JSC 在部分場景下會出現(xiàn)明顯的 GC 長停頓Hermes 的垃圾回收策略讓停頓時間更短、更均勻。反應到用戶側(cè)就是滑動列表時的掉幀少了頁面切換更跟手。1.3 為什么需要一整套工程基線按道理講RN 0.70 之后 Hermes 是默認引擎接入成本應該很低。但我在實際項目里發(fā)現(xiàn)真正麻煩的不是打開開關而是三個隱性成本第一RN 版本升級后的構建鏈路變化老的第三方庫、自定義原生模塊是否兼容需要系統(tǒng)性回歸。第二調(diào)試方式變了原來習慣的 Chrome DevTools 方案在 Hermes 下不能直接用團隊的排查思維要整體切換。第三性能收益不是“打開就有”需要一套統(tǒng)一的度量方式否則每個人拿到的數(shù)據(jù)口徑都不一樣沒法橫向?qū)Ρ?。oh-my-hermes就是奔著這三個隱性成本去的。2. oh-my-hermes 的核心組成配置、校驗、度量、文檔項目名字致敬oh-my-zsh但我很清楚zsh 插件市場那一套并不適合 RN 引擎管理。所以oh-my-hermes沒有做成“一堆腳本隨便塞”而是四個職責清晰的部分配置基線、構建校驗、性能度量、知識文檔。2.1 配置基線把雙端配置收斂成一份清單Hermes 的配置散落在多個地方android/app/build.gradle、ios/Podfile、metro.config.js。很多團隊升級 RN 后只改了 Android 的開關iOS 漏了或者 Metro 配置里沒有正確關閉源碼 bundle 的 source map 內(nèi)聯(lián)導致體積膨脹。oh-my-hermes的配置基線做了一件事把雙端配置整理成交互式 CLI執(zhí)行oh-my-hermes init時自動檢查并生成一份推薦配置。它不覆蓋你已有的自定義項只負責校正和 Hermes 相關的部分。以 Android 為例推薦配置里有幾個關鍵點// android/app/build.gradle react { enableHermes true }檢查enableHermes只是第一步。項目還會檢查 release 構建時是否啟用了字節(jié)碼預編譯開關以及 ProGuard 規(guī)則里對 Hermes 相關類的 keep 規(guī)則是否正確。這些細節(jié)沒配好真機 release 包很可能跑不起來。2.2 構建校驗防止“配置了但沒生效”的坑這是整個項目里我認為最值錢的部分。我們團隊就出過這么一檔子事一位同事在build.gradle里開了 Hermes但 Gradle 增量構建命中緩存最后線上包用的還是舊引擎。單獨看代碼配置完全正確問題是構建產(chǎn)物是舊的。oh-my-hermes的構建校驗腳本干三件事檢查 Android release 產(chǎn)物中l(wèi)ibhermes.so是否存在確認原生庫真的打進去了。檢查 bundle 產(chǎn)物文件頭是否符合 Hermes 字節(jié)碼格式確認 JS bundle 不是原始源碼格式。檢查 iOS 的Podfile.lock中是否包含hermes-engine依賴以及上報的二進制體積是否符合預期。這些校驗全部放進 CI只要產(chǎn)物不對構建直接紅。從此再也沒出現(xiàn)過“本地跑得好好的線上變成舊引擎”的烏龍。2.3 性能度量統(tǒng)一口徑是優(yōu)化的前提“啟動變快了”這種體感不能當優(yōu)化證據(jù)。oh-my-hermes內(nèi)置了一套度量腳本用統(tǒng)一口徑采集冷啟動時間、JS bundle 加載耗時、內(nèi)存高水位三個指標。采集方式用業(yè)內(nèi)常用的方案同一臺中低端測試機系統(tǒng)緩存清空后冷啟動連續(xù)采集多輪取中位數(shù)。腳本會輸出 Markdown 表格方便直接貼進項目周報。下面是我們一個中低端 Android 機型上的實測結(jié)果僅供參考不同機型差異很大指標JSC 基線Hermes變化冷啟動 JS 執(zhí)行耗時中位數(shù)830ms610ms下降約 26%首幀可交互時間中位數(shù)1.8s1.4s下降約 22%內(nèi)存高水位512MB448MB下降約 12%數(shù)據(jù)不代表通用結(jié)論但趨勢非常一致Hermes 在啟動階段和內(nèi)存占用上的優(yōu)勢是肉眼可見的。3. 接入全過程從零到能在產(chǎn)物里確認 Hermes 生效下面這部分是實操路徑。假設你手上是一個從老版本升級上來的 React Native 項目目標是把 Hermes 完整跑起來并且確認它真的生效了。3.1 Android 側(cè)接入Android 側(cè)的接入核心就一件事確認enableHermes為 true并且 release 構建走了字節(jié)碼預編譯。在 RN 0.70 之后的模板里android/app/build.gradle的react配置塊默認已經(jīng)是react { enableHermes true }如果你是老項目升級需要手動加這一行。加完之后執(zhí)行一次完整的 release 構建cd android ./gradlew clean assembleRelease為什么要 clean因為不清緩存可能命中舊的增量構建配置改動沒生效。上面提到的那個“配置了但沒生效”的坑就是這里來的。構建完成后解包 APKunzip app-release.apk -d apk_check重點驗證兩處lib/abi/libhermes.so文件存在。assets/index.android.bundle文件頭不是普通的var或 JSON 格式而是 Hermes 字節(jié)碼的固定魔數(shù)頭。只看第一處不夠。libhermes.so存在只代表原生庫打進去了不代表 JS bundle 走了字節(jié)碼模式。第二處才是引擎真正生效的證據(jù)。3.2 iOS 側(cè)接入iOS 的接入在 RN 0.70 之后的模板里同樣默認開啟入口在ios/Podfileuse_react_native!( path: config[:reactNativePath], hermes_enabled: true )老項目升級時重點檢查 Podfile 里的hermes_enabled參數(shù)是不是被顯式改成 false 過。我們踩過一版由上游腳手架生成的 Podfile里面默認寫了個:hermes_enabled false升級后沒注意iOS 端一直跑在 JSC 上而 Android 端已經(jīng)切到 Hermes雙端行為不一致排查起來非常痛苦。改完之后重新安裝依賴cd ios bundle exec pod installPodfile.lock 里出現(xiàn)hermes-engine相關條目說明依賴已經(jīng)拉下來了。3.3 運行時的二次確認構建層確認完還要在運行時二次確認。最直接的辦法是在代碼里檢查引擎標識const isHermes () !!global.HermesInternal;開發(fā)階段可以在啟動日志里打一行if (isHermes()) { console.log(當前運行引擎: Hermes); } else { console.log(當前運行引擎: JSC); }global.HermesInternal只有 Hermes 引擎才會注入這是判斷引擎類型最可靠的運行時 API。用typeof HermesInternal ! undefined判斷也可以但要小心某些環(huán)境里變量被 polyfill 的情況。3.4 老項目的兼容性風險排查接入過程中最容易翻車的是老代碼里的兼容性假設。Hermes 對 ES 規(guī)范的支持已經(jīng)非常接近現(xiàn)代瀏覽器但仍有一些和老項目代碼沖突的地方如果你的代碼里用了非標準的JSC專屬 API比如某些原生模塊直接依賴 JavaScriptCore 的私有接口Hermes 下會直接失效。老項目里的 Polyfill 代碼如果是為了給 JSC 補能力而寫的在 Hermes 下可能反而會覆蓋掉 Hermes 原生提供的能力。引用的第三方原生庫如果有針對 JSC 的編譯選項需要確認是否提供 Hermes 版本。建議的做法是先小規(guī)?；叶日乙慌_測試機裝一個切了 Hermes 的 release 包跑一遍核心鏈路。如果功能回歸通過再全量放開。4. 三個真正能吃到的性能紅利配置跑通之后性能優(yōu)化才是重點。Hermes 和 JSC 的宏觀區(qū)別前面講過這里拆成三個可以在工程上實際感知到的紅利點。4.1 字節(jié)碼預編譯去掉啟動時的解析成本瀏覽器場景里HTML 加載后要等 JS 引擎現(xiàn)場解析源碼。React Native 的 JSC 模式也一樣啟動時要現(xiàn)場讀源碼做詞法分析、語法分析、字節(jié)碼生成。這套流程在 PC 上感受不明顯在手機上就是幾百毫秒的事。Hermes 在構建時用hermesc提前把 JavaScript 源碼編譯成字節(jié)碼App 里加載的是二進制字節(jié)碼省掉了最耗時的編譯階段。這也是為什么 Hermes 模式下首幀可交互時間會明顯提前。工程上要注意的是字節(jié)碼模式下的 bundle 對 source map 有強依賴。沒有 source map線上報錯就是純十六進制偏移你會連哪一行代碼出問題都看不出來。oh-my-hermes的配置基線里強制要求發(fā)布包必須保留 source map 并歸檔到獨立的存儲不能只存在于構建機本地。4.2 確定性 GC讓卡頓變得可預測JSC 的 GC 是非確定性的什么時候觸發(fā)、停頓多久對開發(fā)者來說是個黑盒。Hermes 的 GC 針對移動端做了大量優(yōu)化停頓更短頻率更穩(wěn)定。這一點在長列表場景特別明顯。我們做過一個實驗同樣的無限滾動列表JSC 模式下在低端機上每滾動一段就會有一次明顯的頓挫切到 Hermes 后明顯平滑。這不代表業(yè)務代碼可以隨便寫。GC 優(yōu)化只能改善引擎層面的停頓如果業(yè)務代碼里頻繁創(chuàng)建大對象、在滾動回調(diào)里做高耗時操作該卡還是會卡。但同樣的代碼換引擎后體感確實會變好。4.3 低端機上的“雪中送炭”效應性能優(yōu)化的收益不是均勻分布的。高端機上 JSC 和 Hermes 的差距可能只有百分之幾但中低端機上因為 CPU 和內(nèi)存的瓶頸更明顯Hermes 的收益會被放大。我們的實測數(shù)據(jù)里一款驍龍 6 系處理器的設備上冷啟動時間從 2.1s 降到 1.6s體感提升非常明顯。這意味著 Hermes 對用戶大盤里占比最高的中低端設備反而是最友好的。如果你正在做性能優(yōu)化匯報建議數(shù)據(jù)分檔展示不要只報均值。高端機、中端機、低端機各截一段數(shù)據(jù)說服力會強很多。5. 換引擎之后調(diào)試這件事比想象中更容易踩坑如果說接入 Hermes 有什么讓我真正頭疼的不是配置而是調(diào)試。5.1 遠程 JS 調(diào)試的致命陷阱React Native 老開發(fā)者習慣用 Chrome DevTools 調(diào)頁面原理是開啟“Remote JS debugging”后JS 代碼在 Chrome 的 V8 引擎里運行DevTools 通過 WebSocket 和 Metro 通信。但這個模式在 Hermes 下有巨大的隱患當你打開“Remote JS debugging”時你的 JS 代碼就不跑在 Hermes 里了而是跑在 V8 里。V8 和 Hermes 對標準規(guī)范的支持程度不一樣很多“只在真機出現(xiàn)、模擬器復現(xiàn)不了”的詭異 bug根源就是調(diào)試模式和生產(chǎn)模式的引擎不一致。oh-my-hermes里有一條硬性規(guī)范禁止在 Hermes 下使用“Remote JS debugging”做行為調(diào)試。你要看 UI 就用真機跑要看日志就用 Metro 日志要斷點就用 Hermes 配套的調(diào)試器。5.2 Hermes 調(diào)試器的正確打開方式Hermes 用的是 Chrome DevTools Protocol但跑在一個獨立 inspector 服務上。RN 新版本里Metro 終端按d開出的調(diào)試菜單選 React Native DevTools 或者類似支持 Hermes inspector 的工具就能直接對 Hermes 里的 JS 代碼打斷點。和 Chrome DevTools 相比功能上略有縮水但斷點、調(diào)用棧、作用域變量這些核心能力都在。如果你在調(diào)試面板里看不到 Hermes 會話檢查兩個地方手機和電腦是否在同一局域網(wǎng)Metro 端口是否被防火墻攔截。是否誤開了“Remote JS debugging”兩個調(diào)試模式會互斥。5.3 線上報錯堆棧的還原路徑Hermes 字節(jié)碼模式下線上報錯的堆棧是類似at anonymous (address at index.android.bundle:1:1234567)這樣的格式看著就頭大。還原方法分三步第一步發(fā)布時強制歸檔 bundle 對應的 source map 文件。 第二步用hermesc自帶的工具或者社區(qū)的開源還原腳本把十六進制偏移轉(zhuǎn)回原始函數(shù)和行號。 第三步把還原后的堆棧和文件版本做綁定保證每個發(fā)布包都有對應的歸檔記錄。這個流程oh-my-hermes已經(jīng)腳本化執(zhí)行一條命令就能完成還原。沒有這層能力Hermes 線上問題基本沒法高效排查。6. 真實項目里落地時我的取舍和經(jīng)驗最后聊聊我在真實項目里的一些體會這些屬于文檔里不太會寫、但實際會決定成敗的細節(jié)。6.1 引擎切換要留“逃生通道”千萬不要“改完之后順手把開關刪掉”。RN 老版本升級到 Hermes本身不是特別絲滑的過程期間隨時可能需要切回 JSC 做對比驗證。我們的做法是保留enableHermes配置開關在 CI 里用參數(shù)控制在最終打包時決定用哪個引擎?；叶绕?AB 對比也靠這個開關實現(xiàn)。等線上穩(wěn)定運行兩三個版本再徹底移除 JSC 相關分支。6.2 度量數(shù)據(jù)一定要“同機同口徑”做性能對比最忌諱換著設備測。Android 的低端機、中端機、高端機差距極大iOS 的模擬器和真機差距巨大。我們的度量基線固定死了一臺 Android 中端機、一臺 iOS 真機只在上面測。測試前清空后臺進程系統(tǒng)緩存清理掉每項指標連續(xù)測 5 到 7 次取中位數(shù)。不打同一個設備基準橫向?qū)Ρ热珶o意義。6.3 團隊習慣的遷移比技術遷移更難技術問題總能找到解法真正的阻力來自團隊舊習慣。用慣了 Chrome DevTools 的同事切到 Hermes 調(diào)試器會本能地想找熟悉的菜單找不到就抱怨“工具不好用”。我的做法是寫一份內(nèi)部排查手冊把常見問題的排查鏈路全部固化下來啟動慢怎么定位、內(nèi)存高怎么分析、線上堆棧怎么還原、Hermes 特有的 GC 報警怎么看。這樣團隊不用每次從頭摸索。oh-my-hermes寫在最后的一部分就是這份持續(xù)更新的手冊。技術方案會演進但把經(jīng)驗沉淀成文檔的習慣才是這個項目能長期給團隊帶來價值的根本原因。如果你也在做 RN 引擎切換希望這篇文章幫你少踩幾個坑。配置開關只是開始真正的工作在驗證、度量和調(diào)試基建上。把這三件事做好了Hermes 的收益才能穩(wěn)穩(wěn)落到用戶側(cè)。