FastStartup

FastStartup是一个组件启动框架，旨在帮助开发人员能够简单、高效地进行各种组件的初始化操作。
Github链接FastStartup

如果你有兴趣看源码工程，那么你能额外收获的东西

1. 了解使用Booster进行开发Gradle插件
2. 了解Gradle插件的开发调试流程
3. 了解Gradle插件的打包流程和打包脚本并发布到mavencenter
4. 了解一个组件如何发布到mavencenter

代码没有过多的封装，让你体验这些流程的原汁原味。

1. 为什么要写这个组件？

这个问题我思考了很久，目前已经有很多类似的组件了，为什么还要写一个？

• 因为他们还比较受限，某些使用场景支持的不是很好
• 使用起来复杂，配置穿插很多地方，很多种，让人摸不着头脑
• 不支持解藕
• 存在反射、IO
• 不支持隐私场景

等等吧，虽然有些方面不能严格说的是弊端，比如说反射、IO。这些方式虽然理论上会增加耗时，但是在数量有限的情况下，带来的额外开销也不是很大，开销很小。但是我个人感觉，能不用还是不用。因为他们不适合我们的场景。

我们的组件是Startup，定位是在应用启动的时候，启动时间又会很敏感，大厂的App都对启动时间有严格的控制，所以一丢丢的开销，能避免也还是避免吧。另外反射会带来额外的内存开销，当你的App体量够大，机型够复杂的时候，就有可能会放大问题，所以我选择了最原始的方式，采用硬编码维护组件的列表。

还有就是启动参数，虽然可以通过其他方式在初始化的时候获取一些配置，比如你的一个任务需要一个key，类似组件就很少支持这种场景。

在写FastStartup的时候，对每一个任务都下发了Application、isDebug、param(Object类型的通用参数)，扩展性很好，给了你最大空间去扩展参数。

支持主线程等待，有了它，你就可以在子线程中去执行你的所有的任务（除非任务必须要在主线程执行），主线程会等待到你需要的任务执行完毕。

在组件很多的场景下，依赖关系可能很复杂，有可能初始化的时候丢了某一个组件或者组件间循环依赖了，为此，特意做了检测算法，能够在发现丢失组件和组件循环依赖的场景下打印出组件间的依赖关系图，让你一目了然，快速发现问题。也支持随谁打印所有的依赖关系图。

我很喜欢App Startup那种依赖即配置的形式，这样在组件化的时候非常方便，为此，特提供了ASM插桩的形式，依赖注解自动完成组件维护。

解藕采用的自动扫描接口的形式，自动扫描组件依赖的接口，维护接口类与组件类之间的关系，当你在依赖接口的时候，内部能够自动去找到对应的组件实体。

内部采用线程池，任务执行完毕后下一轮任务会复用线程，并没有采用其他方案中的所有任务都启动然后再阻塞，等依赖项执行完毕再唤醒这种方案。

还有很多其他的方面，就不一一讲述了，欢迎大家去体验 FastStartup

写这个组件花费了很多个夜晚和周末，如果可以，欢迎点个Star

2. 组件特点

简单、高效、支持解藕。 没有过多的启动配置方式，只为提供简单的使用体验。 全程无反射，无IO操作，能给您提供最快的启动速度。

3.使用它你能得到什么？

1. 全程无反射，无IO操作，提供最快的启动速度
2. 组件只需要关注自己依赖的其他组件，自动维护初始化顺序
3. 组件支持配置运行在UI线程和非UI线程
4. 支持UI线程等待操作，可以让UI线程阻塞到必要组件初始化完成，而必要组件可以运行在任意线程
5. 支持组件初始化参数配置，您可以创建一个任意形式配置信息，该配置信息将贯穿所有组件的初始化操作
6. 支持解藕，采用接口进行依赖管理，避免组件间的强依赖，让您的工程更加简洁
7. 支持组件自动注入，提供AOP方案，让您无需再处理每一个组件，只需要一个注解就可以自动进行初始化，实现依赖即配置
8. 支持组件完成回调，提供了三种回调，分别为每个组件初始化完成的回调、UI线程任务完成的回调、所有任务完成的回调
9. 支持组件初始化耗时统计
10. 支持依赖缺失检测和依赖循环依赖检测
11. 支持隐私模式启动，自动根据组件依赖关系和是否需要隐私模式启动进行初始化处理，能够在隐私权限授予后再次调用自动执行剩余任务
12. 支持组件依赖关系打印

4. 依赖环检测和缺失检测

在FastStartup启动的时候会自动进行依赖环检测和缺失检测 如果依赖有环，会抛出异常并会打印如下信息

如果依赖有缺失，会打印如下消息

5. 耗时统计

也许FastStartup并不完美，但是还是希望它能为你提供一种思路。如果有需要，可以提issues给我，如果你有其他想法，欢迎一起讨论