- 1【鸿蒙应用ArkTS开发系列】- 云开发入门实战二 实现省市地区三级联动地址选择器组件（下）_鸿蒙多级联动
- 2留在一线，逃离一线？我从上海举家回成都的生活经历告诉你
- 3python中Google S2算法的简单使用案例_s2sphere
- 4org.springframework.jdbc.UncategorizedSQLException:
- 5开源免费的NTFS for mac工具mounty_ntfs读写工具免费
- 6Android 虚拟机 (Dalvik & ART)_art虚拟机
- 7opencv 二维mat矩阵增加一行_opencv矩阵拓展1
- 8Unity与VRTK的自定义按键事件_unity steamvr 手柄任意按键按下事件
- 9【Android】Termux安装与使用
- 10边缘计算是什么？边缘计算系统的组成及概念_边缘计算服务器
ContentProvider导致App闪退问题分析_acquireunstablecontentproviderclient
赞
踩
一、背景
近日有部分线上用户反馈打开App后会偶现闪退，但奇怪的是我们在捞取相关设备的App日志时却没有发现任何的异常栈信息，这给我们定位问题带来了不小的难度。没有明确的异常栈信息，那就只能找规律了。从大量的日志中我们发现进程挂掉的前面一小段时间里，都出现了与操作某一个ContentProvider组件相关的日志信息。通过推测+尝试，最终成功在本地复现了闪退现象，并抓取到了关键的系统日志。日志如下：
2021-03-30 16:28:35.661 1091-1459/? I/ActivityManager: Killing 20972:com.test.demo1/u0a71 (adj 100): depends on provider com.test.demo2/.provider.SharedProvider in dying proc com.test.demo2 (adj 0)
2021-03-30 16:28:35.668 1091-1459/? I/ActivityManager: Killing 22561:com.test.demo2/u0a1222 (adj 0): timeout publishing content providers
2021-03-30 16:28:35.674 1091-1459/? D/ActivityManager: proc ProcessRecord{2522dce 22561:com.test.demo2/u0a1222} already removed. so we skip next process.
2021-03-30 16:28:35.676 1091-3793/? E/ActivityManager: Timeout waiting for provider com.test.demo2/11222 for provider com.test.demo2.SharedProviderAuthority providerRunning=false caller=com.test.demo1/10071
- 1
- 2
- 3
- 4
com.test.demo1在进程启动时会去查询com.test.demo2实现的一个ContentProvider组件，该组件名为SharedProvider，对应的authority是com.test.demo2.SharedProviderAuthority。com.test.demo1就是出现闪退问题的App。根据日志我们可以总结出以下几个信息：
- 系统将要杀死com.test.demo1进程，因为它依赖了将死进程com.test.demo2的ContentProvider
- com.test.demo2由于注册ContentProvider超时正在被杀死
也就是说com.test.demo2注册ContentProvider超时除了导致自身被杀以外，同时还导致了调用方com.test.demo1被杀。
这个就有点超出我们以往的认知了，一般来说调用方进程和被调用方进程相互之间都是独立的，被调用方进程出现崩溃等问题不应该会影响到调用方的逻辑。com.test.demo1原先预想的实现逻辑也是如此，优先去查com.test.demo2的SharedProvider中的数据，如果取到了就展示该数据，如果没取到就展示默认的数据。不管demo2的进程是否存活，是否发生崩溃等，我们都不希望它影响到调用方demo1的进程。
二、结合源码分析原因
2.1 初步定义关键代码位置
分析这种问题时，我们可以先通过关键日志定位到导致问题发生的关键代码，再从关键代码处往上层层剖析，这样往往能达到事半功倍的效果。很明显，"depends on provider"是日志中最为关键的一个词，我们直接在安卓Framework的源码中搜一下，就会找到如下的关键代码。这段代码位于ActivityManagerService.java中
private final boolean removeDyingProviderLocked(ProcessRecord proc, ContentProviderRecord cpr, boolean always) { ... for (int i = cpr.connections.size() - 1; i >= 0; i--) { ... ProcessRecord capp = conn.client; conn.dead = true; // 关键就在于conn.stableCount > 0 这个条件 if (conn.stableCount > 0) { // 由于三方应用的进程基本都不是常驻进程，因此都会满足以下这个if条件，从而走到kill逻辑中 if (!capp.isPersistent() && capp.thread != null && capp.pid != 0 && capp.pid != MY_PID) { capp.kill("depends on provider " + cpr.name.flattenToShortString() + " in dying proc " + (proc != null ? proc.processName : "??") + " (adj " + (proc != null ? proc.setAdj : "??") + ")", ApplicationExitInfo.REASON_DEPENDENCY_DIED, ApplicationExitInfo.SUBREASON_UNKNOWN, true); } ... } ... }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
从方法名来看，removeDyingProviderLocked应该是AMS用来移除将死进程的Provider信息的。并且在移除这些Provider信息的时候会根据一些条件来判断是否要杀死调用方。接下去我们可以分两个方向来分析，一个是removeDyingProviderLocked(ProcessRecord proc, ContentProviderRecord cpr, boolean always)这个方法何时会被调用，另一个则是conn.stableCount在满足怎样的条件时会大于0。
2.1 removeDyingProviderLocked()方法的调用逻辑
探究removeDyingProviderLocked(ProcessRecord proc, ContentProviderRecord cpr, boolean always)方法调用逻辑其实就是就是在探究ContentProvider的注册和查询流程，注册方以及调用方是如何和system_server做交互的。这部分内容比较多，不熟悉ContentProvider原理的同学可以看这篇文章: 理解ContentProvider原理
借用这篇文章中的一张概括图继续往下分析
导致demo1闪退的关键就在system_server到provider process的交互过程中。
AMS首先会调用getContentProviderImp()方法尝试获取target provider。如果ContentProvider还未被注册（即所在进程还未启动），则会调用startProcessLocked()方法来启动server process，对应开头的例子就是指com.test.demo2进程
private ContentProviderHolder getContentProviderImpl(IApplicationThread caller, String name, IBinder token, int callingUid, String callingPackage, String callingTag, boolean stable, int userId) { ... // If the provider is not already being launched, then get it // started. if (i >= N) { final long origId = Binder.clearCallingIdentity(); try { ... if (proc != null && proc.thread != null && !proc.killed) { if (DEBUG_PROVIDER) Slog.d(TAG_PROVIDER, "Installing in existing process " + proc); if (!proc.pubProviders.containsKey(cpi.name)) { checkTime(startTime, "getContentProviderImpl: scheduling install"); proc.pubProviders.put(cpi.name, cpr); try { proc.thread.scheduleInstallProvider(cpi); } catch (RemoteException e) { } } } else { checkTime(startTime, "getContentProviderImpl: before start process"); proc = startProcessLocked(cpi.processName, cpr.appInfo, false, 0, new HostingRecord("content provider", new ComponentName(cpi.applicationInfo.packageName, cpi.name)), ZYGOTE_POLICY_FLAG_EMPTY, false, false, false); checkTime(startTime, "getContentProviderImpl: after start process"); if (proc == null) { Slog.w(TAG, "Unable to launch app " + cpi.applicationInfo.packageName + "/" + cpi.applicationInfo.uid + " for provider " + name + ": process is bad"); return null; } } cpr.launchingApp = proc; mLaunchingProviders.add(cpr); } finally { Binder.restoreCallingIdentity(origId); } } ... }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
而server（com.test.demo2）进程在启动时会调用attachApplicationLocked(@NonNull IApplicationThread thread, int pid, int callingUid, long startSeq)方法，关键代码如下：
static final int CONTENT_PROVIDER_PUBLISH_TIMEOUT_MSG = 57;
private boolean attachApplicationLocked(@NonNull IApplicationThread thread,
int pid, int callingUid, long startSeq) {
// ...
if (providers != null && checkAppInLaunchingProvidersLocked(app)) {
Message msg = mHandler.obtainMessage(CONTENT_PROVIDER_PUBLISH_TIMEOUT_MSG);
msg.obj = app;
mHandler.sendMessageDelayed(msg,
ContentResolver.CONTENT_PROVIDER_PUBLISH_TIMEOUT_MILLIS);
}
// ...
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
server（com.test.demo2）进程会判断当前AndroidManifest.xml文件中是否存在需要注册的ContentProvider，如果存在就给Handler发送一个延时消息。这个消息的处理逻辑如下：
case CONTENT_PROVIDER_PUBLISH_TIMEOUT_MSG: {
ProcessRecord app = (ProcessRecord)msg.obj;
synchronized (ActivityManagerService.this) {
processContentProviderPublishTimedOutLocked(app);
}
} break;
- 1
- 2
- 3
- 4
- 5
- 6
private final void processContentProviderPublishTimedOutLocked(ProcessRecord app) {
cleanupAppInLaunchingProvidersLocked(app, true);
mProcessList.removeProcessLocked(app, false, true,
ApplicationExitInfo.REASON_INITIALIZATION_FAILURE,
ApplicationExitInfo.SUBREASON_UNKNOWN,
"timeout publishing content providers");
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
final boolean cleanUpApplicationRecordLocked(ProcessRecord app, boolean restarting, boolean allowRestart, int index, boolean replacingPid) { ... // Remove published content providers. for (int i = app.pubProviders.size() - 1; i >= 0; i--) { ContentProviderRecord cpr = app.pubProviders.valueAt(i); if (cpr.proc != app) { // If the hosting process record isn't really us, bail out continue; } final boolean alwaysRemove = app.bad || !allowRestart; final boolean inLaunching = removeDyingProviderLocked(app, cpr, alwaysRemove); ... } ... }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
AMS$MainHandler.handleMessage()
—> AMS.processContentProviderPublishTimedOutLocked()
—> AMS.cleanUpApplicationRecordLocked()
—> AMS.removeDyingProviderLocked()
经过层层调用最终调用到了AMS.removeDyingProviderLocked()方法。
我们在全局范围内搜索CONTENT_PROVIDER_PUBLISH_TIMEOUT_MSG的时候会发现，还有removeMessage的方法。总共有两个调用地方
- 重启server进程
final boolean cleanUpApplicationRecordLocked(ProcessRecord app, boolean restarting, boolean allowRestart, int index, boolean replacingPid) { ... if (restart && allowRestart && !app.isolated) { // We have components that still need to be running in the // process, so re-launch it. if (index < 0) { ProcessList.remove(app.pid); } // Remove provider publish timeout because we will start a new timeout when the // restarted process is attaching (if the process contains launching providers). mHandler.removeMessages(CONTENT_PROVIDER_PUBLISH_TIMEOUT_MSG, app); mProcessList.addProcessNameLocked(app); app.pendingStart = false; mProcessList.startProcessLocked(app, new HostingRecord("restart", app.processName), ZYGOTE_POLICY_FLAG_EMPTY); return true; } ... }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- ContentProvider注册成功
public final void publishContentProviders(IApplicationThread caller,
List<ContentProviderHolder> providers) {
...
if (wasInLaunchingProviders) {
mHandler.removeMessages(CONTENT_PROVIDER_PUBLISH_TIMEOUT_MSG, r);
}
...
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
看到这里，removeDyingProviderLocked(ProcessRecord proc, ContentProviderRecord cpr, boolean always)的调用过程就已经很清晰了。system_server在启动进程时如果目标进程有需要注册的ContentProvider，就会发送一个10s的超时信息；如果目标进程的ContentProvider在十秒内加载完成，system_server就会移除这个超时信息；如果没有注册完成，system_server就会处理这个信息，最终就会调用到removeDyingProviderLocked()方法。
但是，调用到removeDyingProviderLocked()这个方法并不一定就会导致调用方进程被杀，还要满足conn.stableCount > 0的条件，因此接下去我们继续看下conn.stableCount的相关赋值逻辑。
4.2 conn.stableCount的赋值逻辑
conn.stableCount的赋值涉及到ContentProvider中的引用计数逻辑，详细分析可见: ContentProvider引用计数。关键就在于下面这张表
再看下com.test.demo1中调用ContentProvider的逻辑
我们会看到com.test.demo1通过ContentResolver的call()方法来操作com.test.demo2的SharedProvider，ContentResolver.call()方法的实现如下：
public final @Nullable Bundle call(@NonNull String authority, @NonNull String method, @Nullable String arg, @Nullable Bundle extras) { Preconditions.checkNotNull(authority, "authority"); Preconditions.checkNotNull(method, "method"); try { if (mWrapped != null) return mWrapped.call(authority, method, arg, extras); } catch (RemoteException e) { return null; } // 关键地方：stableCount+1 IContentProvider provider = acquireProvider(authority); if (provider == null) { // provider为null，抛出异常 throw new IllegalArgumentException("Unknown authority " + authority); } try { final Bundle res = provider.call(mPackageName, authority, method, arg, extras); Bundle.setDefusable(res, true); return res; } catch (RemoteException e) { // Arbitrary and not worth documenting, as Activity // Manager will kill this process shortly anyway. return null; } finally { releaseProvider(provider); } }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
显然client端调用call()方法后如果server端的ContentProvider注册失败，stableCount就会加一但是没有减一，此时如果服务端超过十秒没注册完相应的Provider组件，那么就会导致client端被system_server杀死。
但如果我们把call()方法换成常用的query()方法，就会发现并不会出现这个问题。这是为什么呢？我们再看下query方法的实现：
public final @Nullable Cursor query(final @RequiresPermission.Read @NonNull Uri uri, @Nullable String[] projection, @Nullable Bundle queryArgs, @Nullable CancellationSignal cancellationSignal) { Preconditions.checkNotNull(uri, "uri"); try { if (mWrapped != null) { return mWrapped.query(uri, projection, queryArgs, cancellationSignal); } } catch (RemoteException e) { return null; } IContentProvider unstableProvider = acquireUnstableProvider(uri); if (unstableProvider == null) { return null; } IContentProvider stableProvider = null; Cursor qCursor = null; try { long startTime = SystemClock.uptimeMillis(); ICancellationSignal remoteCancellationSignal = null; if (cancellationSignal != null) { cancellationSignal.throwIfCanceled(); remoteCancellationSignal = unstableProvider.createCancellationSignal(); cancellationSignal.setRemote(remoteCancellationSignal); } try { qCursor = unstableProvider.query(mPackageName, uri, projection, queryArgs, remoteCancellationSignal); } catch (DeadObjectException e) { // The remote process has died... but we only hold an unstable // reference though, so we might recover!!! Let's try!!!! // This is exciting!!1!!1!!!!1 unstableProviderDied(unstableProvider); stableProvider = acquireProvider(uri); if (stableProvider == null) { return null; } qCursor = stableProvider.query( mPackageName, uri, projection, queryArgs, remoteCancellationSignal); } if (qCursor == null) { return null; } // Force query execution. Might fail and throw a runtime exception here. qCursor.getCount(); long durationMillis = SystemClock.uptimeMillis() - startTime; maybeLogQueryToEventLog(durationMillis, uri, projection, queryArgs); // Wrap the cursor object into CursorWrapperInner object. final IContentProvider provider = (stableProvider != null) ? stableProvider : acquireProvider(uri); final CursorWrapperInner wrapper = new CursorWrapperInner(qCursor, provider); stableProvider = null; qCursor = null; return wrapper; } catch (RemoteException e) { // Arbitrary and not worth documenting, as Activity // Manager will kill this process shortly anyway. return null; } finally { if (qCursor != null) { qCursor.close(); } if (cancellationSignal != null) { cancellationSignal.setRemote(null); } if (unstableProvider != null) { releaseUnstableProvider(unstableProvider); } if (stableProvider != null) { releaseProvider(stableProvider); } } }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
从代码中我们很明显就能看出原因所在，query方法调的是acquireUnstableProvider()，stableCount的值并不会增加，所以即使服务端超过10s没有注册完成Provider，也不会导致客户端被杀。
至此，我们终于找到导致线上用户App闪退的原因了。小结一下就是，demo1进程通过ContentResolve的call()方法来查询demo2的ContentProvider时，由于demo2进程启动较慢，超过十秒还没有注册好相应的ContentProvider，导致AMS在杀死demo2进程的同时，也连带着杀死了demo1进程。
三、总结
3.1 会导致闪退的ContentResolver方法
根据ContentResolve中各个方法的实现逻辑，我大致列出了以下几个有可能导致调用方进程闪退的方法。包括：acquireProvider()、getStreamTypes()、canonicalize()、uncanonicalize()、refresh()、insert()、bulkInsert()、delete()、update()、call()、acquireContentProviderClient()（有些不是public类型的方法我也列出来了）。
3.2 解决方案
问题找到了，如何解决呢？方案一：不使用ContentResolve的call()方法，直接用query()。这种方案简单粗暴，在当前的业务场景下确实也能满足需求。但是总有治标不治本的感觉，如果以后必须要用call()方法怎么办呢？况且不仅仅是call()方法会导致这个问题，如3.1中所列的，update()等方法也存在这个问题。
我们再仔细回想下这个问题发生的关键点在哪，一个是demo1进程调用了call()方法来启动demo2进程，另一个是demo2进程启动太慢。我们能改变的只有第一点，至于第二点demo2进程的启动速度则不是我们可以把握的，即使是demo2进程本身也很难把握，进程启动速度是和当时设备的状态强相关的。
既然用call()方法来启动demo2进程可能会导致闪退，我们能不能先用query()方法来启动demo2进程，之后判断拿到的返回结果，如果返回的Cursor对象不为null再调用call()方法。如此一来既不会有闪退的风险，也能够调用任意的方法了。思路大概就是这个思路，只是调完query()方法再调call()方法总有种脱裤子放屁的样子。其实还有一个更优雅的方法，就是acquireUnstableContentProviderClient()方法。这个方法返回的是一个ContentProviderClient对象，通过判断这个对象是不是空，我们再决定是否继续调用call()方法。
3.3 其他坑
趁着这次线上bug仔细梳理了下ContentProvider的相关逻辑，同时排查了下App中个业务方对ContentProvider的使用逻辑，避免后续又出现类似问题。在排查的过程中发现了各种五花八门的写法。有连返回的Cursor是不是null都不判断就直接往下操作的，还有不带try…catch保护的，再有就是直接调用3.1所列的可能导致调用方闪退的方法的。平时没出事的原因是ContentProvider使用得较少，而server 进程启动慢于十秒出现的概率也比较低，如果不是大规模地去实现这个Provider的话，还是不容易发现问题的。
此外，上面说的都是调用方Client端的坑。除调用方外，被调用方Server端中需要注意的一个坑就是，ContentProvider的onCreate()方法会先于Application的onCreate()被调用，而App的基础组件一般都是在Application的onCreate()方法中才初始化的，因此千万不要在ContentProvider的onCreate()中调用基础组件，query()等其他的方法里面最好也不要调。并且如果崩溃是发生在ContentProvider的onCreate()方法中，热修复都修复不了（热修复组件都还没来得及初始化呢！！！）
3.4一种比较安全的写法
想要防止出现由于ContentProvider导致的异常闪退等问题，就需要规范地使用ContentProvider，考虑到种种可能出现的异常情况。从3.3的分析中，我们可以知道，操作ContentProvider的代码逻辑中需要至少需要加上非空判断 + try…catch保护，而且如果调用的是stable相关的方法，则要先用通过acquireUnstableContentProviderClient()方法来尝试拉起ContentProvider所在的进程，代码如下：
private void queryProvider() { try { ContentResolver contentResolver = getContentResolver(); String targetProviderAuthority = "com.test.demom2.SharedProviderAuthority"; ContentProviderClient targetProviderClient = contentResolver.acquireUnstableContentProviderClient(targetProviderAuthority); if (targetProviderClient == null) { Log.e(TAG, "targetProviderClient is null, return"); return; } Bundle bundle = contentResolver.call(targetProviderAuthority, "xxx", null, null); if (bundle == null) { Log.e(TAG, "bundle is null, return"); } // 具体的业务逻辑 } catch (Exception e) { Log.e(TAG, e.getMessage()); } }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
最后，还有一个小问题说明下，为何在我们的进程日志里面看不到任何的异常栈信息？原因其实很简单，因为我们的进程根本就没有发生异常！我们的进程被杀仅仅只是因为我们调用的ContentProvider组件加载超时了。
