Android中Binder詳細(xì)學(xué)習(xí)心得

該文章是一個(gè)系列文章,是本人在Android開(kāi)發(fā)的漫漫長(zhǎng)途上的一點(diǎn)感想和記錄,我會(huì)盡量按照先易后難的順序進(jìn)行編寫(xiě)該系列。該系列引用了《Android開(kāi)發(fā)藝術(shù)探索》以及《深入理解Android 卷Ⅰ,Ⅱ,Ⅲ》中的相關(guān)知識(shí),另外也借鑒了其他的優(yōu)質(zhì)博客,在此向各位大神表示感謝,膜拜?。?!另外,本系列文章知識(shí)可能需要有一定Android開(kāi)發(fā)基礎(chǔ)和項(xiàng)目經(jīng)驗(yàn)的同學(xué)才能更好理解,也就是說(shuō)該系列文章面向的是Android中高級(jí)開(kāi)發(fā)工程師。

成都創(chuàng)新互聯(lián)公司主營(yíng)阿魯科爾沁網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營(yíng)網(wǎng)站建設(shè)方案,app軟件開(kāi)發(fā)公司,阿魯科爾沁h(yuǎn)5小程序設(shè)計(jì)搭建,阿魯科爾沁網(wǎng)站營(yíng)銷推廣歡迎阿魯科爾沁等地區(qū)企業(yè)咨詢

前言

上一次還不如不說(shuō)去面試了呢,估計(jì)是掛了,數(shù)據(jù)結(jié)構(gòu)與算法方面雖然面試前突擊了一波,但是時(shí)間太短,當(dāng)時(shí)學(xué)的也不好。另外Android的一些知識(shí)也不是很了解。不過(guò)這也加大了我寫(xiě)博客的動(dòng)力。許多知識(shí)總覺(jué)得自己掌握的還挺好,不過(guò)一問(wèn)到比較細(xì)節(jié)的方面就不太清楚了。所以寫(xiě)這整個(gè)博客的目的也是加深自己的知識(shí),培養(yǎng)自己的溝通能力,和大家一起學(xué)習(xí)吧。
好了,閑話少說(shuō),我們這一篇先解決上一篇中遺留的問(wèn)題,之后有時(shí)間的話,我把這次的面試經(jīng)歷單寫(xiě)一篇博客,和大家共勉。
本篇我們來(lái)看一下ServiceManager。上一篇中沒(méi)怎么說(shuō)它,ServiceManager作為Android系統(tǒng)服務(wù)的大管家。我們還是有必要來(lái)看一下它的。

ServiceManager概述

ServiceManager是Android世界中所有重要系統(tǒng)服務(wù)的大管家。像前文提到的AMS(ActivityManagerService),還有許多以后可能分析到的PackageManagerService等等服務(wù)都需要像ServiceManager中注冊(cè)。那么為何需要一個(gè)ServiceManager呢,其重要作用何在呢?私認(rèn)為有以下幾點(diǎn):

ServiceManager能集中管理系統(tǒng)內(nèi)的所有服務(wù),它能施加權(quán)限控制,并不是任何進(jìn)程都能注冊(cè)服務(wù)的。 ServiceManager支持通過(guò)字符串名稱來(lái)查找對(duì)應(yīng)的Service。這個(gè)功能很像DNS。由于各種原因的影響,Server進(jìn)程可能生死無(wú)常。 如果讓每個(gè)Client都去檢測(cè),壓力實(shí)在太大了。 現(xiàn)在有了統(tǒng)一的管理機(jī)構(gòu),Client只需要查詢ServiceManager,就能把握動(dòng)向,得到最新信息。

ServiceManager

[SystemServer.java]

public void setSystemProcess() {
  try {
    //注冊(cè)服務(wù),第二個(gè)參數(shù)為this,這里假設(shè)SystemServer通過(guò)“socket”與SM交互
    ServiceManager.addService(Context.ACTIVITY_SERVICE, this, true);
    ..........
  } catch (PackageManager.NameNotFoundException e) {
    ........
  }
}

 

