當前位置：首頁 > 编程语言 > java >内容正文

java

Java服务框架分析

發布時間：2025/3/21 java 24 豆豆

生活随笔收集整理的這篇文章主要介紹了 Java服务框架分析小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

Android服務框架由本地服務框架(Native Service Framework)和Java服務框架(Java Service Framework)兩部分組成。

Java服務框架是一系列類的集合，這些類用于支持開發Java系統服務，這些服務運行在基于Java的應用程序框架中。Java服務框架實際上是在本地服務框架的基礎上實現的，它通過JNI來使用本地服務框架中的功能，示意圖如下：

借助JNI，Java層的用戶不僅可以使用由Java語言編寫的服務，還可以使用由C++語言編寫的本地服務。

1.Java服務框架的層次結構

跟本地服務框架類似，Java服務框架也是分為三層：服務層、RPC層、IPC層。層次結構示意圖如下:

服務層

與本地服務框架不同，Java服務框架中的服務層需要實現FooManager類，原因是SDK包中并不包含ServiceManager類(實際上源碼中是存在這個類的，但是它被標記為@hide，所以不會被編譯進SDK中)，應用程序無法使用ServiceManager類來注冊或檢索系統服務。

因此，為了讓應用程序開發者能夠使用系統服務，系統服務開發者就需要將包裝類包含到SDK中。例如，為了讓應用程序開發者能夠使用FooService，系統服務開發者就要編寫FooManager包裝類，添加使用ServiceManager獲取FooService的功能，并將其編入SDK中。之后，應用程序開發者就可以通過包含在SDK中的FooManager類來使用FooService系統服務了。如下圖所示：

RPC層

Java服務框架使用Android平臺中的AIDL語言與編譯器自動生成服務代理和服務Stub.在Android系統中進程之間不能共享內存，為了使其他應用程序也可以訪問本應用程序提供的服務，Android系統采用了遠程過程調用的方式來實現，并使用AIDL來公開服務的接口。

IPC層

為了支持Binder IPC，本地服務框架提供了BpBinder與BBinder兩個類，Java服務框架則提供了BinderProxy與Binder兩個類。實際上，Java服務框架是通過JNI使用本地服務框架的Binder IPC，即BinderProxy與Binder通過JNI使用本地服務框架的BpBinder與BBinder類的功能。示意圖如下：

由上圖可知，用戶調用服務時，首先是BinderProxy的transact()方法使用JNI本地函數調用BpBinder的transact()函數，而后通過Binder IPC調用BBinder的transact()函數。之后BBinder會調用transact()函數，從而引起JavaBBinder對象的回調:onTransact()，而在該方法中會通過JNI調用Binder中的execTransact()方法，在execTransact()中會調用Stub的服務方法，從而最終調用服務。

2.實現過程

完整的Java系統服務實現包含注冊、獲取、調用這3個階段。下面就按這3個階段對Java系統服務框架進行分析。為了便于說明，此處以AlarmManagerService為例進行講解。

2.1 Java系統服務注冊

在ServiceManager類中，注冊服務的代碼如下：

public static void addService(String name,IBinder service){try{getIServiceManager().addService(name,service);}catch(RemoteException e){Log.e(TAG,"error in addService",e);} } 復制代碼

其中name為服務名稱，而service則為服務對象，如AlarmManagerService對象。然后看getIServiceManager()方法：

private static IServiceManager getIServiceManager(){if(sServiceManager!=null){return sServiceManager;}sServiceManager=ServiceManagerNative.asInterface(BinderInternal.getContextObject());return sServiceManager; } 復制代碼

首先分析BinderInternal.getContextObject()方法，其聲明如下：

public static final native IBinder getContextObject(); 復制代碼

顯然，這是一個native方法，它對應的本地函數是什么呢？在/frameworks/base/core/jni/android_util_Binder.cpp中有如下映射數組：

static const JNINativeMethod gBinderInternalMethods[] = {/* name, signature, funcPtr */{ "getContextObject", "()Landroid/os/IBinder;", (void*)android_os_BinderInternal_getContextObject },{ "joinThreadPool", "()V", (void*)android_os_BinderInternal_joinThreadPool },{ "disableBackgroundScheduling", "(Z)V", (void*)android_os_BinderInternal_disableBackgroundScheduling },{ "handleGc", "()V", (void*)android_os_BinderInternal_handleGc } }; 復制代碼

顯然，該native方法對應的本地函數為android_os_BinderInternal_getContextObject()，該函數的定義如下:

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

