Crashlytics loadLibrary
最近一個月，湧入上萬用戶使用我們家的 App，特別是 Android 手機用戶佔了大部分。當然用戶一多，就會出現不預期的狀況，這在開發 App 是很普遍發生的狀況。
特別是 Android 系統，相比 iOS 較為不穩定，因為是開放系統，讓各家軟硬廠商有較多的彈性去調整系統。於是乎，會遇到不預期的崩潰狀況，是理所當然之事。
這次來記錄一下，Crashlytics 記錄最多崩潰的事件：FlutterJNI.loadLibrary。
（繼續閱讀…）Posts tagged ‘Firebase’
Crashlytics ANR
最近我負責的產品 App 流量大增（至少成長十倍），各種崩潰數據也跟著多了起來，尤其是 Android App，出現了一堆我壓根沒見過的問題，畢竟過去十年我都在做 iOS App，這下子得趁這一波學習一下啦～
我在 Firebase Crashlytics 後台上見到一些議題，先截個圖來看看多麽嚴重刺激！？😃
[iOS] 判斷 NaN
進公司兩年，還是有一些 Bug/Crash 未解，不是我不想解，只是不知道如何「重現」。偶然間我終於可以持續重現狀況，趕緊放下手邊工作，接上手機編譯 App，在 Xcode 設中斷點，便能知道前後變數當前的值，推敲源頭是什麼～😗
透過 Performance 看優化成果
人總是會不斷地成長，若沒有成長就會感到不開心，是真的吧？🤪
看到自己經營的App有大幅度進步，實在令人振奮！
上次寫了 Firebase Performance 如何使用，也經過了一個多月，可以來見證我優化某功能的成果囉～🥳
廣告
[iOS] Firebase Performance
產品若已經穩定，就可有空閒時間來優化它！Google旗下的Firebase Performance，就成了我們嘗試的目標。
其實早在我進公司第一週，我在把玩公司App時，就發現載入卡片這個產品好慢，實際去追程式碼，發現下載資源檔進行了兩次一模一樣的API呼叫，當時就有跟老闆反應。現在終於可讓上萬人一起來累計數據，再拿給老闆看更有說服力，到時候著手優化此過程，我要來邀功囉～🤡
原本專案就已經有整合Firebase Crashlytics，於是就如此簡單就加入Firebase Performance，執行某行程回傳數據，約莫一天的等待後，數據真的就出現在Firebase後台，真是令人振奮！
廣告
[圖解] APP 一年來發佈趨勢
在公司開發APP已超過一年，這期間進行了相當多任務，包含維護舊功能與開發新功能。每隔一段時間（可能是兩週或一個月）就會發佈新版本，並觀察用戶更新後的使用狀況。
在此我要記錄一下APP發佈後，用戶更新採用的比例，APP 一年來發佈趨勢。
在iOS的生態系，系統預設會自動更新APP，也就是App Store一旦有新版本，用戶手機系統會悄悄地幫更新版本，少數用戶可能會關掉自動更新功能。所以其實更新會分「自動更新」與「手動更新」。
接下來我們來看快樂印APP自動與手動更新狀況～
上圖是一年來版本用戶採納趨勢圖，可發現約莫半個月會達80%。
[iOS] 從Fabric Crashlytics遷移Firebase Crashlytics
由於時代不停的變遷，使得必須從Fabric Crashlytics遷移Firebase Crashlytics。
自從2017年Google收購Fabric，我之前所整合的Answers和Crashlytics就逐漸被整合到Firebase。遙想2017年我還在看Fabric後台，很有成就感地看著我開發的HiLife和Nissan。文章：Fabric Crashlytics 崩潰紀錄。
逍遙文工作室 
HappyMan・迴響