我們SystemServer進(jìn)程中的AMS通過(guò)SM的代理與SM進(jìn)程交互(讀者也可以把這個(gè)過(guò)程想象為你所能理解的進(jìn)程間通信方式,例如管道、Socket等),并把自己注冊(cè)在SM中。這個(gè)情況下,我們使用ServiceManager的代理與SM進(jìn)程交互,既然有代理,那么也得有對(duì)應(yīng)的服務(wù)端。那么根據(jù)我們之前博客的思路分析的話,就是如下的流程:

ServiceManager是如何啟動(dòng)的?

按照我們之前博客的思路,我們?cè)赟ystemServer端有了個(gè)ServiceManager的代理,那么Android系統(tǒng)中應(yīng)該提供類似AMS這樣的繼承或間接繼承自java層Binder然后重寫(xiě)onTransact方法以處理請(qǐng)求。但是并沒(méi)有,ServiceManager并沒(méi)有使用如AMS這樣復(fù)雜的Binder類結(jié)構(gòu)。而是直接與Binder驅(qū)動(dòng)設(shè)備打交道。所以我們上一篇說(shuō)了ServiceManager不一樣。我們來(lái)看具體看一下。

ServiceManager在init.rc配置文件中配置啟動(dòng),是一個(gè)以c/c++語(yǔ)言編寫(xiě)的程序。init進(jìn)程、SM進(jìn)程等關(guān)系如下圖

Android中Binder詳細(xì)學(xué)習(xí)心得

我們來(lái)看它的main方法。

int main(int argc, char **argv)
{
  struct binder_state *bs;
  //①應(yīng)該是打開(kāi)binder設(shè)備吧?
  bs = binder_open(128*1024);
  if (!bs) {
    ALOGE("failed to open binder driver\n");
    return -1;
  }
  //②成為manager
  if (binder_become_context_manager(bs)) {
    ALOGE("cannot become context manager (%s)\n", strerror(errno));
    return -1;
  }
  ......
  //③處理客戶端發(fā)過(guò)來(lái)的請(qǐng)求
  binder_loop(bs, svcmgr_handler);
  return 0;
}

①打開(kāi)Binder設(shè)備

[binder.c]

struct binder_state*binder_open(unsigned mapsize)
{
  struct binder_state*bs;
  bs=malloc(sizeof(*bs));
  ......
  //打開(kāi)Binder設(shè)備
  bs->fd=open("/dev/binder",O_RDWR);
  ......
  bs->mapsize=mapsize;
  //進(jìn)行內(nèi)存映射
  bs->mapped=mmap(NULL,mapsize,PROT_READ,MAP_PRIVATE,bs->
  fd,0);
}

 

這一步的目的是把內(nèi)核層的binder驅(qū)動(dòng)映射到用戶空間。我們知道進(jìn)程之間是獨(dú)立的,進(jìn)程呢運(yùn)行在用戶空間內(nèi),內(nèi)核層的Binder驅(qū)動(dòng)可以看成是一個(gè)文件(實(shí)際上它也是,Linux上都是文件)。這一步呢,可以看成把一個(gè)文件映射到用戶空間,我們的進(jìn)程呢通過(guò)這個(gè)文件進(jìn)行交互。

Android中Binder詳細(xì)學(xué)習(xí)心得

②成為manager

[Binder.c]

int binder_become_context_manager(struct binder_state*bs)
{
  //實(shí)現(xiàn)太簡(jiǎn)單了!這個(gè)有個(gè)0,什么鬼?
  return ioctl(bs->fd,BINDER_SET_CONTEXT_MGR,0);
}

 

③處理客戶端發(fā)過(guò)來(lái)的請(qǐng)求

[Binder.c]

