Android跨進程通信 Binder AIDL 知識點總結

一匈勋、IPC跨進程通訊的四種方式

Android系統(tǒng)中應用程序之間不能共享內(nèi)存若皱,在android SDK中提供了4種用于跨進程通訊的方式兔毙。這4種方式正好對應于android系統(tǒng)中4種應用程序組件:Activity、Content Provider渴邦、Broadcast和Service疯趟。

1、Activity可以跨進程調(diào)用其他應用程序的Activity几莽。

進程內(nèi)(同一個應用程序)
跨進程訪問

2迅办、Content Provider可以跨進程訪問其他應用程序中的數(shù)據(jù)(以Cursor對象形式返回)

Content Provider存在的目的向其他應用程序共享數(shù)據(jù)和允許其他應用程序?qū)?shù)據(jù)進行增、刪章蚣、改操作

3站欺、Broadcast可以向android系統(tǒng)中所有應用程序發(fā)送廣播,而需要跨進程通訊的應用程序可以監(jiān)聽這些廣播

廣播(Broadcast):廣播是一種被動跨進程通訊的方式纤垂。當某個程序向系統(tǒng)發(fā)送廣播時矾策,其他的應用程序只能被動地接收廣播數(shù)據(jù)

發(fā)送一條廣播
接收廣播: 繼承BroadcastReceiver
接收者在Manifest文件中寫明要接收的廣播

4、Service返回的是Java對象峭沦,這種可以跨進程通訊的服務叫AIDL服務贾虽。

二、AIDL(Android Interface Definition Language Android接口定義語言)

三吼鱼、Service Binder

1蓬豁,什么是service?

Service是一個可以在后臺執(zhí)行長時間操作而不使用用戶界面的應用組件绰咽。既然它不使用用戶界面,那么它怎么知道應該什么時候開始執(zhí)行什么操作呢地粪?答案是——它可以與其他的引用組件形成一些聯(lián)系取募,從而可以根據(jù)其傳來的信息在合適的時候執(zhí)行合適的操作。
一般來講蟆技,這種聯(lián)系分為兩種:startService()以及bindService()玩敏。這兩種聯(lián)系都可以使得一個service開始運行,但是在其他方面有著諸多不同质礼,看一下對比:

(1)啟動service的方式:

startService :在其他組件中調(diào)用startService()方法后旺聚,服務即處于啟動狀態(tài)
bindService:在其他組件中調(diào)用bindService()方法后,服務即處于啟動狀態(tài)

(2)停止service的方式:

startService :service中調(diào)用stopSelf()方法眶蕉,或者其他組件調(diào)用stopService()方法后砰粹,service將停止運行
bindService:所有與service綁定的組件都被銷毀,或者它們都調(diào)用了unbindService()方法后妻坝,service將停止運行

(3)service與啟動它的組件之間的通信方式:
startService :沒有提供默認的通信方式伸眶,啟動service后該service就處于獨立運行狀態(tài)
bindService:可以通過 ServiceConnection進行通信,組件可以與service進行交互刽宪、發(fā)送請求、獲取結果界酒,甚至是利用IPC跨進程執(zhí)行這些操作

(4)service的生命周期
startService :一旦啟動圣拄,service即可在后臺無限期運行,即使啟動service的組件已被銷毀也不受其影響毁欣,直到其被停止
onCreate() - onStartCommand() - onDestory()