ProcessState::self()->getContextObject()方法在分析本地服務注冊的博客中講解過，它會返回一個BpBinder對象，而且該BpBinder對象的handle值為0; 然后進入javaObjectForIBinder()方法：

jobject javaObjectForIBinder(JNIEnv* env, const sp<IBinder>& val) {if (val == NULL) return NULL;if (val->checkSubclass(&gBinderOffsets)) {// One of our own!jobject object = static_cast<JavaBBinder*>(val.get())->object();//printf("objectForBinder %p: it's our own %p!\n", val.get(), object);return object;}// For the rest of the function we will hold this lock, to serialize// looking/creation of Java proxies for native Binder proxies.AutoMutex _l(mProxyLock);// Someone else's... do we know about it?jobject object = (jobject)val->findObject(&gBinderProxyOffsets);if (object != NULL) {jobject res = env->CallObjectMethod(object, gWeakReferenceOffsets.mGet);if (res != NULL) {LOGV("objectForBinder %p: found existing %p!\n", val.get(), res);return res;}LOGV("Proxy object %p of IBinder %p no longer in working set!!!", object, val.get());android_atomic_dec(&gNumProxyRefs);val->detachObject(&gBinderProxyOffsets);env->DeleteGlobalRef(object);}object = env->NewObject(gBinderProxyOffsets.mClass, gBinderProxyOffsets.mConstructor);if (object != NULL) {LOGV("objectForBinder %p: created new %p!\n", val.get(), object);// The proxy holds a reference to the native object.env->SetIntField(object, gBinderProxyOffsets.mObject, (int)val.get());val->incStrong(object);// The native object needs to hold a weak reference back to the// proxy, so we can retrieve the same proxy if it is still active.jobject refObject = env->NewGlobalRef(env->GetObjectField(object, gBinderProxyOffsets.mSelf));val->attachObject(&gBinderProxyOffsets, refObject,jnienv_to_javavm(env), proxy_cleanup);// Note that a new object reference has been created.android_atomic_inc(&gNumProxyRefs);incRefsCreated(env);}return object; } 復制代碼

首先，前面說過val其實是對應一個handle值為0的BpBinder對象，而BpBinder并沒有重寫IBinder的checkSubclass()方法，故返回false，從而此處不新建JavaBBinder對象; 又由于第一次請求時BpBinder的findObject()返回值為NULL,故此處會通過env->NewObject()方法新建BinderProxy對象，并且將BpBinder對象保存到BinderProxy對象中的mObject中。

再回到BinderInternal中的native IBinder getContextObject()方法中，顯然它返回的是一個BinderProxy(BinderProxy繼承于IBinder)對象。

然后回到getIServiceManager()方法中，如下所示：

顯然，此時ServiceManagerNative.asInterface(BinderInternal.getContextObject());等價于ServiceManagerNative.asInterface(new BinderProxy());下面進入ServiceManagerNative.asInterface()方法：

static public IServiceManager asInterface(IBinder obj){if(obj==null){return null;}IServiceManager h=(IServiceManager)obj.queryLocalInterface(descriptor);if(in!=null){return in;}return new ServiceManagerProxy(obj);} ```這里的obj其實是BinderProxy對象，而BinderProxy的queryLocalInterface()方法始終返回null,故此處會新建ServiceManagerProxy對象，而ServiceManagerProxy的構造方法特別簡單： ```javapublic ServiceManagerProxy(IBinder remote){mRemote=remote;} 復制代碼

即將之前新建的BinderProxy對象保存在mRemote中。所以getIServiceManager().addService(name,service);其實調用ServiceManagerProxy中的addService()方法，代碼如下：

public void addService(String name,IBinder service)throws RemoteException{Parcel data=Parcel.obtain();Parcel reply=Parcel.obtain();data.writeInterfaceToken(IServiceManager.descriptor);data.writeString(name);data.writeStrongBinder(service);mRemote.transact(ADD_SERVICE_TRANSACTION,data,reply,0);reply.recycle();data.recycle(); } 復制代碼

該方法中首先是將RPC數據寫入到data中，接口描述符和服務名稱都很好理解，關鍵是data.writeStringBinder(service);注意service是AlarmManagerService對象。 Parcel類的writeStrongBinder()方法如下：

public final native void writeStrongBinder(IBinder val); 復制代碼

顯然，它是一個native方法，類似地，在/frameworks/base/core/jni/android_util_Binder.cpp中可以找到它對應的本地函數是android_os_Parcel_writeStrongBinder(),其代碼如下(注意傳入的參數clazz是Java中的Parcel類對象，object則是AlarmManagerService對象)：

static void android_os_Parcel_writeStrongBinder(JNIEnv* env, jobject clazz, jobject object) {Parcel* parcel = parcelForJavaObject(env, clazz);if (parcel != NULL) {const status_t err = parcel->writeStrongBinder(ibinderForJavaObject(env, object));if (err != NO_ERROR) {jniThrowException(env, "java/lang/OutOfMemoryError", NULL);}} } 復制代碼

其中parcelForJavaObject()的目的是將Parcel(Java類)中的mObject轉化為Parcel(C++)指針。在分析Parcel(C++)類的writeStrongBinder()方法之前，我們先分析ibinderForJavaObject()方法，注意此處傳入的參數obj是AlarmManagerService對象：

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) : NULL;}if (env->IsInstanceOf(obj, gBinderProxyOffsets.mClass)) {return (IBinder*)env->GetIntField(obj, gBinderProxyOffsets.mObject);}LOGW("ibinderForJavaObject: %p is not a Binder object", obj);return NULL; } 復制代碼

