據說你 Binder 機制學的不錯，來解決下這幾個問題（三）
不少文章將Binder框架定義了四個角色：Server，Client，ServiceManager、以及Binder驅動，但這容易將人引導到歧途：好像全部的Binder服務都須要去ServiceManager去註冊才能使用，其實不是這樣。例如，平時APP開發經過bindService啓動的服務，以及有些本身定義的AIDL遠程調用，都不必定都ServiceManager註冊這條路，我的理解：ServiceManager主要功能是：管理系統服務，好比AMS、WMS、PKMS服務等，而APP經過的bindService啓動的Binder服務實際上是由SystemServer的ActivityManagerService負責管理。這篇主要關注Android APP Java層Binder通訊一些奇葩點：javascript
- ServiceManager addService的限制（並不是服務都能使用ServiceManager的addService）
- bindService啓動Service與Binder服務實體的流程
- Java層Binder實體與與BinderProxy是如何實例化及使用的，與Native層的關係是怎樣的
- Parcel readStrongBinder與writeStrongBinder的原理（首先兩端知曉）
ServiceManager addService的限制--並不是服務都能經過addService添加到ServiceManager
ServiceManager其實主要的面向對象是系統服務，大部分系統服務都是由SystemServer進程總添加到ServiceManager中去的，在經過ServiceManager添加服務的時候，是有些權限校驗的，源碼以下：java
int svc_can_register(unsigned uid, uint16_t *name)
{
unsigned n;
// 誰有權限add_service 0進程，或者 AID_SYSTEM進程
if ((uid == 0) || (uid == AID_SYSTEM))
return 1;
for (n = 0; n < sizeof(allowed) / sizeof(allowed[0]); n++)
if ((uid == allowed[n].uid) && str16eq(name, allowed[n].name))
return 1;
return 0;
}複製代碼
能夠看到 (uid == 0) 或者 (uid == AID_SYSTEM)的進程都是能夠添加服務的，uid=0，表明root用戶，而uid=AID_SYSTEM，表明系統用戶 。或者是一些特殊的配置進程。SystemServer進程在被Zygote建立的時候，就被分配了UID 是AID_SYSTEM（1000），node
private static boolean startSystemServer()
throws MethodAndArgsCaller, RuntimeException {
/* Hardcoded command line to start the system server */
String args[] = {
"--setuid=1000",
"--setgid=1000",
"--setgroups=1001,1002,1003,1004,1005,1006,1007,1008,1009,1010,1018,3001,3002,3003,3006,3007",
"--capabilities=130104352,130104352",
"--runtime-init",
"--nice-name=system_server",
"com.android.server.SystemServer",
};複製代碼
Android每一個APP的UID，都是不一樣的，用了Linux的UID那一套，可是沒徹底沿用，這裏不探討，總之，普通的進程是沒有權限註冊到ServiceManager中的，那麼APP平時經過bindService啓動的服務怎麼註冊於查詢的呢？接管這個任務的就是SystemServer的ActivityManagerService。android
bindService啓動Service與Binder服務實體的流程 （ActivityManagerService）
- bindService的框架
- binder服務實例化與轉化
- 業務邏輯的喚醒
- 請求代理的轉化與喚醒
bindService比startService多了一套Binder通訊，其他的流程基本相同，而startService的流程，同startActivity差很少，四大組件的啓動流程這裏不作分析點，主要看bindService中C/S通訊的創建流程，在這個流程裏面，APP與服務端互爲C/S的特性更明顯，在APP開發的時候，binder服務是經過Service來啓動的。Service的啓動方式有兩種startService，與bindService，這裏只考慮後者，另外啓動的binder服務也分爲兩種狀況：第一種，client同server位於同一進程，能夠看作內部服務，第二種，Client與Server跨進程，即便是位於同一個APP，第一桶能夠不用AIDL來編寫，可是第二種必須經過AIDL實現跨進程通訊，看一個最簡單的AIDL例子，首先在定義一個aidl接口：緩存
IMyAidlInterface.aidlcookie
interface IMyAidlInterface {
void communicate(int count);
}app
IMyAidlInterface.aidl定義了通訊的藉口，經過build以後，構建工具會自動爲IMyAidlInterface.aidl生成一些輔助類，這些輔助類主要做用是生成Binder通訊協議框架，必須保證兩方通訊須要指令相同，才能解析通訊內容。天王蓋地虎，寶塔鎮河妖。Java層Binder的對應關係Binder與BinderProxy從這裏能夠看出，binder採用了代理模式 stub與proxy對應，使用aidl實現的服務時候，Client若是想要得到Binder實體的代理能夠經過asInterface來處理，好比若是在同一進程就是實體，不在就新建代理對象框架
public interface IMyAidlInterface extends android.os.IInterface {
public static abstract class Stub extends android.os.Binder implements com.snail.labaffinity.IMyAidlInterface {
private static final java.lang.String DESCRIPTOR = "com.snail.labaffinity.IMyAidlInterface";
public Stub() {
this.attachInterface(this, DESCRIPTOR);
}
public static com.snail.labaffinity.IMyAidlInterface asInterface(android.os.IBinder obj) {
if ((obj == null)) {
return null;
}
android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);
if (((iin != null) && (iin instanceof com.snail.labaffinity.IMyAidlInterface))) {
return ((com.snail.labaffinity.IMyAidlInterface) iin);
}
return new com.snail.labaffinity.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_communicate: {
data.enforceInterface(DESCRIPTOR);
int _arg0;
_arg0 = data.readInt();
this.communicate(_arg0);
reply.writeNoException();
return true;
}
}
return super.onTransact(code, data, reply, flags);
}
private static class Proxy implements com.snail.labaffinity.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 void communicate(int count) throws android.os.RemoteException {
android.os.Parcel _data = android.os.Parcel.obtain();
android.os.Parcel _reply = android.os.Parcel.obtain();
try {
_data.writeInterfaceToken(DESCRIPTOR);
_data.writeInt(count);
mRemote.transact(Stub.TRANSACTION_communicate, _data, _reply, 0);
_reply.readException();
} finally {
_reply.recycle();
_data.recycle();
}
}
}
static final int TRANSACTION_communicate = (android.os.IBinder.FIRST_CALL_TRANSACTION + 0);
}
public void communicate(int count) throws android.os.RemoteException;
}複製代碼
啓動Binder服務端封裝Service，之因此成爲封裝Service，是由於Service對於Binder實體的最大做用是個做爲新建服務的入口：ide
public class AidlService extends Service {
@Nullable
@Override
public IBinder onBind(Intent intent) {
return new BBinderService();
}
public class BBinderService extends IMyAidlInterface.Stub {
@Override
public void communicate(int count) throws RemoteException {
}
}
}複製代碼
而啓動的入口：函數
public class MainActivity extends AppCompatActivity {
...
void bind(){
Intent intent = createExplicitFromImplicitIntent(MainActivity.this, new Intent("com.snail.labaffinity.service.AidlService"));
bindService(intent, new ServiceConnection() {
@Override
public void onServiceConnected(ComponentName componentName, IBinder iBinder) {
IMyAidlInterface iMyAidlInterface = IMyAidlInterface.Stub.asInterface(iBinder);
}
@Override
public void onServiceDisconnected(ComponentName componentName) {
}
}, Context.BIND_AUTO_CREATE);
}
}複製代碼
以上四個部分就組成了AIDL跨進程服務的基本組件，如今從ActivitybindService入口開始分析：bindService大部分的流程與startActivity相似，其實都是經過AMS啓動組件，這裏只將一些不一樣的地方，Activity啓動只須要Intent就能夠了，而Service的bind須要一個ServiceConnection對象，這個對象實際上是爲了AMS端在啓動Service後回調用的，ServiceConnection是個接口，其實例在ContextImpl的：
private boolean bindServiceCommon(Intent service, ServiceConnection conn, int flags,
UserHandle user) {
IServiceConnection sd;
if (conn == null) {
throw new IllegalArgumentException("connection is null");
}
if (mPackageInfo != null) {
sd = mPackageInfo.getServiceDispatcher(conn, getOuterContext(),
mMainThread.getHandler(), flags);
} else {
throw new RuntimeException("Not supported in system context");
}
validateServiceIntent(service);
try {
IBinder token = getActivityToken();
if (token == null && (flags & BIND_AUTO_CREATE) == 0 && mPackageInfo != null
&& mPackageInfo.getApplicationInfo().targetSdkVersion
< android.os.Build.VERSION_CODES.ICE_CREAM_SANDWICH) {
flags |= BIND_WAIVE_PRIORITY;
}
service.prepareToLeaveProcess();
int res = ActivityManagerNative.getDefault().bindService(
mMainThread.getApplicationThread(), getActivityToken(), service,
service.resolveTypeIfNeeded(getContentResolver()),
sd, flags, getOpPackageName(), user.getIdentifier());
if (res < 0) {
throw new SecurityException(
"Not allowed to bind to service " + service);
}
return res != 0;
} catch (RemoteException e) {
throw new RuntimeException("Failure from system", e);
}
}複製代碼
mPackageInfo是一個LoadApk類，經過它的getServiceDispatcher得到一個IServiceConnection對象，這個對象一個Binder實體，看一下具體原理
public final IServiceConnection getServiceDispatcher(ServiceConnection c,
Context context, Handler handler, int flags) {
synchronized (mServices) {
LoadedApk.ServiceDispatcher sd = null;
ArrayMap<ServiceConnection, LoadedApk.ServiceDispatcher> map = mServices.get(context);
if (map != null) {
sd = map.get(c);
}
if (sd == null) {
sd = new ServiceDispatcher(c, context, handler, flags);
if (map == null) {
map = new ArrayMap<ServiceConnection, LoadedApk.ServiceDispatcher>();
mServices.put(context, map);
}
map.put(c, sd);
} else {
sd.validate(context, handler);
}
return sd.getIServiceConnection();
}
}複製代碼
在LoadApk中IServiceConnection對象是經過context鍵值來存儲ServiceDispatcher對象，而ServiceDispatcher對象內存會有個InnerConnection對象，該對象就是getServiceDispatcher的返回對象。所以bindServiceCommon最終調用
ActivityManagerNative.getDefault().bindService(x,x,x,x,x sd, x, x, x) 的時候，傳遞的參數sd其實就是一個InnerConnection對象，這是個Binder實體。可是，Binder.java中的Binder只是對native層BBinder的一個簡單封裝,真正的實例化仍是經過JNI到native層去建立一個JavaBBinderHolder對象，並初始化gBinderOffsets，讓其能映射Java層Binder對象，而JavaBBinderHolder中又能夠實例化BBinder的實例JavaBBinder，不過BBinder的實例化時機並不在這裏，而是在Parcel對象writeStrongBinder的時候，
static struct bindernative_offsets_t
{
// Class state.
jclass mClass;
jmethodID mExecTransact;
// Object state.
jfieldID mObject;
} gBinderOffsets;
static void android_os_Binder_init(JNIEnv* env, jobject obj)
{
JavaBBinderHolder* jbh = new JavaBBinderHolder();
jbh->incStrong((void*)android_os_Binder_init);
env->SetIntField(obj, gBinderOffsets.mObject, (int)jbh);
}複製代碼
繼續往下看bindService，會調用到ActivityManagerProxy的bindService
public int bindService(IApplicationThread caller, IBinder token,
Intent service, String resolvedType, IServiceConnection connection,
int flags, int userId) throws RemoteException {
Parcel data = Parcel.obtain();
Parcel reply = Parcel.obtain();
data.writeInterfaceToken(IActivityManager.descriptor);
data.writeStrongBinder(caller != null ? caller.asBinder() : null);
data.writeStrongBinder(token);
service.writeToParcel(data, 0);
data.writeString(resolvedType);
data.writeStrongBinder(connection.asBinder());
data.writeInt(flags);
data.writeInt(userId);
mRemote.transact(BIND_SERVICE_TRANSACTION, data, reply, 0);
reply.readException();
int res = reply.readInt();
data.recycle();
reply.recycle();
return res;
}複製代碼
利用Parcel的writeStrongBinder會將Binder實體寫入到Parcel中去，這裏首先看一下 Parcel data = Parcel.obtain();在java層Parcel只是一個容器，具體Parcel相關的操做都在Native層
static jint android_os_Parcel_create(JNIEnv* env, jclass clazz)
{
Parcel* parcel = new Parcel();
return reinterpret_cast<jint>(parcel);
}複製代碼
這裏的返回值，其實就是Parcel對象的地址，被賦值給了Parcel.java的mNativePtr成員變量，方便Native調用，接着看writeStrongBinder的實現，其實就是調用Parcel.cpp中的對應方法，經過flatten_binder將Binder實體對象打扁，建立flat_binder_object寫入Parcel中，
static void android_os_Parcel_writeStrongBinder(JNIEnv* env, jclass clazz, jint nativePtr, jobject object)
{
Parcel* parcel = reinterpret_cast<Parcel*>(nativePtr);
if (parcel != NULL) {
const status_t err = parcel->writeStrongBinder(ibinderForJavaObject(env, object));
if (err != NO_ERROR) {
signalExceptionForError(env, clazz, err);
}
}
}複製代碼
ibinderForJavaObject主要爲Java層Binder實例化native binder對象：
sp<IBinder> ibinderForJavaObject(JNIEnv* env, jobject obj)
{
if (obj == NULL) return NULL;
if (env->IsInstanceOf(obj, gBinderOffsets.mClass)) {
JavaBBinderHolder* jbh = (JavaBBinderHolder*)
env->GetIntField(obj, gBinderOffsets.mObject);
return jbh != NULL ? jbh->get(env, obj) : NULL;
}
if (env->IsInstanceOf(obj, gBinderProxyOffsets.mClass)) {
return (IBinder*)
env->GetIntField(obj, gBinderProxyOffsets.mObject);
}
return NULL;
}複製代碼
若是BBinder還沒實例化，要經過JavaBBinderHolder的get函數實例化一個BBinder對象，這裏就是JavaBBinder對象，綜上分析Java層與Native的Binder其對應關係以下：
BBinder對象被Parcel轉換成flat_binder_object，通過一次拷貝寫入目標進程，並執行BINDER_TYPE_BINDER與BINDER_TYPE_HANDLE的轉換，以下：
static void
binder_transaction(struct binder_proc *proc, struct binder_thread *thread,
struct binder_transaction_data *tr, int reply)
...
fp = (struct flat_binder_object *)(t->buffer->data + *offp);
switch (fp->type) {
case BINDER_TYPE_BINDER:
case BINDER_TYPE_WEAK_BINDER: {..
if (fp->type == BINDER_TYPE_BINDER)
fp->type = BINDER_TYPE_HANDLE;
else
fp->type = BINDER_TYPE_WEAK_HANDLE;
fp->handle = ref->desc;
} break;
case BINDER_TYPE_HANDLE:
case BINDER_TYPE_WEAK_HANDLE: {..
struct binder_ref *ref = binder_get_ref(proc, fp->handle);
if (ref->node->proc == target_proc) {
if (fp->type == BINDER_TYPE_HANDLE)
fp->type = BINDER_TYPE_BINDER;
else
fp->type = BINDER_TYPE_WEAK_BINDER;
fp->binder = ref->node->ptr;
fp->cookie = ref->node->cookie;
} else {
struct binder_ref *new_ref;
new_ref = binder_get_ref_for_node(target_proc, ref->node);
fp->handle = new_ref->desc;
}
} break;
}複製代碼
在內核中，bindService中的InnerConnection會由BINDER_TYPE_BINDER轉換成BINDER_TYPE_HANDLE，以後，AMS線程被喚醒後，執行後面的流程，在前文分析Parcel數據轉換的時候，在Binder線程被喚醒繼續執行的時候，會將數據映射到一個natvie Parcel對象中
status_t IPCThreadState::executeCommand(int32_t cmd)
{
BBinder* obj;
switch (cmd) {
..
// read到了數據請求，這裏是須要處理的邏輯 ，處理完畢，
case BR_TRANSACTION:
{
binder_transaction_data tr;
result = mIn.read(&tr, sizeof(tr));
Parcel buffer;
<!--關鍵點1 -->
buffer.ipcSetDataReference(
reinterpret_cast<const uint8_t*>(tr.data.ptr.buffer),
tr.data_size,
reinterpret_cast<const size_t*>(tr.data.ptr.offsets),
tr.offsets_size/sizeof(size_t), freeBuffer, this);
...
<!--關鍵點2 -->
if (tr.target.ptr) {
sp<BBinder> b((BBinder*)tr.cookie);
const status_t error = b->transact(tr.code, buffer, &reply, tr.flags);
if (error < NO_ERROR) reply.setError(error);
}
..
}
} 複製代碼
首先看一下關鍵點1 ，這裏將內核數據映射到一個用戶空間的Parcel對象中去，以後在調用目標Service的transact函數，進而調用他的onTrasanct函數 , 經過前面的分析知道，Java層Binder在註冊時候，最終註冊的是JavaBBinder對象，看一下它的onTrasanct函數：
virtual status_t onTransact(
uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags = 0)
{
JNIEnv* env = javavm_to_jnienv(mVM);
IPCThreadState* thread_state = IPCThreadState::self();
const int strict_policy_before = thread_state->getStrictModePolicy();
thread_state->setLastTransactionBinderFlags(flags);
..
jboolean res = env->CallBooleanMethod(mObject, gBinderOffsets.mExecTransact,
code, (int32_t)&data, (int32_t)reply, flags);
..
return res != JNI_FALSE ? NO_ERROR : UNKNOWN_TRANSACTION;
}複製代碼
關鍵代碼只有一句：env->CallBooleanMethod(mObject, gBinderOffsets.mExecTransact, code, (int32_t)&data, (int32_t)reply, flags)，其實就是調用Binder.java的execTransact函數，該函數首先將Native的Parcel映射成Jave層Parcel，以後調用BBinder子類的onTransact函數執行對應的業務邏輯：
private boolean execTransact(int code, int dataObj, int replyObj,
int flags) {
Parcel data = Parcel.obtain(dataObj);
Parcel reply = Parcel.obtain(replyObj);
boolean res;
try {
res = onTransact(code, data, reply, flags);
} ...
reply.recycle();
data.recycle();
return res;
}}複製代碼
對於AMS而bindService對應的操做以下
public boolean onTransact(int code, Parcel data, Parcel reply, int flags)
throws RemoteException {
。。
case BIND_SERVICE_TRANSACTION: {
data.enforceInterface(IActivityManager.descriptor);
IBinder b = data.readStrongBinder();
IApplicationThread app = ApplicationThreadNative.asInterface(b);
IBinder token = data.readStrongBinder();
Intent service = Intent.CREATOR.createFromParcel(data);
String resolvedType = data.readString();
b = data.readStrongBinder();
int fl = data.readInt();
int userId = data.readInt();
IServiceConnection conn = IServiceConnection.Stub.asInterface(b);
int res = bindService(app, token, service, resolvedType, conn, fl, userId);
reply.writeNoException();
reply.writeInt(res);
return true;
}複製代碼
b = data.readStrongBinder()會先讀取Binder對象，這裏會調用本地函數nativeReadStrongBinder(mNativePtr)，mNativePtr就是Native層Parcel的首地址：
public final IBinder readStrongBinder() {
return nativeReadStrongBinder(mNativePtr);
}複製代碼
nativeReadStrongBinder(mNativePtr)會將本地Binder對象轉化成Java層對象，其實就是將傳輸的InnerConnection讀取出來，不過因爲Binder驅動將BINDER_TYPE_BINDER轉換成了BINDER_TYPE_HANDLE，對於AMS實際上是實例化BinderProxy
static jobject android_os_Parcel_readStrongBinder(JNIEnv* env, jclass clazz, jint nativePtr)
{
Parcel* parcel = reinterpret_cast<Parcel*>(nativePtr);
if (parcel != NULL) {
// /parcel->readStrongBinder() 其實就會建立BpBInder、
return javaObjectForIBinder(env, parcel->readStrongBinder());
}
return NULL;
}複製代碼
首先會利用Parcel.cpp的parcel->readStrongBinder()，讀取binder對象，這裏會根據flat_binder_object的類型，分別進行BBinder與BpBinder映射，若是是Binder實體直接將指針賦值out，若是不是，則根據handle獲取或者新建BpBinder返回給out。
status_t unflatten_binder(const sp<ProcessState>& proc,
const Parcel& in, sp<IBinder>* out)
{
const flat_binder_object* flat = in.readObject(false);
if (flat) {
switch (flat->type) {
case BINDER_TYPE_BINDER:
*out = static_cast<IBinder*>(flat->cookie);
return finish_unflatten_binder(NULL, *flat, in);
case BINDER_TYPE_HANDLE:
*out = proc->getStrongProxyForHandle(flat->handle);
return finish_unflatten_binder(
static_cast<BpBinder*>(out->get()), *flat, in);
}
}
return BAD_TYPE;
}複製代碼
以後會牽扯一個將native binder轉換成java層Binder的操做，javaObjectForIBinder，這個函數很關鍵，是理解Java層BinderProxy或者BBinder實體的關鍵：
jobject javaObjectForIBinder(JNIEnv* env, const sp<IBinder>& val)
{
if (val == NULL) return NULL;
<!--關鍵點1-->
if (val->checkSubclass(&gBinderOffsets)) {
jobject object = static_cast<JavaBBinder*>(val.get())->object();
return object;
}
AutoMutex _l(mProxyLock);
<!--關鍵點2-->
jobject object = (jobject)val->findObject(&gBinderProxyOffsets);
if (object != NULL) {
android_atomic_dec(&gNumProxyRefs);
val->detachObject(&gBinderProxyOffsets);
env->DeleteGlobalRef(object);
}
<!--關鍵點3-->
object = env->NewObject(gBinderProxyOffsets.mClass, gBinderProxyOffsets.mConstructor);
if (object != NULL) {
env->SetIntField(object, gBinderProxyOffsets.mObject, (int)val.get());
val->incStrong((void*)javaObjectForIBinder);
jobject refObject = env->NewGlobalRef(
env->GetObjectField(object, gBinderProxyOffsets.mSelf));
val->attachObject(&gBinderProxyOffsets, refObject,
jnienv_to_javavm(env), proxy_cleanup);
sp<DeathRecipientList> drl = new DeathRecipientList;
drl->incStrong((void*)javaObjectForIBinder);
env->SetIntField(object, gBinderProxyOffsets.mOrgue, reinterpret_cast<jint>(drl.get()));
android_atomic_inc(&gNumProxyRefs);
incRefsCreated(env);
}
return object;
}複製代碼
先看關鍵點1， checkSubclass默認返回false，可是JavaBBinder，該類對此函數進行了覆蓋，若是是JavaBBinder，就會返回true，但若是是BpBinder，則會返回false，
bool checkSubclass(const void* subclassID) const
{
return subclassID == &gBinderOffsets;
}複製代碼
再看關鍵點2，若是是BpBinder，則須要首先在gBinderProxyOffsets中查找，是否是已經新建了Java層代理BinderProxy對象，若是沒有，則新建便可，若是新建過，就看是否還存在緩存有效的BinderProxy。最後看關鍵點3 ：
env->NewObject(gBinderProxyOffsets.mClass, gBinderProxyOffsets.mConstructor)
其實就是新建BinderProxy對象，Java層的BinderProxy都是Native新建的，Java層並無BinderProxy的新建入口，以後，再經過IServiceConnection.Stub.asInterface(b)進行轉換，實例化一個IServiceConnection.Proxy代理對，該對象在Binder通訊的基礎上封裝了業務邏輯，其實就是一些具體的操做。
public static XXXAidlInterface asInterface(android.os.IBinder obj) {
if ((obj == null)) {
return null;
}
android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);
if (((iin != null) && (iin instanceof XXXAidlInterface))) {
return ((XXXAidlInterface) iin);
}
return new XXXAidlInterface.Stub.Proxy(obj);
}複製代碼
這裏注意一點杜宇BinderProxy，obj.queryLocalInterface(DESCRIPTOR)返回爲null，對於Binder實體，返回的是Binder自身，這樣就能爲上層區分出是生成代理仍是存根自身，總體對象轉換流程以下：
到這裏分析了一半，Java層命令及回調Binder入口已經被傳遞給AMS，AMS以後須要負責啓動Service，並經過回調入口爲Client綁定服務，跟蹤到AMS源碼
public int bindService(IApplicationThread caller, IBinder token,
Intent service, String resolvedType,
IServiceConnection connection, int flags, int userId) {
...
synchronized(this) {
return mServices.bindServiceLocked(caller, token, service, resolvedType,
connection, flags, userId);
}
}複製代碼
最後調用ActiveService的bindServiceLocked，這裏會分三中狀況，
- Service已經經啓動
- Service未啓動，可是進程已經啓動
- Service與進程君未啓動
不過這裏只討論「 Service未啓動，可是進程已經啓動的狀況」，關鍵代碼以下
int bindServiceLocked(IApplicationThread caller, IBinder token,
Intent service, String resolvedType,
IServiceConnection connection, int flags, int userId) {
try {
.。。
if ((flags&Context.BIND_AUTO_CREATE) != 0) {
s.lastActivity = SystemClock.uptimeMillis();
<!--關鍵點1--> if (bringUpServiceLocked(s, service.getFlags(), false) != null) { return 0; } } <!--關鍵點2--> .. requestServiceBindingLocked(s, b.intent, false); .. } }複製代碼
關鍵點1其實就是啓動Service，主要是經過ApplicationThread的binder通訊通知App端啓動Service，這個流程同Activity啓動同樣。關鍵點2是Service特有的：requestServiceBindingLocked，這個命令是告訴APP端：「在Service啓動後須要向AMS發消息，以後AMS才能向其餘須要綁定該Service的Client發送反饋」。
AMS端
private final boolean requestServiceBindingLocked(ServiceRecord r,
IntentBindRecord i, boolean rebind) {
if ((!i.requested || rebind) && i.apps.size() > 0) {
..
r.app.thread.scheduleBindService(r, i.intent.getIntent(), rebind);
..
} }
return true;
}
APP端
private void handleBindService(BindServiceData data) {
Service s = mServices.get(data.token);
...
if (!data.rebind) {
IBinder binder = s.onBind(data.intent);
ActivityManagerNative.getDefault().publishService(
data.token, data.intent, binder);
}
}複製代碼
ActivityManagerNative.getDefault().publishService會將啓動的Binder服務實體傳遞給AMS，上面分析過Binder實體傳輸，這裏的原理是同樣的，AMS端在傳輸結束後，會得到Service端服務實體的引用，這個時候，就能經過最初的InnerConnection的回調將這個服務傳遞給Client端。Binder實體與引用的總體流程圖以下：
若是要深究Activity的bindService流程，能夠按如下幾步來分析
- 一、Activity調用bindService：經過Binder通知ActivityManagerService，要啓動哪一個Service
- 二、ActivityManagerService建立ServiceRecord，並利用ApplicationThreadProxy回調，通知APP新建並啓動Service啓動起來
- 三、ActivityManagerService把Service啓動起來後，繼續經過ApplicationThreadProxy，通知APP，bindService，其實就是讓Service返回一個Binder對象給ActivityManagerService，以便AMS傳遞給Client
- 四、ActivityManagerService把從Service處獲得這個Binder對象傳給Activity，這裏是經過IServiceConnection binder實現。
- 五、Activity被喚醒後經過Binder Stub的asInterface函數將Binder轉換爲代理Proxy，完成業務代理的轉換，以後就能利用Proxy進行通訊了。
據說你Binder機制學的不錯，來解決下這幾個問題（一）
據說你 Binder 機制學的不錯，來解決下這幾個問題（二）
據說你 Binder 機制學的不錯，來解決下這幾個問題（三）
僅供參考，歡迎指正
- 1. 據說你 Binder 機制學的不錯，來解決下這幾個問題（三）
- 2. 據說你Binder機制學的不錯，來解決下這幾個問題（一）
- 3. 據說你 Binder 機制學的不錯，來解決下這幾個問題（二）
- 4. 據說你Binder機制學的不錯，來面試下這幾個問題
- 5. 聽說你Binder機制學的不錯，來面試下這幾個問題（一）
- 6. 據說你看過HashMap源碼，來面試下這幾個問題
- 7. EurekaServer這幾個錯誤 你能夠這樣解決
- 8. 【面試官問你】說說你對Binder的理解吧
- 9. 說說你對 binder 驅動的瞭解？
- 10. fckeditor的幾個問題的解決
- 更多相關文章...
- • Redis樂觀鎖解決高併發搶紅包的問題 - 紅包項目實戰
- • Redis悲觀鎖解決高併發搶紅包的問題 - 紅包項目實戰
- • 漫談MySQL的鎖機制
- • IntelliJ IDEA中SpringBoot properties文件不能自動提示問題解決
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. python的安裝和Hello，World編寫
- 2. 重磅解讀：K8s Cluster Autoscaler模塊及對應華爲雲插件Deep Dive
- 3. 鴻蒙學習筆記2（永不斷更）
- 4. static關鍵字 和構造代碼塊
- 5. JVM筆記
- 6. 無法啓動 C/C++ 語言服務器。IntelliSense 功能將被禁用。錯誤: Missing binary at c:\Users\MSI-NB\.vscode\extensions\ms-vsc
- 7. 【Hive】Hive返回碼狀態含義
- 8. Java樹形結構遞歸（以時間換空間）和非遞歸（以空間換時間）
- 9. 數據預處理---缺失值
- 10. 都要2021年了，現代C++有什麼值得我們學習的？