現在繼續對android進行溫習，上一篇日記主要溫習了android比較宏觀的知識和四大組件中的activity.現在開始下一個組件的溫習:
Content Provider：
Content Provider內容提供者，在android系統中數據是私有的，兩個應用程序之間可以通過Content Provider來實現。通過它將自己的數據暴露出去，外界不知道這些數據是如何存儲的，重要的是外界可以通過這一套標準及統一的接口和程序裏的數據打交道。外界的程序通過contentResolver()接口可以訪問contentProvider提供的數據，通過getContentResolver()得到當前應用的contentResolver實例。 另外，每個content Provider存儲的數據都是以表的形式存在，那用什麼來爲這些表做標識呢？沒錯就是URI，URI的形式是這樣<scheme>://<authority><path>?<query>對於content Provider的數據表，<scheme>字段內容固定爲"content",<authority>字段內容指定了content Provider的具體類別。我們知道了用URI來標識content provider,那麼如何生成我們需要的URI呢？其實生成具體URI常用方法有ContentUris類的Uri ContentUris.withAppendedId(Uri contentUri,long id)和 Uri類的Uri.withAppendedPath(Uri baseUri,String PathSegment).我們必須爲URI與對應的表或者數據類型建立映射，在Content Provider解析URI以確定具體的表及數據時，通常使用UriMatcher類的addURI(string authority,string path,int code)方法來建立URI和指定數據表的記錄的關係。根據content Provider的實現及聲明方式，content Provider和使用它的應用可以在同一進程內，也可以不在同一進程內。當處於同一進程時，可以互相訪問對方在系統/data/data中的資源，實現資源共享。
介紹完content provider的使用方法後，我們來了解一下content provider的加載機制吧，當啓動時平臺通過acquireProvider（）解析AndroidManifest.xml文件中content Provider聲明的<authority>字段，並自動加載所有content provider,content provider的android:multiprocess屬性值決定了該content provider能否在多個應用進程中被創建，默認爲false.當其它應用使用該content provider,則會通過進程間通信(IPC)方式調用content provider對象。如果此時該content provider存儲數據不用在多個進程間同步，則可以將android:multiprocess賦爲true,當多個調用該content provider應用進程分別創建content provider實例。
Service:
接下來要介紹的就是Service，Service的生命週期包括:onCreate、onStart、和onDestroy，應該注意的是在一個生命週期中，onCreate只會調用一次，而onStart可以被調用多次。我們可以通過以下兩種方式啓動一個Service。a.通過startService:Service會經歷onCreate()->onStart()->stopService(),stopService的時候會直接onDestroy.b.通過bindService:Service只會onCreate,調用者和Service會綁定在一起，當調用者退出時，Service會調用onUnbind->onDestoyed。當我通過這些方法啓動Service時，如果service還沒有運行，則android會調用onCreate方法，然後再調用onStart，而如果service已運行，則通過新的Intent調用onStart方法.同時我們應該注意先bind和先start是有區別的，如果我們先bind時，start的時候就會直接運行service的onStart方法，而且先bind,stop不了，只可以先unbindService再stopService。而先start時，bind的時候直接運行onBind.
BroadcastReceiver:
廣播接收者的註冊方式有兩種:AndroidMinfest.xml中註冊BroadcastReceiver之外;還可以在代碼 中註冊.需要注意的是爲減輕系統的負載，註銷註冊的BroadcastReceiver是良好的習慣.
在onReceive()方法執行中，則Android系統認爲Receiver處於活動狀態,onReceive()執行完後，則認爲非活動狀態，系統會任意時間銷燬。在所調用的onReceive(Context,Intent),函數裏，不能有過於耗時的操作，不能使用線程來執行，對於耗時的操作，請startService來完成。因爲當得到其它異步操作所返回的結果時，BroadcastReceiver可能已經無效了.需要記住的是BroadcastReceiver是四大組件中唯一一個被動接收數據的組件.
到目前爲止，已經重新粗略地溫習了一次Android四大組件的一些用法和知識點，下一次就要開始Intent和IntentFilter與四大組件之間的關係和知識點