摘抄自https://www.jianshu.com/p/51aaa65d5d25，隻選取部分覺得需要記錄一下的内容，用于查閱
文章目錄
- Activity
-
- 生命周期圖：
- onPause()執行相關
- Activity生命周期異常情況
- Activity與Fragment生命周期關系
- Activity與menu建立先後順序
- Activity的啟動模式
- Service
-
- 基本說明
- 兩種啟動方式
- IntentService
- BroadcastReceiver
- ContentProvider
Activity
生命周期圖：
onPause()執行相關
表示activity正在停止，此時可以做一些存儲資料，停止動畫等工作，注意不能太耗時，因為這會影響到新activity的顯示，onPause必須先執行完，新的activity的onResume才會執行。
當activity中彈出dialog對話框的時候，activity不會回調onPause。
然而當activity啟動dialog風格的activity的時候，此activity會回調onPause函數。
Activity生命周期異常情況
情況1：資源相關的系統配置發生改變導緻activity被殺死并重新建立
比如說目前activity處于豎屏狀态，如果突然旋轉螢幕，由于系統配置發生了改變，在預設情況下，activity就會被銷毀并且重新建立，當然我們也可以組織系統重新建立我們的activity。
系統配置發生改變以後，activity會銷毀，其onPause，onStop，onDestory均會被調用，由于activity是在異常情況下終止的，系統會調用onSaveInstance來儲存目前activity狀态，這個方法的調用時機是在onStop之前。與onPause沒有既定的時序關系，當activity重新建立後，系統會調用onRestoreInstanceState，并且把activity銷毀時onSaveInstanceState方法儲存的Bundle對象作為參數同時傳遞給onRestoreInstanceState和onCreate方法。onRestoreInstanceState()在onStart()方法後回調。
同時，在onSaveInstanceState和onRestoreInstanceState方法中，系統自動為我們做了一些恢複工作，如：文本框（EditeText）中使用者輸入的資料，ListView滾動的位置等，這些view相關的狀态系統都能夠預設為我們恢複。可以檢視view源碼，和activity一樣，每個view都有onSaveInstanceState方法和onRestoreInstanceState方法。
情況2：資源記憶體不足導緻低優先級的activity被殺死
這裡的情況和前面的情況1資料存儲和恢複是完全一緻的，activity按照優先級從高到低可以分為如下三種：
（1）前台activity—正在和使用者互動的activity，優先級最高
（2）可見但非前台activity—比如activity中彈出了一個對話框，導緻activity可見但是位于背景無法和使用者直接互動。
（3）背景activity—已經被暫停的activity，比如執行了onStop，優先級最低。
重新建立activity：activity指定configChange屬性來不讓系統重新建立activity。
android : configChanges = “orientation”
Activity與Fragment生命周期關系
建立
銷毀
Activity與menu建立先後順序
在activity建立完回調onResume後建立menu，回調onCreateOptionsMenu
Activity的啟動模式
tandard模式：在這種模式下，activity預設會進入啟動它的activity所屬的任務棧中。 注意：在非activity類型的context（如ApplicationContext）并沒有所謂的任務棧，是以不能通過ApplicationContext去啟動standard模式的activity。
singleTop模式：棧頂複用模式。如果新activity位于任務棧的棧頂的時候，activity不會被重新建立，同時它的onNewIntent方法會被回調。 注意：這個activity的onCreate，onStart，onResume不會被回調，因為他們并沒有發生改變。
singleTask模式：棧内複用模式。隻要activity在一個棧中存在，那麼多次啟動此activity不會被重新建立單例，系統會回調onNewIntent。
singleInstance模式：單執行個體模式。預設情況下，所有activity所需的任務棧的名字為應用的包名，可以通過給activity指定TaskAffinity屬性來指定任務棧，這個屬性值不能和包名相同，否則就沒有意義 。
Service
基本說明
調用者和service在同一個程序裡，是以運作在主程序的main線程中。是以不能進行耗時操作，可以采用在service裡面建立一個Thread來執行任務。任何 Activity 都可以控制同一 Service，而系統也隻會建立一個對應 Service 的執行個體。
兩種啟動方式
第一種：start
不在使用時，調用stopService(Intent)方法停止服務
使用start方式啟動的生命周期：
onCreate() – > onStartCommand() – > onDestory()
注意：如果服務已經開啟，不會重複回調onCreate()方法，如果再次調用context.startService()方法，service而是會調用onStart()或者onStartCommand()方法。
特點：
一旦服務開啟就跟調用者（開啟者）沒有任何關系了。開啟者退出了，開啟者挂了，服務還在背景長期的運作，開啟者不能調用服務裡面的方法。
第二種：bind
不再使用時，調用unbindService(ServiceConnection)方法停止該服務
使用這種bind方式啟動的service的生命周期如下：
onCreate() – > onBind() --> onUnbind() – > onDestory()
注意：綁定服務不會調用onStart()或者onStartCommand()方法
特點：bind的方式開啟服務，綁定服務，調用者挂了，服務也會跟着挂掉。綁定者可以調用服務裡面的方法。
IntentService
IntentService是Service的子類，比普通的Service增加了額外的功能。先看Service本身存在兩個問題：
Service不會專門啟動一條單獨的程序，Service與它所在應用位于同一個程序中；
Service也不是專門一條新線程，是以不應該在Service中直接處理耗時的任務；
IntentService特征:
會建立獨立的worker線程來處理所有的Intent請求；
會建立獨立的worker線程來處理onHandleIntent()方法實作的代碼，無需處理多線程問題；
所有請求處理完成後，IntentService會自動停止，無需調用stopSelf() 方法停止Service；
為Service的onBind()提供預設實作，傳回null；
為Service的onStartCommand提供預設實作，将請求Intent添加到隊列中；
Github: ServiceDemo
BroadcastReceiver
普通廣播是完全異步的，可以在同一時刻（邏輯上）被所有接收者接收到，消息傳遞的效率比較高，但缺點是：接收者不能将處理結果傳遞給下一個接收者，并且無法終止廣播Intent的傳播；然而有序廣播是按照接收者聲明的優先級别（聲明在intent-filter元素的android:priority屬性中，數越大優先級别越高,取值範圍:-1000到1000。也可以調用IntentFilter對象的setPriority()進行設定），被接收者依次接收廣播。
注意 ：BroadcastReceiver生命周期很短
不應該在BroadcastReceiver中開啟一個新的線程，因為BroadcastReceiver生命周期很短，在執行完onReceiver以後就結束，如果開啟一個新的線程，可能出現BroadcastRecevier退出以後線程還在，而如果BroadcastReceiver所在的程序結束了，該線程就會被标記為一個空線程，根據Android的記憶體管理政策，在系統記憶體緊張的時候，會按照優先級，結束優先級低的線程，而空線程無異是優先級最低的，這樣就可能導緻BroadcastReceiver啟動的子線程不能執行完成。
廣播還可以通過動态注冊，一定要加上這個權限
android:name=“android.permission.PROCESS_OUTGOING_CALLS”
ContentProvider
它主要的作用就是将程式的内部的資料和外部進行共享，為資料提供外部通路接口，被通路的資料主要以資料庫的形式存在，而且還可以選擇共享哪一部分的資料。ContentProvider是android中一種跨程式共享資料的重要元件。
也可以使用系統的ContentProvider。系統的ContentProvider有很多，如通話記錄，短信，通訊錄等等，都需要和第三方的app進行共享資料。既然是使用系統的，那麼ContentProvider的具體實作就不需要我們擔心了。