Android Component Lifecycles - Broadcast Receiver(三)

一.Broadcast Receiver Lifecycle
只有一個LifeCycle callback method

void onReceive(Context curContext, Intent broadcastMsg)

當有訊息傳達到receiver,Android就會呼叫執行Receiver內的 onReceive()
並把intent傳進去給onReceive()，只有在執行onReceive()時,receiver的狀態是active的,當執行完return後
就會變成inactive狀態

當receiver在active狀態時是被保護不被殺的，一旦執行完處於inactive狀態,則在任何時間要砍都可以
記憶體不足時就可先砍掉這receiver

receiver存在的一個隱藏性的危險是，如果當receiver要回應broadcast message，需要開啟一個新的thread去處理時,receiver在開啟thread後會立刻return(其實,處理程序還在運作)，receiver已經被當作是inactive狀態,隨時有可能會被砍掉。解決的方式是啟動一個service去處理要做的事,而不要在receiver內去開啟新的thread。

二.Processes 重要性順序
Android系統會盡可能保留所有的process,但如果當記憶體不足時,就會需要砍掉一些較不重要的process。如何判斷process的重要性,以下為重要性順序

1. foreground process:也就是正在進行中的程序
    1.使用者正在互動執行的Activity
    2.正在執行中Activity所正在呼叫運作的Service
    3.Service內部正在進行不可中斷的callback包括onCreate() 
      onStart()或onDestroy()
    4.正在執行onReceive()的BroadCast Receiver物件
      除非系統記憶體已經太低太低，否則系吐統不太可能把正在
      前景執行的程序砍掉
2.visible process:
    1.不是在前景運作，但仍然在螢幕上看的到的元件(已經呼叫了
      onPause())例如前景activity是個對話窗，但還允許前一個
      activity在後面被看到
    2.與visible Activity有關聯的Service
3.service process:
    透過startService()啟動的service，但不在以上兩層次範圍內
    雖然service並非直接與使用者看到的東西關聯在一起，但仍在
    用作使用者在意的事
    例如在背景播放音樂或在背後下載資料，除非記憶體不足否則系
    統會讓他保持運作
4.background process
    一個在背景已經看不到的Activity(已經呼叫了onStop)，通常都
    會有許多background process被保留在後面，在記憶體不足時可
    以砍掉節省資源
5.empty process
    沒有任何Activity的元件，就如同cache一樣，這存在只是用來改
    善啟動效能的快慢，為了調節效能,process cache與
    kernal cache經常會被清除

因為一個service的排序是高於一個visible activity，所以在Activity初始化時,若需要進行較長時間處理，最好是啟動一個service來作,效果會比產生一個thread來作好。例如播放音樂與上傳圖片到網站上,在service作會比較好。還有就是在receiver的onReceive處理內,啟動service去執行也較佳