由于AlarmManagerService繼承于IAlarmManager.Stub，而IAlarmManager.Stub繼承于Binder，而gBinderOffsets.mClass對應的正是Binder類，故env->IsInstanceOf(obj,gBinderOffsets.mClass)這個判斷成立，從而會新建JavaBBinderHolder類，其構造函數如下：

JavaBBinderHolder(JNIEnv*env,jobject object):mObject(object) {LOGV("Creating JavaBBinderHolder for Object %p\n",object); } 復制代碼

顯然，AlarmManagerService對象被賦值給了JavaBBinderHolder中的mObject成員; 之后返回jbh->get(evn)，而JavaBBinder的get()方法如下：

sp<JavaBBinder> get(JNIEnv* env) {AutoMutex _l(mLock);sp<JavaBBinder> b = mBinder.promote();if (b == NULL) {b = new JavaBBinder(env, mObject);mBinder = b;LOGV("Creating JavaBinder %p (refs %p) for Object %p, weakCount=%d\n",b.get(), b->getWeakRefs(), mObject, b->getWeakRefs()->getWeakCount());}return b; } 復制代碼

顯然這里采用了懶加載的方式，在第一次使用時新建了JavaBBinder對象，注意前面說到的mObject，它實際上對應AlarmManagerService對象。而JavaBBinder的構造函數如下：

JavaBBinder(JNIEnv* env, jobject object): mVM(jnienv_to_javavm(env)), mObject(env->NewGlobalRef(object)){LOGV("Creating JavaBBinder %p\n", this);android_atomic_inc(&gNumLocalRefs);incRefsCreated(env);} 復制代碼

首先jnienv_to_javavm()函數的作用是通過jni環境獲得java虛擬機并且賦值給mVm;
之后為object(AlarmManagerService對象的本地引用)創建全局引用，這種對象如果不主動釋放，它永遠都不會被垃圾回收，這樣做的目的是為了讓AlarmManagerService在手機開機時一直保持運行。
再回到ibinderForJavaObject()這個方法中，通過上面的分析我們知道它返回一個JavaBBinder對象，并且該對象中的mObject保存著AlarmManagerService對象的本地引用;
再回到android_os_Parcel_writeStrongBinder()方法中，parcel->writeStrongBinder(ibinderForJavaObject(env, object))就等價于parcel->writeStrongBinder(new JavaBBinder());注意這里是和單純的本地系統服務注冊過程中不同的地方，單純的本地系統服務中在writeStrongBinder(service);中的service是本地服務對象，如MediaPlayerService對象，而這里用的是JavaBBinder，它有點像一個包裝類，將Java服務對象(如AlarmManagerService對象)包裝在它的成員mObject中。這個mObject后面還會提到.
而writeStrongBinder()方法的代碼如下：

status_t Parcel::writeStrongBinder(const sp<IBinder>& val){return flatten_binder(Process::self(),val,this);} 復制代碼

注意這里傳入的參數val是JavaBBinder對象。flatten_binder()方法如下：

status_t flatten_binder(const sp<ProcessState>& proc,const sp<IBinder>& binder, Parcel* out){flat_binder_object obj;obj.flags = 0x7f | FLAT_BINDER_FLAG_ACCEPTS_FDS;if (binder != NULL) {IBinder *local = binder->localBinder();if (!local) {BpBinder *proxy = binder->remoteBinder();if (proxy == NULL) {LOGE("null proxy");}const int32_t handle = proxy ? proxy->handle() : 0;obj.type = BINDER_TYPE_HANDLE;obj.handle = handle;obj.cookie = NULL;} else {obj.type = BINDER_TYPE_BINDER;obj.binder = local->getWeakRefs();obj.cookie = local;}} else {obj.type = BINDER_TYPE_BINDER;obj.binder = NULL;obj.cookie = NULL;}return finish_flatten_binder(binder, obj, out);} 復制代碼

