Android 8.0 SystemUI（二）：启动流程和初始化
这篇的话，将对SystemUI的启动和大体的初始化作描述。篇幅应该比上篇多了些。哈哈。
老样子，先上目录，简洁明了。
概述
由于需要实时反馈系统状态，如蓝牙开关、wifi开关、时间及相应用户导航栏操作，SystemUI从系统一启动就被带起来了（SystemUI：我也不想啊！老累了！）。正常使用过程中的SystemUI，大多数功能模块都是出于运行状态，只有少数功能，比如：截屏功能，你长按电源+音量下键才会咔嚓截屏。
这里简要说下系统启动过程：由init进程->Zygote进程->SystemServer进程。
那init进程又是怎么起来的？当你按下电源键，系统上电，从固定地址开始加载固化在ROM的Bootloader代码到RAM中并执行，Bootloader引导程序负责将系统OS拉起。当系统OS被拉起，并完成一些列初始化和系统设置后，就会首先在系统文件中寻找“init”文件并启动这个咱们用户空间的第一个进程。
Emmm，扯远了，回到主题。按照一开始的系统启动过程，我们的SystemUI进程是在SystemServer的启动过程中被带起来。
从第一篇介绍我们知道，SystemUI有着很多的模块且对应着相应的界面。这些模块有些共同的地方，例如都需要：
- 处理各自模块的初始化
- 处理系统的状态变化
- 执行dump
- 系统启动完成时，要处理相应逻辑
所以在代码中体现为：将这些共同点提取并抽象，形成SystemUI抽象类，结构如下。
简单对这段代码说明下：
- 为子类定义了一个start方法供子类完成初始化，这个方法是一个抽象方法，因此具体的子类必现实现。
- onConfigurationChanged是处理系统状态变化的回调，这里的状态变化包括：时区变更，字体大小变更，输入模式变更，屏幕大小变更，屏幕方向变更等。
- 系统中很多的模块都包含了dump方法。dump方法用来将模块的内部状态dump到输出流中，这个方法主要是辅助调试所用。开发者可以在开发过程中，通过adb shell执行dump来了解系统的内部状态。
- onBootCompleted是系统启动完成的回调方法。
除了截屏服务，提及模块均继承抽象类SystemUI并在应用启动时被分别初始化。从这种角度来看，SystemUI应用更像是这些功能模块的容器。
值得一提的是，和Nougat相比，在Oreo中，抽象类SystemUI的两个子类：BaseStatusBar和PhoneStatusBar被合并替换成了StatusBar.java。相信了解接触过SystemUI模块的老司机对PhoneStatusBar这个核心类一定很熟悉和，现在也尘归尘、土归土咯。
二、SystemUI启动流程
SystemServer负责系统中各种重要服务的启动，不巧，由于SystemUI的重要性，她也在被启动之列，虽然是处于“Other”的地位~（SystemServer的代码对系统服务类别大体分为三类：Bootstrap->Core->Other，SystemUI的启动就在Other中）。
在startOtherServices()中，通过调用AMS的systemReady()方法通知AMS准备就绪。systemReady()拥有一个名为goingCallback的Runnable实例作为参数，So，当AMS完成对systemReady()的处理后将会回调这一Runnable的run()方法。
-
private void startOtherServices() { -
... //省略大概1000行 -
mActivityManagerService.systemReady(() -> { -
Slog.i(TAG, "Making services ready"); -
... -
traceBeginAndSlog("StartSystemUI"); -
try { -
startSystemUi(context, windowManagerF); -
} catch (Throwable e) { -
reportWtf("starting System UI", e); -
} -
... -
} -
}
并在startSystemUi方法中，通过红框中的组件名启动了SystemUI中的SystemUIService服务
对于Android系统来说，当一个应用启动，系统会保证其Application类是第一个被实例化的类，并且Application的onCreate方法，一定先于应用中所有的Activity，Service和BroadcastReceiver的创建。
SystemUI中，SystemUIApplication就是第一个被实例化的类。
在其中，定义了两组服务：
- 一类是所有用户共用的SystemUI服务，例如：Status Bar
- 一类是每个用户独有的服务
下面的两个数组记录了这两组服务
前面也提到，SystemUI抽取了功能模块的共性形成抽象类SystemUI.class，上图中所有列出的类型，均是SystemUI的子类实现。
接着说，在SystemUIApplication中，onCreate方法被调用：主要注册一个广播接收器，用以接收BOOT_COMPLETED广播，在接收到广播后，调用各模块的函数onBootCompleted。
你还记的SystemServer中启动SystemUI的代码不？那个目标是SystemUIService的Intent。
当SystemApplication家的onCreate执行完毕，就会去启动这个SystemUIService。按照规矩，此服务onCreate方法在启动时被调用。
不研究不知道，哇靠，这家伙只是个中转代理（给别人一个启动你的机会）而已~，不信你看，实际代码只有下面一行，看下图。
整个服务，真正干活的只有红框中的一句话。仔细瞅瞅，调用的是SystemUIApplication中的startServicesIfNeeded方法，转了一圈又回来了。
这就是启动各模块的地方。
-
private void startServicesIfNeeded(Class<?>[] services) { -
if (mServicesStarted) { -
return; -
} -
if (!mBootCompleted) { -
// check to see if maybe it was already completed long before we began -
// see ActivityManagerService.finishBooting() -
if ("1".equals(SystemProperties.get("sys.boot_completed"))) { -
// sys.boot_completed属性值，在系统boot完成后，AMS会对其进行设置 -
mBootCompleted = true; -
if (DEBUG) Log.v(TAG, "BOOT_COMPLETED was already sent"); -
} -
} -
Log.v(TAG, "Starting SystemUI services for user " + -
Process.myUserHandle().getIdentifier() + "."); -
final int N = services.length; -
for (int i = 0; i < N; i++) { -
Class<?> cl = services[i]; -
if (DEBUG) Log.d(TAG, "loading: " + cl); -
try { -
// SystemUIFactory类在6.0上还没有，是7.0上出现的，目的是为了提供可定制化的SystemUI -
Object newService = SystemUIFactory.getInstance().createInstance(cl); -
mServices[i] = (SystemUI) ((newService == null) ? cl.newInstance() : newService); -
} catch (IllegalAccessException ex) { -
throw new RuntimeException(ex); -
} catch (InstantiationException ex) { -
throw new RuntimeException(ex); -
} -
// 对数组中的每一个Service都进行初始化 -
mServices[i].mContext = this; -
mServices[i].mComponents = mComponents; -
if (DEBUG) Log.d(TAG, "running: " + mServices[i]); -
mServices[i].start(); -
if (mBootCompleted) { -
mServices[i].onBootCompleted(); -
} -
} -
... -
}
对于SystemUI App启动，这里总结了一张启动时序图给大家参考，如下所示：
进一步的话，就到了各个模块独自的初始化逻辑了。
这里我们单独对SystemBars的初始进行进一步的说明。
三、e.g. SystemBars
SystemBars主要包含了NavigationBar和StatusBar，不知道这两个Bar对应位置的同学可以看下第一篇『图文并茂的介绍:D』。
Show the code：
-
public class SystemBars extends SystemUI { -
private static final String TAG = "SystemBars"; -
private static final boolean DEBUG = false; -
private static final int WAIT_FOR_BARS_TO_DIE = 500; -
// in-process fallback implementation, per the product config -
private SystemUI mStatusBar; -
@Override -
public void start() { -
if (DEBUG) Log.d(TAG, "start"); -
createStatusBarFromConfig(); -
} -
@Override -
public void dump(FileDescriptor fd, PrintWriter pw, String[] args) { -
if (mStatusBar != null) { -
mStatusBar.dump(fd, pw, args); -
} -
} -
private void createStatusBarFromConfig() { -
if (DEBUG) Log.d(TAG, "createStatusBarFromConfig"); -
final String clsName = mContext.getString(R.string.config_statusBarComponent); -
if (clsName == null || clsName.length() == 0) { -
throw andLog("No status bar component configured", null); -
} -
Class<?> cls = null; -
try { -
cls = mContext.getClassLoader().loadClass(clsName); -
} catch (Throwable t) { -
throw andLog("Error loading status bar component: " + clsName, t); -
} -
try { -
mStatusBar = (SystemUI) cls.newInstance(); -
} catch (Throwable t) { -
throw andLog("Error creating status bar component: " + clsName, t); -
} -
mStatusBar.mContext = mContext; -
mStatusBar.mComponents = mComponents; -
mStatusBar.start(); -
if (DEBUG) Log.d(TAG, "started " + mStatusBar.getClass().getSimpleName()); -
} -
private RuntimeException andLog(String msg, Throwable t) { -
Log.w(TAG, msg, t); -
throw new RuntimeException(msg, t); -
} -
}
这段代码说明如下：
- start方法由SystemUIApplication调用
- 调用createStatusBarFromConfig方法，根据配置文件中的信息来进行Status Bar的初始化
- 读取配置文件中实现类的类名。这个值于frameworks/base/packages/SystemUI/res/values/config.xml中定义。在手机中，其值是：com.android.systemui.statusbar.phone.StatusBar
- 通过类加载器加载对应的类
- 通过反射API创建对象实例
- 最后调用实例的start方法对其进行初始化。如果是手机设备，这里就是StatusBar.start方法
为什么要读取资源文件获取类名并通过反射来创建实例呢？
好处是：
这里将类名配置在资源文件中，那么对于Tv和Car这些不同的平台，可以不用修改任何的代码，只需要修改配置文件，便替换了系统中状态栏的实现，由此减少了模块间的耦合，也减少了系统的维护成本。
值得我们借鉴。
好了，SystemUI的启动到这里就结束了，具体SystemBars以及StatusBar都做了些什么，后续会进行跟进。