對移動端app容災的思考

語言: CN / TW / HK

移動端app容災

可能很多人對這個概念比較陌生,我們常說的容災策略,一般都特指伺服器端的容災,那麼移動端容災是個啥!其實跟伺服器一樣,就是持續保證我們app的可用性,在crash或者anr的時候,能夠通過一些手段實現保證後續可用。

本篇不涉及複雜技術,更多的是對方案的探討,請放心食用!

為什麼會有這個概念

其實在筆者角度上看,技術與業務的關係其實是比較單一的,雖然不至於對立,但是一個業務人員看待技術,最關心的可能就是穩定性了,在“老闆”角度上看,他其實不太關心所用的技術是什麼,但是一定關心這個服務能不能保證自己的業務能不能持續,這也是筆者訪談了幾位非技術人員得出的結論,同時在“降本增效”的今天,追求穩定性可能是大部分公司的選擇了。還有就是站在長遠立場上看,移動端的容災也慢慢會成為各大公司角逐的一個點。一個由於crash導致而離開的使用者,就有可能帶走10個相關聯客戶,在app場景如此,在遊戲場景也是,如果打著遊戲突然閃退了,肯定是一個非常不好的體驗。

本文希望介紹一些移動端的容災策略,希望能夠給各大開發者提供一個啟發。

容災策略

降級

首先是第一個策略,降級,比如app crash的時候,我們採用降級的手段,轉移到h5頁面

image.png

這個方案的特點是 存在兩套頁面,一個是原生頁面,一個是h5頁面,大部分公司可能都會同時有這兩套ui,一個用於投放app,一個用於h5頁面,比如網頁還有m站這些。 當主頁(也可以是特定activity),跳轉到其他頁面時,如果發生了crash,就從主頁直接開啟h5容器,展示h5頁面,這個在拼*多app方案上常用

程序多活

android在多程序上給我們提供了很多便捷的地方,只需要在activity或者其他的manifest檔案上宣告process即可 android:process=":test" 一般我們不做特殊配製的話,activity等就是執行在以包名為名稱的程序上。這裡的多程序方案有兩個 - app crash的時候,通過安全氣囊機制,重新為使用者開啟到當前頁面,即我們會殺掉原本的程序,重新開啟一個新程序,併為使用者定位到當前頁,可以攜帶本地的tag或者其他標識進行頁面的定位,這個方案可以運用在遊戲中,如果crash了立馬主動幫使用者重開,並提高這部分使用者的載入速度!

image.png - (這也是我最推薦的)app crash/anr的時候,不重新進入原頁面,而是通過安全氣囊機制,開啟一個純淨版的鏈路這個鏈路是怎麼理解呢?這裡特指是業務簡單的鏈路,即滿足使用者最基本需求的鏈路。比如說我們有一個商城app,那麼下單就是最關鍵的鏈路,我們只需要在app crash的時候,開啟一個業務最簡單的頁面,讓使用者去操作即可,這樣就避免二次可能產生的crash!

image.png

強制升級

如果某個使用者在app的crash次數達到一定時,就直接採取強制升級的方案,讓使用者的app始終保持最新版本,避免由於老版本的影響導致這部分的使用者流失。這個方案的實現可直接對接到app內的升級策略

髒資料清除

有一些crash可能是由於使用者本地的髒資料引起而導致的,那麼我們可以在crash的時候,把這部分資料清除,或者簡單來說直接清除所有快取,這種“重置”操作會一定程度上避免由於髒資料等特定crash的發生。

安全氣囊機制

可以看到,無論是哪一個方案,我們都需要依靠crash/anr檢測的機制,才能夠實現,沒關係,相關的文章早已準備好黑科技!讓Native Crash 與ANR無處發洩!,同時也配備了開源庫Signal,運用Signal,我們可以實現很多crash後的安全措施,也希望大家執行起來demo,嘗試一下各種腦洞大開的方案!

讓業務能夠持續穩定下去,降低由於異常導致的損失,這是筆者一開始想要實現的,當然,目前我們的庫還在不斷完善的過程中,也希望廣大開發者能夠加入進來,一起去探索一個新方向!

最後

本來決定要分享asm相關的,但是在洗澡的過程中發現其實很多對伺服器端的容災策略的思想也是可以在移動端上去進行的,在app的業務迭代過程中,一定會對穩定性造成很多挑戰,在各大公司人員縮減的背景下更是如此,所以說,建立一套安全氣囊裝置,一定會是後面多個公司的探索方向!

往期推薦

為什麼說獲取堆疊從來就不是一件簡單的事情

聽說Compose與RecyclerView結合會有水土不服?