Android 8.0 SystemUI 源码分析（二）：启动流程和初始化

最新推荐文章于 2024-02-02 07:56:35 发布

原创最新推荐文章于 2024-02-02 07:56:35 发布 · 1.8k 阅读

6 ·

CC 4.0 BY-SA版权

文章标签：

#Android #SystemUI #进阶 #源码分析

Android 同时被 2 个专栏收录

5 篇文章

订阅专栏

SystemUI

2 篇文章

订阅专栏

本文首发微信公众号：菜天Android

零、前言

上篇『图文并茂的介绍:D』中我对 Android 8.0 中的SystemUI 作了简要的介绍，自我感觉很不错，又是思维导图又是截图的，觉得会对不了解的人会有帮助。但可能是太简要了，被骂是水货。qaq，呸呸呸！

这篇的话，将对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的初始进行进一步的说明。

三、举例说明：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都做了些什么，后续会进行跟进。

欢迎关注微信公众号

菜天Android

主推 Android 干货文章

关注得 Android 详细知识图谱