Android | 使用 ContentProvider 无侵入获取 Context

zhangchen • • 杂文

前言

  • 在 Android 中，使用三方库或二方库时，经常需要使用 Context 进行初始化，一般的做法是调用仓库的初始化方法，并传入合适的 Context 对象；
  • 在这篇文章里，我将介绍基于 ContentProvider 启动机制实现的 无侵入获取 Context 的方法。如果能帮上忙，请务必点赞加关注，这真的对我非常重要。

相关文章

目录

1. 获取 Context 的常规方法

首先，我们回顾一下 Context 以及它的子类，在之前的这篇文章里，我们曾经讨论过：《Android | 一个进程有多少个 Context 对象（答对的不多）》。简单来说：Context 使用了装饰模式，除了 ContextImpl 外，其他 Context 都是 ContextWrapper 的子类。

我们熟悉的 Activity & Service & Application，都是 ContextWrapper 的子类。

1.1 获取 Application 对象

Application 对象的生命周期是最长的，经常被用来初始化第三方库，可以使用一个静态方法将对象暴露出去，也可以在 Application#onCreate()中初始化第三方库：

MainApplication.kt

class MainApplication : Application() {

    companion object {
        lateinit var application: Application
            get
    }

    override fun onCreate() {
        super.onCreate()
        application = this

        初始化第三方库...
    }
}

1.2 获取 Activity & Service 对象

同样地，Activity & Service 也是 Context 的实现类，那么我们就可以在程序运行过程中，可以按需初始化第三方库。例如使用 Glide 时，并不需要一开始就调用Glide#with(Context)，只需要在显示图片的时候调用即可；

1.3 小结

  • 优点
    最常用的方式，实现简单，没有性能 / 稳定性风险；可以按需初始化第三方库 & 懒加载；
  • 缺点
    需要获取 ApplicationContext / Context (依赖方与库代码强耦合)，不利于组件化。

下面，我将介绍两种无侵入获取 Context 的方法，将涉及到 Android 进程的启动流程，若还不了解，请务必阅读文章：《Android | 带你理解 Application 的创建过程》

2. 反射 ActivityThread 获得 ApplicationContext（不推荐）

这一节介绍一种通过 ActivityThread.java 获得 Application 的方法，具体如下：

2.1 源码分析

我们都知道，在启动四大组件（Activity、Service、ContentProvider, BroadcastReceiver）时，如果对应的进程未启动，就需要先创建进程，相应地也会创建一个 Application对象，即：

  • 在system_server进程，通过AMS#getProcessRecordLocked(...)获取进程信息 (ProcessRecord)；
  • 若不存在，则调用AMS#startProcessLocked(...)创建进程；
  • 在 Zygote 孵化目标进程之后，在目标进程反射执行ActivityThread#main()，并最终在ActivityThread#handleBindApplication(...)中创建 Application 对象。

ActivityThread.java

Application mInitialApplication;

public Application getApplication() {
        return mInitialApplication;
}
    
private void handleBindApplication(AppBindData data) {
    // ...
    Application app;
    // data.info 为 LoadedApk.java
    app = data.info.makeApplication(data.restrictedBackupMode, null);
    // ...
    mInitialApplication = app;
    // ...
}

可以看到，创建 Application 对象之后会保存在mInitialApplication属性中，那么如果我们可以访问到这个属性，是不是就可以获得 Application 对象了呢？

首先，我们需要获得 ActivityThread 对象，那么我们先在源码中寻找创建 ActivityThread 对象的地方：

ActivityThread.java

private static volatile ActivityThread sCurrentActivityThread;

public static ActivityThread currentActivityThread() {
    return sCurrentActivityThread;
}
    
// (简化)
public static void main(String[] args) {
    Looper.prepareMainLooper();
    
    // 创建 ActivityThread 对象
    ActivityThread thread = new ActivityThread();
    thread.attach(false, startSeq);
    
    Looper.loop();
}

private void attach(boolean system, long startSeq) {
    sCurrentActivityThread = this;
}

可以看到，ActivityThread 对象存储在静态变量sCurrentActivityThread中，那么我们就可以写反射代码了。

2.2 使用步骤

Context.kt

// 新建文件 
private var application: Context? = null

fun context(): Context {
    if (null == application) {
        try {
            val activityThread: Any
            val clazz = Class.forName("android.app.ActivityThread")
            val currentActivityThread = clazz.getMethod("currentActivityThread").apply {
                isAccessible = true
            }
            val getApplication = clazz.getMethod("getApplication").apply {
                isAccessible = true
            }
            activityThread = currentActivityThread.invoke(null)
            application= getApplication.invoke(activityThread) as Context
        } catch (e: Throwable) {
            // 存在未适配的风险
        }
    }
    return application!!
}

运行测试一下，context()的返回结果：

android.app.Application@c12661f