bindService: 當所有與其綁定的組件都取消綁定(可能是組件被銷毀也有可能是其調(diào)用了unbindService()方法后庇谆,service將停止
onCreate() - onBind() - onUnbind() - onDestory()

注: 1.以上“其他組件”不包括Broadcast receiver,其無法直接啟動或綁定service凭疮。 2.startService()與bindService()并不沖突饭耳,同一個service可能既有組件調(diào)用了startService()啟動它,又有組件與它進行了綁定执解。當同一個service與其他組件同時存在這兩種聯(lián)系時寞肖,其生命周期會發(fā)生變化,必須從兩種方法的角度看service均停止才能真正停止衰腌。

2新蟆,如何創(chuàng)建一個service?

創(chuàng)建一個類繼承自Service(或它的子類右蕊,如IntentService)琼稻,重寫里面的一些關鍵的回調(diào)方法,如onStartCommand()饶囚,onBind()等
在Manifests文件里面為其聲明帕翻,并根據(jù)需要配置一些其他屬性鸠补。

講道理,這一切跟新建一個Activity灰常的像嘀掸,跟孿生兄弟一樣——包括其里面的一些關鍵方法莫鸭,都充斥著一種濃濃的基情。
onCreate() 在每個service的生命周期中這個方法會且僅會調(diào)用一次横殴,并且它的調(diào)用在onStartCommand()以及onBind()之前被因,我們可以在這個方法中進行一些一次性的初始化工作。

onStartCommand() 當其他組件通過startService()方法啟動service時衫仑,此方法將會被調(diào)用梨与。

onBind() 當其他組件通過bindService()方法與service相綁定之后,此方法將會被調(diào)用文狱。這個方法有一個IBinder的返回值粥鞋,這意味著在重寫它的時候必須返回一個IBinder對象,它是用來支撐其他組件與service之間的通信的——另外瞄崇,如果你不想讓這個service被其他組件所綁定呻粹,可以通過在這個方法返回一個null值來實現(xiàn)。

onDestroy() 這是service一生中調(diào)用的最后一個方法苏研,當這個方法被調(diào)用之后等浊,service就會被銷毀。所以我們應當在這個方法里面進行一些資源的清理摹蘑,比如注冊的一些監(jiān)聽器什么的筹燕。

在Manifests文件里進行聲明的時候,只有android:name屬性是必須要有的衅鹿,其他的屬性都可以沒有撒踪。但是有的時候適當?shù)呐渲每梢宰屛覀兊拈_發(fā)進行地更加順利,所以了解一下注冊一個service可以聲明哪些屬性也是很有必要的大渤。

<service android:enabled=["true" | "false"]
    android:exported=["true" | "false"] 
    android:icon="drawable resource" 
    android:isolatedProcess=["true" | "false"] 
    android:label="string resource"
    android:name="string" 
    android:permission="string" 
    android:process="string" >
</service>

android:enabled : 如果為true制妄,則這個service可以被系統(tǒng)實例化,如果為false泵三,則不行耕捞。默認為true

android:exported : 如果為true,則其他應用的組件也可以調(diào)用這個service并且可以與它進行互動切黔,如果為false砸脊,則只有與service同一個應用或者相同user ID的應用可以開啟或綁定此service。它的默認值取決于service是否有intent filters纬霞。如果一個filter都沒有凌埂,就意味著只有指定了service的準確的類名才能調(diào)用,也就是說這個service只能應用內(nèi)部使用——其他的應用不知道它的類名诗芜。這種情況下exported的默認值就為false瞳抓。反之埃疫,只要有了一個filter,就意味著service是考慮到外界使用的情況的孩哑,這時exported的默認值就為true

android:icon : 一個象征著這個service的icon

android:isolatedProcess : 如果設置為true栓霜,這個service將運行在一個從系統(tǒng)中其他部分分離出來的特殊進程中,我們只能通過Service API來與它進行交流横蜒。默認為false胳蛮。

android:label : 顯示給用戶的這個service的名字。如果不設置丛晌,將會默認使用<application>的label屬性仅炊。

android:name : 這個service的路徑名,例如“com.lypeer.demo.MyService”澎蛛。這個屬性是唯一一個必須填的屬性抚垄。

android:permission : 其他組件必須具有所填的權限才能啟動這個service。

android:process : service運行的進程的name谋逻。默認啟動的service是運行在主進程中的呆馁。

下面是一個例子:

public class ServiceDemo extends Service { 
    private static final String TAG = "ServiceDome";
    @Override
    public void onCreate() {
        super.onCreate();
        Log.d(TAG, "onCreate");
       //只在service創(chuàng)建的時候調(diào)用一次,可以在此進行一些一次性的初始化操作 
     } 

    @Override
    public int onStartCommand(Intent intent, int flags, int startId) { 
       Log.d(TAG, "onStartCommand");
      //當其他組件調(diào)用startService()方法時毁兆,此方法將會被調(diào)用
      //在這里進行這個service主要的操作 
      return super.onStartCommand(intent, flags, startId); 
    }

