現在看崩潰紀錄，有另一個選擇，就是直接在 Xcode 中查看，不過這也得用戶願意分享，才能獲取到其崩潰紀錄。
在此我就以兩個我經手的 App，可以看到跟我們 debug 時出現的一樣，而且有更多的手機資訊，如 Device、iOS、Architecture 等等。
我還是覺得，Firebase Crashlytics 紀錄比較詳細啦～🙃
事實上，很多工具都是第三方做得很棒，然後大廠就直接出價買下來佔為己有！像是 Google 收購 Firebase 和 Crashlytics，或是 Apple 收購 Testflight，開發贏不過，就直接收購。
進公司兩年，還是有一些 Bug/Crash 未解，不是我不想解，只是不知道如何「重現」。偶然間我終於可以持續重現狀況，趕緊放下手邊工作，接上手機編譯 App，在 Xcode 設中斷點，便能知道前後變數當前的值，推敲源頭是什麼～😗
2020年～新冠肺炎疫情瀰漫全球一整年，終於來到最後倒數計時，總是要來回顧這一年來的收穫，看我們在哪個地方成長多少。
我在公司負責產品已超過一年，經過我一手「調教」之後的App，在品質與用戶是否有成長呢？透過Google後台統計，可輕易檢索各式各樣的指標。首先就以「事件數」和「用戶數」來看成長幅度。
整個時間軸我調整一年來做比較，期間2019/12/15-2020/12/15對比2018/12/16-2019/12/17。可見圖表有藍色實線與虛線，實線代表最近一年，虛線代表前一年，可清楚看到最近一年成長幅度相當大！
多虧Firebase Crashlytics的幫助，讓我曉得用戶發生哪些崩潰，在後台記錄得非常詳細，可以清楚讓我知道哪一個Class中的哪一行Code是崩潰關鍵！
可看到最近一週，有10次崩潰，影響10個用戶。
由於時代不停的變遷，使得必須從Fabric Crashlytics遷移Firebase Crashlytics。
自從2017年Google收購Fabric，我之前所整合的Answers和Crashlytics就逐漸被整合到Firebase。遙想2017年我還在看Fabric後台，很有成就感地看著我開發的HiLife和Nissan。文章：Fabric Crashlytics 崩潰紀錄。
辛苦一週的週五傍晚，應是期待放假的好時候，下班前居然出現不明原因，使得我們家App在開啟的時候crash，而且是持續不斷。起初還以為是自己不小心改到什麼，或是自家的後台發生狀況，查詢後才發現，竟然是Facebook SDK出包⋯⋯
可以看到程式碼crash在Facebook SDK之中，回傳這個NSNull物件⋯⋯
身為成長駭客(Growth Hacker)的我，除了觀察Google Analytics 行為流程之外，還可以查看Fabric Crashlytics 崩潰紀錄，根據重要程度優先來對非常重要的崩潰進行除錯(debug)。一般在開發的時候，不太可能完全地偵測出問題，此時就可透過使用者的實際操作狀況來了解潛在的問題。
於是乎，在專案開發之初我就會整合Fabric，此平台除了像Google Analytics可統計使用者數、活躍者數、線上人數等之外，還有可給開發者了解的Crashlytics 崩潰紀錄，基本上很適合開發經營維護產品的成長駭客。
第一個是知名超商APP：
我發現在商品兌換的時候容易崩潰！猜測是產生QR code要給櫃檯人員掃描，使用者在這過程太快點擊「取消兌換」或「離開」，使得API撈回來的資料有誤而沒處理到就發生崩潰。
第二個是知名車廠APP：
我發現在刻意阻擋使用者操作時，很容易崩潰ＸＤ～那是我要破解第三方套件所使用的撇步。
它可以選擇版本、事件、期間來篩選出何時發生的崩潰(crash)。
之前我也介紹過Fabric App，可視覺化觀察Fabric 活躍使用者 (Fabric Activity User)，在乎iOS版本普及狀況的話可透過Fabric Answers 觀察 iOS 升級狀況。
一直以來我都只看IDE中的crash log，沒想到這次要查看蘋果審查委員給的crash log檔案，這時候麻煩可大了，如果沒有弄清楚crash在哪，審委是不會讓我上架的⋯⋯看了它給的檔案，僅知道是IAP（應用內購買）程序有問題，儘管我怎麼測都沒有發生過！之後我陸續送了兩個版本，審委依然給我同樣的回覆，讓我不得不去找辦法轉譯crash log檔！
很幸運地我總算學會SymbolicateCrash來分析崩潰紀錄啦～
不知是快要壽終正寢（從96年11月到現在），還是快被我操爛掉（因為常用來跑實驗），已經用將近三年的桌電，Windows XP藍屏後重開機的狀況越來越頻繁，還好我總是有隨時存檔的好習慣，不然寫到一半的論文就會整個消失！
逍遙文工作室 
HappyMan・迴響