這里的binder其實是JavaBBinder對象，而JavaBBinder繼承于BBinder,它重寫了localBinder()方法，返回this,所以這里執行的是如下代碼：

obj.type = BINDER_TYPE_BINDER; obj.binder = local->getWeakRefs(); obj.cookie = local; 復制代碼

所以flat_binder_object對象obj的成員type為BINDER_TYPE_BINDER,成員binder則為JavaBBinder對象的弱引用，成員cookie則保存著JavaBBinder對象。之后Parcel方法的調用與單純的本地系統服務一致。

再回到addService()方法中：

mRemote在之前已經說過，它是一個BinderProxy對象，所以mRemote.transact()實際上調用的是BinderProxy的transact()方法，代碼如下：

public native boolean transact(int code,Parcel data,Parcel reply,int flags) throws RemoteException; 復制代碼

顯然，這是一個native方法，它對應的本地函數也可以在/frameworks/base/core/jni/android_util_Binder.cpp中找到，對應的函數是android_os_BinderProxy_transact()，如下所示，注意傳入的參數obj為BinderProxy對象，code為ADD_SERVICE_TRANSACTION,dataObj為上面的Parcel對象data的本地引用(其中data中含有IServiceManager接口描述符,服務名稱以及AlarmManagerService對象),replyObj則為Parcel對象的本地引用：