     @Nullable
     @Override public IBinder onBind(Intent intent) { 
         Log.d(TAG, "onBind"); 
        //當其他組件調(diào)用bindService()方法時浙滤,此方法將會被調(diào)用
        //如果不想讓這個service被綁定,在此返回null即可
        return null;
      }
     @Override
     public void onDestroy() {
         Log.d(TAG, "onDestroy");
         //service調(diào)用的最后一個方法
        //在此進行資源的回收        
        super.onDestroy();
    }
}

<!--in manifests --><service android:name=".ServiceDemo"/>

3荧恍,如何啟動service瓷叫?

前面講了兩種啟動service的方式,但是都講的比較概括送巡,這里就詳細的講一下這兩種方式。

3.1盒卸,startService()

另一個組件通過調(diào)用startService()方法骗爆,就可以啟動一個特定的service,并且這將導致service中的onStartCommand()方法被調(diào)用蔽介。

在調(diào)用startService()方法的時候摘投,其他組件需要在方法中傳遞一個intent參數(shù),然后service將會在onStartCommand()中接收這個intent虹蓄,并獲取一些數(shù)據(jù)犀呼。

比如此時某個Activity要將一些數(shù)據(jù)存入數(shù)據(jù)庫中,我就可以通過intent把數(shù)據(jù)傳入service薇组,然后讓service去進行連接數(shù)據(jù)庫外臂,存儲數(shù)據(jù)等操作,而此時用戶可以執(zhí)行其他的任何操作——甚至包括銷毀那個Activity——這并不會影響service存儲數(shù)據(jù)這件事律胀。

當一個service通過這種方式啟動之后宋光,它的生命周期就已經(jīng)不受啟動它的組件影響了貌矿,它可以在后臺無限期的運行下去,只要service自身沒有調(diào)用stopSelf()并且其他的組件沒有調(diào)用針對它的stopService()罪佳。

另外逛漫,如果確定了使用這種方式啟動service并且不希望這個service被綁定的話,那么也許除了傳統(tǒng)的創(chuàng)建一個類繼承service之外我們有一個更好的選擇——繼承IntentService赘艳。

如果是擴建Service類的話酌毡,通常情況下我們需要新建一個用于執(zhí)行工作的新線程,因為默認情況下service將工作于應用的主線程蕾管,而這將會降低所有正在運行的Activity的性能枷踏。而IntentService就不同了。它是Service的子類娇掏,它使用工作線程來注意的處理所有的startService請求呕寝。如果你不要求這個service要同時處理多個請求,那么繼承這個類顯然要比直接繼承Service好到不知道哪里去了婴梧。(感覺跟HandlerThread似的)

IntentService已經(jīng)做了這些事:

(1)創(chuàng)建默認的工作線程下梢,用于在應用的主線程外執(zhí)行傳遞給 onStartCommand() 的所有 Intent
(2)創(chuàng)建工作隊列,用于將一個 Intent 逐一傳遞給 onHandleIntent() 實現(xiàn)塞蹭,這樣的話就永遠不必擔心多線程問題了
(3)在處理完所有啟動請求后停止服務孽江,從此媽媽再也不用擔心我忘記調(diào)用 stopSelf() 了
(4)提供 onBind() 的默認實現(xiàn)(返回 null)
(4)提供 onStartCommand() 的默認實現(xiàn),可將 Intent 依次發(fā)送到工作隊列和 onHandleIntent() 實現(xiàn)

因此我們只需要實現(xiàn)onHandleIntent()方法來完成具體的功能邏輯就可以了番电。例如:

// 現(xiàn)在在一個Activity里面
Intent intent = new Intent(MainActivity.this, IntentServiceDemo.class);
startService(intent);

public class IntentServiceDemo extends IntentService { 
    public IntentServiceDemo(String name) { 
    super(name); 
    //構造方法
 } 
@Override
 protected void onHandleIntent(Intent intent) {
 //在這里根據(jù)intent進行操作
 }
}

相比上面的繼承service實現(xiàn)岗屏,這個確實要簡單許多。但是要注意的是漱办,如果需要重寫其他的方法这刷,比如onDestroy()方法,一定不要刪掉它的父類實現(xiàn)娩井!因為它的父類實現(xiàn)里面也許包括了對工作線程還有工作隊列的初始化以及銷毀等操作暇屋,如果沒有了的話很容易出問題。

