注：本文來自“友盟杯”，僅在此閱讀，學(xué)習(xí)
這個(gè)文章主要是講Android開發(fā)的四大組件，本文主要分為
一、Activity詳解
二、Service詳解
三、Broadcast Receiver詳解
四、Content Provider詳解
外加一個(gè)重要組件 intent的詳解。
一、Activity詳解
Activty的生命周期的也就是它所在進(jìn)程的生命周期。
一個(gè)Activity的啟動(dòng)順序：
onCreate()——>onStart()——>onResume()
當(dāng)另一個(gè)Activity啟動(dòng)時(shí):
第一個(gè)Activity onPause()——>第二個(gè)Activity onCreate()——>onStart()——>onResume()
——>第一個(gè)Activity onStop()
當(dāng)返回到第一個(gè)Activity時(shí)：
第二個(gè)Activity onPause() ——> 第一個(gè)Activity onRestart()——>onStart()——>onResume()
——>第二個(gè)Activity onStop()——>onDestroy()
一個(gè)Activity的銷毀順序:
（情況一）onPause()——><Process Killed>
（情況二）onPause()——>onStop()——><Process Killed>
（情況三）onPause()——>onStop()——>onDestroy()
每一個(gè)活動(dòng)（ Activity ）都處于某一個(gè)狀態(tài)，對(duì)于開發(fā)者來說，是無法控制其應(yīng)用程序處于某一個(gè)狀態(tài)的，這些均由系統(tǒng)來完成。
但是當(dāng)一個(gè)活動(dòng)的狀態(tài)發(fā)生改變的時(shí)候，開發(fā)者可以通過調(diào)用 onXX() 的方法獲取到相關(guān)的通知信息。
在實(shí)現(xiàn) Activity 類的時(shí)候，通過覆蓋（ override ）這些方法即可在你需要處理的時(shí)候來調(diào)用。
一、 onCreate ：當(dāng)活動(dòng)第一次啟動(dòng)的時(shí)候，觸發(fā)該方法，可以在此時(shí)完成活動(dòng)的初始化工作。
onCreate 方法有一個(gè)參數(shù)，該參數(shù)可以為空（ null ），也可以是之前調(diào)用 onSaveInstanceState （）方法保存的狀態(tài)信息。
二、 onStart ：該方法的觸發(fā)表示所屬活動(dòng)將被展現(xiàn)給用戶。
三、 onResume ：當(dāng)一個(gè)活動(dòng)和用戶發(fā)生交互的時(shí)候，觸發(fā)該方法。
四、 onPause ：當(dāng)一個(gè)正在前臺(tái)運(yùn)行的活動(dòng)因?yàn)槠渌幕顒?dòng)需要前臺(tái)運(yùn)行而轉(zhuǎn)入后臺(tái)運(yùn)行的時(shí)候，觸發(fā)該方法。這時(shí)候需要將活動(dòng)的狀態(tài)持久化，比如正在編輯的數(shù)據(jù)庫記錄等。
五、 onStop ：當(dāng)一個(gè)活動(dòng)不再需要展示給用戶的時(shí)候，觸發(fā)該方法。如果內(nèi)存緊張，系統(tǒng)會(huì)直接結(jié)束這個(gè)活動(dòng)，而不會(huì)觸發(fā) onStop 方法。 所以保存狀態(tài)信息是應(yīng)該在onPause時(shí)做，而不是onStop時(shí)做?；顒?dòng)如果沒有在前臺(tái)運(yùn)行，都將被停止或者Linux管理進(jìn)程為了給新的活動(dòng)預(yù)留足夠的存儲(chǔ)空間而隨時(shí)結(jié)束這些活動(dòng)。因此對(duì)于開發(fā)者來說，在設(shè)計(jì)應(yīng)用程序的時(shí)候，必須時(shí)刻牢記這一原則。在一些情況下，onPause方法或許是活動(dòng)觸發(fā)的最后的方法，因此開發(fā)者需要在這個(gè)時(shí)候保存需要保存的信息。
六、onRestart ：當(dāng)處于停止?fàn)顟B(tài)的活動(dòng)需要再次展現(xiàn)給用戶的時(shí)候，觸發(fā)該方法。
七、 onDestroy ：當(dāng)活動(dòng)銷毀的時(shí)候，觸發(fā)該方法。和 onStop 方法一樣，如果內(nèi)存緊張，系統(tǒng)會(huì)直接結(jié)束這個(gè)活動(dòng)而不會(huì)觸發(fā)該方法。
· onSaveInstanceState ：系統(tǒng)調(diào)用該方法，允許活動(dòng)保存之前的狀態(tài)，比如說在一串字符串中的光標(biāo)所處的位置等。
通常情況下，開發(fā)者不需要重寫覆蓋該方法，在默認(rèn)的實(shí)現(xiàn)中，已經(jīng)提供了自動(dòng)保存活動(dòng)所涉及到的用戶界面組件的所有狀態(tài)信息。
Activity棧
上面提到開發(fā)者是無法控制Activity的狀態(tài)的，那Activity的狀態(tài)又是按照何種邏輯來運(yùn)作的呢？這就要知道 Activity 棧。
每個(gè)Activity的狀態(tài)是由它在Activity棧（是一個(gè)后進(jìn)先出LIFO，包含所有正在運(yùn)行Activity的隊(duì)列）中的位置決定的。
當(dāng)一個(gè)新的Activity啟動(dòng)時(shí)，當(dāng)前的活動(dòng)的Activity將會(huì)移到Activity棧的頂部。
如果用戶使用后退按鈕返回的話，或者前臺(tái)的Activity結(jié)束，活動(dòng)的Activity就會(huì)被移出棧消亡，而在棧上的上一個(gè)活動(dòng)的Activity將會(huì)移上來并變?yōu)榛顒?dòng)狀態(tài)。如下圖所示： 一個(gè)應(yīng)用程序的優(yōu)先級(jí)是受最高優(yōu)先級(jí)的Activity影響的。當(dāng)決定某個(gè)應(yīng)用程序是否要終結(jié)去釋放資源，Android內(nèi)存管理使用棧來決定基于Activity的應(yīng)用程序的優(yōu)先級(jí)。
Activity狀態(tài)
一般認(rèn)為Activity有以下四種狀態(tài)：
活動(dòng)的：當(dāng)一個(gè)Activity在棧頂，它是可視的、有焦點(diǎn)、可接受用戶輸入的。Android試圖盡最大可能保持它活動(dòng)狀態(tài)，殺死其它Activity來確保當(dāng)前活動(dòng)Activity有足夠的資源可使用。當(dāng)另外一個(gè)Activity被激活，這個(gè)將會(huì)被暫停。
暫停：在很多情況下，你的Activity可視但是它沒有焦點(diǎn)，換句話說它被暫停了。有可能原因是一個(gè)透明或者非全屏的Activity被激活。
當(dāng)被暫停，一個(gè)Activity仍會(huì)當(dāng)成活動(dòng)狀態(tài)，只不過是不可以接受用戶輸入。在極特殊的情況下，Android將會(huì)殺死一個(gè)暫停的Activity來為活動(dòng)的Activity提供充足的資源。當(dāng)一個(gè)Activity變?yōu)橥耆[藏，它將會(huì)變成停止。
停止：當(dāng)一個(gè)Activity不是可視的，它“停止”了。這個(gè)Activity將仍然在內(nèi)存中保存它所有的狀態(tài)和會(huì)員信息。盡管如此，當(dāng)其它地方需要內(nèi)存時(shí)，它將是最有可能被釋放資源的。當(dāng)一個(gè)Activity停止后，一個(gè)很重要的步驟是要保存數(shù)據(jù)和當(dāng)前UI狀態(tài)。一旦一個(gè)Activity退出或關(guān)閉了，它將變?yōu)榇脿顟B(tài)。
待用： 在一個(gè)Activity被殺死后和被裝在前，它是待用狀態(tài)的。待用Acitivity被移除Activity棧，并且需要在顯示和可用之前重新啟動(dòng)它。
activity的四種加載模式
在android的多activity開發(fā)中，activity之間的跳轉(zhuǎn)可能需要有多種方式，有時(shí)是普通的生成一個(gè)新實(shí)例，有時(shí)希望跳轉(zhuǎn)到原來某個(gè)activity實(shí)例，而不是生成大量的重復(fù)的activity。加載模式便是決定以哪種方式啟動(dòng)一個(gè)跳轉(zhuǎn)到原來某個(gè)Activity實(shí)例。
在android里，有4種activity的啟動(dòng)模式，分別為：
·standard: 標(biāo)準(zhǔn)模式，一調(diào)用startActivity()方法就會(huì)產(chǎn)生一個(gè)新的實(shí)例。
·singleTop: 如果已經(jīng)有一個(gè)實(shí)例位于Activity棧的頂部時(shí)，就不產(chǎn)生新的實(shí)例，而只是調(diào)用Activity中的newInstance()方法。如果不位于棧頂，會(huì)產(chǎn)生一個(gè)新的實(shí)例。
·singleTask: 會(huì)在一個(gè)新的task中產(chǎn)生這個(gè)實(shí)例，以后每次調(diào)用都會(huì)使用這個(gè)，不會(huì)去產(chǎn)生新的實(shí)例了。
·singleInstance: 這個(gè)跟singleTask基本上是一樣，只有一個(gè)區(qū)別：在這個(gè)模式下的Activity實(shí)例所處的task中，只能有這個(gè)activity實(shí)例，不能有其他的實(shí)例。
這些啟動(dòng)模式可以在功能清單文件AndroidManifest.xml中進(jìn)行設(shè)置，中的launchMode屬性。
相關(guān)的代碼中也有一些標(biāo)志可以使用,比如我們想只啟用一個(gè)實(shí)例,則可以使用 Intent.FLAG_ACTIVITY_REORDER_TO_FRONT 標(biāo)志，這個(gè)標(biāo)志表示：如果這個(gè)activity已經(jīng)啟動(dòng)了，就不產(chǎn)生新的activity，而只是把這個(gè)activity實(shí)例加到棧頂來就可以了。
- Intent intent = new Intent(ReorderFour.this, ReorderTwo.class);
- intent.addFlags(Intent.FLAG_ACTIVITY_REORDER_TO_FRONT);
- startActivity(intent);
Activity的加載模式受啟動(dòng)Activity的Intent對(duì)象中設(shè)置的Flag和manifest文件中Activity的元素的特性值交互控制。
下面是影響加載模式的一些特性
核心的Intent Flag有：
FLAG_ACTIVITY_NEW_TASK
FLAG_ACTIVITY_CLEAR_TOP
FLAG_ACTIVITY_RESET_TASK_IF_NEEDED
FLAG_ACTIVITY_SINGLE_TOP
核心的特性有：
taskAffinity
launchMode
allowTaskReparenting
clearTaskOnLaunch
alwaysRetainTaskState
finishOnTaskLaunch
四種加載模式的區(qū)別
所屬task的區(qū)別
一般情況下，“standard”和”singleTop”的activity的目標(biāo)task，和收到的Intent的發(fā)送者在同一個(gè)task內(nèi)，就相當(dāng)于誰調(diào)用它，它就跟誰在同一個(gè)Task中。
除非Intent包括參數(shù)FLAG_ACTIVITY_NEW_TASK。如果提供了FLAG_ACTIVITY_NEW_TASK參數(shù)，會(huì)啟動(dòng)到別的task里。
“singleTask”和”singleInstance” 總是把要啟動(dòng)的activity作為一個(gè)task的根元素，他們不會(huì)被啟動(dòng)到一個(gè)其他task里。
是否允許多個(gè)實(shí)例
“standard”和”singleTop”可以被實(shí)例化多次，并且是可以存在于不同的task中；這種實(shí)例化時(shí)一個(gè)task可以包括一個(gè)activity的多個(gè)實(shí)例；
“singleTask”和”singleInstance”則限制只生成一個(gè)實(shí)例，并且是task的根元素。
singleTop 要求如果創(chuàng)建intent的時(shí)候棧頂已經(jīng)有要?jiǎng)?chuàng)建的Activity的實(shí)例，則將intent發(fā)送給該實(shí)例，而不創(chuàng)建新的實(shí)例。
是否允許其它activity存在于本task內(nèi)
“singleInstance”獨(dú)占一個(gè)task，其它activity不能存在那個(gè)task里；
如果它啟動(dòng)了一個(gè)新的activity，不管新的activity的launch mode 如何，新的activity都將會(huì)到別的task里運(yùn)行（如同加了FLAG_ACTIVITY_NEW_TASK參數(shù)）。
而另外三種模式，則可以和其它activity共存。
是否每次都生成新實(shí)例
“standard”對(duì)于每一個(gè)啟動(dòng)Intent都會(huì)生成一個(gè)activity的新實(shí)例；
“singleTop”的activity如果在task的棧頂?shù)脑?，則不生成新的該activity的實(shí)例，直接使用棧頂?shù)膶?shí)例，否則，生成該activity的實(shí)例。
比如：
現(xiàn)在task棧元素為A-B-C-D（D在棧頂），這時(shí)候給D發(fā)一個(gè)啟動(dòng)intent，如果D是 “standard”的，則生成D的一個(gè)新實(shí)例，棧變?yōu)锳－B－C－D－D。
如果D是singleTop的話，則不會(huì)生產(chǎn)D的新實(shí)例，棧狀態(tài)仍為A-B-C-D
如果這時(shí)候給B發(fā)Intent的話，不管B的launchmode是”standard” 還是 “singleTop” ，都會(huì)生成B的新實(shí)例，棧狀態(tài)變?yōu)锳-B-C-D-B。
“singleInstance”是其所在棧的唯一activity，它會(huì)每次都被重用。
“singleTask” 如果在棧頂，則接受intent，否則，該intent會(huì)被丟棄，但是該task仍會(huì)回到前臺(tái)。 當(dāng)已經(jīng)存在的activity實(shí)例處理新的intent時(shí)候，會(huì)調(diào)用onNewIntent()方法，如果收到intent生成一個(gè)activity實(shí)例，那么用戶可以通過back鍵回到上一個(gè)狀態(tài)；如果是已經(jīng)存在的一個(gè)activity來處理這個(gè)intent的話，用戶不能通過按back鍵返回到這之前的狀態(tài)。
-----------------------------------
二、Service詳解
service可以在和多場(chǎng)合的應(yīng)用中使用，比如播放多媒體的時(shí)候用戶啟動(dòng)了其他Activity這個(gè)時(shí)候程序要在后臺(tái)繼續(xù)播放，比如檢測(cè)SD卡上文件的變化，再或者在后臺(tái)記錄你地理信息位置的改變等等，總之服務(wù)嘛，總是藏在后頭的。
Service是在一段不定的時(shí)間運(yùn)行在后臺(tái)，不和用戶交互應(yīng)用組件。每個(gè)Service必須在manifest中 通過<service>來聲明?？梢酝ㄟ^contect.startservice和contect.bindserverice來啟動(dòng)。
Service和其他的應(yīng)用組件一樣，運(yùn)行在進(jìn)程的主線程中。這就是說如果service需要很多耗時(shí)或者阻塞的操作，需要在其子線程中實(shí)現(xiàn)。
service的兩種模式（startService()/bindService()不是完全分離的）：
本地服務(wù) Local Service 用于應(yīng)用程序內(nèi)部。
它可以啟動(dòng)并運(yùn)行，直至有人停止了它或它自己停止。在這種方式下，它以調(diào)用Context.startService()啟動(dòng)，而以調(diào)用Context.stopService()結(jié)束。它可以調(diào)用Service.stopSelf() 或 Service.stopSelfResult()來自己停止。不論調(diào)用了多少次startService()方法，你只需要調(diào)用一次stopService()來停止服務(wù)。
用于實(shí)現(xiàn)應(yīng)用程序自己的一些耗時(shí)任務(wù)，比如查詢升級(jí)信息，并不占用應(yīng)用程序比如Activity所屬線程，而是單開線程后臺(tái)執(zhí)行，這樣用戶體驗(yàn)比較好。
遠(yuǎn)程服務(wù) Remote Service 用于android系統(tǒng)內(nèi)部的應(yīng)用程序之間。
它可以通過自己定義并暴露出來的接口進(jìn)行程序操作?？蛻舳私⒁粋€(gè)到服務(wù)對(duì)象的連接，并通過那個(gè)連接來調(diào)用服務(wù)。連接以調(diào)用Context.bindService()方法建立，以調(diào)用 Context.unbindService()關(guān)閉。多個(gè)客戶端可以綁定至同一個(gè)服務(wù)。如果服務(wù)此時(shí)還沒有加載，bindService()會(huì)先加載它。
可被其他應(yīng)用程序復(fù)用，比如天氣預(yù)報(bào)服務(wù)，其他應(yīng)用程序不需要再寫這樣的服務(wù)，調(diào)用已有的即可。
生命周期
使用context.startService() 啟動(dòng)Service是會(huì)會(huì)經(jīng)歷:
context.startService() ->onCreate()- >onStart()->Service running
context.stopService() | ->onDestroy() ->Service stop
如果Service還沒有運(yùn)行，則android先調(diào)用onCreate()然后調(diào)用onStart()；如果Service已經(jīng)運(yùn)行，則只調(diào)用onStart()，所以一個(gè)Service的onStart方法可能會(huì)重復(fù)調(diào)用多次。
stopService的時(shí)候直接onDestroy，如果是調(diào)用者自己直接退出而沒有調(diào)用stopService的話，Service會(huì)一直在后臺(tái)運(yùn)行。該Service的調(diào)用者再啟動(dòng)起來后可以通過stopService關(guān)閉Service。
所以調(diào)用startService的生命周期為：onCreate --> onStart(可多次調(diào)用) --> onDestroy
使用使用context.bindService()啟動(dòng)Service會(huì)經(jīng)歷：
context.bindService()->onCreate()->onBind()->Service running
onUnbind() -> onDestroy() ->Service stop
onBind將返回給客戶端一個(gè)IBind接口實(shí)例，IBind允許客戶端回調(diào)服務(wù)的方法，比如得到Service運(yùn)行的狀態(tài)或其他操作。這個(gè)時(shí)候把調(diào)用者（Context，例如Activity）會(huì)和Service綁定在一起，Context退出了，Srevice就會(huì)調(diào)用onUnbind->onDestroy相應(yīng)退出。
所以調(diào)用bindService的生命周期為：onCreate --> onBind(只一次，不可多次綁定) --> onUnbind --> onDestory。
在Service每一次的開啟關(guān)閉過程中，只有onStart可被多次調(diào)用(通過多次startService調(diào)用)，其他onCreate，onBind，onUnbind，onDestory在一個(gè)生命周期中只能被調(diào)用一次。
而啟動(dòng)service，根據(jù)onStartCommand的返回值不同，有兩個(gè)附加的模式：
1. START_STICKY 用于顯示啟動(dòng)和停止service。
2. START_NOT_STICKY或START_REDELIVER_INTENT用于有命令需要處理時(shí)才運(yùn)行的模式。
服務(wù)不能自己運(yùn)行，需要通過調(diào)用Context.startService()或Context.bindService()方法啟動(dòng)服務(wù)。這兩個(gè)方法都可以啟動(dòng)Service，但是它們的使用場(chǎng)合有所不同。
1. 使用startService()方法啟用服務(wù)，調(diào)用者與服務(wù)之間沒有關(guān)連，即使調(diào)用者退出了，服務(wù)仍然運(yùn)行。
如果打算采用Context.startService()方法啟動(dòng)服務(wù)，在服務(wù)未被創(chuàng)建時(shí)，系統(tǒng)會(huì)先調(diào)用服務(wù)的onCreate()方法，接著調(diào)用onStart()方法。
如果調(diào)用startService()方法前服務(wù)已經(jīng)被創(chuàng)建，多次調(diào)用startService()方法并不會(huì)導(dǎo)致多次創(chuàng)建服務(wù)，但會(huì)導(dǎo)致多次調(diào)用onStart()方法。
采用startService()方法啟動(dòng)的服務(wù)，只能調(diào)用Context.stopService()方法結(jié)束服務(wù)，服務(wù)結(jié)束時(shí)會(huì)調(diào)用onDestroy()方法。
2. 使用bindService()方法啟用服務(wù)，調(diào)用者與服務(wù)綁定在了一起，調(diào)用者一旦退出，服務(wù)也就終止，大有“不求同時(shí)生，必須同時(shí)死”的特點(diǎn)。
onBind()只有采用Context.bindService()方法啟動(dòng)服務(wù)時(shí)才會(huì)回調(diào)該方法。該方法在調(diào)用者與服務(wù)綁定時(shí)被調(diào)用，當(dāng)調(diào)用者與服務(wù)已經(jīng)綁定，多次調(diào)用Context.bindService()方法并不會(huì)導(dǎo)致該方法被多次調(diào)用。
采用Context.bindService()方法啟動(dòng)服務(wù)時(shí)只能調(diào)用onUnbind()方法解除調(diào)用者與服務(wù)解除，服務(wù)結(jié)束時(shí)會(huì)調(diào)用onDestroy()方法。
看看官方給出的比較流程示意圖：
官方文檔告訴我們，一個(gè)service可以同時(shí)start并且bind，在這樣的情況，系統(tǒng)會(huì)一直保持service的運(yùn)行狀態(tài)如果service已經(jīng)start了或者BIND_AUTO_CREATE標(biāo)志被設(shè)置。如果沒有一個(gè)條件滿足，那么系統(tǒng)將會(huì)調(diào)用onDestory方法來終止service.所有的清理工作（終止線程，反注冊(cè)接收器）都在onDestory中完成。
擁有service的進(jìn)程具有較高的優(yōu)先級(jí)
官方文檔告訴我們，Android系統(tǒng)會(huì)盡量保持擁有service的進(jìn)程運(yùn)行，只要在該service已經(jīng)被啟動(dòng)(start)或者客戶端連接(bindService)到它。當(dāng)內(nèi)存不足時(shí)，需要保持，擁有service的進(jìn)程具有較高的優(yōu)先級(jí)。
1． 如果service正在調(diào)用onCreate,onStartCommand或者onDestory方法，那么用于當(dāng)前service的進(jìn)程則變?yōu)榍芭_(tái)進(jìn)程以避免被killed。
2． 如果當(dāng)前service已經(jīng)被啟動(dòng)(start)，擁有它的進(jìn)程則比那些用戶可見的進(jìn)程優(yōu)先級(jí)低一些，但是比那些不可見的進(jìn)程更重要，這就意味著service一般不會(huì)被killed.
3． 如果客戶端已經(jīng)連接到service (bindService),那么擁有Service的進(jìn)程則擁有最高的優(yōu)先級(jí)，可以認(rèn)為service是可見的。
4． 如果service可以使用startForeground(int, Notification)方法來將service設(shè)置為前臺(tái)狀態(tài)，那么系統(tǒng)就認(rèn)為是對(duì)用戶可見的，并不會(huì)在內(nèi)存不足時(shí)killed。
如果有其他的應(yīng)用組件作為Service,Activity等運(yùn)行在相同的進(jìn)程中，那么將會(huì)增加該進(jìn)程的重要性。
本地service
1.不需和Activity交互的本地服務(wù)
- public class LocalService extends Service {
- private static final String TAG = "LocalService";
- @Override
- public IBinder onBind(Intent intent) {
- Log.i(TAG, "onBind");
- return null;
- }
- @Override
- public void onCreate() {
- Log.i(TAG, "onCreate");
- super.onCreate();
- }
- @Override
- public void onDestroy() {
- Log.i(TAG, "onDestroy");
- super.onDestroy();
- }
- @Override
- public void onStart(Intent intent, int startId) {
- Log.i(TAG, "onStart");
- super.onStart(intent, startId);
- }
- }
- public class ServiceActivity extends Activity {
- @Override
- protected void onCreate(Bundle savedInstanceState) {
- super.onCreate(savedInstanceState);
- setContentView(R.layout.servicedemo);
- ((Button) findViewById(R.id.startLocalService)).setOnClickListener(
- new View.OnClickListener(){
- @Override
- public void onClick(View view) {
- // TODO Auto-generated method stub
- startService(new Intent("com.demo.SERVICE_DEMO"));
- }
- });
- ((Button) findViewById(R.id.stopLocalService)).setOnClickListener(
- new View.OnClickListener(){
- @Override
- public void onClick(View view) {
- // TODO Auto-generated method stub
- stopService(new Intent("com.demo.SERVICE_DEMO"));
- }
- });
- }
- }
- <service android:name=".LocalService">
- <intent-filter>
- <action android:name="com.demo.SERVICE_DEMO" />
- <category android:name="android.intent.category.default" />
- </intent-filter>
- </service>
對(duì)于這類不需和Activity交互的本地服務(wù)，是使用startService/stopService的最好例子。
運(yùn)行時(shí)可以發(fā)現(xiàn)第一次startService時(shí)，會(huì)調(diào)用onCreate和onStart，在沒有stopService前，無論點(diǎn)擊多少次startService，都只會(huì)調(diào)用onStart。而stopService時(shí)調(diào)用onDestroy。再次點(diǎn)擊stopService，會(huì)發(fā)現(xiàn)不會(huì)進(jìn)入service的生命周期的，即不會(huì)再調(diào)用onCreate，onStart和onDestroy。
而onBind在startService/stopService中沒有調(diào)用。
2.本地服務(wù)和Activity交互
對(duì)于這種case，官方的sample(APIDemo\app.LocalService)是最好的例子:
- /**
- * This is an example of implementing an application service that runs locally
- * in the same process as the application. The {@link LocalServiceController}
- * and {@link LocalServiceBinding} classes show how to interact with the
- * service.
- *
- * <p>Notice the use of the {@link NotificationManager} when interesting things
- * happen in the service. This is generally how background services should
- * interact with the user, rather than doing something more disruptive such as
- * calling startActivity().
- */
- public class LocalService extends Service {
- private NotificationManager mNM;
- /**
- * Class for clients to access. Because we know this service always
- * runs in the same process as its clients, we don't need to deal with
- * IPC.
- */
- public class LocalBinder extends Binder {
- LocalService getService() {
- return LocalService.this;
- }
- }
- @Override
- public void onCreate() {
- mNM = (NotificationManager)getSystemService(NOTIFICATION_SERVICE);
- // Display a notification about us starting. We put an icon in the status bar.
- showNotification();
- }
- @Override
- public int onStartCommand(Intent intent, int flags, int startId) {
- Log.i("LocalService", "Received start id " + startId + ": " + intent);
- // We want this service to continue running until it is explicitly
- // stopped, so return sticky.
- return START_STICKY;
- }
- @Override
- public void onDestroy() {
- // Cancel the persistent notification.
- mNM.cancel(R.string.local_service_started);
- // Tell the user we stopped.
- Toast.makeText(this, R.string.local_service_stopped, Toast.LENGTH_SHORT).show();
- }
- @Override
- public IBinder onBind(Intent intent) {
- return mBinder;
- }
- // This is the object that receives interactions from clients. See
- // RemoteService for a more complete example.
- private final IBinder mBinder = new LocalBinder();
- /**
- * Show a notification while this service is running.
- */
- private void showNotification() {
- // In this sample, we'll use the same text for the ticker and the expanded notification
- CharSequence text = getText(R.string.local_service_started);
- // Set the icon, scrolling text and timestamp
- Notification notification = new Notification(R.drawable.stat_sample, text,
- System.currentTimeMillis());
- // The PendingIntent to launch our activity if the user selects this notification
- PendingIntent contentIntent = PendingIntent.getActivity(this, 0,
- new Intent(this, LocalServiceController.class), 0);
- // Set the info for the views that show in the notification panel.
- notification.setLatestEventInfo(this, getText(R.string.local_service_label),
- text, contentIntent);
- // Send the notification.
- // We use a layout id because it is a unique number. We use it later to cancel.
- mNM.notify(R.string.local_service_started, notification);
- }
- }
1. 添加了一個(gè)public內(nèi)部類繼承Binder，并添加getService方法來返回當(dāng)前的Service對(duì)象；
2. 新建一個(gè)IBinder對(duì)象--new那個(gè)Binder內(nèi)部類；
3. onBind方法返還那個(gè)IBinder對(duì)象。
Activity:
- /**
- * <p>Example of binding and unbinding to the {@link LocalService}.
- * This demonstrates the implementation of a service which the client will
- * bind to, receiving an object through which it can communicate with the service.</p>
- */
- public class LocalServiceBinding extends Activity {
- private boolean mIsBound;
- private LocalService mBoundService;
- @Override
- protected void onCreate(Bundle savedInstanceState) {
- super.onCreate(savedInstanceState);
- setContentView(R.layout.local_service_binding);
- // Watch for button clicks.
- Button button = (Button)findViewById(R.id.bind);
- button.setOnClickListener(mBindListener);
- button = (Button)findViewById(R.id.unbind);
- button.setOnClickListener(mUnbindListener);
- }
- private ServiceConnection mConnection = new ServiceConnection() {
- public void onServiceConnected(ComponentName className, IBinder service) {
- // This is called when the connection with the service has been
- // established, giving us the service object we can use to
- // interact with the service. Because we have bound to a explicit
- // service that we know is running in our own process, we can
- // cast its IBinder to a concrete class and directly access it.
- mBoundService = ((LocalService.LocalBinder)service).getService();
- // Tell the user about this for our demo.
- Toast.makeText(LocalServiceBinding.this, R.string.local_service_connected,
- Toast.LENGTH_SHORT).show();
- }
- public void onServiceDisconnected(ComponentName className) {
- // This is called when the connection with the service has been
- // unexpectedly disconnected -- that is, its process crashed.
- // Because it is running in our same process, we should never
- // see this happen.
- mBoundService = null;
- Toast.makeText(LocalServiceBinding.this, R.string.local_service_disconnected,
- Toast.LENGTH_SHORT).show();
- }
- };
- private OnClickListener mBindListener = new OnClickListener() {
- public void onClick(View v) {
- // Establish a connection with the service. We use an explicit
- // class name because we want a specific service implementation that
- // we know will be running in our own process (and thus won't be
- // supporting component replacement by other applications).
- bindService(new Intent(LocalServiceBinding.this,
- LocalService.class), mConnection, Context.BIND_AUTO_CREATE);
- mIsBound = true;
- }
- };
- private OnClickListener mUnbindListener = new OnClickListener() {
- public void onClick(View v) {
- if (mIsBound) {
- // Detach our existing connection.
- unbindService(mConnection);
- mIsBound = false;
- }
- }
- };
- }
明顯看出這里面添加了一個(gè)名為ServiceConnection類，并實(shí)現(xiàn)了onServiceConnected(從IBinder獲取Service對(duì)象)和onServiceDisconnected(set Service to null)。
而bindService和unbindService方法都是操作這個(gè)ServiceConnection對(duì)象的。
AndroidManifest.xml里添加:
- <service android:name=".app.LocalService" />
運(yùn)行時(shí)，發(fā)現(xiàn)調(diào)用次序是這樣的：
bindService:
1.LocalService : onCreate
2.LocalService : onBind
3.Activity: onServiceConnected
unbindService: 只是調(diào)用onDestroy
可見，onStart是不會(huì)被調(diào)用的，而onServiceDisconnected沒有調(diào)用的原因在上面代碼的注釋有說明。
------------------------
三、Broadcast Receiver詳解
BroadcastReceiver 用于異步接收廣播Intent。主要有兩大類，用于接收廣播的：
·正常廣播 Normal broadcasts（用 Context.sendBroadcast()發(fā)送）是完全異步的。它們都運(yùn)行在一個(gè)未定義的順序，通常是在同一時(shí)間。這樣會(huì)更有效，但意味著receiver不能包含所要使用的結(jié)果或中止的API。
·有序廣播 Ordered broadcasts（用 Context.sendOrderedBroadcast()發(fā)送）每次被發(fā)送到一個(gè)receiver。所謂有序，就是每個(gè)receiver執(zhí)行后可以傳播到下一個(gè)receiver，也可以完全中止傳播--不傳播給其他receiver。 而receiver運(yùn)行的順序可以通過matched intent-filter 里面的android:priority來控制，當(dāng)priority優(yōu)先級(jí)相同的時(shí)候，Receiver以任意的順序運(yùn)行。
要注意的是，即使是Normal broadcasts，系統(tǒng)在某些情況下可能會(huì)恢復(fù)到一次傳播給一個(gè)receiver。 特別是receiver可能需要?jiǎng)?chuàng)建一個(gè)進(jìn)程，為了避免系統(tǒng)超載，只能一次運(yùn)行一個(gè)receiver。
Broadcast Receiver 并沒有提供可視化的界面來顯示廣播信息?？梢允褂肗otification和Notification Manager來實(shí)現(xiàn)可視化的信息的界面，顯示廣播信息的內(nèi)容，圖標(biāo)及震動(dòng)信息。
生命周期
一個(gè)BroadcastReceiver 對(duì)象只有在被調(diào)用onReceive(Context, Intent)的才有效的，當(dāng)從該函數(shù)返回后，該對(duì)象就無效的了，結(jié)束生命周期。
因此從這個(gè)特征可以看出，在所調(diào)用的onReceive(Context, Intent)函數(shù)里，不能有過于耗時(shí)的操作，不能使用線程來執(zhí)行。對(duì)于耗時(shí)的操作，請(qǐng)start service來完成。因?yàn)楫?dāng)?shù)玫狡渌惒讲僮魉祷氐慕Y(jié)果時(shí)，BroadcastReceiver 可能已經(jīng)無效了。
發(fā)送廣播
事件的廣播比較簡(jiǎn)單，構(gòu)建Intent對(duì)象，可調(diào)用sendBroadcast(Intent)方法將廣播發(fā)出。另外還有sendOrderedBroadcast()，sendStickyBroadcast()等方法，請(qǐng)查閱API Doc。
1.new Intent with action name
Intent intent = new Intent(String action);
或者 只是new Intent, 然后
intent.setAction(String action);
2.set data等準(zhǔn)備好了后，in activity,
sendBroadcast(Intent); // 發(fā)送廣播
接收廣播
通過定義一個(gè)繼承BroadcastReceiver類來實(shí)現(xiàn)，繼承該類后覆蓋其onReceiver方法，并在該方法中響應(yīng)事件。
- public class SMSReceiver extends BroadcastReceiver {
- @Override
- public void onReceive(Context context, Intent intent) {
- // get data from SMS intent
- Bundle bundle = intent.getExtras();
- if (bundle != null){
- // get message by "pdus"
- Object[] objArray = (Object[]) bundle.get("pdus");
- // rebuild SMS
- SmsMessage[] messages = new SmsMessage[objArray.length];
- for (int i=0; i < objArray.length; i++){
- messages[i] = SmsMessage.createFromPdu((byte[])objArray[i]);
- StringBuilder str = new StringBuilder("from: ");
- str.append(messages[i].getDisplayOriginatingAddress());
- str.append("\nmessage:\n");
- str.append(messages[i].getDisplayMessageBody());
- Toast.makeText(context, str.toString(), Toast.LENGTH_LONG)
- .show();
- }
- }
- }
- }
注冊(cè)有兩種方式：
1. 靜態(tài)方式，在AndroidManifest.xml的application里面定義receiver并設(shè)置要接收的action。
- <receiver android:name=".SMSReceiver">
- <intent-filter>
- <action android:name="android.provider.Telephony.SMS_RECEIVED" />
- </intent-filter>
- </receiver>
- public class HelloDemo extends Activity {
- private BroadcastReceiver receiver;
- @Override
- protected void onStart() {
- super.onStart();
- receiver = new CallReceiver();
- registerReceiver(receiver, new IntentFilter("android.intent.action.PHONE_STATE"));
- }
- @Override
- protected void onStop() {
- unregisterReceiver(receiver);
- super.onStop();
- }
- }
個(gè)人推薦使用靜態(tài)注冊(cè)方式，由系統(tǒng)來管理receiver，而且程序里的所有receiver，可以在xml里面一目了然。而動(dòng)態(tài)注冊(cè)方式，隱藏在代碼中，比較難發(fā)現(xiàn)。
而且動(dòng)態(tài)注冊(cè)，需要特別注意的是，在退出程序前要記得調(diào)用Context.unregisterReceiver()方法。一般在activity的onStart()里面進(jìn)行注冊(cè), onStop()里面進(jìn)行注銷。官方提醒，如果在Activity.onResume()里面注冊(cè)了，就必須在Activity.onPause()注銷。
Permission權(quán)限
要接收某些action，需要在AndroidManifest.xml里面添加相應(yīng)的permission。例如接收SMS:
- <uses-permission android:name="android.permission.RECEIVE_SMS" />
一種方式是直接讀取intent.getStringExtra("incoming_number")來獲取來電號(hào)碼：
- public class CallReceiver extends BroadcastReceiver {
- @Override
- public void onReceive(Context context, Intent intent) {
- TelephonyManager teleManager = (TelephonyManager) context.getSystemService(Context.TELEPHONY_SERVICE);
-
- switch(teleManager.getCallState()){
- case TelephonyManager.CALL_STATE_RINGING: //響鈴
- Toast.makeText(context, "Ringing: " + intent.getStringExtra("incoming_number"), Toast.LENGTH_LONG).show();
- break;
- case TelephonyManager.CALL_STATE_OFFHOOK: //接聽
- Toast.makeText(context, "OffHook: " + intent.getStringExtra("incoming_number"), Toast.LENGTH_LONG).show();
- break;
- case TelephonyManager.CALL_STATE_IDLE: //掛斷
- Toast.makeText(m_context, "Idle: " + incomingNumber, Toast.LENGTH_LONG).show();
- break;
- }
- }
- }
另一種方式是通過PhoneStateListener的onCallStateChanged來監(jiān)聽狀態(tài)的變化：
- public class CallReceiver extends BroadcastReceiver {
- private Context m_context;
- @Override
- public void onReceive(Context context, Intent intent) {
- m_context = context;
- TelephonyManager teleManager = (TelephonyManager) context.getSystemService(Context.TELEPHONY_SERVICE);
- teleManager.listen(new PhoneStateListener(){
- @Override
- public void onCallStateChanged(int state, String incomingNumber) {
- switch(state){
- case TelephonyManager.CALL_STATE_RINGING: //響鈴
- Toast.makeText(m_context, "Ringing: " + incomingNumber, Toast.LENGTH_LONG)
- .show();
- break;
- case TelephonyManager.CALL_STATE_OFFHOOK: //接聽
- Toast.makeText(m_context, "OffHook: " + incomingNumber, Toast.LENGTH_LONG)
- .show();
- break;
- case TelephonyManager.CALL_STATE_IDLE: //掛斷
- Toast.makeText(m_context, "Idle: " + incomingNumber, Toast.LENGTH_LONG)
- .show();
- break;
- }
- }}, PhoneStateListener.LISTEN_CALL_STATE);
- }
- }
因?yàn)檫@里監(jiān)聽的是通話的狀態(tài)變化，所以這個(gè)receiver會(huì)被調(diào)用3次。
監(jiān)聽通話狀態(tài)需要加上權(quán)限：
- <uses-permission android:name="android.permission.READ_PHONE_STATE"/>
小結(jié)：
1. 對(duì)于sendBroadCast的intent對(duì)象，需要設(shè)置其action name；
2. 推薦使用顯式指明receiver，在配置文件AndroidManifest.xml指明；
3. 一個(gè)receiver可以接收多個(gè)action;
4. 每次接收廣播都會(huì)重新生成一個(gè)接收廣播的對(duì)象，再次調(diào)用onReceive；
5. 在BroadCast 中盡量不要處理太多邏輯問題，建議復(fù)雜的邏輯交給Activity 或者 Service 去處理。
--------------------------------------------
四、Content Provider詳解
ContentProvider（內(nèi)容提供者）是Android中的四大組件之一。主要用于對(duì)外共享數(shù)據(jù)，也就是通過ContentProvider把應(yīng)用中的數(shù)據(jù)共享給其他應(yīng)用訪問，其他應(yīng)用可以通過ContentProvider對(duì)指定應(yīng)用中的數(shù)據(jù)進(jìn)行操作。ContentProvider分為系統(tǒng)的和自定義的，系統(tǒng)的也就是例如聯(lián)系人，圖片等數(shù)據(jù)。
android中對(duì)數(shù)據(jù)操作包含有：
file, sqlite3, Preferences, ContectResolver與ContentProvider前三種數(shù)據(jù)操作方式都只是針對(duì)本應(yīng)用內(nèi)數(shù)據(jù)，程序不能通過這三種方法去操作別的應(yīng)用內(nèi)的數(shù)據(jù)。
android中提供ContectResolver與ContentProvider來操作別的應(yīng)用程序的數(shù)據(jù)。
使用方式:
一個(gè)應(yīng)用實(shí)現(xiàn)ContentProvider來提供內(nèi)容給別的應(yīng)用來操作，
一個(gè)應(yīng)用通過ContentResolver來操作別的應(yīng)用數(shù)據(jù)，當(dāng)然在自己的應(yīng)用中也可以。
以下這段是Google Doc中對(duì)ContentProvider的大致概述:
內(nèi)容提供者將一些特定的應(yīng)用程序數(shù)據(jù)供給其它應(yīng)用程序使用。內(nèi)容提供者繼承于ContentProvider 基類，為其它應(yīng)用程序取用和存儲(chǔ)它管理的數(shù)據(jù)實(shí)現(xiàn)了一套標(biāo)準(zhǔn)方法。然而，應(yīng)用程序并不直接調(diào)用這些方法，而是使用一個(gè) ContentResolver 對(duì)象，調(diào)用它的方法作為替代。ContentResolver可以與任意內(nèi)容提供者進(jìn)行會(huì)話，與其合作來對(duì)所有相關(guān)交互通訊進(jìn)行管理。
1.ContentProvider
Android提供了一些主要數(shù)據(jù)類型的ContentProvider，比如音頻、視頻、圖片和私人通訊錄等?？稍赼ndroid.provider包下面找到一些Android提供的ContentProvider。通過獲得這些ContentProvider可以查詢它們包含的數(shù)據(jù)，當(dāng)然前提是已獲得適當(dāng)?shù)淖x取權(quán)限。
主要方法：
public boolean onCreate() 在創(chuàng)建ContentProvider時(shí)調(diào)用
public Cursor query(Uri, String[], String, String[], String) 用于查詢指定Uri的ContentProvider，返回一個(gè)Cursor
public Uri insert(Uri, ContentValues) 用于添加數(shù)據(jù)到指定Uri的ContentProvider中
public int update(Uri, ContentValues, String, String[]) 用于更新指定Uri的ContentProvider中的數(shù)據(jù)
public int delete(Uri, String, String[]) 用于從指定Uri的ContentProvider中刪除數(shù)據(jù)
public String getType(Uri) 用于返回指定的Uri中的數(shù)據(jù)的MIME類型
*如果操作的數(shù)據(jù)屬于集合類型，那么MIME類型字符串應(yīng)該以vnd.android.cursor.dir/開頭。
例如：要得到所有person記錄的Uri為content://contacts/person，那么返回的MIME類型字符串為"vnd.android.cursor.dir/person"。
*如果要操作的數(shù)據(jù)屬于非集合類型數(shù)據(jù)，那么MIME類型字符串應(yīng)該以vnd.android.cursor.item/開頭。
例如：要得到id為10的person記錄的Uri為content://contacts/person/10，那么返回的MIME類型字符串應(yīng)為"vnd.android.cursor.item/person"。
2.ContentResolver
當(dāng)外部應(yīng)用需要對(duì)ContentProvider中的數(shù)據(jù)進(jìn)行添加、刪除、修改和查詢操作時(shí)，可以使用ContentResolver類來完成，要獲取ContentResolver對(duì)象，可以使用Context提供的getContentResolver()方法。
ContentResolver cr = getContentResolver();
ContentResolver提供的方法和ContentProvider提供的方法對(duì)應(yīng)的有以下幾個(gè)方法。
public Uri insert(Uri uri, ContentValues values) 用于添加數(shù)據(jù)到指定Uri的ContentProvider中。
public int delete(Uri uri, String selection, String[] selectionArgs) 用于從指定Uri的ContentProvider中刪除數(shù)據(jù)。
public int update(Uri uri, ContentValues values, String selection, String[] selectionArgs) 用于更新指定Uri的ContentProvider中的數(shù)據(jù)。
public Cursor query(Uri uri, String[] projection, String selection, String[] selectionArgs, String sortOrder) 用于查詢指定Uri的ContentProvider。
3.Uri
Uri指定了將要操作的ContentProvider，其實(shí)可以把一個(gè)Uri看作是一個(gè)網(wǎng)址，我們把Uri分為三部分。
第一部分是"content://"。可以看作是網(wǎng)址中的"http://"。
第二部分是主機(jī)名或authority，用于唯一標(biāo)識(shí)這個(gè)ContentProvider，外部應(yīng)用需要根據(jù)這個(gè)標(biāo)識(shí)來找到它?？梢钥醋魇蔷W(wǎng)址中的主機(jī)名，比如"blog.csdn.net"。
第三部分是路徑名，用來表示將要操作的數(shù)據(jù)?？梢钥醋骶W(wǎng)址中細(xì)分的內(nèi)容路徑。
---------------------------------
本站僅提供存儲(chǔ)服務(wù)，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請(qǐng)
點(diǎn)擊舉報(bào)。
