[Android][筆記] Background update

Reading time ~5 minutes

今天跟人討論到關於Background update相關的問題, 這個議題一直是看似簡單(反正就是在backgroud抓資料), 但實際上很複雜也很難做的好

剛剛又拿了今年Google IO的Android protips這session的投影片複習了一下, 這個session裡剛好也有提到相關的內容, 就順便拿來借題發揮一下

為什麼要做background data update? 無非是 - Being Fresh

  • 讓user在想要看他所想看的資料時不用等待(Means never have to wait)
  • 讓user可以隨時拿到最新的資料(Means always being up to date)

原本投影片上有三點, 我簡化成兩點, 是我覺得2,3其實可以歸為同一類(把位置當成是一種資料來看), 對於資料導向的應用程式來說, 是提供user一個好的使用體驗的方式, 因為大部分的資料都在背景幫你先預取回來了

另外我再多加一點: 需要提供使用者有新資料通知(Notification)時, 如新郵件, 新回覆之類的

但其實在移動裝置上, 要實現這樣的東西, 其實考量點並不只是抓取資料這麼簡單, 移動裝置通常意味著有較少的資源(運算能力, 記憶體, 儲存空間等等), 可能有限的且昂貴的網路環境(lower bandwidth, high data rate), 以及有限的電量(battery life)

第一點, 在現在高端手機的硬體競賽之下, 移動裝置其實已經漸漸的不比PC, Notebook來的差了, 雙核甚至四核的CPU, 更多的RAM, 儲存空間或許還有點距離, 不過也是越來越大, 這點, 變成比較不是問題, 更多的資源意味著可以容納更多的事情一起進行, 包含background update, 但相對的也意味的, 越來越耗費電源, 現行的電池科技並未進步到可以提供這麼大量的消耗, 因此移動裝置可以使用的時間會因此越來越短, 也會影響到整體的實用性

至於網路環境方面, 台灣的3G收費還不算貴, 多則不到一千就可以擁有無限制的data rate (吃到飽), 但並不是所有的地方都擁有這樣的環境, 很多國家, 資料總額還是有上限, 雖然大多已經相當的夠用了, 但多餘的資料抓取, 可能還是會變成無形中在偷使用者的荷包, 再者, 雖然電信商在智慧型手機流行的今天, 提供更多資料型的資費方案可選擇, 但大部分的電信商並沒預算好由於智慧型手機所帶來的網路流量, 有些電信商本身的infrastructure並不好, 越來越多的資料流量反而造成網路負擔不起

因此, 針對background update這類的設計, battery life跟資料量就是很重要的考量點

在這份投影片中提到"When is the best time to update your app’s data":

  • 在還有電時 Provided they still have battery (不知道是我翻譯不好, 總覺有點廢話, 應該要是在電量還在某一定程度之上吧)
  • 有網路時 They have connectivty and bandwidth (大部分的background update都是要從網路上抓取資料, 因此在沒網路時還要去抓取資料, 當然很不經濟)

這兩點, 主要還是都是針對電力的角度

根據過去做的經驗, 這樣其實並不是很夠, 在Android上允許很多background processes, 這有時來說是種災難, 每個processes可能都要此起彼落的起來抓取資料, 就算還有電源, 還是會加速電力的消耗, 即使是接著電源, 也可能會導致充電效率變低, iPhone 4其中一個讓我最印象深刻的是充電效率, 其實不只是電源要能夠持久, 充電效率高也是很重要的, 那代表user可以花比較少的時間回復到他正常使用的狀態

在"Monitor device state to vary refresh rate"裡面有更進階的提到幾點:

  • Update without connectivity?
  • More updates when on Wifi?
  • More updates when on charging?
  • Suspend update when battery is low
  • Mote updates when docked
  • Suspend update when in car dock

基本上這幾點都是很實用的設計, 不過, 真正實行起來會發現, background update的學問可能還比這多很多, 例如上面所說充電的問題, 也就表示說, 並不是充電時多抓點東西就是好事, 而且多抓點東西也表示需要消耗更多的網路頻寬, 撇開資費和電信商的頻寬不說, 當user如果正在使用網路, 比如說瀏覽網頁, 看影片, 這時候如果背景也在狂抓取資料, 就有可能影響到user在前景的使用

我覺得, 還有更根本的問題, 比如說, 到底是要啥時抓, 多久抓一次資料才足夠, 要抓多少資料才足夠, 抓資料的次數越頻繁, 抓取的資料量越多, 代表裝置要耗費更多原本可以休息的時間來處理, 這方面可能得從整體設計面來考量, 先分析出有哪些資料需要background update, 這些資料在遠端被更新的頻率有多高(藉由此來決定到底更新頻率多高才是合理), 每一種資料需要的即時性不同, 有些資料久久才會有變化, 有些資料則很快, 如果很久才變化的資料, 沒事就去更新, 不但耗電, 而且浪費資料頻寬, 甚至這些資料你有沒在背景更新, 使用者也不會有任何感覺, 另外一個是資料量的問題, 如何縮減傳輸的資料量, 一方面是節省頻寬, 更重要的是節省每次抓取資料的時間, 這樣耗費的電量也才可以更少

iOS4上雖然也允許了Background task, 但它的限制就高上很多, 很多需要做背景更新的, 還是透過push來達成居多, 不過push的方式在某方面來說可以減少不必要的update(比如說, 如果資料沒更新的話, pull的方式還是會上server去抓, push的方式則無這種無意義的浪費), 但設計不好的話, 其實也是會造成同樣的問題的….