static jboolean android_os_BinderProxy_transact(JNIEnv* env, jobject obj,jint code, jobject dataObj,jobject replyObj, jint flags) {if (dataObj == NULL) {jniThrowException(env, "java/lang/NullPointerException", NULL);return JNI_FALSE;}Parcel* data = parcelForJavaObject(env, dataObj);if (data == NULL) {return JNI_FALSE;}Parcel* reply = parcelForJavaObject(env, replyObj);if (reply == NULL && replyObj != NULL) {return JNI_FALSE;}IBinder* target = (IBinder*)env->GetIntField(obj, gBinderProxyOffsets.mObject);if (target == NULL) {jniThrowException(env, "java/lang/IllegalStateException", "Binder has been finalized!");return JNI_FALSE;}LOGV("Java code calling transact on %p in Java object %p with code %d\n",target, obj, code);// Only log the binder call duration for things on the Java-level main thread.// But if we don'tconst bool time_binder_calls = should_time_binder_calls();int64_t start_millis;if (time_binder_calls) {start_millis = uptimeMillis();}//printf("Transact from Java code to %p sending: ", target); data->print();status_t err = target->transact(code, *data, reply, flags);//if (reply) printf("Transact from Java code to %p received: ", target); reply->print();if (time_binder_calls) {conditionally_log_binder_call(start_millis, target, code);}if (err == NO_ERROR) {return JNI_TRUE;} else if (err == UNKNOWN_TRANSACTION) {return JNI_FALSE;}signalExceptionForError(env, obj, err);return JNI_FALSE; } 復制代碼

前面的代碼都是將Java中的Parcel對象轉化為C++中的Parcel對象，之后獲取BinderProxy中的mObject成員，前面說過，mObject成員保存的是BpBinder對象，所以這里IBinder*target其實指向的是BpBinder對象。從而target->transact()其實調用的是BpBinder的transact()方法，該方法的代碼如下:

status_t BpBinder::transact(uint32_t code,const Parcel& data,Parcel* reply,uint32_t flags) {if(mAlive){status_t status=IPCThreadState::self()->transact(mHandle,code,data,reply,flags);if(status==DEAD_OBJECT) mAlive=0;return status;}return DEAD_OBJECT; } 復制代碼

然后進入IPCThreadState的transact()方法，其主要代碼如下：

status_t IPCThreadState::transact(int32_t handle,uint32_t code, const Parcel& data,Parcel* reply, uint32_t flags){status_t err = data.errorCheck();flags |= TF_ACCEPT_FDS;if (err == NO_ERROR) {err = writeTransactionData(BC_TRANSACTION, flags, handle, code, data, NULL);}if (err != NO_ERROR) {if (reply) reply->setError(err);return (mLastError = err);}if ((flags & TF_ONE_WAY) == 0) {if (reply) {//we will get reply from this function.err = waitForResponse(reply);} else {Parcel fakeReply;err = waitForResponse(&fakeReply);}} else {err = waitForResponse(NULL, NULL);}return err;} 復制代碼

然后進入writeTransactionData()函數中，注意傳入的參數cmd為BC_TRANSACTION,binderFlags為flags(0),handle為0,code為ADD_SERVICE_TRANSACTION,data為上面的Parcel對象,statusBuffer為NULL：

status_t IPCThreadState::writeTransactionData(int32_t cmd, uint32_t binderFlags,int32_t handle, uint32_t code, const Parcel& data, status_t* statusBuffer){binder_transaction_data tr;tr.target.handle = handle;tr.code = code;tr.flags = binderFlags;const status_t err = data.errorCheck();if (err == NO_ERROR) {tr.data_size = data.ipcDataSize();tr.data.ptr.buffer = data.ipcData();tr.offsets_size = data.ipcObjectsCount()*sizeof(size_t);tr.data.ptr.offsets = data.ipcObjects();} else if (statusBuffer) {...} else {return (mLastError = err);}mOut.writeInt32(cmd);mOut.write(&tr, sizeof(tr));return NO_ERROR;} 復制代碼

顯然，這里主要就是將IPC數據寫入binder_transaction_data對象中,并且將cmd(此處值為BC_TRANSACTION)寫入到mOut中.

再回到IPCThreadState::transact()方法中，之后執行waitForResponse()方法中,其代碼如下：

status_t IPCThreadState::waitForResponse(Parcel *reply, status_t *acquireResult) {int32_t cmd;int32_t err;while (1) {if ((err=talkWithDriver()) < NO_ERROR) break;err = mIn.errorCheck();if (err < NO_ERROR) break;if (mIn.dataAvail() == 0) continue;cmd = mIn.readInt32();switch (cmd) {case BR_TRANSACTION_COMPLETE:if (!reply && !acquireResult) goto finish;break;case BR_DEAD_REPLY:err = DEAD_OBJECT;goto finish;case BR_FAILED_REPLY:err = FAILED_TRANSACTION;goto finish;case BR_ACQUIRE_RESULT:{LOG_ASSERT(acquireResult != NULL, "Unexpected brACQUIRE_RESULT");const int32_t result = mIn.readInt32();if (!acquireResult) continue;*acquireResult = result ? NO_ERROR : INVALID_OPERATION;}goto finish;case BR_REPLY:{binder_transaction_data tr;err = mIn.read(&tr, sizeof(tr));LOG_ASSERT(err == NO_ERROR, "Not enough command data for brREPLY");if (err != NO_ERROR) goto finish;if (reply) {if ((tr.flags & TF_STATUS_CODE) == 0) {reply->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);} else {err = *static_cast<const status_t*>(tr.data.ptr.buffer);freeBuffer(NULL,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), this);}} else {freeBuffer(NULL,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), this);continue;}}goto finish;default:err = executeCommand(cmd);if (err != NO_ERROR) goto finish;break;}} finish:if (err != NO_ERROR) {if (acquireResult) *acquireResult = err;if (reply) reply->setError(err);mLastError = err;}return err; } 復制代碼

talkWithDriver()的作用，就是將保存在mOut中的Binder IPC數據傳遞給Binder Driver，并將來自Binder Driver的Binder IPC數據保存在mIn中，同時會新建binder_node.

在talkWithDriver()中新建完binder_node之后，Binder IPC協議就變成BR_REPLY,所以此時tr中包含的數據就是BR_REPLY和binder_transaction_data對象，之后通過調用ipcSetDataReference()方法將注冊AlarmManagerService的結果存入到Parcel對象reply中，至此，添加服務的過程就完成了。

2.2 Java系統服務獲取

當Context對象(如Activity)調用getSystemService(Context.ALARM_SERVICE)方法時，實際調用的是ContextImpl中的getSystemService()方法，該方法如下：

@Override public Object getSystemService(String name) {if (WINDOW_SERVICE.equals(name)) {return WindowManagerImpl.getDefault();} else if (LAYOUT_INFLATER_SERVICE.equals(name)) {synchronized (mSync) {LayoutInflater inflater = mLayoutInflater;if (inflater != null) {return inflater;}mLayoutInflater = inflater =PolicyManager.makeNewLayoutInflater(getOuterContext());return inflater;}} else if (ACTIVITY_SERVICE.equals(name)) {return getActivityManager();} else if (INPUT_METHOD_SERVICE.equals(name)) {return InputMethodManager.getInstance(this);} else if (ALARM_SERVICE.equals(name)) {return getAlarmManager();} else if (ACCOUNT_SERVICE.equals(name)) {return getAccountManager();} else if (POWER_SERVICE.equals(name)) {return getPowerManager();} else if (CONNECTIVITY_SERVICE.equals(name)) {return getConnectivityManager();} else if (THROTTLE_SERVICE.equals(name)) {return getThrottleManager();} else if (WIFI_SERVICE.equals(name)) {return getWifiManager();} else if (NOTIFICATION_SERVICE.equals(name)) {return getNotificationManager();} else if (KEYGUARD_SERVICE.equals(name)) {return new KeyguardManager();} else if (ACCESSIBILITY_SERVICE.equals(name)) {return AccessibilityManager.getInstance(this);} else if (LOCATION_SERVICE.equals(name)) {return getLocationManager();} else if (SEARCH_SERVICE.equals(name)) {return getSearchManager();} else if (SENSOR_SERVICE.equals(name)) {return getSensorManager();} else if (STORAGE_SERVICE.equals(name)) {return getStorageManager();} else if (VIBRATOR_SERVICE.equals(name)) {return getVibrator();} else if (STATUS_BAR_SERVICE.equals(name)) {synchronized (mSync) {if (mStatusBarManager == null) {mStatusBarManager = new StatusBarManager(getOuterContext());}return mStatusBarManager;}} else if (AUDIO_SERVICE.equals(name)) {return getAudioManager();} else if (TELEPHONY_SERVICE.equals(name)) {return getTelephonyManager();} else if (CLIPBOARD_SERVICE.equals(name)) {return getClipboardManager();} else if (WALLPAPER_SERVICE.equals(name)) {return getWallpaperManager();} else if (DROPBOX_SERVICE.equals(name)) {return getDropBoxManager();} else if (DEVICE_POLICY_SERVICE.equals(name)) {return getDevicePolicyManager();} else if (UI_MODE_SERVICE.equals(name)) {return getUiModeManager();}return null; } 復制代碼

由于傳入的參數為Context.ALARM_SERVICE,進入getAlarmManager()方法中：

private AlarmManager getAlarmManager() {synchronized (sSync) {if (sAlarmManager == null) {IBinder b = ServiceManager.getService(ALARM_SERVICE);IAlarmManager service = IAlarmManager.Stub.asInterface(b);sAlarmManager = new AlarmManager(service);}}return sAlarmManager; } 復制代碼

首先分析ServiceManager.getService()這個方法：

public static IBinder getService(String name) {try{IBinder service=cCache.get(name);if(service!=null){return service;}else if{return getIServiceManager().getService(name);}}catch(RemoteException e){Log.e(TAG,"error in getService",e);}return null; } 復制代碼

如果是第一次請求該服務，則沒有緩存，從而調用getIServiceManager().getService()方法。

在上面的服務注冊過程中分析了getIServiceManager()其實返回的是ServiceManagerProxy對象，并且該ServiceManagerProxy對象中的mRemote保存著BinderProxy對象。

再回到ServiceManager.getService()方法中，可知getIServiceManager().getService()其實調用的是ServiceManagerProxy的getService()方法，該方法的代碼如下：

public IBinder getService(String name) throws RemoteException{Parcel data=Parcel.obtain();Parcel reply=Parcel.obtain();data.writeInterfaceToken(IServiceManager.descriptor);data.writeString(name);mRemote.transact(GET_SERVICE_TRANSACTION,data,reply,0);IBinder binder=reply.readStrongBinder();reply.recycle();data.recycle();return binder; } 復制代碼

這個方法里，重點是mRemote.transact(GET_SERVICE_TRANSACTION,data,reply,0);這個語句，前面說過，mRemote是一個BinderProxy對象，所以這里其實調用的是BinderProxy的transact()方法，代碼如下：

public native boolean transact(int code,Parcel data,Parcel reply,int flags) throws RemoteException; 復制代碼

顯然，這是一個native方法，它對應的本地函數也可以在/frameworks/base/core/jni/android_util_Binder.cpp中找到，對應的函數是android_os_BinderProxy_transact()，如下所示：

返回到getService()方法中，下面要調用的是reply.readStrongBinder();該方法的定義如下：

public final native IBinder readStrongBinder(); 復制代碼

顯然，該方法是一個native方法，它對應的是android_os_Parcel_readStrongBinder()函數：

static jobject android_os_Parcel_readStrongBinder(JNIEnv*env,jobject clazz) {Parcel*parcel=parcelForJavaObject(env,clazz);if(parcel!=null){return javaObjectForIBinder(env,parcel->readStrongBinder());}return NULL; } 復制代碼

readStrongBinder()實際上返回的是一個持有相應服務handle值的BpBinder對象(注意，這個BpBinder對象和前面的BpBinder對象不同，前面的BpBinder持有的handle值為0，而此處為AlarmManagerService注冊的handle值).

而javaObjectForIBinder()函數在前面已經分析過，它會生成一個BinderProxy對象，并且將剛剛生成的BpBinder對象保存在BinderProxy中的mObject中.

getService()方法就分析完了，最終結果是返回BinderProxy對象，并且該對象中的mObject保存著對應于AlarmManagerService的BpBinder對象.

下面再回到getAlarmManager()中：

下面分析IAlarmManager.Stub.asInterface()方法：

public static android.app.IAlarmManager asInterface(android.os.IBinder obj) {if(obj==null){return null;}android.os.IInterface iin=(android.os.IInterface)obj.queryLocalInterface(DESCRIPTOR);if((iin!=null)&&(iin instanceof android.app.IAlarmManager)){return ((android.app.IAlarmManager)iin);}return new android.app.IAlarmManager.Stub.Proxy(obj); } 復制代碼

前面說過，這個obj其實是BinderProxy對象，前面說過，BinderProxy的queryLocalInterface()始終返回null,所以這里會新建IAlarmManager.Stub.Proxy對象，其構造方法如下：

Proxy(android.os.IBinder remote) {mRemote=remote; } 復制代碼

即將BinderProxy對象保存在Proxy中的mRemote成員中。

再回到getAlarmManager()方法中，可見service其實是一個IAlarmManager.Stub.Proxy對象。下面一句很簡單，就是新建AlarmManager對象，其構造方法如下：

AlarmManager(IAlarmManager service){mService=service; } 復制代碼

將前面新建的IAlarmManager.Stub.Proxy對象保存在AlarmManager中的mService對象中。

我們就成功獲取到了AlarmManager對象，并且AlarmManager對象中的mService保存著IAlarmManager.Stub.Proxy對象，而Proxy對象中保存著BinderProxy對象，BinderProxy對象中保存著持有AlarmManagerService的handle值的BpBinder(C++)對象.

由于BpBinder持有了AlarmManagerService的handle值，所以到這里就相當于獲取到了我們需要的鬧鐘服務。

2.3 Java系統服務調用

獲取到服務后，返回AlarmManager對象，調用鬧鐘服務的過程示意圖如下所示：

獲取了AlarmManager對象之后，比如調用setTime()方法，代碼如下：

public void setTime(long millis){try{mService.setTime(millis);}catch(RemoteException ex){} } 復制代碼

前面說過，mService其實是IAlarmManager.Stub.Proxy對象，所以mService.setTime(millis);其實是調用IAlarmManager.Stub.Proxy的setTime()方法，代碼如下所示：

public void setTime(long millis) 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.writeLong(millis);mRemote.transact(Stub.TRANSACTION_setTime,_data,_reply,0);_reply.readException();}finally{_reply.recycle();_data.recycle();} } 復制代碼