void binder_loop(struct binder_state *bs, binder_handler func)
{
  int res;
  struct binder_write_read bwr;
  uint32_t readbuf[32];
  bwr.write_size = 0;
  bwr.write_consumed = 0;
  bwr.write_buffer = 0;
  readbuf[0] = BC_ENTER_LOOPER;
  binder_write(bs, readbuf, sizeof(uint32_t));
  for (;;) {//果然是循環(huán)
    bwr.read_size = sizeof(readbuf);
    bwr.read_consumed = 0;
    bwr.read_buffer = (uintptr_t) readbuf;
    res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr);
    if (res < 0) {
      ALOGE("binder_loop: ioctl failed (%s)\n", strerror(errno));
      break;
    }
    //接收到請(qǐng)求交給binder_parse,最終會(huì)調(diào)用func來(lái)處理這些請(qǐng)求
    res = binder_parse(bs, 0, (uintptr_t) readbuf, bwr.read_consumed, func);
    if (res == 0) {
      ALOGE("binder_loop: unexpected reply?!\n");
      break;
    }
    if (res < 0) {
      ALOGE("binder_loop: io error %d %s\n", res, strerror(errno));
      break;
    }
  }
}

上面?zhèn)魅雈unc的是svcmgr_ handler函數(shù)指針,所以會(huì)在svcmgr_handler中進(jìn)行集中處理客戶端的請(qǐng)求。

[service_manager.c]

ServiceManager的代理是如何獲得的?

我們來(lái)回到最初的調(diào)用

[SystemServer.java]

public void setSystemProcess() {
  try {
    //注冊(cè)服務(wù),第二個(gè)參數(shù)為this,這里假設(shè)SystemServer通過(guò)“socket”與SM交互
    ServiceManager.addService(Context.ACTIVITY_SERVICE, this, true);
    ..........
  } catch (PackageManager.NameNotFoundException e) {
    ........
  }
}

上面的請(qǐng)求最終是通過(guò)SM服務(wù)代理發(fā)送的,那這個(gè)代理是怎么來(lái)的呢?我們來(lái)看

[ServiceManager.java]

public static void addService(String name, IBinder service) {
  try {
    getIServiceManager().addService(name, service, false);
  } catch (RemoteException e) {
    Log.e(TAG, "error in addService", e);
  }
}
private static IServiceManager getIServiceManager() {
  if (sServiceManager != null) {
    return sServiceManager;
  }
  // 是這里,沒(méi)錯(cuò)了
  sServiceManager = ServiceManagerNative.asInterface(BinderInternal.getContextObject());
  return sServiceManager;
}

我們先來(lái)看BinderInternal.getContextObject()

[BinderInternal.java]

//好吧,它還是個(gè)native函數(shù)
public static final native IBinder getContextObject();

跟進(jìn)[android_ util_Binder.cpp]

static jobject android_os_BinderInternal_getContextObject(JNIEnv* env, jobject clazz)
{
  sp<IBinder> b = ProcessState::self()->getContextObject(NULL);
  return javaObjectForIBinder(env, b);
}

跟進(jìn)[ProcessState.cpp]

sp<IBinder> ProcessState::getContextObject(const sp<IBinder>& /*caller*/)
{
  return getStrongProxyForHandle(0);
}
/*這個(gè)函數(shù)是不是我們之前見(jiàn)過(guò)*/
sp<IBinder> ProcessState::getStrongProxyForHandle(int32_t handle)
{
  sp<IBinder> result;
  AutoMutex _l(mLock);
  handle_entry* e = lookupHandleLocked(handle);
  if (e != NULL) {
    IBinder* b = e->binder;
    if (b == NULL || !e->refs->attemptIncWeak(this)) {
      if (handle == 0) {//這里我們的handle為0
        Parcel data;
      //在handle對(duì)應(yīng)的BpBinder第一次創(chuàng)建時(shí)
      //會(huì)執(zhí)行一次虛擬的事務(wù)請(qǐng)求,以確保ServiceManager已經(jīng)注冊(cè)
        status_t status = IPCThreadState::self()->transact(
            0, IBinder::PING_TRANSACTION, data, NULL, 0);
        if (status == DEAD_OBJECT)
          return NULL;//如果ServiceManager沒(méi)有注冊(cè),直接返回
      }
      //這里還是以handle參數(shù)創(chuàng)建了BpBinder
      b = new BpBinder(handle); 
      e->binder = b;
      if (b) e->refs = b->getWeakRefs();
      result = b;
    } else {
      
      result.force_set(b);
      e->refs->decWeak(this);
    }
  }
  return result;
}

