Google IO 2018 - Android Vitals

startup time

1. slow cold start: cold start超過五秒者：

定義為：
1. app 不在memory
2. app經過onCreate() -> Activity running

2. slow warm start: app已經在memory，重新叫起超過2秒者：

定義為：
1. app 在memory
2. app經過onCreate() -> Activity running

3. slow hot start: 某個已經launched activity又restart 到 onResume的時間的時間超過1.5秒者：

定義為：
1. app 在memory
2. app經過onRestart() -> Activity running

Detecting Crashes

Android Vitals是一個platform tool，所以可以在3rd party crash-detection sdk (e.g. Fabric Crashlytics)還沒起來前，就能偵測到crash!

Battery

這是最重要的效能指標，因為mobile device是很resource-limited。

1. 不要直接使用wake lock api，有可能因為bug造成螢幕/CPU永不關閉。改用：

2. 盡量少wake up

Permission

統計看來，user並不喜歡grant permissions:

Vitals會把這些permission列出來：

不過目前應該還是在beta吧？！ 我們的app都看不到這些資訊。奇怪。

ANRs

這個是Android系統中惡名昭彰的代名詞，android vitals也是有偵測這個東西，這怎麼發生呢？

當main thread (UI thread) 被block住，無法處理render / ui input時，系統偵測到此狀態維持幾秒鐘之後，就會出現ANR警告。block的原因可能包括：

1. I/O operations: network, disk

上面這個function call看似沒有read/write operations，但實際上一但被instantiated，就馬上有read operations (SharedPreference implementation就是如此）。所以看似無害的code，實際上在main thread做了I/O operation了。

下面是另一個I/O example:

上面的code實際上在 access headerFields就會真的去讀取connection，甚至在某些版本的Android，連if （）中的URL equality comparison就會進行IO了！

不過developers哪有辦法知道所有這些眉角？？？？？
還好Android提供一個debug api，可以讓我們在debug time抓出這些在main thread不該做的事：

penaltyDeath() 會造成runtime crash，所以記得不要在release版本時候打開！！！當違反strict mode crash之後，可以從log找到發生的行數：

2. long computation

這個就不用多說了，肯定是block。
要常態性使用Android Profiler來看哪些code有可能造成long computation。
Strict mode api也提供自己加入註解一段slow code，讓strict mode偵測到此slow code被main thread上執行時，可以penalty crash。

3. Interprocess communication (IPC)

既然另外一個process (通常是另外一個app)不受我們控制，我們當然不能在main thread去做IPC，否則有可能造成main thread上做一些blocking operations。

4. Multithreaded programming

使用一些synchronization primitives的時候，要很確定自己知道自己在幹嘛，否則有可能造成dead lock => ANR

android vitals的log可以幫助我們找出這類型的問題：

5. Slow BroadcastReceiver handling
我們宣告BroadcastReceiver在manifest中，如果一個broadcast進來，handler是在main thread上跑的！ 所以不該做任何以上四點提到的operations。如果你的handler在10秒內沒exit，OS會殺掉整個process (app)。

所以要在handler中用另一個thread來做上面四點的事：

Crashes

我們常常為了怕某些狀況下會crash，而做一堆null check或是try-catch，不過目前Android官方建議全部使用Jetpack的架構來解決這些問題：

另外使用Kotlin的built-in nullity check，也是有幫助。