前面說過，保存在Proxy對象中的mRemote中保存的是BinderProxy對象，而BinderProxy的transact()是個native方法，它對應的本地函數為android_os_BinderProxy_transact()，注意傳入的參數obj為BinderProxy對象的本地引用,code為Stub.TRANSACTION_setTime,dataObj為保存Binder IPC數據的Parcel對象,replyObj則用于存放返回結果:

顯然，這里會調用BpBinder對象的transact()方法，需要注意的是這個BpBinder對象是持有AlarmManagerService的handle值的BpBinder，而不是handle值為0的BpBinder. 之后仍然是調用IPCThreadState::transact()方法，writeTransactionData()也都差別不大,但是注意handle,code值不一樣,其中handle為AlarmManagerService對應的handle值，code則為Stub.TRANSACTION_setTime. 然后調用waitForResponse()方法，客戶端進程進入等待狀態。

而Service Server進程則被喚醒，開始執行命令，下面是IPCThreadState::executeCommand()方法的主要代碼：

status_t IPCThreadState::executeCommand(int32_t cmd) {BBinder* obj;RefBase::weakref_type* refs;status_t result = NO_ERROR;switch (cmd) {...case BR_TRANSACTION:{binder_transaction_data tr;result = mIn.read(&tr, sizeof(tr));LOG_ASSERT(result == NO_ERROR,"Not enough command data for brTRANSACTION");if (result != NO_ERROR) break;Parcel buffer;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);const pid_t origPid = mCallingPid;const uid_t origUid = mCallingUid;mCallingPid = tr.sender_pid;mCallingUid = tr.sender_euid;int curPrio = getpriority(PRIO_PROCESS, mMyThreadId);if (gDisableBackgroundScheduling) {if (curPrio > ANDROID_PRIORITY_NORMAL) {// We have inherited a reduced priority from the caller, but do not// want to run in that state in this process. The driver set our// priority already (though not our scheduling class), so bounce// it back to the default before invoking the transaction.setpriority(PRIO_PROCESS, mMyThreadId, ANDROID_PRIORITY_NORMAL);}} else {if (curPrio >= ANDROID_PRIORITY_BACKGROUND) {// We want to use the inherited priority from the caller.// Ensure this thread is in the background scheduling class,// since the driver won't modify scheduling classes for us.// The scheduling group is reset to default by the caller// once this method returns after the transaction is complete.androidSetThreadSchedulingGroup(mMyThreadId,ANDROID_TGROUP_BG_NONINTERACT);}}Parcel reply;if (tr.target.ptr) {sp<BBinder> b((BBinder*)tr.cookie);const status_t error = b->transact(tr.code, buffer, &reply, 0);if (error < NO_ERROR) reply.setError(error);} else {const status_t error = the_context_object->transact(tr.code, buffer, &reply, 0);if (error < NO_ERROR) reply.setError(error);}if ((tr.flags & TF_ONE_WAY) == 0) {LOG_ONEWAY("Sending reply to %d!", mCallingPid);sendReply(reply, 0);} else {LOG_ONEWAY("NOT sending reply to %d!", mCallingPid);}mCallingPid = origPid;mCallingUid = origUid;}break;...}if (result != NO_ERROR) {mLastError = result;}return result; } 復制代碼

這里先將tr.cookie轉化為BBinder指針.前面已經說過,與單純的本地服務不同，tr.cookie中存放的不是類似MediaPlayerService對象指針，而是JavaBBinder對象指針，而之前分析過BBinder的transact()中會調用onTransact()方法，JavaBBinder又重寫了onTransact()方法，因而此處調用的是JavaBBinder中的onTransact()方法，其代碼主要如下：

virtual status_t onTransact(uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags = 0) {JNIEnv* env = javavm_to_jnienv(mVM);jboolean res = env->CallBooleanMethod(mObject, gBinderOffsets.mExecTransact,code, (int32_t)&data, (int32_t)reply, flags);jthrowable excep = env->ExceptionOccurred();if (excep) {report_exception(env, excep,"*** Uncaught remote exception! ""(Exceptions are not yet supported across processes.)");res = JNI_FALSE;/* clean up JNI local ref -- we don't return to Java code */env->DeleteLocalRef(excep);}//aout << "onTransact to Java code; result=" << res << endl// << "Transact from " << this << " to Java code returning "// << reply << ": " << *reply << endl;return res != JNI_FALSE ? NO_ERROR : UNKNOWN_TRANSACTION; } 復制代碼

前面說過，JavaBBinder對象中mObject成員是AlarmManagerService對象，因而這里調用的是AlarmManagerService對象的execTransact()方法(因為AlarmManagerService繼承于IAlarmManager.Stub,而IAlarmManager.Stub又繼承于Binder,Binder中定義了execTransact()方法),代碼如下：

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);}catch(RemoteException e){reply.writeException(e);res=true;}catch(RuntimeException e){reply.writeException(e);res=true;}reply.recycle();data.recycle();return res; } 復制代碼

顯然，這里會調用Stub中的onTransact()方法，代碼如下:

@Override public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) throws android.os.RemoteException {switch (code){...case TRANSACTION_setTime:{data.enforceInterface(DESCRIPTOR);long _arg0;_arg0 = data.readLong();this.setTime(_arg0);reply.writeNoException();return true;}case TRANSACTION_setTimeZone:{data.enforceInterface(DESCRIPTOR);java.lang.String _arg0;_arg0 = data.readString();this.setTimeZone(_arg0);reply.writeNoException();return true;}case TRANSACTION_remove:{data.enforceInterface(DESCRIPTOR);android.app.PendingIntent _arg0;if ((0!=data.readInt())) {_arg0 = android.app.PendingIntent.CREATOR.createFromParcel(data);}else {_arg0 = null;}this.remove(_arg0);reply.writeNoException();return true;}}return super.onTransact(code, data, reply, flags); } 復制代碼

總結

以上是生活随笔為你收集整理的Java服务框架分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

JAVA
框架

上一篇： springcloud13---zuul
下一篇： Git 分支 - 变基