為了測試當機回報，我故意讓 App 當機，它卻沒當機

要測試收集器，App 必須真的當機

遊戲在手機上出問題時，我希望自己比評論更早知道。所以我做了一個蒐集錯誤的小工具，裝進大約十款遊戲。它會接收 WebView 錯誤、出錯前最後一個操作，以及整個 App 直接消失的原生當機。

難的是測試。要確認收集器抓不抓得到當機，App 就得真的當機。所以我另外加了一個故意讓 App 當機的開關。按下藏起來的按鈕，就會對 App 的處理程序送出 SIGSEGV（記憶體存取錯誤的訊號）。

誤判一：我以為送出訊號 App 就會死

我在 iPhone 11 Pro 實機上按了開關，App 沒有死。畫面原封不動，收集器也什麼都沒收到。

這時最危險的結論，是認定收集器抓不到當機。其實是開關沒能讓 App 當機，如果怪到收集器頭上，就會去修好好的程式碼，真正的漏洞反而留著。查下去，原因出在開關。WebView 早就掛好的訊號處理器，搶先攔下了那個訊號。

修法只有一行：送出訊號之前，先把 SIGSEGV 還原成預設行為。這樣 App 就當機了，下次啟動時，WebView 的異常終止紀錄和 iOS 整理好的 SIGSEGV 報告都送達了。我就在這天學到，測試工具有可能比被測試的對象更早出錯。

誤判二：我以為上架後立刻收到的錯誤是使用者的

收集器有嚴重度標準。啟動後 8 秒內發生的啟動錯誤只要有 2 場以上，就判定為嚴重，立刻準備熱修。第一週有兩款遊戲踩到這條線：瓦普塔 1.0.10 和奇奇背包 1.0.0，都是剛上架 Play 之後，而且是同一個錯誤。著色器連結失敗，uniform 數量是 261。

我當時以為是我的遊戲在使用者手機上啟動到一半就死了。不是。我把瓦普塔 1.0.10 放到工作用手機（Adreno 740）上跑，錯誤是 0，而 261 這個數字，是 Google 虛擬裝置使用的軟體算圖器（SwiftShader）的上限值。我把 Play 在上架後立刻跑的發布前測試機器人所產生的錯誤，當成了真人的錯誤。

所以我改了什麼

只要收集器是在軟體算圖器或 Firebase Test Lab 裝置上跑，就完全不送出 session 和錯誤。我在工作用手機上親自確認過：打開標記就被辨識為機器人，關掉就被辨識為真人。我也把它加進同步檢查，避免出現漏掉這道防護的複本。

第一週得到的規則有兩條。測試用的開關，先確認那個開關真的有用。新的監控裝置，先把自己製造的雜訊濾掉。

如果你也一樣，可以先試試這些

如果你是第一次裝當機收集器的獨立開發者，我建議照這個順序。

• 寫了故意讓 App 當機的程式碼，先在實機上確認 App 真的會死。
• 當機之後，還要看下次啟動時報告有沒有送達。
• Play 上架後立刻收到的錯誤，先和發布前報告的裝置清單對照。
• 可疑的錯誤，用同一個版本在一支真實手機上重現看看。
• 新的通知標準，第一週先數自己製造了多少雜訊。