我們?cè)僖徊讲椒祷?/p>

[android_ util_Binder.cpp]

static jobject android_os_BinderInternal_getContextObject(JNIEnv* env, jobject clazz)
{
  sp<IBinder> b = ProcessState::self()->getContextObject(NULL);
  //這里的b = new BpBinder(0);
  return javaObjectForIBinder(env, b);
}
/*這個(gè)函數(shù)我們上一篇是不是也見(jiàn)過(guò)*/
jobject javaObjectForIBinder(JNIEnv* env, const sp<IBinder>& val) {
  if (val == NULL) return NULL;
  //如果val是Binder對(duì)象,進(jìn)入下面分支,此時(shí)val是BpBinder
  if (val->checkSubclass(&gBinderOffsets)) {
    // One of our own!
    jobject object = static_cast<JavaBBinder*>(val.get())->object();
    LOGDEATH("objectForBinder %p: it's our own %p!\n", val.get(), object);
    return object;
  }
  .........
  //調(diào)用BpBinder的findObject函數(shù)
  //在Native層的BpBinder中有一個(gè)ObjectManager,它用來(lái)管理在Native BpBinder上創(chuàng)建的Java BinderProxy對(duì)象
  //findObject用于判斷gBinderProxyOffsets中,是否存儲(chǔ)了已經(jīng)被ObjectManager管理的Java BinderProxy對(duì)象
  jobject object = (jobject)val->findObject(&gBinderProxyOffsets);
  if (object != NULL) {
    jobject res = jniGetReferent(env, object);
    ............
    //如果該Java BinderProxy已經(jīng)被管理,則刪除這個(gè)舊的BinderProxy
    android_atomic_dec(&gNumProxyRefs);
    val->detachObject(&gBinderProxyOffsets);
    env->DeleteGlobalRef(object);
  }
  //創(chuàng)建一個(gè)新的BinderProxy對(duì)象
  object = env->NewObject(gBinderProxyOffsets.mClass, gBinderProxyOffsets.mConstructor);
  if (object != NULL) {
    env->SetLongField(object, gBinderProxyOffsets.mObject, (jlong)val.get());
    val->incStrong((void*)javaObjectForIBinder);
    jobject refObject = env->NewGlobalRef(
        env->GetObjectField(object, gBinderProxyOffsets.mSelf));
    //新創(chuàng)建的BinderProxy對(duì)象注冊(cè)到BpBinder的ObjectManager中,同時(shí)注冊(cè)一個(gè)回收函數(shù)proxy_cleanup
    //當(dāng)BinderProxy對(duì)象detach時(shí),proxy_cleanup函數(shù)將被調(diào)用,以釋放一些資源
    val->attachObject(&gBinderProxyOffsets, refObject,
        jnienv_to_javavm(env), proxy_cleanup);
    // Also remember the death recipients registered on this proxy
    sp<DeathRecipientList> drl = new DeathRecipientList;
    drl->incStrong((void*)javaObjectForIBinder);
    //將死亡通知list和BinderProxy聯(lián)系起來(lái)
    env->SetLongField(object, gBinderProxyOffsets.mOrgue, reinterpret_cast<jlong>(drl.get()));
    // Note that a new object reference has been created.
    android_atomic_inc(&gNumProxyRefs);
    //垃圾回收相關(guān);利用gNumRefsCreated記錄創(chuàng)建出的BinderProxy數(shù)量
    //當(dāng)創(chuàng)建出的BinderProxy數(shù)量大于200時(shí),該函數(shù)將利用BinderInternal的ForceGc函數(shù)進(jìn)行一個(gè)垃圾回收
    incRefsCreated(env);
    return object;
  }
}

