Android利用ContentProvider初始化组件的踩坑记录

 更新时间:2022年04月29日 10:37:33   作者:pumpkin的玄学  
做Android SDK开发的时候,一般我们会将初始化的方法封装,然后让调用SDK的开发者在Application的onCreate方法中进行初始化,下面这篇文章主要给大家介绍了关于Android利用ContentProvider初始化组件的踩坑记录,需要的朋友可以参考下

项目描述

先简单描述一下遇到的问题。

项目比较庞大是以组件化的形式进行构建的,记录崩溃日志是由专门的一个组件去做,这里且叫它crash吧。而crash的核心逻辑如下:

//伪代码
public class MyCrash implements UncaughtExceptionHandler {
    
    private static UncaughtExceptionHandler defaultUncaughtExceptionHandler;
    
    public static void init(String path) {
        ...
        //获取到默认的ExceptionHandler
        defaultUncaughtExceptionHandler = Thread.getDefaultUncaughtExceptionHandler();
        //设置自己的ExceptionHandler
        Thread.setDefaultUncaughtExceptionHandler(new MyCrash());
    }
    @Override    
    public void uncaughtException(Thread t, Throwable e) {
        try {
            //日志记录逻辑
        } catch (IOException e) {
            e.printStackTrace();
        } finally {
            //回调默认的ExceptionHandler
            if (defaultUncaughtExceptionHandler != null) {
                defaultUncaughtExceptionHandler.uncaughtException(t, e);
            }
        }
    }
}

然后该组件利用ContentProvider进行初始化,大概如下所示:

class MyContentProvider : ContentProvider() {
    override fun onCreate(): Boolean {
        //伪代码,初始化。
        MyCrash.init("")
        return true
    }
    ......
}

问题排查

收到反馈说,部分手机不会记录崩溃日志。这就是很奇怪了,因为理论上来说,只要设置了ExceptionHandle都会捕获到传过来的异常呀。难道是没有设置到ExceptionHandle?

后经过断点排查,不会上传崩溃日志的手机,在运行阶段Thread持有的defaultUncaughtExceptionHandler,不是我们设置的MyCrash,而是一个三方组件设置他们自己的CrashExceptionHandle且没有回调我们的MyCrash,而他们也是利用ContentProvider初始化的。

所以这时候就牵扯到ContentProvider的初始化流程了,具体在ActivityThread中,下面放一下伪代码。

ActivityThread
private void handleBindApplication(AppBindData data) {
    ...
    //1.获取到Application
    app = data.info.makeApplication(data.restrictedBackupMode, null);
    ...
    //2.初始化ContentProvider
    installContentProviders(app, data.providers);
    ...
    //3.调用Application的onCreate
    mInstrumentation.callApplicationOnCreate(app);
    ...
}

整体顺序是获取Application->初始化ContentProvider->调用Application#onCreate。也就是说ContentProvider的初始化是要在Application之前的。其中ContentProvider的初始化就是循环便利储存ContentProvider的集合调用它的onCreate方法。

private void installContentProviders(Context context, List<ProviderInfo> providers) {
    ...
    for (ProviderInfo cpi : providers) {
       //这里会获取到ContentProvider,最终会调用到ContentProvider的attachInfo,在attachInfo中调用了onCreate
    }
    ...
}

那ContentProvider的初始化顺序就很清晰明了了。而我们的问题是部分手机记录不了,也就是说ContentProvider在集合中的顺序是不可保证的,这样才能解释部分手机有问题,部分手机正常,那这个顺序是怎么来的呢?

起初我想到顺序是不是和合并后的AndroidManifest.xml文件里面注册的ContentProvider节点顺序有关系,随后就将该想法排除,因为生成的APK是一样的,所以AndroidManifest.xml文件里面注册的ContentProvider节点顺序是一定的。而有问题的是部分手机,所以一定不是这里的问题,没办法只能继续查看源码,看看ContentProvider究竟是如何读到内存中的。

经过一番查找,发现ContentProvider的集合是从ComponentResolver中private final ArrayMap<ComponentName, ParsedProvider> mProviders = new ArrayMap<>();取得。由于涉及到得源码比较多,这里就不一一列举了,下面放上源码大致的调用链

ActivityManagerService#attachApplicationLocked -> ActivityManagerService#generateApplicationProvidersLocked -> PackageManagerService#queryContentProviders -> ComponentResolver#queryProviders -> ActivityThread#bindApplication -> ActivityThread#handleBindApplication

我们注意一下重点,ContentProvider得信息是被储存在ArrayMap中得,而ArrayMap肯定是无法保证顺序的呀。不了解ArrayMap的下面我简单介绍一下,

