如何治理 Electron 版本淘寶直播應用崩潰？
編者按：本文作者是前端工程師科來，來自大淘寶技術淘寶直播前端團隊，介紹了 Electron 版本淘寶直播應用崩潰的處理流程，歡迎查閱～
經過幾個月的努力，基于 Electron 框架開發(fā)的新版淘寶直播推流軟件終于上線了。隨之而來的就是線上用戶反饋的各種問題，其中最影響用戶體驗的當屬應用崩潰問題了。當應用程序出現未 catch 的異常時就會發(fā)生崩潰，本文介紹了客戶端應用崩潰的處理流程。
01 背景
主播前期花了很長時間精心策劃了一場直播，在淘寶直播推流軟件開播。當開播時間到來時，倒計時 3、2、1 后開始直播，一切都非常順利。
但沒想到剛直播了一會，突然彈出一個 “系統(tǒng)崩潰提醒” 彈框，提示應用崩潰了：
主播立馬按照提示輸入釘釘號提交崩潰信息，并且加入釘釘群反饋應用崩潰問題。作為技術小二的我發(fā)現顯示一切正常，怎么在主播端運行就遇到崩潰問題了，一定是使用方法不對。
但首要關頭得趕緊解決問題，并且以后要保證應用的穩(wěn)定性。作為前端工程師的我嘗試開始學習如何分析和解決應用崩潰問題。
在此之前，讓我們先來了解下前端處理 js error 異常的整體流程：首先 js error 異常是如何產生的，其次要如何捕獲上報 js error 異常，接著如何監(jiān)控并分析 js error 異常堆棧，最后是如何運用 sourcemap 來定位到具體是哪個函數的哪一行代碼引起的 error，以此來解決該異常問題。
了解完前端處理異常的流程后，我們接下來開始了解客戶端應用程序處理崩潰異常的流程，下文均以 Windows 平臺講述內容。
02 應用崩潰是如何產生的
我們先來看下 Windows 系統(tǒng)的整體架構圖，主要分為內核模式和用戶模式。像常見的內核程序、設備驅動程序等運行在內核模式，而像系統(tǒng)服務進程、用戶應用程序如淘寶直播主播工作臺等運行在用戶模式。
淘寶直播主播工作臺地址：https://market.m.taobao.com/app/mtb/live-portal/download/index.html
當 Windows 系統(tǒng)或應用程序調用 CreateProcess 函數啟動主線程或 CreateThread 啟動線程時，線程函數會在如下代碼中運行（下面的代碼引自《Windows 核心編程》第 25 章未處理異常和 C++ 異常）：
從上面的代碼可以看出，當線程運行中出現未捕獲異常時，會調用 UnHandledExceptionFilter 函數來過濾異常信息，然后調用 ExitProcess 函數退出進程的運行。也就是說，當線程中出現未 catch 的異常（類比前端 js error 未 catch）時，比如主播在使用綠幕大屏添加超大尺寸圖片時應用程序 memcpy 失敗但未 catch 異常導致崩潰、系統(tǒng)內核異常導致藍屏現象，系統(tǒng) / 程序就會崩潰并生成 dump 文件來幫忙尋找異常原因。
那 dump 文件究竟是什么呢？Windows 平臺 dump 文件分為兩大類：內核模式 dump 和用戶模式 dump。內核模式 dump 是操作系統(tǒng)創(chuàng)建的崩潰轉儲，最經典的就是系統(tǒng)藍屏時會自動創(chuàng)建內核模式的 dump。用戶模式 dump 進一步可以分為 fulldump 和minidump。fulldump 包含了某個進程完整的地址空間數據，以及許多用于調試的堆棧、寄存器等信息。毫無疑問，這樣的 fulldump 對于事后調試非常有價值，但由于文件太大（幾G字節(jié)）使得通過請求發(fā)送給開發(fā)者非常困難。而 minidump 則有許多類型，按照最常用的配置只包括了最必要的信息，用于恢復故障進程的所有線程的調用堆棧，以及查看故障時刻局部變量的值。這樣的 minidump 文件通常很小（只有幾K ~ 幾M字節(jié)），通過請求發(fā)送給開發(fā)者非常容易。
事實證明，minidump 已成為各個平臺的客戶端崩潰的常用轉儲文件（類比 js stack trace）。下面的代碼就是定義了 pExceptionFilter 函數，當捕獲到應用崩潰時調用該函數生成 minidump 文件。
03 如何捕獲上報應用崩潰
通過上文我們了解到，當應用程序出現未 catch 的異常時就會發(fā)生崩潰。那我們要如何捕獲到應用程序的崩潰呢？
在客戶端中捕獲應用崩潰
經過調研發(fā)現，Google 已經開發(fā)了一個名為 Breakpad 的庫及其繼任者 Crashpad，它能夠在各種操作系統(tǒng)和 CPU 架構上生成 minidump 文件。由于 Electron 使用 Crashpad 而不是 Breakpad 來捕獲和上傳崩潰信息，因此我們重點介紹下 Crashpad 原理。
Breakpad地址：https://chromium.googlesource.com/breakpad/breakpad/ Crashpad地址：https://chromium.googlesource.com/crashpad/crashpad/
Crashpad 是一個用于從客戶端應用程序捕獲、存儲和上傳崩潰信息到服務器的庫，旨在使客戶端能夠以盡可能高的保真度和覆蓋范圍，以最小成本捕獲崩潰時的進程狀態(tài)。
Crashpad 還為客戶端提供了最小的工具，以使用每個進程鍵 / 值對形式來封裝他們的崩潰，而且客戶端還能夠通過擴展點進一步擴充崩潰報告。下圖是 Crashpad 整體設計圖：
在 Windows 平臺，操作系統(tǒng)在崩潰線程的上下文中調度異常。為了通知異常處理程序，Crashpad 客戶端在客戶端進程中注冊一個 UnhandledExceptionFilter (UEF)。當異常傳遞到 UEF 時，它將異常信息和崩潰線程的 ID 存儲在向處理程序注冊的 ExceptionInformation 結構中。然后它設置一個事件句柄來通知處理程序繼續(xù)處理異常。當發(fā)生崩潰時，Crashpad最終會調用 generate_dump 來生成一個包含正在運行的進程快照的 minidump 文件。
在 Electron 中捕獲應用崩潰
幸運的是，Electron 框架已經集成了它，當主進程 / 渲染進程崩潰時，內置的崩潰報告器會自動創(chuàng)建 minidump 文件。作為開發(fā)者使用起來也很簡單，只需要幾行 JavaScript 代碼就可以使用它來捕獲崩潰并把 minidump 文件上傳到遠程服務器中（類比 js error catch 上報），為下一步監(jiān)控和分析治理崩潰問題做準備。
到現在為止，我們只是寫了上面幾行代碼，只知道可以用來捕獲和上傳崩潰文件到服務器上。但崩潰文件到底是長啥樣的呢？讓我們來一探究竟。
由于 Electron crashReporter 底層是通過 http/https post 來上傳崩潰日志的請求，于是我們可以通過 wireshark 抓包工具抓到 Electron 捕獲崩潰并上傳至服務器的請求，這就是 dump 文件的二進制內容。
wireshark地址：https://www.wireshark.org/download.html
揭開廬山真面目之后，我們還是不認識這堆二進制內容。但至少邁進了一步，我們已經感知到它的存在了。接下來就先把它統(tǒng)一監(jiān)控起來吧。
??04 如何監(jiān)控應用崩潰
那要怎么把線上用戶崩潰問題都監(jiān)控起來呢？目前提供了兩個選擇：分別是為螞蟻前端開發(fā)者打造的實時監(jiān)控告警雨燕平臺（背后使用的是支付寶小程序 IDE 最佳實踐方案）、阿里集團為開發(fā)者提供桌面客戶端標準化解決方案（包括崩潰管理）的千鳥平臺（類比 arms / JsTracker 監(jiān)控平臺）。
支付寶小程序 IDE 最佳實踐
支付寶小程序 IDE 最佳實踐方案的整體捕獲上報流程圖如下：
該方案使用 Electron 自帶的 crashReporter 機制來捕獲應用程序崩潰，然后利用阿里云 FC 來解析 dump 文件，最終將崩潰結果上報到雨燕平臺進行監(jiān)控。
在這個過程中，該方案基于大量的字段約定來實現信息收集：
本次崩潰明細 -> 雨燕監(jiān)控的每一條記錄可查看明細，如版本、平臺等。
崩潰堆棧 -> 從明細中可以進入查看堆棧頁面，或者在監(jiān)控首頁點擊某條記錄的分析。
用戶環(huán)境信息、程序啟動參數信息，上報的原始 payload，minidump 解析報告、文件等 -> 可在 HI 文件管理中在線查看，上報到 HI 的文件名有當前用戶 ID，用戶自定義 ID 等，可以通過搜索來定位到具體文件。
作為開發(fā)者來說，接入成本也很低，只需要寫下面幾行 JavaScript 代碼并在主進程中 start 一次即可。
千鳥平臺
千鳥平臺也是基于 Electron 的 crashReporter 模塊進行了一個封裝，內置了千鳥的崩潰上傳邏輯。作為開發(fā)者來說，接入成本也很低，也只需要寫下面幾行 JavaScript 代碼并在主進程中 start 一次即可。
05 如何分析應用崩潰
幸好有雨燕、千鳥平臺，我們可以很方便地把應用崩潰問題監(jiān)控起來，接下來就要開始分析這些崩潰日志了。這里介紹兩種分析 dump 崩潰文件的方案：雨燕平臺在線分析崩潰和 Visual Studio / WinDbg Preview 本地分析崩潰。
雨燕平臺在線分析崩潰
雨燕平臺在線分析崩潰功能是基于開源項目 electron-minidump 實現解析 minidump 文件，獲取崩潰異常錯誤的堆棧信息。如下圖所示，我們可以清晰地看到崩潰堆棧，但只能獲取到哪個模塊崩潰，不清楚具體是哪一行代碼導致的崩潰，無法進一步排查崩潰原因。
electron-minidump地址：https://github.com/nornagon/electron-minidump
由于雨燕平臺在線分析崩潰存在局限性，因此我們需要把 dump 文件下載到本地，繼續(xù)用 Visual Studio / WinDbg Preview 等工具進一步分析是哪一行代碼導致的崩潰。
Visual Studio / WinDbg Preview 本地分析崩潰
在我們使用 Visual Studio / WinDbg Preview 等工具本地分析崩潰文件之前，我們有必要簡要了解下符號是什么。符號是調試和其他診斷工具的基本要求，對于 Microsoft 編譯器，這些是作為構建的一部分生成的 .pdb 文件。符號 (.pdb) 文件默認情況下包含以下信息（類比 js SourceMap 文件）：
公共符號 (所有函數、靜態(tài)變量和全局變量)
負責可執(zhí)行文件中代碼部分的對象文件列表
FPO 幀指針優(yōu)化信息
局部變量和數據結構的名稱和類型信息
源文件和行號信息
符號地址：https://learn.microsoft.com/zh-cn/windows/win32/dxtecharts/debugging-with-symbols?redirectedfrom=MSDN
那為什么我們需要符號呢？如果沒有 PDB 文件，調試器無法解析函數名稱、參數或任何存儲在堆棧上的局部變量，無法將應用程序中執(zhí)行的指令與原始源代碼相關聯。符號對于調試非常重要，根據我們正在調試的內容，可能需要符號來顯示完整的調用堆棧，并使用 Watch 窗口或 DataTips 來檢查對象。如果我們正在調試不包含堆的轉儲文件，調試器將需要訪問原始二進制文件，以便確定要加載的正確符號文件。換句話說，如果我們正在調試沒有堆信息的轉儲，則需要符號路徑上的相應二進制文件和符號文件。
對于調試非常重要：https://learn.microsoft.com/zh-cn/previous-versions/visualstudio/visual-studio-2015/debugger/specify-symbol-dot-pdb-and-source-files-in-the-visual-studio-debugger?view=vs-2015&redirectedfrom=MSDN
對應 Electron 開發(fā)的應用程序來說，一般只需要以下三種 PDB 符號文件：
Microsoft PDB 符號服務器：https://msdl.microsoft.com/download/symbols
Electron PDB 符號服務器：https://symbols.electronjs.org
應用程序 PDB 符號（本地 PDB 文件路徑）
了解完符號文件后，我們就可以開始用 Visual Studio / WinDbg Preview 等工具分析調試本地崩潰文件了。
Visual Studio 本地分析崩潰
首先安裝 Visual Studio 后打開 dump 文件，Visual Studio 將在屏幕上方區(qū)域顯示有關崩潰的一般信息，并在下方顯示已加載模塊的列表，包括應用程序名稱及其版本。
Visual Studio地址：https://code.visualstudio.com/docs/?dv=win
接著點擊 “使用僅限本機進行調試” 按鈕，Visual Studio 將盡最大努力調試 dump 文件，但沒有顯示任何有用的調用堆棧信息。
為了獲取調用堆棧信息，我們將告訴 Visual Studio 在哪里可以找到二進制文件。首先，打開調試菜單并選擇選項。然后單擊符號，把 Microsoft PDB 符號服務器、Electron PDB 符號服務器、應用程序 PDB 符號（本地 PDB 文件路徑）都填進去。
現在 Visual Studio 將顯示所有可用模塊的列表，并能夠清晰地看到調用堆棧信息，以及具體是哪一行代碼導致崩潰。
若要繼續(xù)調試崩潰代碼以及查看調用函數變量等信息，還需要配置源代碼路徑。在 Visual Studio 中打開解決方案資源管理器，然后點擊屬性->調試源文件，填入源代碼目錄。這樣就可以在崩潰那一行代碼斷點下來查看變量值或者斷點調試都行，崩潰問題排查起來就很容易了。
至此已介紹完如何使用 Visual Studio 工具分析崩潰文件的流程。
WinDbg Preview 本地分析崩潰
接下來再分享一個更輕量化的分析崩潰工具 WinDbg Preview。該工具可用于調試 Windows 內核模式和用戶模式代碼、分析故障 dump 文件以及在代碼執(zhí)行時檢查 CPU 寄存器。
首先安裝 WinDbg Preview 后打開 dump 文件，WinDbg Preview 將在屏幕上方區(qū)域顯示有關崩潰的一般信息。
WinDbg Preview地址：https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-tools
為了獲取調用堆棧信息，我們將告訴 WinDbg Preview 在哪里可以找到二進制文件。打開 Settings 設置菜單并選擇調試設置選項。然后把 Microsoft PDB 符號服務器、Electron PDB 符號服務器、應用程序 PDB 符號（本地 PDB 文件路徑）都填進去。
現在運行下 !analyze -v 命令，WinDbg Preview 將顯示所有可用模塊的列表，并能夠清晰地看到調用堆棧信息，以及具體是哪一行代碼導致崩潰。
若要繼續(xù)調試崩潰代碼以及查看調用函數變量等信息，還需要配置源代碼路徑。打開 Settings 設置菜單并選擇調試設置選項。然后填入源代碼目錄。這樣就可以在崩潰那一行代碼斷點下來查看變量值或者斷點調試都行，崩潰問題排查起來就很容易了。
至此已介紹完如何使用 WinDbg Preview 工具分析崩潰文件的流程。
06 總結和展望
總結
客戶端崩潰處理流程
首先從一個 “為什么應用就崩潰了” 的問題出發(fā)，追溯應用崩潰到底是如何產生的。
然后講述了如何使用集成了 Crashpad 的 Electron crashReporter 捕獲應用崩潰，并上報到雨燕、千鳥平臺來監(jiān)控應用崩潰的。
最后通過對雨燕平臺在線分析崩潰及 Visual Studio / WinDbg Preview 本地分析崩潰工具的認識，讓我們深刻知道 “工欲善其事，必先利其器”，以此來解決線上應用崩潰。
前端 js error 處理流程
如果是前端工程師第一次接觸客戶端應用程序崩潰處理流程可能會有點困難，為了降低理解成本，我們可以類比下客戶端應用程序處理崩潰和前端處理 js error 的流程。
首先客戶端 dump 產生類比 js error 異常。
然后 dump 捕獲上報類比 js error catch 上報。
接著雨燕 / 千鳥監(jiān)控平臺類比 arms / JsTracker 監(jiān)控平臺。
最后 dump 文件類比 js stack trace，pdb 調試符號文件類比 js SourceMap 文件。
對于前端工程師來說，我們也要了解 js error 異常是如何產生的，如何進行捕獲上報并實現監(jiān)控，如何分析 js 堆棧及運用 sourcemap 來定位到具體是哪個函數的哪一行代碼引起的 error，以此來解決該異常問題。
了解完前端處理 js error 的整體流程后，有沒有覺得跟前面介紹的客戶端應用處理崩潰流程基本一致呢？其實各個端上處理異常（不僅限于處理異常）的流程都是相通的，學會遷移學習才能夠快速掌握其他領域的知識，是不是突然覺得跨端門檻也沒有想象中那么高了呢？
展望
即使我們使勁渾身解數通過各種工具分析治理應用崩潰問題、及時升級 Electron 版本等，只要應用程序運行的那一刻開始，崩潰問題就永遠無法避免。
因此，我們還需要實現一個獨立于 Electron 主進程的守護進程。在 ?Electron 應用程序啟動時該守護進程就可以隨之啟動，然后它來守護 Electron 進程。如果 Electron 進程崩潰時，就由它來啟動 Electron 進程，讓應用程序繼續(xù)運行起來。
07 團隊介紹
我們是大淘寶技術淘寶直播前端團隊，負責淘系增長最快的直播業(yè)務，業(yè)務上升空間非常大。在技術方面，我們在探索直播間互動、游戲互動、數據可視化、音視頻播放器、微前端、智能搭建、Web 3D、Electron 跨端開發(fā)、桌面推流客戶端開發(fā)、跨 PC/H5/Native 的多端架構等。
