先从
AndroidManifest.xml文件开始分析：SystemUIApplication是Application，PhoneSystemUIAppComponentFactory是Component
在System_server中，会拉起SystemUI，调用到Manifest注册的service
这时候，会调用到刚才的SystemUIApplication，在应用启动就会创建Application的声明周期
在
Android14版本中，SystemUI对所有的service都设置为CoreStartable，即所有的service都继承实现了CoreStartable
Application构建完成，我们看如何调用startServicesIfNeeded
调用到这里，继承CoreStartable的类，比如statusbar，就会启动start方法
下面的CentralSurfacesImpl 287行的代码，就是启动statusBar的类
稍微看一下statusBar的start方法，里面有获取锁屏控制器、创建底部导航栏、注册各种回调、
广播的相关逻辑。
到此，这段代码算走完整。
((SystemUIApplication) getApplication()).startServicesIfNeeded()
看其余的启动流程，基本就是dump相关的错误，开启监听，开启新的dump service。
到这里，SystemUI的服务启动完成。
这里面难点在于谷歌创建了大量的dagger，使用了控制反转的设计模式，很多的module、inject、binds、provide找起来难度也很大，有可能还在其父类中的module有我们需要的provider。
比如这个：
就是刚才我们使用到的所有的需要启动的组件。