ArrayMap是Google专门提供的key-value映射集合,主要为了解决HashMap浪费控件的问题,在小数据量上性能不错,但是它底层是用数组来着,利用二分查找,而二分查找的顺序是根据hash值来的,默认的hash值是通过System.identityHashCode(key)来进行获取的,而这玩意儿又和对象的地址有关系。所以不同的手机顺序肯定就不一样了。

到这里,问题就分析结束了,最终解决方案是,去除了利用ContentProvider的初始化机制,改在Application中直接进行初始化。

总结

上面的问题虽然解决了,但是利用ContentProvider解耦初始化组件真的好吗?直观的有以下几个问题。

  1. 内存泄漏。初始化完成之后ContentProvider会被系统直接持有,无用,但也不删除
  2. 无法保证组件初始化的顺序。这个就是我们上面分析的问题
  3. 会拉长启动时间。上面我们看到了,ContentProvider循环初始化完成之后,才会进行Application#onCreate的调用,所以对于一些非必要在主线程初始化的组件,这无疑会拉长启动时间。

不过如果非要去解耦组件初始化,可以看一看Jetpack startup组件,它也是利用ContentProvider去初始化的,但是它利用AndroidManifest.xml合并的功能最终会合并成一个ContentProvider,而且内存维持有集合可以保证组件初始化顺序。

总之一句话,不要滥用ContentProvider仅仅去做一个初始化。

到此这篇关于Android利用ContentProvider初始化组件踩坑的文章就介绍到这了,更多相关Android ContentProvider初始化组件内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!

相关文章

  • Android EditText实现分割输入内容

    Android EditText实现分割输入内容

    这篇文章主要为大家详细介绍了Android EditText实现分割输入内容的相关资料,具有一定的参考价值,感兴趣的小伙伴们可以参考一下
    2017-04-04
  • Flutter路由fluro引入配置和使用的具体方法

    Flutter路由fluro引入配置和使用的具体方法

    Flutter本身提供了路由机制,本文主要介绍了Flutter fluro配置使用,文中通过示例代码介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们可以参考一下
    2021-09-09
  • Android实现左上角(其他边角)倾斜的标签(环绕效果)效果

    Android实现左上角(其他边角)倾斜的标签(环绕效果)效果

    这篇文章主要介绍了Android实现左上角(其他边角)倾斜的标签(环绕效果)效果,本文通过图文实例代码相结合的形式给大家介绍的非常详细,具有一定的参考借鉴价值,需要的朋友可以参考下
    2019-10-10
  • Android原生绘图工具Canvas详细

    Android原生绘图工具Canvas详细

    上一篇文章给大家介绍了Android原生绘图工具Paint,然而android中提供了类似的工具Canvas和Paint,分别对应画布和画笔,所以今天的这篇文章就来介绍Androi原生绘图的另一个工具Canvas,感兴趣的小伙伴一起来学习下面文章内容
    2021-09-09
  • Flutter RSA加密解密的示例代码

    Flutter RSA加密解密的示例代码

    数据加密有对称加密(对称密钥方案) 和非对称加密(公钥加密) 两种加密方式,本文主要介绍了Flutter RSA加密解密的示例代码,感兴趣的可以了解一下
    2022-04-04
  • Android实现简易的闹钟功能

    Android实现简易的闹钟功能

    这篇文章主要为大家详细介绍了Android实现简易的闹钟功能,文中示例代码介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们可以参考一下
    2022-09-09
  • 简述Android中实现APP文本内容的分享发送与接收方法

    简述Android中实现APP文本内容的分享发送与接收方法

    本篇文章主要对Android中实现APP文本内容的分享发送与接收方法进行介绍,相信对大家学习会有很好的帮助,需要的朋友一起来看下吧
    2016-12-12
  • Android中Bitmap、File与Uri之间的简单记录

    Android中Bitmap、File与Uri之间的简单记录

    这篇文章主要给大家介绍了关于Android中Bitmap、File与Uri之间的相关资料,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面来一起学习学习吧
    2019-02-02
  • Android实现下拉刷新的视图和图标的旋转

    Android实现下拉刷新的视图和图标的旋转

    本篇文章主要介绍了Android实现下拉刷新的视图和图标的旋转的实例,具有很好的参考价值。下面跟着小编一起来看下吧
    2017-03-03
  • Android 微信摇一摇功能实现详细介绍

    Android 微信摇一摇功能实现详细介绍

    这篇文章主要介绍了Android 微信摇一摇功能实现详细介绍的相关资料,并附实例代码及实现微信摇一摇的思路,需要的朋友可以参考下
    2016-11-11

最新评论