我为何弃用Jetpack的App Startup？

前言

最近Jetpack又添加了新成员App Startup，官方声明这是一个在Android应用启动时，针对初始化组件进行优化的依赖库。本人第一次听到后非常高兴，因为自己负责的项目在启动时需要初始化的东西实在是太多，而且有点杂乱无章，都耦合在一起了。对于可以异步初始化的组件也没有进行异步处理，而对于已经处理过的异步组件它们之间的依赖关系或者多个异步之后的统一逻辑处理也没有一个很好的统一规范。所以针对这种情况早就想找个方案来优化了，这次终于等到了App Startup。

但是，当我元气满满的去查看官方文档时，并没有找到预想中的结果。官方文档中只提到了可以通过一个ContentProvider来统一管理需要初始化的组件，同时通过dependencies()方法解决组件间初始化的依赖顺序，然后呢？没了？等等官方你是不是漏了什么？

异步处理呢？虽然我们可以在create()方法中手动创建子线程进行异步任务，但一个异步任务依赖另一个异步任务又该如何处理呢？多个异步任务完成之后，统一逻辑处理又在哪里呢？依赖任务完成后的回调又在哪里？亦或者是依赖任务完成后的通知？

我有点不相信，所以又去查看了App Startup的源码，源码很简单，也就几个文件，最后发现确实只支持上面的那几个功能。

如果你的项目都是同步初始化的话，并且使用到了多个ContentProvider，App Startup可能有一定的优化空间，毕竟统一到了一个ContentProvider中，同时支持了简单的顺序依赖。

值得一提的是，App Startup中只提供了使用反射来获取初始化的组件实例，这对于一些没有过多依赖的初始化项目来说，盲目使用App Startup来优化是否会对启动速度进一步造成影响呢？

所以细想了一下，不禁让我想起了三国时的一个名词：鸡肋。食之无味，弃之可惜。

但最终我还是决定放弃使用它。

放弃之后有点不甘心，可能更多的是它没有解决我当前的项目场景。都分析了这么多，源码都看了，总不能半途而废吧，所以自己咬咬牙再补充一点呗。

所以坚持一下，就有了下面这个库，App Startup的进阶版Android Startup。

Android Startup

Android Startup提供一种在应用启动时能够更加简单、高效的方式来初始化组件。开发人员可以使用Android Startup来简化启动序列，并显式地设置初始化顺序与组件之间的依赖关系。
与此同时，Android Startup支持同步与异步等待，并通过有向无环图拓扑排序的方式来保证内部依赖组件的初始化顺序。

由于Android Startup是基于App Startup进行的扩展，所以它的使用方式与App Startup有点类似，该有的功能基本上都有，同时额外还附加其它功能。

下面是一张与google的App Startup功能对比的表格。

指标	App Startup	Android Startup
手动配置	✅	✅