但是洞辣,如果你有讓service同時處理多個請求的需求咐刨,這個時候就只能去繼承Service了。這個時候就要自己去處理工作線程那些事扬霜。下面是一個官方的例子:

public class HelloService extends Service {
  private Looper mServiceLooper;
  private ServiceHandler mServiceHandler;

  private final class ServiceHandler extends Handler {
      public ServiceHandler(Looper looper) {
          super(looper);
      }
      @Override
      public void handleMessage(Message msg) {
          long endTime = System.currentTimeMillis() + 5*1000;
          while (System.currentTimeMillis() < endTime) {
              synchronized (this) {
                  try {
                      wait(endTime - System.currentTimeMillis());
                  } catch (Exception e) {
                  }
              }
          }
          stopSelf(msg.arg1);
      }
  }

  @Override
  public void onCreate() {
    HandlerThread thread = new     HandlerThread("ServiceStartArguments",
        Process.THREAD_PRIORITY_BACKGROUND);
    thread.start();
    mServiceLooper = thread.getLooper();
    mServiceHandler = new ServiceHandler(mServiceLooper);
  }

  @Override
  public int onStartCommand(Intent intent, int flags, int startId) {
      Toast.makeText(this, "service starting",    Toast.LENGTH_SHORT).show();

      Message msg = mServiceHandler.obtainMessage();
      msg.arg1 = startId;
      mServiceHandler.sendMessage(msg);

      return START_STICKY;
  }

  @Override
  public IBinder onBind(Intent intent) {
      return null;
  }

  @Override
  public void onDestroy() {
    Toast.makeText(this, "service done",     Toast.LENGTH_SHORT).show();
  }
}

比起IntentService來定鸟,顯然做的工作要多的多的多。但是著瓶,由于是自己處理的對onStartCommand的調(diào)用联予,它可以同時執(zhí)行多個請求——雖然官方的栗子里沒有這樣做。但是如果你想這樣做,就可以為每一個請求創(chuàng)建一個線程躯泰,然后立即運行這些請求谭羔。

另外,我們注意到onStartCommand()的返回值是一個很奇怪的值START_STICKY麦向,這是個什么呢瘟裸?或者說這個方法的返回值是用來干嘛的呢?

事實上诵竭,它的返回值是用來指定系統(tǒng)對當前線程的行為的话告。它的返回值必須是以下常量之一:

(1)START_NOT_STICKY : 如果系統(tǒng)在 onStartCommand() 返回后終止服務,則除非有掛起 Intent 要傳遞卵慰,否則系統(tǒng)不會重建服務沙郭。這是最安全的選項,可以避免在不必要時以及應用能夠輕松重啟所有未完成的作業(yè)時運行服務裳朋。

(2)START_STICKY : 如果系統(tǒng)在 onStartCommand() 返回后終止服務病线,則會重建服務并調(diào)用 onStartCommand(),但絕對不會重新傳遞最后一個 Intent鲤嫡。相反送挑,除非有掛起 Intent 要啟動服務(在這種情況下,將傳遞這些 Intent )暖眼,否則系統(tǒng)會通過空 Intent 調(diào)用 onStartCommand()惕耕。這適用于不執(zhí)行命令、但無限期運行并等待作業(yè)的媒體播放器(或類似服務)诫肠。

(3)START_REDELIVER_INTENT : 如果系統(tǒng)在 onStartCommand() 返回后終止服務司澎,則會重建服務,并通過傳遞給服務的最后一個 Intent 調(diào)用 onStartCommand()栋豫。任何掛起 Intent 均依次傳遞挤安。這適用于主動執(zhí)行應該立即恢復的作業(yè)(例如下載文件)的服務。

除此之外丧鸯,繼承service來實現(xiàn)的service漱受,一定要記得,停止這個service骡送。因為除非系統(tǒng)必須回收內(nèi)存資源,否則系統(tǒng)不會停止或銷毀service絮记。事實上摔踱,如果這個service是與可見組件綁定,其幾乎永遠不會被停止或銷毀怨愤。在這種情況下派敷,如果你忘記了在其工作完成之后將其停止,勢必會造成系統(tǒng)資源的浪費以及電池電量的消耗,而這應當是我們要極力避免的篮愉。

3.2腐芍,bindService()