接著返回到[ServiceManager.java]

private static IServiceManager getIServiceManager() {
  if (sServiceManager != null) {
    return sServiceManager;
  }
  // 是這里,沒(méi)錯(cuò)了BinderInternal.getContextObject()是BinderProxy對(duì)象
  sServiceManager = ServiceManagerNative.asInterface(BinderInternal.getContextObject());
  return sServiceManager;
}

跟進(jìn)[[ServiceManagerNative.java]]

static public IServiceManager asInterface(IBinder obj)
{
  if (obj == null) {
    return null;
  }
  我們知道這里的obj指向的是BinderProxy對(duì)象
  IServiceManager in =
    (IServiceManager)obj.queryLocalInterface(descriptor);
  if (in != null) {
    return in;
  }
  return new ServiceManagerProxy(obj);
}

跟進(jìn)[Binder.java]

final class BinderProxy implements IBinder {
  public IInterface queryLocalInterface(String descriptor) {
    return null;
  }
}

跟進(jìn)[ServiceManagerNative.java]

class ServiceManagerProxy implements IServiceManager {
  public ServiceManagerProxy(IBinder remote) {
    //這里的mRemote指向了BinderProxy,與我們上一篇博客中講述的遙相呼應(yīng)
    mRemote = remote;
  }
}

本節(jié)小結(jié)

我們?cè)敱M講述了SM進(jìn)程的啟動(dòng)以及它作為服務(wù)大管家的意義。結(jié)合上一篇的內(nèi)容我們總算是把Binder講述的比較清楚了。

Binder補(bǔ)充說(shuō)明 AIDL

經(jīng)過(guò)上面的介紹,你應(yīng)該明白Java層Binder的架構(gòu)中,Bp端可以通過(guò)BinderProxy的transact()方法與Bn端發(fā)送請(qǐng)求,而B(niǎo)n端通過(guò)集成Binder重寫(xiě)onTransact()接收并處理來(lái)自Bp端的請(qǐng)求。這個(gè)結(jié)構(gòu)非常清晰簡(jiǎn)單,在Android6.0,我們可以處處看到這樣的設(shè)計(jì),比如我們的ActivityManagerNavtive這個(gè)類,涉及到Binder通信的基本上都是這種設(shè)計(jì)。不過(guò)如果我們想要自己來(lái)定義一些遠(yuǎn)程服務(wù)。那這樣的寫(xiě)法就比較繁瑣,還好Android提供了AIDL,并且在Android8.0之后,我們可以看到與ActivityManagerNavtive相似的許多類已經(jīng)被標(biāo)注過(guò)時(shí),因?yàn)锳ndroid系統(tǒng)也使用AIDL了。

AIDL的簡(jiǎn)單例子

AIDL的語(yǔ)法與定義一個(gè)java接口非常類似。下面我就定以一個(gè)非常簡(jiǎn)單的aidl

IMyAidlInterface.aidl

interface IMyAidlInterface {
  int getTest();
}

然后基本上就行了,我們重新build之后會(huì)得到一個(gè)
IMyAidlInterface.java文件,這個(gè)文件由aidl工具生成,我們現(xiàn)在使用的基本是AndroidStudio,即使你使用的是Eclipse也沒(méi)關(guān)系,這個(gè)文件會(huì)自動(dòng)生成,不需要你操心。但是我們還是得來(lái)看看我們生成的這個(gè)文件