2.3 小结

  • 优点：
    依赖方不需要传递 Context 对象给库进行初始化，减少了代码耦合，有利于组件化；
  • 缺点：
    需要反射调用私有 API ，存在系统版本适配风险；使用反射有一定性能损耗。

3. 使用 ContentProvider 获取 ApplicationContext

这一节介绍一种通过ContentProvider.java获得 Application 的方法。ContentProvider 通常的用法是为当前进程 / 远程进程提供内容服务，它们会在应用启动的时候初始化，正因如此，我们可以利用 ContentProvider 来获得 Context 。

3.1 源码分析

ActivityThread.java

private void handleBindApplication(AppBindData data) {
    // ...
    1、实例化 Application 对象
    Application app;
    app = data.info.makeApplication(data.restrictedBackupMode, null);
    mInitialApplication = app;

    2、初始化所有 ContentProvider
    installContentProviders(app, data.providers);

    3、调用 Application#onCreate()
    mInstrumentation.callApplicationOnCreate(app);
    ...
}

-> 1、实例化 Application 对象
public Application makeApplication(boolean forceDefaultAppClass,
            Instrumentation instrumentation) {
    ...
    1.1 Context 基础对象
    ContextImpl appContext = ContextImpl.createAppContext(mActivityThread, this);

    1.2 实例化，内部会调用 Context#attachBaseContext(...)
    app = mActivityThread.mInstrumentation.newApplication(cl, appClass, appContext);

    1.3 Context 基础对象持有代理类
    appContext.setOuterContext(app);
    ...
}

-> 2、初始化所有 ContentProvider
private void installContentProviders(Context context, List providers) {
    final ArrayList results = new ArrayList<>();

    for (ProviderInfo cpi : providers) {
        // 依次初始化 ContentProvider
        ContentProviderHolder cph = installProvider(context, null, cpi,
                false /*noisy*/, true /*noReleaseNeeded*/, true /*stable*/);
        if (cph != null) {
            cph.noReleaseNeeded = true;
            results.add(cph);
        }
    }
    // ...
}

可以看到，installContentProviders()将安装属于当前进程的 ContentProvider，具体的调用时机在Context#attachBaseContext(...)与Application#onCreate()之间：

3.2 使用步骤

了解 ContentProvider 启动机制之后，我们就可以利用 ContentProvider 来拿到 ApplicationContext。具体步骤如下：

步骤一：实现 ContentProvider 子类
// ContextProvider.kt

internal class ContextProvider : ContentProvider(){

    override fun onCreate(): Boolean {
        init(context!!)
        return true
    }
    
    // 其他方法直接 return 
}
// Context.kt
private lateinit var application : Context

fun init(context : Context){
    application= context
}

fun context() : Context{
    return application
}
步骤二：在 AndroidManifest 中配置
// AndroidManifest.xml
步骤三：使用
Toast.makeText(context(),"",Toast.LENGTH_SHORT).show()

3.3 小结

  • 优点：
    依赖方不需要传递 Context 对象给库进行初始化，减少了代码耦合，有利于组件化
  • 缺点：
    在 App 启动时就初始化 ContentProvider，不是懒初始化；如果应用的 ContentProvider 过多，会增加应用的启动时间；
  • 风险：
    应保证初始化非常轻量，否则会降低 App 的启动速度

4. 案例

下面举出一些基于 ContentProvider 机制实现无侵入地获取 Context 的例子：

  • LeakCanary 2.4

AppWatcherInstaller.java

internal sealed class AppWatcherInstaller : ContentProvider() {

    internal class MainProcess : AppWatcherInstaller()

    internal class LeakCanaryProcess : AppWatcherInstaller()

    override fun onCreate(): Boolean {
        val application = context!!.applicationContext as Application
        AppWatcher.manualInstall(application)
        return true
    }

    // 其他方法直接 return 
}
  • AutoSize 1.1.2

InitProvider.java

public class InitProvider extends ContentProvider {
    @Override
    public boolean onCreate() {
        AutoSizeConfig.getInstance()
                .setLog(true)
                .init((Application) getContext().getApplicationContext())
                .setUseDeviceSize(false);
        return true;
    }

    // 其他方法直接 return 
}
  • Picasso 2.7

PicassoProvider.java

public final class PicassoProvider extends ContentProvider {

    @SuppressLint("StaticFieldLeak") static Context context;

    @Override public boolean onCreate() {
        context = getContext();
        return true;
    }

    // 其他方法直接 return 
}

推荐阅读

感谢喜欢！你的点赞是对我最大的鼓励！欢迎关注彭旭锐的简书！

版权声明：
作者：zhangchen
链接：https://www.techfm.club/p/23831.html
来源：TechFM
文章版权归作者所有，未经允许请勿转载。

THE END
分享
二维码
< <上一篇
下一篇>>