這是一種比startService更復雜的啟動方式,同時使用這種方式啟動的service也能完成更多的事情试躏,比如其他組件可向其發(fā)送請求猪勇,接受來自它的響應,甚至通過它來進行IPC等等颠蕴。我們通常將綁定它的組件成為客戶端泣刹,而稱它為服務器。

如果要創(chuàng)建一個支持綁定的service犀被,我們必須要重寫它的onBind()方法椅您。這個方法會返回一個IBinder對象,它是客戶端用來和服務器進行交互的接口寡键。而要得到IBinder接口掀泳,我們通常有三種方式:繼承Binder類,使用Messenger類西轩,使用AIDL员舵。

這三種方式也是各有各的好處以及缺點,更多的講解將放在下一篇博客中進行遭商。http://blog.csdn.net/luoyanglizi/article/details/51594016

參考:
http://blog.csdn.net/luoyanglizi/article/details/51980630
http://blog.csdn.net/luoyanglizi/article/details/51594016

最后編輯于
?著作權歸作者所有,轉載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末固灵,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子劫流,更是在濱河造成了極大的恐慌巫玻,老刑警劉巖,帶你破解...
    沈念sama閱讀 212,599評論 6 492
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件祠汇,死亡現(xiàn)場離奇詭異仍秤,居然都是意外死亡,警方通過查閱死者的電腦和手機可很,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 90,629評論 3 385
  • 文/潘曉璐 我一進店門诗力,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人我抠,你說我怎么就攤上這事苇本。” “怎么了菜拓?”我有些...
    開封第一講書人閱讀 158,084評論 0 348
  • 文/不壞的土叔 我叫張陵瓣窄,是天一觀的道長。 經(jīng)常有香客問我纳鼎,道長俺夕,這世上最難降的妖魔是什么裳凸? 我笑而不...
    開封第一講書人閱讀 56,708評論 1 284
  • 正文 為了忘掉前任,我火速辦了婚禮劝贸,結果婚禮上姨谷,老公的妹妹穿的比我還像新娘。我一直安慰自己映九,他們只是感情好梦湘,可當我...
    茶點故事閱讀 65,813評論 6 386
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著氯迂,像睡著了一般践叠。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上嚼蚀,一...
    開封第一講書人閱讀 50,021評論 1 291
  • 那天禁灼,我揣著相機與錄音,去河邊找鬼轿曙。 笑死弄捕,一個胖子當著我的面吹牛,可吹牛的內(nèi)容都是我干的导帝。 我是一名探鬼主播守谓,決...
    沈念sama閱讀 39,120評論 3 410
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼您单!你這毒婦竟也來了斋荞?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 37,866評論 0 268
  • 序言:老撾萬榮一對情侶失蹤虐秦,失蹤者是張志新(化名)和其女友劉穎平酿,沒想到半個月后,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體悦陋,經(jīng)...
    沈念sama閱讀 44,308評論 1 303
  • 正文 獨居荒郊野嶺守林人離奇死亡蜈彼,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 36,633評論 2 327
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了俺驶。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片幸逆。...
    茶點故事閱讀 38,768評論 1 341
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖暮现,靈堂內(nèi)的尸體忽然破棺而出还绘,到底是詐尸還是另有隱情,我是刑警寧澤栖袋,帶...
    沈念sama閱讀 34,461評論 4 333
  • 正文 年R本政府宣布蚕甥,位于F島的核電站,受9級特大地震影響栋荸,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 40,094評論 3 317
  • 文/蒙蒙 一晌块、第九天 我趴在偏房一處隱蔽的房頂上張望爱沟。 院中可真熱鬧,春花似錦匆背、人聲如沸呼伸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,850評論 0 21
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽括享。三九已至,卻和暖如春珍促,著一層夾襖步出監(jiān)牢的瞬間铃辖,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 32,082評論 1 267
  • 我被黑心中介騙來泰國打工猪叙, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留娇斩,地道東北人。 一個月前我還...
    沈念sama閱讀 46,571評論 2 362
  • 正文 我出身青樓穴翩,卻偏偏與公主長得像犬第,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子芒帕,可洞房花燭夜當晚...
    茶點故事閱讀 43,666評論 2 350

推薦閱讀更多精彩內(nèi)容