public interface IMyAidlInterface extends android.os.IInterface {
  //抽象的Stub類,繼承自Binder并實(shí)現(xiàn)我們定義的IMyAidlInterface接口
  //繼承自Binder,重寫(xiě)onTransact方法,是不是感覺(jué)跟我們的XXXNative很像
  public static abstract class Stub extends android.os.Binder implements com.mafeibiao.testapplication.IMyAidlInterface {
    private static final java.lang.String DESCRIPTOR = "com.mafeibiao.testapplication.IMyAidlInterface";
    /**
     * Construct the stub at attach it to the interface.
     */
    public Stub() {
      this.attachInterface(this, DESCRIPTOR);
    }
    /**
     * Cast an IBinder object into an com.mafeibiao.testapplication.IMyAidlInterface interface,
     * generating a proxy if needed.
     */
    public static com.mafeibiao.testapplication.IMyAidlInterface asInterface(android.os.IBinder obj) {
      if ((obj == null)) {
        return null;
      }
      android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);
      if (((iin != null) && (iin instanceof com.mafeibiao.testapplication.IMyAidlInterface))) {
        return ((com.mafeibiao.testapplication.IMyAidlInterface) iin);
      }
      return new com.mafeibiao.testapplication.IMyAidlInterface.Stub.Proxy(obj);
    }
    @Override
    public android.os.IBinder asBinder() {
      return this;
    }
    @Override
    public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) throws android.os.RemoteException {
      switch (code) {
        case INTERFACE_TRANSACTION: {
          reply.writeString(DESCRIPTOR);
          return true;
        }
        case TRANSACTION_getTest: {
          data.enforceInterface(DESCRIPTOR);
          int _result = this.getTest();
          reply.writeNoException();
          reply.writeInt(_result);
          return true;
        }
      }
      return super.onTransact(code, data, reply, flags);
    }
    /*這個(gè)Proxy不用說(shuō)肯定是代理了,其內(nèi)部還有個(gè)mRemote對(duì)象*/
    private static class Proxy implements com.mafeibiao.testapplication.IMyAidlInterface {
      private android.os.IBinder mRemote;

      Proxy(android.os.IBinder remote) {
        mRemote = remote;
      }
      @Override
      public android.os.IBinder asBinder() {
        return mRemote;
      }
      public java.lang.String getInterfaceDescriptor() {
        return DESCRIPTOR;
      }
      @Override
      public int getTest() throws android.os.RemoteException {
        android.os.Parcel _data = android.os.Parcel.obtain();
        android.os.Parcel _reply = android.os.Parcel.obtain();
        int _result;
        try {
          _data.writeInterfaceToken(DESCRIPTOR);
          mRemote.transact(Stub.TRANSACTION_getTest, _data, _reply, 0);
          _reply.readException();
          _result = _reply.readInt();
        } finally {
          _reply.recycle();
          _data.recycle();
        }
        return _result;
      }
    }
    static final int TRANSACTION_getTest = (android.os.IBinder.FIRST_CALL_TRANSACTION + 0);
  }
  public int getTest() throws android.os.RemoteException;
}

可見(jiàn),AIDL的本質(zhì)與XXXNative之類的類并沒(méi)有什么本質(zhì)的不同,不過(guò)他的出現(xiàn)使得構(gòu)建一個(gè)Binder服務(wù)的工作大大簡(jiǎn)化了。

AIDL的使用詳解

上面用一個(gè)非常簡(jiǎn)單的小例子來(lái)解密AIDL的本質(zhì),但是在實(shí)際使用AIDL的時(shí)候還有許多地方需要注意。

AIDL支持的數(shù)據(jù)類型 基本數(shù)據(jù)類型(int,long,charmboolean,double等) String和CharSequence List:只支持ArrrayList,并且里面每個(gè)元素的類型必須是AIDL支持的 Map:只支持HashMap,t,并且里面每個(gè)元素的類型必須是AIDL支持的 Parcelable:所有實(shí)現(xiàn)Parcelable接口的對(duì)象 AIDL:所有的AIDL接口本身也可以在AIDL文件中使用

