數據分析,可靠的Firebase
秋末的十月
豔陽一樣高照
完全感受不到冬天來臨的絲毫氣息
在Coding的世界裡
也感受不出四季變化
這個月的工作重點為串接Firebase
當初會想要接Firebase
是想要使用他的Remote config
目的是在自家server有狀況時
可以及時顯示公告訊息
讓用戶知道目前正在維修中
照著上面的教學走
大概幾十分鐘就可以搞定
App的流程也不用大改
只需要切換拿Config的方法就可以了
既然不用重新上code
就等於可以動態更換App內的數值
於是我突發奇想
感覺適合拿來做跑馬燈功能
不但可以隨時抽換公告內容
甚至根據不同版本顯示不同的公告
請用戶去更新之類的
(其實靈感是自強號火車上的跑馬燈)
不等PM吩咐就先做了一個版本
效果意外的好
於是就跟隨著其他功能更一起上線
自己規劃功能自己實做的感覺也不錯
不過既然都串了remote config
沒道理Firebase上面的其他服務不用
所以整個月大部分的時間
都在研究firebase上面的功能
我自己首推是crashlytics
即閃退報告分析
原本我們是看Flurry的閃退報告
雖然可以知道閃退率
就Flurry對於閃退原因的分析就沒有那麼好用
即使上傳了解析閃退報告的dsym檔案
還是給你0XFFFFF這種記憶體位置沒用的資訊
必須再用其他程式
才能知道程式碼閃退在哪一行
由於一條閃退報告
往往要花三到五分鐘
去解析壞在哪一行
真的是曠日廢時
所以才接Firebase 的crashlytics
接完才知道Firebase的好啊
不但告訴你錯在哪一行
還有GUI介面篩選App版本
作業系統版本
以及閃退時用戶的手機狀態
真的像廣告台詞說的
用過就回不去了
當然也就看到自己犯下的愚蠢錯誤
用驚嘆號強迫取值
index out of range等等
不過更多的是iOS 13底層的crash問題
有鑑於iOS 13不斷在更新修復閃退
我就期待官方修好自己的bug
我也修好我自己的bug
井水不犯河水
多虧分析紀錄快速抓出閃退點
程式碼的閃退率也從2%降到將近0.5%以下
以我自己的標準來說
是相當滿意的了
第二個串接的是遠端推播
起因是發現透過server打出的推播
Android的到達率比起iOS高了許多
差別就在Android使用的是
Firebase Cloud Message(FCM)的服務
而iOS是用Appler自家的APNS server
後端的同事們
前前後後查了兩個月
始終無法解決iOS收不到推播的問題
痛定思痛全面改換FCM
所以我們前端也要接上Firebase的推播功能
才能把新格式的token傳回給server
果真換到FCM後
客戶抱怨收不到推播的比例就大幅降低了
真的是很不可思議
原生APNS比外來FCM不可靠的現象
到現在還是一個謎
不過除了提高推播到達率
串接FCM之後還有一個好處
就是我們的PM可以自行手動排定推播
想推就推
想打就打
因為不用錢
也不用麻開需求給後端同事
加上推播可以設定參數
讓使用者點開推播後
就可以跳到指定的頁面
對於推廣新功能有很大的幫助
第三個串接的
是比起推播更強大的服務
也就是Dynamic Link
由於推播需要下載App後
才能透過註冊token打推播
但是對於沒有下載App的用戶就沒轍了
Dynamic Links就是為了解決這個問題而生
顧名思義
這是一個動態連結
表面上的短網址不會改變
但隱藏在裡面的deep link可以隨時更動
而且用戶在第一次點擊Dynamics link
進入商店載完App第一次開啟程式時
deep link的資訊仍然會帶進app裡面
所以還是可以達到跳頁的功能
真的是很像黑科技
除了上述功能
Firebase對於用戶留存率
活躍數的分析也相當不錯
也可以埋ScreenView事件
加深探究使用者行為
用了才知道相見恨晚
另外這一期還有發現一個新Bug
就是圖片的快取服務
故事的開頭是有一天老闆在用App時
發現有一張股票走勢圖有誤
應該是紅色的卻顯示是綠色的
印象中那張圖片只是去一個網址
拿到jpg檔案後
把圖片放到image view上面
所以聽到bug狀況的時候
直覺反應是server給錯的圖片
但是問題當然沒有那麼簡單阿~
後來打開網頁
輸入服務的網址
一看才嚇到
iOS, Android和網頁
同一道網址出來的圖片都不一樣
百思不得其解
問了網頁的前輩後
才知道圖片的三方管理套件
通常都會做快取處理
一回去檢查套件的程式碼
還真的有快取
而且還分記憶體和硬碟快取
預設快取時間長達一個禮拜
看到真的是傻眼
因為服務的網址是固定的
所以只要呼過一次後
這張圖片就會被快取住
七天不能超生了
解決方式有兩種
第一種就是在帶網址時
後面加上一些亂數
魅惑套件的快取機制
第二種方法是限制快取的時間
其實三方套件原本就有提供這個對外接口
不過從原本的快取一周到快取一小時
怕會一直向自家server轟Request
把server操掛
雖然理論上不會那麼脆弱
但是保險起見
就配合剛剛說的remote config
讓程式可以動態決定快取的時間
萬一真的server 扛不住
就把快取時間改回一天甚至更久
所幸上線後也沒有發生什麼大包
小看我們家server
真的是多慮了
實際上來說
十月沒啥技術上的成長
都是抱著Firebase的大腿
不過偶爾抱腿也是滿不錯的~