今天主要从组件化 + 责任链 的角度去讲启动。主要讲代码的可维护性、解耦，跟启动速度没什么关系
有些错误的做法是 在宿主的 Application 中初始化所有的组件。
app 启动包括三个部分： Application 过程、 Splash 过程、 Mainactivity 过程（第一个 Activity）
有可能在 Application 中用户同意了某些条款和不同意的情况下初始化还不一样。工信部要求App 这样。所以可能宿App 中定义一个 BaseApplication 接口，除了其他方法之外，在其中至少定义几个方法：
不论同不同意用户协议都需要执行的方法
用户同意了协议才执行的方法
用户拒绝后执行的方法
然后，让每个组件去实现这个接口，实现上述的方法，自己实现各自的逻辑。可以利用 autoService 将这些组件的 Application 注册到宿主中，并不需要自己去遍历添加到list 里面。这是在编译期间将这些组件的 Application 添加到宿主的list 中的，所以对于运行效率是没有影响的。
在 autoService 的 gradle 中实现的，可以看看他的 gradle 文件
compose 是一套新的 UI 体系，和以前的 View 和 ViewGroup 有啥区别？
前者是声明式的，数据驱动的，后者是命令驱动的
compose 和 databinding 的区别：
databinding ： 只能绑定属性，只能绑定xml 属性中的值
compose 可以根据数据的变化改变视图的结构
只有在主进程才需要执行我们的逻辑，有些SDK 可能会开启自己的进程，所以需要判断下。
老师说写 SplashActivity ，在 manifest 中给这个 SplashActivity 设置 theme ，在 theme 里面设置 background ，但是其实前面说启动优化的时候，给整个 App 设置 theme ，然后设置 android:windowSplashscreenContent 属性就好了，注意区分和甄别。
SplashActivity 启动 MainActivity ，那么 SplashActivity 在什么时候可以结束？我们知道，在启动过程肯定是 SplashActivity.onPause -> MainActivity.onCreate -> MainActivity.onResume -> SplashActivity.onStop 这样的顺序执行的，当然，MainActivity的其他无关的回调省略了。所以，在 SplashActivity 的 onStop 的时候， SplashActivity 就没有什么意义了，所以可以在 SplashActivity 的 onStop 回调中执行 finish 结束。
为什么这样做呢？因为如果在 SplashActivity 中 start MainActivity的时候直接 finish SplashActivity ，某种情况就可能会出现白屏，或者 MainActivity 崩溃了，就看不到我们 App 了
讲到 1 小时40分钟的时候直接听不懂了，放弃，后续有时间看