以上6種數(shù)據(jù)類型就是AIDL所支持的所有類型,其中自定義的Parcel對(duì)象和AIDL對(duì)象必須要顯示import進(jìn)來(lái),不管他們是否和當(dāng)前的AIDL文件位于同一個(gè)包內(nèi)。

另外一個(gè)需要注意的地方是如果我們?cè)贏IDL中使用了自定義的Parcelable接口的對(duì)象,那么我們必須新建一個(gè)和它同名的AIDL文件,并在其中聲明它為Parcelable類型。

如下例

[IBookManager.aidl]

package com.ryg.chapter_2.aidl;
/*這里顯示import*/
import com.ryg.chapter_2.aidl.Book;
interface IBookManager {
   //這里我們使用了自定義的Parcelable對(duì)象
   List<Book> getBookList();
   void addBook(in Book book);
}

這里我們新建一個(gè)與Book同名的AIDL文件并聲明

[Book.aidl]

package com.ryg.chapter_2.aidl;
parcelable Book;

定向tag

定向tag:這是一個(gè)極易被忽略的點(diǎn)——這里的“被忽略”指的不是大家都不知道,而是很少人會(huì)正確的使用它。
AIDL中的定向 tag 表示了在跨進(jìn)程通信中數(shù)據(jù)的流向,其中 in 表示數(shù)據(jù)只能由客戶端流向服務(wù)端, out 表示數(shù)據(jù)只能由服務(wù)端流向客戶端,而 inout 則表示數(shù)據(jù)可在服務(wù)端與客戶端之間雙向流通。其中,數(shù)據(jù)流向是針對(duì)在客戶端中的那個(gè)傳入方法的對(duì)象而言的。in 為定向 tag 的話表現(xiàn)為服務(wù)端將會(huì)接收到一個(gè)那個(gè)對(duì)象的完整數(shù)據(jù),但是客戶端的那個(gè)對(duì)象不會(huì)因?yàn)榉?wù)端對(duì)傳參的修改而發(fā)生變動(dòng);out 的話表現(xiàn)為服務(wù)端將會(huì)接收到那個(gè)對(duì)象的的空對(duì)象,但是在服務(wù)端對(duì)接收到的空對(duì)象有任何修改之后客戶端將會(huì)同步變動(dòng);inout 為定向 tag 的情況下,服務(wù)端將會(huì)接收到客戶端傳來(lái)對(duì)象的完整信息,并且客戶端將會(huì)同步服務(wù)端對(duì)該對(duì)象的任何變動(dòng)。

另外,Java 中的基本類型和 String ,CharSequence 的定向 tag 默認(rèn)且只能是 in 。還有,請(qǐng)注意,請(qǐng)不要濫用定向 tag ,而是要根據(jù)需要選取合適的——要是不管三七二十一,全都一上來(lái)就用 inout ,等工程大了系統(tǒng)的開(kāi)銷就會(huì)大很多——因?yàn)榕帕姓韰?shù)的開(kāi)銷是很昂貴的。

所有的非基本參數(shù)都需要一個(gè)定向tag來(lái)指出數(shù)據(jù)的流向,不管是 in , out , 還是 inout ?;緟?shù)的定向tag默認(rèn)是并且只能是 in 。

本篇總結(jié)

我們本篇詳細(xì)分析了ServiceManager,ServiceManager并沒(méi)有使用復(fù)雜的類結(jié)構(gòu),他直接與Binder驅(qū)動(dòng)設(shè)備交互達(dá)到IPC通信的目的。感謝你對(duì)創(chuàng)新互聯(lián)的支持。

本文標(biāo)題:Android中Binder詳細(xì)學(xué)習(xí)心得
文章分享:http://muchs.cn/article20/pihdco.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供外貿(mào)建站、標(biāo)簽優(yōu)化網(wǎng)站策劃、微信公眾號(hào)外貿(mào)網(wǎng)站建設(shè)、網(wǎng)站內(nèi)鏈

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來(lái)源: 創(chuàng)新互聯(lián)

微信小程序開(kāi)發(fā)