聊聊Android中的ContextImpl

提及这个ContextImpl.可能有些同窗不太熟悉，但提及Context，我想都认识它吧，上下文，也能够说是表明一种所在的场景，因为Context只是一个抽象类，而抽象类一定是有一个具体的实现类的，另外还有ContextThemeWrapper和ContextWrapper,不过这些都是Context的子类而已，他们是以装饰模式而存在的一种关系，简单说下装饰模式，装饰模式是经常使用的设计模式之一，通常状况下若是须要动态地给一个对象添加一些额外的职责但又不想增长子类，那么就能够用到装饰模式了，若是单纯增长功能来讲，Decorator模式相比生成子类更为灵活,该模式以对客 户端透明的方式扩展对象的功能,下面举一个简单的例子说明一下，首先一我的，有吃饭的功能接口

代码以下:

Component

public interface Person {
 
    void eat();
}
复制代码

ConcreteComponent

public class Man implements Person {

    public void eat() {
        System.out.println("男人在吃饭");
    }
}
复制代码

Decorator(这个类是关键，实现了接口而且有真实对象的引用)

public abstract class Decorator implements Person {

    protected Person person;
    
    public Decorator(Person person){
        this.person=person;
    }
    
    public void eat() {
        person.eat();
    }
}
复制代码

下面的就是具体的添加额外功能的了具体子类，好比有些人吃饭前先洗手或者吃完饭后洗碗之类，固然具体什么事情根据业务决定

public class ManDecoratorA extends Decorator {

    public ManDecoratorA(Person person) {
        super(person);
    }
    public void eat() {
        wash();
        super.eat();
    }

    private void wash() {
        System.out.println("饭前先洗洗手");
    }
}
public class ManDecoratorB extends Decorator {
    
    public ManDecoratorB(Person person) {
        super(person);
    }
    public void eat() {
        super.eat();
        washDishes();
    }
    
    private void washDishes(){
          System.out.println("吃完饭后洗碗");
    }
}
复制代码

测试的结果为:

public static void main(String[] args) {
        Person person=new Man();
        ManDecoratorA md1=new ManDecoratorA(person);
        ManDecoratorB md2=new ManDecoratorB(person);
        md1.eat();
        System.out.println("===============");
        md2.eat();
    }
复制代码

运行结果为:

能够看到在吃饭前和吃饭后作了一些事情，这就达到了不增长子类而又能够添加一些额外功能的做用

回到ContextImpl和Context，其实也是同样的，这个ContextImpl至关于代码中的Man,而Context至关于Person,只是一个接口，一个抽象类，但本质都是同样，而Decorator至关于ContextWrapper，那么具体的抽象实现类为何呢，在Android中Activity和Service就是相似代码中的ManDecoratorA和ManDecoratorB了，只不过Activity有界面，天然就有Theme主题，所以对应的是ContextThemeWrapper，如今已经对装饰模式理解的更深了吧。

如今回到ContextImpl自己来，ContextImpl做为Context的抽象类，实现了全部的方法，咱们常见的getResources(),getAssets(),getApplication()等等的具体实现都是在ContextImpl的，下面是具体的一些代码

@Override
    public ContentResolver getContentResolver() {
        return mContentResolver;
    }

    @Override
    public Looper getMainLooper() {
        return mMainThread.getLooper();
    }

    @Override
    public Context getApplicationContext() {
        return (mPackageInfo != null) ?
                mPackageInfo.getApplication() : mMainThread.getApplication();
    }
复制代码

能够看到咱们日常开发所调用的方法的实现都是在这里完成，做为一名android开发者，咱们应该多去研究一些源码之类的，这样在出问题的时候能够根据源码找出问题的具体所在，ContextImpl在主线程ActivityThread经过传入主线程对象建立了一个系统的ContextImpl,下面是代码:

public ContextImpl getSystemContext() {
        synchronized (this) {
            if (mSystemContext == null) {
                mSystemContext = ContextImpl.createSystemContext(this);
            }
            return mSystemContext;
        }
    }
复制代码

这个是在ActivityThread里面完成的，ActivityThread是Android应用程序的主线程环境，关于对ActivityThread的分析，能够看个人另外一篇文章 关于Android主线程(ActivityThread)源代码分析以及一些特殊问题的很是规方法
你们有空能够去看看,实际上Activity和Service中的Context也是经过ContextImpl来的,你们有时间能够去看看主线程的源码，好了，咱们知道了ContextImpl里面的方法了，下面说一个具体的不太常见的需求.曾经有个需求，要求用户在卸载以后再从新安装进入的时候可以读取一些配置信息，当初服务端要求这个客户端本身去实现，有同窗说了这个自己不难，很简单啊，用SharePreference就能够搞定，恩，是很简单，但是需求说了再卸载以后从新进入的时候须要读取出来原来的配置，卸载以后整个应用程序的目录都不见了，全部数据都消失了，配置文件哪里来呢？,咱们知道，SharePreference是保存在一个叫作shared_prefs目录下面的，这个目录随着程序卸载也会被删掉，也就是说卸载以后，保存在原来默认的存储就会所有消失，那应该怎么办呢，其实只须要修改原来的路径改成自定义的路径就好，好比放在外部SD卡或者其余地方，这样程序卸载的时候就不会删除这些自定义的目录了，从而能够在安装再次进入的时候读取出来，看起来这个方法能够的

ContextImpl里面有一个字段mPreferencesDir，这个文件目录就是保存了SharePreference路径的，咱们只须要修改这个为咱们自定义的路径就行了，因为ContextImpl是一个隐藏类，咱们须要使用反射去实现，随我走一波吧，下面是具体的代码:

try {
            Class<?> clazz=Class.forName("android.app.ContextImpl");
            Method method=clazz.getDeclaredMethod("getImpl", Context.class);
            method.setAccessible(true);
            Object mContextImpl=method.invoke(null,this);
            //获取ContextImpl的实例
            Log.d("[app]","mContextImpl="+mContextImpl);
            Field mPreferencesDir=clazz.getDeclaredField("mPreferencesDir");
            mPreferencesDir.setAccessible(true);
            //咱们自定义的目录假设在SD卡, 其余目录也是同样的
            if (Environment.getExternalStorageState().equals(Environment.MEDIA_MOUNTED)){
                File file=new File(Environment.getExternalStorageDirectory(),"new_shared_pres");
                if (!file.exists()){
                    file.mkdirs();
                }
                mPreferencesDir.set(mContextImpl,file);
                Log.d("[app]","修改sp路径成功");
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
        
    下面是具体的执行结果:
    12-08 17:28:42.811 12404-12404/com.example.hotfixdemo D/[app]: mContextImpl=android.app.ContextImpl@db6fc37
12-08 17:28:42.818 12404-12404/com.example.hotfixdemo D/[app]: 修改sp路径成功
复制代码

OK,已经成功修改成自定义的路径了，这样就达到目的了。

实际上，除了SP的路径，ContextImpl里面还有不少相似这样的路径，同样是能够经过相似的手段修改的，达到一些特定的目的，好比360的插件框架也是Hook了ContextImpl类的数据库路径，达到加载的目的，你们有空能够去看看，Java层的Hook基本以反射和动态代理为主，这两方面的内容，有时间再写，今天就写到这里，感谢你们阅读。