本文的調(diào)查基于Android P的原生源代碼崖飘。
本周在處理某一款應(yīng)用的問題時，遇到一處名為ServiceConnectionLeaked的運行時異常，異常信息如下：
Service com.xxx.xxx.alexaservice.MetroAlexaAudioProviderService has leaked ServiceConnection com.xxx.xxx.connection.MetroConnection@32dc748 that was originally bound here
備注：因涉及三方應(yīng)用强挫，所以包名以com.xxx.xxx替換
詳細(xì)信息：
10-29 15:15:19.422 1000 1190 1209 I ActivityManager: Start proc 2308:com.xxx.xxx/u0a165 for activity com.xxx.xxx/com.xxx.xxx.AlexaSettingsLauncherActivity caller=com.android.settings
......
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: Service com.xxx.xxx.alexaservice.MetroAlexaAudioProviderService has leaked ServiceConnection com.xxx.xxx.connection.MetroConnection@32dc748 that was originally bound here
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: android.app.ServiceConnectionLeaked: Service com.xxx.xxx.alexaservice.MetroAlexaAudioProviderService has leaked ServiceConnection com.xxx.xxx.connection.MetroConnection@32dc748 that was originally bound here
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at android.app.LoadedApk$ServiceDispatcher.<init>(LoadedApk.java:1618)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at android.app.LoadedApk.getServiceDispatcher(LoadedApk.java:1510)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at android.app.ContextImpl.bindServiceCommon(ContextImpl.java:1670)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at android.app.ContextImpl.bindService(ContextImpl.java:1623)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at android.content.ContextWrapper.bindService(ContextWrapper.java:708)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at com.xxx.xxx.alexaservice.MetroAlexaAudioProviderService.connectToMetroService(MetroAlexaAudioProviderService.java:168)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at com.xxx.xxx.alexaservice.MetroAlexaAudioProviderService.doBind(MetroAlexaAudioProviderService.java:68)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at com.xxx.xxx.AlexaAudioProviderService.onBind(Unknown Source:0)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at android.app.ActivityThread.handleBindService(ActivityThread.java:3626)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at android.app.ActivityThread.access$1600(ActivityThread.java:207)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1722)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at android.os.Handler.dispatchMessage(Handler.java:106)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at android.os.Looper.loop(Looper.java:201)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at android.app.ActivityThread.main(ActivityThread.java:6831)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at java.lang.reflect.Method.invoke(Native Method)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:547)
10-29 15:15:20.360 10165 2308 2308 E ActivityThread: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:927)
從異常信息中仰楚，粗略看到Service對象MetroAlexaAudioProviderService泄漏了其成員變量MetroConnection@32dc748隆判，這一變量是ServiceConnection類型。有些疑惑僧界。
ServiceConnectionLeaked是繼承自AndroidRuntimeException類的子類侨嘀。
先解釋下該應(yīng)用（包名：com.xxx.xxx）的這段異常堆棧吧，通過反編譯apk源代碼發(fā)現(xiàn)捂襟，原來是：
com.xxx.xxx進(jìn)程啟動后咬腕，有調(diào)用端通過bindService來綁定服務(wù)
MetroAlexaAudioProviderService（父類：com.xxx.xxx.AlexaAudioProviderService），MetroAlexaAudioProviderService的doBind方法執(zhí)行中葬荷，會調(diào)用connectToMetroService方法綁定另外一個新的服務(wù)綁定新服務(wù)過程：ContextWrapper.bindService → ContextImpl.bindService → ContextImpl.bindServiceCommon → android.app.LoadedApk.getServiceDispatcher → android.app.LoadedApk$ServiceDispatcher.<init>涨共，最后突然拋出ServiceConnectionLeaked異常，也就是我們看到的上面Java異常棧宠漩。
查看棧頂?shù)恼{(diào)用at android.app.LoadedApk$ServiceDispatcher.<init>(LoadedApk.java:1618)举反，這里的代碼是：
// android/app/LoadedApk.java
ServiceDispatcher(ServiceConnection conn,
Context context, Handler activityThread, int flags) {
mIServiceConnection = new InnerConnection(this);
mConnection = conn;
mContext = context;
mActivityThread = activityThread;
mLocation = new ServiceConnectionLeaked(null);
mLocation.fillInStackTrace(); // LoadedApk.java:1618
mFlags = flags;
}
第1618行是mLocation.fillInStackTrace方法。熟悉此方法的同學(xué)了解扒吁，這里相當(dāng)于埋雷火鼻，預(yù)先收集了執(zhí)行到此函數(shù)的Java棧調(diào)用，像是保存了相關(guān)快照，但異常并非在這里拋出魁索！
那異常是在哪里拋出的融撞？根據(jù)"Service xxx has leaked ServiceConnection xxx that was originally bound here"，我們可以發(fā)現(xiàn)蛾默，真正觸發(fā)并拋出異常的代碼位置是：android/app/LoadedApk.java中 removeContextRegistrations方法懦铺，
public void removeContextRegistrations(Context context,
String who, String what) {
// ...
synchronized (mServices) {
//Slog.i(TAG, "Receiver registrations: " + mReceivers);
ArrayMap<ServiceConnection, LoadedApk.ServiceDispatcher> smap =
mServices.remove(context);
if (smap != null) {
for (int i = 0; i < smap.size(); i++) {
LoadedApk.ServiceDispatcher sd = smap.valueAt(i);
ServiceConnectionLeaked leak = new ServiceConnectionLeaked(
what + " " + who + " has leaked ServiceConnection "
+ sd.getServiceConnection() + " that was originally bound here");
leak.setStackTrace(sd.getLocation().getStackTrace());
Slog.e(ActivityThread.TAG, leak.getMessage(), leak);
if (reportRegistrationLeaks) {
StrictMode.onServiceConnectionLeaked(leak);
}
try {
ActivityManager.getService().unbindService(
sd.getIServiceConnection());
} catch (RemoteException e) {
throw e.rethrowFromSystemServer();
}
sd.doForget();
}
}
// ...
}
}
removeContextRegistrations方法最后觸發(fā)了ServiceConnectionLeaked異常，那什么時候會調(diào)用removeContextRegistrations支鸡，并觸發(fā)這樣的異常呢冬念？
通過查看frameworks/base/core/java/android/app/源碼，以下是removeContextRegistrations的正常2種使用場景調(diào)用：
ActivityThread#handleDestroyActivity → ContextImpl#scheduleFinalCleanup → ContextImpl#performFinalCleanup → LoadedApk#removeContextRegistrations
ActivityThread#handleStopService → ContextImpl#scheduleFinalCleanup → ContextImpl#performFinalCleanup → LoadedApk#removeContextRegistrations
總結(jié)來說牧挣，應(yīng)用的Acitivty和Service在銷毀時急前，會最終調(diào)用到LoadedApk#removeContextRegistrations方法，這里有可能會拋出ServiceConnectionLeaked異常瀑构。
那下一個問題是裆针，為何會拋出ServiceConnectionLeaked異常？它的作用是什么呢寺晌？
這里先要學(xué)習(xí)下Android中bindService世吨、unbindService的代碼實現(xiàn)知識：
首先我們知道，客戶端在bindService時呻征，需要生成一個ServiceConnection對象耘婚，該對象會封裝為一個ServiceDispatcher對象，并將其內(nèi)部類InnerConnection對象陆赋，通過ActivityManager#bindService沐祷，binder調(diào)用傳遞給AMS
-
注意：內(nèi)部類InnerConnection對象是一個Binder對象，傳遞給AMS的目的是攒岛，bindService成功執(zhí)行后赖临，AMS可以通過該對象回調(diào)其connected方法，最終在應(yīng)用端ServiceConnection對象的onServiceConnected方法被調(diào)用灾锯，一次完成的bindService成功完成兢榨！具體可參考：
- 服務(wù)端：com/android/server/am/ActiveServices.java#bindServiceLocked
- 客戶端：android/app/LoadedApk.java#ServiceDispatcher#InnerConnection類的connected方法
客戶端斷開服務(wù)時，會通過調(diào)用unbindService方法顺饮，ContextImpl#unbindService執(zhí)行時色乾，會先調(diào)用
LoadedApk#forgetServiceDispatcher方法，該方法作用非常重要：其會將本地ServiceConnection對象與其ServiceDispatcher對象關(guān)系從ArrayMap中移除领突，并執(zhí)行ServiceDispatcher的doForget方法（主要作用：解除針對服務(wù)端Service的死亡回調(diào)注冊暖璧。因為這是正常的unbind，不再需要監(jiān)聽服務(wù)端的死亡回調(diào)）君旦。
// android/app/ContextImpl.java
@Override
public void unbindService(ServiceConnection conn) {
if (conn == null) {
throw new IllegalArgumentException("connection is null");
}
if (mPackageInfo != null) {
IServiceConnection sd = mPackageInfo.forgetServiceDispatcher(
getOuterContext(), conn);
try {
ActivityManager.getService().unbindService(sd);
} catch (RemoteException e) {
throw e.rethrowFromSystemServer();
}
} else {
throw new RuntimeException("Not supported in system context");
}
}
那什么情況下會拋出ServiceConnectionLeaked異常呢澎办？我們看到正常情況下嘲碱，通過unbindService斷開服務(wù)時，本地保存的ArrayMap（ArrayMap<ServiceConnection, LoadedApk.ServiceDispatcher>）信息會被清理局蚀、刪除麦锯。但是ServiceConnectionLeaked異常拋出時，也就是方法
removeContextRegistrations中的邏輯執(zhí)行時琅绅，本地保存的ArrayMap（ArrayMap<ServiceConnection, LoadedApk.ServiceDispatcher>）信息仍然存在扶欣！這里可推斷說明：
結(jié)論：
應(yīng)用的Acitivty和Service在銷毀前，如果其已綁定一個服務(wù)Service千扶，那么應(yīng)用需主動調(diào)用unbindService方法（例如Acitity或Service的onDestroy方法中）解綁料祠。否則銷毀走到removeContextRegistrations方法邏輯中時，就會拋出ServiceConnectionLeaked異常澎羞，并通過提前埋雷的方式髓绽，將相關(guān)棧信息打印出來，以便開發(fā)者查清原因妆绞。
最后顺呕，本地Demo復(fù)現(xiàn)此問題：
我們在Demo應(yīng)用（包名：com.kevin.test）的Activity#onCreate中調(diào)用bindService來綁定服務(wù)，onDestroy方法中未調(diào)用unbindService括饶，那么打開頁面Activity后株茶，進(jìn)入最近任務(wù)，強(qiáng)制上滑殺掉應(yīng)用图焰，那么日志中就會發(fā)現(xiàn)ServiceConnectionLeaked異常信息了启盛。示例如下：
public class MainActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
TestService service = new TestService(this);
service.connectService(); //其中會調(diào)用mContext.bindService(intent, mConnection, mContext.BIND_AUTO_CREATE);
}
@Override
protected void onDestroy() {
super.onDestroy();
}
}
拋出的異常信息：
11-04 14:39:20.624 11439 11439 E ActivityThread: Activity com.kevin.test.MainActivity has leaked ServiceConnection com.kevin.test.TestService$2@3201e07 that was originally bound here
11-04 14:39:20.624 11439 11439 E ActivityThread: android.app.ServiceConnectionLeaked: Activity com.kevin.test.MainActivity has leaked ServiceConnection com.kevin.test.TestService$2@3201e07 that was originally bound here
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.app.LoadedApk$ServiceDispatcher.<init>(LoadedApk.java:1618)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.app.LoadedApk.getServiceDispatcher(LoadedApk.java:1510)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.app.ContextImpl.bindServiceCommon(ContextImpl.java:1669)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.app.ContextImpl.bindService(ContextImpl.java:1622)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.content.ContextWrapper.bindService(ContextWrapper.java:708)
11-04 14:39:20.624 11439 11439 E ActivityThread: at com.kevin.test.TestService.connectService(TestService.java:29)
11-04 14:39:20.624 11439 11439 E ActivityThread: at com.kevin.test.MainActivity.onCreate(MainActivity.java:20)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.app.Activity.performCreate(Activity.java:7224)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.app.Activity.performCreate(Activity.java:7213)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1272)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2926)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3081)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:78)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:108)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:68)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1831)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.os.Handler.dispatchMessage(Handler.java:106)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.os.Looper.loop(Looper.java:201)
11-04 14:39:20.624 11439 11439 E ActivityThread: at android.app.ActivityThread.main(ActivityThread.java:6806)
11-04 14:39:20.624 11439 11439 E ActivityThread: at java.lang.reflect.Method.invoke(Native Method)
11-04 14:39:20.624 11439 11439 E ActivityThread: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:547)
11-04 14:39:20.624 11439 11439 E ActivityThread: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:873)
這樣我們的分析，便得到驗證楞泼！
最后說明下驰徊，此問題影響不大笤闯，更多的是暴露了開發(fā)者開發(fā)時的不規(guī)范堕阔，未考慮到bindService、unbindService的成對調(diào)用或正確時機(jī)調(diào)用颗味。因為在最后Activity超陆、Service銷毀時removeContextRegistrations中會最后調(diào)用AMS#unbindService方法，ServiceDispatcher#doForget方法完成補(bǔ)救浦马。但值得開發(fā)者注意时呀！
作者：kevin song，2019.11.4于南京建鄴區(qū)
