3.1、惯性思维下的歧途——自定义Application
在App开发中，我们一般会从自定义Application中获取应用的全局上下文，用于相关资源和服务的获取。示例如下：
public class App extends Application {
@SuppressLint("StaticFieldLeak") private static Context sContext;
@Override public void onCreate() { super.onCreate(); sContext = this; }
public static Context getContext() { return sContext; } }
SDK在一定程度上是App的子集，通过抽象出App的部分业务与逻辑封装而成。因此，惯性思维下，容易将这段代码直接在SDK内部实现。殊不知，这就是歧途开始的路口...
在自定义Application对象时，需要手动在AndroidManifest.xml的application节点中，通过android:name=".App"指定，否则不会加载这个自定义的Application。
在惯性思维下，SDK开发者很容易想到一个解决方案：让App来指定加载SDK内置自定义Application对象不就行了？那么问题来了，他App已经有了自己的自定义Application了呢？
再次惯性下去：那让App继承SDK的Application不就行了？那么问题又来了，他App已经继承了其他SDK的自定义Application了呢？
继续惯性下去，已经继承了一个？那就再继承一个，来个Application多继承吧？一查，Java没提供多个类继承的直接支持，但是也能曲线实现：
通过接口实现 + 反射 的方式来创建代理Application对象，曲线实现Application的多继承，由于代码较多，这里就不贴源码了。
解决方案：
至此，在惯性三连下，成功误入歧途。不是说没解决问题，只是解决的过于粗暴，友善度直线下降...
我们再回头看下，SDK初始化的本质就是为SDK注入一个App的上下文，而不是注入一个自定义Application。路肯定是走歪了的，但是我们也从歪路中学到了一些奇奇怪怪的知识，安慰下自己，也算是有收获吧。换个思路，继续往前走吧！
3.2、普遍采用的静态方法初始化
再复习一下SDK初始化的本质：注入App上下文，用于获取相关资源及服务。那么，为什么要在Application里初始化呢？
我们完全可以自定义一个“伪Application类”，再通过静态方法来注入应用上下文（一般为Application Context）。示例如下：
public class MySDK {
private static Context sContext;
private MySDK() { }
public static void initSdk(Context context) { //获取ApplicationContext防止内存泄漏 sContext = context.getApplicationContext(); initSomething();
}
public static Context getContext() { return sContext; }
private static void initSomething() { //init something }
}
如此一来，便可愉快初始化了：
public class App extends Application {
@Override public void onCreate() { super.onCreate();
//初始化SDK MySDK.initSdk(this);
} }
如此一来，别说获取App的上下文，初始化SDK的相关逻辑也有地方写了，友善度up up up。
3.3、“无侵入”的ContentProvider初始化方案
相信细心的朋友发现了，有些SDK看起来直接引入就行，也没有进行初始化呀？那他们是怎么做的呢？答案正是利用的ContentProvider获取了应用的上下文。看个示例
以上截图来自著名工具类SDK：AndroidUtilCode ,其实还有更多采用类似方式初始化的SDK，比如利用此方法进行初始化的鼻祖Firebase（貌似是），其他就不再一一举例了，大家平时也可以留意一下。
那么问题来了，为啥在ContentProvider就可以做初始化，并且获取到application context的呢？且看几段源码
截了三段源码，可以看到App的启动过程中加载了provider，并且传了一个Application实例进去，最终在ContentProvider中调用了onCreate()方法。因此，在自定义的ContentProvider中，通过getContext()方法就可以获取到Application的实例了。
其实从这段源码中，我们也可以看到，ContentProvider中的onCreate()方法是先于Application中的onCreate()方法执行的（注意：此时Application对象已经创建）。
关于App启动耗时的优化思路，是不是又多了一个关注点？
说完了源码再来看下SDK工程中怎么配置吧（其实开头的截图已经有了）：
public class MySDKInitProvider extends FileProvider{
@Override public boolean onCreate() { //初始化 MySDK.initSdk(getContext()); return super.onCreate(); } }
在SDK Module下的manifest中注册，编译时将会合并至主工程项目
<provider android:name=".MySDKInitProvider"
