问题背景：
在android12的版本上，陆陆续续发现一个低概率偶现的问题，那就是桌面第一次启动会存在显示空白10s以上，正常空白一般在1-2s，在个空白10s以上确实就属于非常严重的问题，但这个是一个低概率偶现问题，而且只有一例，所以说一直也没有引起重视。直到陆续确实有测试都报有这个同样问题，这个时候就开始要着力重点解决，这里分享一下针对这种低概率偶现问题的处理方式，这种方式适合所有framework端的一些低概率的偶现问题解决。
更多framework干货知识手把手教学
Log.i("千里马qq群"，“422901085”);
framework层面低概率偶现问题处理方法
这里主要分享一下公司里面是如何处理低概率偶现问题的：
1、需要在对应的怀疑地方加追踪日志，等待下一次测试复现时候可以有更多的log依据
2、如果概率较高，比如可以几十次复现一次，那么就需要组织测试人力进行集中复现该问题
3、只要可以概率复现，和测试合作复现，就不断的加日志缩小范围，追踪到根本原因
4、知道了根本原因后,考虑修改代码故意触发错误，然后让问题必现，看看现象是否和低概率问题一致
5、确定波及最小的修改问题方案进行修改，修改后验证可以先考虑让代码故意触发bug看看是否 修改已经生效，然后再去除故意触发bug代码，提交给测试验证测试
contentprovider的具体问题揭秘
首先来看看android 12上的acquireProvider代码：
@UnsupportedAppUsage
public final IContentProvider acquireProvider(
Context c, String auth, int userId, boolean stable) {
final IContentProvider provider = acquireExistingProvider(c, auth, userId, stable);
if (provider != null) {
return provider;
}
ContentProviderHolder holder = null;
final ProviderKey key = getGetProviderKey(auth, userId);
try {
synchronized (key) {
//这里从ams查询又没有改provider
holder = ActivityManager.getService().getContentProvider(
getApplicationThread(), c.getOpPackageName(), auth, userId, stable);
//如果没有查询到provider，那么就需要等待ams发布provider即notifyContentProviderPublishStatus执行
if (holder != null && holder.provider == null && !holder.mLocal) {
synchronized (key.mLock) {//注意这里加锁进行下面操作
//注意这里就有wait 10s的操作
key.mLock.wait(ContentResolver.CONTENT_PROVIDER_READY_TIMEOUT_MILLIS);
holder = key.mHolder;
}
if (holder != null && holder.provider == null) {
// probably timed out
holder = null;
}
}
}
}
//省略
return holder.provider;
}
//ams端回调app进程通知provider已经准备好了
@Override
public void notifyContentProviderPublishStatus(@NonNull ContentProviderHolder holder,
@NonNull String authorities, int userId, boolean published) {
final String auths[] = authorities.split(";");
for (String auth: auths) {
final ProviderKey key = getGetProviderKey(auth, userId);
synchronized (key.mLock) {
//注意这里进行对应的mHolder设置填充
key.mHolder = holder;
key.mLock.notifyAll();
}
}
}
乍一看好像代码没有问题，代码想要实现流程如下：
但是为啥有会有这个等待10s问题，而且等了10s后确实有相应的provider值
问题关键，多线程并发，没有注意锁的范围控制：
同时看看notifyContentProviderPublishStatus的锁也是这个key.mLock
public void notifyContentProviderPublishStatus(@NonNull ContentProviderHolder holder,
@NonNull String authorities, int userId, boolean published) {
//省略
synchronized (key.mLock) {
key.mHolder = holder;
key.mLock.notifyAll();
}
}
但是呢？大家看看
那么也就存在可能
holder = ActivityManager.getService().getContentProvider(
getApplicationThread(), c.getOpPackageName(), auth, userId, stable);
这一行代码查询时候确实没有，但是查询完了后如果多线程产生并发notifyContentProviderPublishStatus又同时执行了，那么notifyContentProviderPublishStatus先获取了mLock,而且给provider赋值了，导致自己的mLock就再也不会有notifyContentProviderPublishStatus来解锁
synchronized (key) {
holder = ActivityManager.getService().getContentProvider(
getApplicationThread(), c.getOpPackageName(), auth, userId, stable);
if (holder != null && holder.provider == null && !holder.mLocal) {
//查询完成后，还没有执行下面的代码，马上有ams回调执行了notifyContentProviderPublishStatus，导致了这个key.mLock执行在notifyContentProviderPublishStatus后面
synchronized (key.mLock) {
key.mLock.wait(ContentResolver.CONTENT_PROVIDER_READY_TIMEOUT_MILLIS);
holder = key.mHolder;
}
if (holder != null && holder.provider == null) {
// probably timed out
holder = null;
}
}
那么问题就明白了相当于本质其实就是锁范围不对，导致了这个10s问题
解决方案
这里为了最小的波及范围，不采用修改锁的范围方式，采用如下检测修改方案
synchronized (key) {
holder = ActivityManager.getService().getContentProvider(
getApplicationThread(), c.getOpPackageName(), auth, userId, stable);
if (holder != null && holder.provider == null && !holder.mLocal) {
synchronized (key.mLock) {
if (key.mHolder== null) {//这里需要加个再判断是否这个mHolder还为null，才进行等待
key.mLock.wait(ContentResolver.CONTENT_PROVIDER_READY_TIMEOUT_MILLIS);
}
holder = key.mHolder;
}
if (holder != null && holder.provider == null) {
// probably timed out
holder = null;
}
}
发现aosp 13已经有官方修复的patch，和上面修改方案差不多：
