透過 Flutter 框架開發的 App (含 iOS 與 Android) 已經上線，開始要追蹤用戶使用時，是否有發生不預期的狀況。
如同開發原生 iOS App 那樣，我將 Firebase Crashlytics 導入 Flutter App 中，一旦有任何崩潰、例外狀況，就會被記錄且上傳到 Firebase，讓我每天能明確掌握 App 使用狀況，並在適當時機修正並釋出新版本。🙃
這是我開啟記錄「例外」事件功能後，在 Firebase 上所搜集統計的資料。在沒有開啟此功能前是一片祥和，幾乎沒有「崩潰」事件。然而我為了優化 App 各種不預期的使用狀況，便有需要去了解會有哪些「例外」事件。🤔
（繼續閱讀…）最近一個月，湧入上萬用戶使用我們家的 App，特別是 Android 手機用戶佔了大部分。當然用戶一多，就會出現不預期的狀況，這在開發 App 是很普遍發生的狀況。
特別是 Android 系統，相比 iOS 較為不穩定，因為是開放系統，讓各家軟硬廠商有較多的彈性去調整系統。於是乎，會遇到不預期的崩潰狀況，是理所當然之事。
這次來記錄一下，Crashlytics 記錄最多崩潰的事件：FlutterJNI.loadLibrary。
（繼續閱讀…）最近我負責的產品 App 流量大增（至少成長十倍），各種崩潰數據也跟著多了起來，尤其是 Android App，出現了一堆我壓根沒見過的問題，畢竟過去十年我都在做 iOS App，這下子得趁這一波學習一下啦～
我在 Firebase Crashlytics 後台上見到一些議題，先截個圖來看看多麽嚴重刺激！？😃
由於時代不停的變遷，使得必須從Fabric Crashlytics遷移Firebase Crashlytics。
自從2017年Google收購Fabric，我之前所整合的Answers和Crashlytics就逐漸被整合到Firebase。遙想2017年我還在看Fabric後台，很有成就感地看著我開發的HiLife和Nissan。文章：Fabric Crashlytics 崩潰紀錄。
身為成長駭客(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 升級狀況。
開發好一個應用型App，我們會想要讓它變得更好，可是要從哪方面下手？這時候就可以觀察使用者的狀況，來決定新增、修改、刪除的優先順序。
半年來持續在使用Crashlytics，它不僅可以收集崩潰資訊，還能發布測試版本，現在甚至能夠統合使用者數據，這第三個功能實在深得我心呢！
以垃圾管家為例，可以看到橫向時間軸，有高低起伏的線條，這是當前活躍使用者的數目，我實際測試開啟垃圾管家，不到三秒就會有反應！
Active Users：The number of users that have started a session in the last 5 minutes.
曾經陪我們測試過許多App的平台Testflight，即將在這個月底（2/26）結束營業XD～好啦，其實是被Apple買去，整合到iTunes Connect中，未來可以去嘗試看看。
在此，我要介紹另一個發佈版本給使用者測試平台Crashlytics，它有三大功能：
過去我很常使用1和2，現在可以來嘗試3。
逍遙文工作室 
HappyMan・迴響