Android SDK开发艺术探索(三)初始化

3,498 阅读7分钟

一、前言

本篇是Android SDK开发艺术探索系列的第三篇文章。系统介绍了SDK的几种初始化方式,以及SDK开发历程中由于“误入歧途”而了解到的Java多重继承、ContentProvider用于SDK初始化的姿势等。通过认识初始化到初始化的几种方式,进而试图探索初始化的本质和最优解。

系列文章:

Android SDK开发艺术探索(一)开篇与设计

Android SDK开发艺术探索(二)Exception or ErrorCode

Android SDK开发艺术探索(三)初始化

Android SDK开发艺术探索(四)个性化配置

Android SDK开发艺术探索(五)安全与校验

Android SDK开发艺术探索(六)压缩与优化

Android SDK开发艺术探索(七)依赖原则与打包方法

二、初始化的概念

在日常的开发中,可以看到我们常用的第三方SDK在使用前都需要一个初始化的步骤。那么为什么要初始化?初始化到底做了啥?笔者认为:初始化的本质是将App的上下文(Context)注入到SDK中,使其能通过这个上下文访问到App的资源与服务。也包括在初始化时调用SDK方法进行相关选项的自定义配置。

三、初始化的几种方式

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.xmlapplication节点中,通过android:name=".App"指定,否则不会加载这个自定义的Application。

在惯性思维下,SDK开发者很容易想到一个解决方案:让App来指定加载SDK内置自定义Application对象不就行了?那么问题来了,他App已经有了自己的自定义Application了呢?

再次惯性下去:那让App继承SDK的Application不就行了?那么问题又来了,他App已经继承了其他SDK的自定义Application了呢?

继续惯性下去,已经继承了一个?那就再继承一个,来个Application多继承吧?一查,Java没提供多个类继承的直接支持,但是也能曲线实现:

通过接口实现 + 反射 的方式来创建代理Application对象,曲线实现Application的多继承,由于代码较多,这里就不贴源码了。解决方案:ApplicationProxyDemo

至此,在惯性三连下,成功误入歧途。不是说没解决问题,只是解决的过于粗暴,友善度直线下降...

我们再回头看下,SDK初始化的本质就是为SDK注入一个App的上下文,而不是注入一个自定义Application。路肯定是走歪了的,但是我们也从歪路中学到了一些奇奇怪怪的知识,安慰下自己,也算是有收获吧。换个思路,继续往前走吧!

3.2、普遍采用的静态方法初始化

再复习一下SDK初始化的本质:注入App上下文,用于获取相关资源及服务。那么,为什么要在Application里初始化呢?

我们完全可以自定义一个“伪Application类”,再通过静态方法来注入应用上下文(一般为Application Context)。示例如下:

/**
 * <pre>
 *     author : bruce
 *     time   : 2020/07/09
 *     desc   : SDK初始化入口
 *     version: 1.0.0
 * </pre>
 */
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
    }

}

如此一来,便可愉快初始化了:

/**
 * <pre>
 *     author : bruce
 *     time   : 2020/07/09
 *     desc   : 自定义Application
 *     version: 1.0.0
 * </pre>
 */
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获取了应用的上下文。看个示例

AndroidUtilCode-源码

以上截图来自著名工具类SDK:AndroidUtilCode ,其实还有更多采用类似方式初始化的SDK,比如利用此方法进行初始化的鼻祖Firebase(貌似是),其他就不再一一举例了,大家平时也可以留意一下。

那么问题来了,为啥在ContentProvider就可以做初始化,并且获取到application context的呢?且看几段源码

ActivityThread-handleBindApplication

ActivityThread-installProvider

ContentProvider-attachInfo

截了三段源码,可以看到App的启动过程中加载了provider,并且传了一个Application实例进去,最终在ContentProvider中调用了onCreate()方法。因此,在自定义的ContentProvider中,通过getContext()方法就可以获取到Application的实例了。

其实从这段源码中,我们也可以看到,ContentProvider中的onCreate()方法是先于Application中的onCreate()方法执行的(注意:此时Application对象已经创建)。关于App启动耗时的优化思路,是不是又多了一个关注点?

说完了源码再来看下SDK工程中怎么配置吧(其实开头的截图已经有了):

/**
 * <pre>
 *     author : bruce
 *     time   : 2020/07/09
 *     desc   : 自定义用于初始化的Provider,FileProvider是ContentProvider的子类
 *     version: 1.0.0
 * </pre>
 */
public class MySDKInitProvider extends FileProvider{

    @Override
    public boolean onCreate() {
        //初始化
        MySDK.initSdk(getContext());
        return super.onCreate();
    }
}

在SDK Module下的manifest中注册,编译时将会合并至主工程项目

<provider
    android:name=".MySDKInitProvider"
    android:authorities="${applicationId}.MySDKInitProvider"
    android:exported="false"
    android:grantUriPermissions="true">
    <meta-data
        android:name="android.support.FILE_PROVIDER_PATHS"
        android:resource="@xml/my_sdk_provider_paths" />
</provider>

这里需要注意的是Provider的authorities千万别写死,否则两个引入同样SDK的App就无法共存了,这大概是SDK最不该犯的错误之一吧!

3.4、初始化新姿势-App Startup

关注Jetpack的同学可能有留意到,不久前谷歌新增了一个组件—— App Startup 。

App Startup提供了一种在应用程序启动时高效、直接初始化组件的方法。SDK开发人员和APP开发人员都可以使用App Startup简化启动顺序并显式设置初始化顺序。 App Startup还允许通过定义共享的ContentProvider统一组件的初始化,大大缩短应用启动时间。

该组件的发布,也可以看到谷歌试图为混乱的ContentProvider初始化填坑,为更加可控的初始化填坑。虽然将Provider用于初始化方便了调用人员,看似“无侵入”,实则“强侵入”。试想一下,在追求App性能与启动速度的场景中,多个SDK同时利用各自定义的ContentProvider实现“自启动”,还要在各种有先后顺序与依赖的SDK初始化下做优化,那滋味恐怕也不好受吧?

由于该组件还处于alpha的阶段,就不太建议用于生产环境中了。感兴趣的可以自行了解一下,官方文档地址:app-startup

四、结语

本篇主要介绍了SDK初始化的相关概念,以及初始化的本质,即:将App的上下文(Context)注入到SDK中,使其能通过这个上下文访问到App的资源与服务。以及在SDK开发中几种可行的初始化方式:一是被抛弃的自定义Application方案,二是可行的静态初始化方法,三是利用ContentProvider实现的“无侵入”初始化方案。至于为什么给“无侵入”打上了双引号,相信大家看完后也有了一些感性的认识。

最后,如果本篇文档对您的开发有所帮助或启发,点赞/关注/分享三连就是对作者持续创作最好的激励,感谢支持!

参考文章

版权声明:

本文首发于我的专栏 AndDev安卓开发 已授权鸿洋公众号独家发布。