【系统解读】SystemUI篇（一）SystemUI启动流程

前言

转载请声明，转自【https://www.cnblogs.com/andy-songwei/p/11471355.html】，谢谢！

SystemUI是系统启动中第一个用户肉眼可见的应用，其功能包罗万象，比如开机后看到的锁屏界面，充电时充电界面，状态栏，导航栏，多任务栏等，都是与Android手机用户息息相关的功能。所以不止SystemUI开发者，普通的应用开发者也很有必要去了解一下SystemUI。本系列文章会基于Android P和Android Q来介绍SystemUI的各个方面，本篇作为本系列第一篇，主要介绍了SystemUI的启动流程，以及主要功能简介。

本文的主要内容如下：

一、SystemUI简介

SystemUI，顾名思义是系统为用户提供的系统级别的信息显示与交互的一套UI组件，所以其功能包罗万象。比如锁屏、状态栏、底部导航栏、最近使用App列表等，大部分功能相互独立，按需启动，后文会继续列出更多功能。在系统源码中，其位置为：frameworks/base/package/SystemUI。尽管从表现形式上看，SystemUI和普通的Android APP有较大的差别，但其本质和普通APP并没有什么差别，也是以apk的形式存在，如下图所示：

以当前测试机为例，其就预置在系统指定的目录下。也是通过Android的4大组件中的Activity、Service、BroadcastReceiver来接受外界的请求并执行相关的操作，只不过它们所接受的请求主要来自各个系统服务而已。

二、Lambda表达式简介

由于后面有个流程中用到了Lambda表达式，为了后面便于讲解，这里咱们先简单介绍一下它，并简单演示其使用方法，这里不做深入探讨，有兴趣的可以自行研究。

Lambda表达式是一个匿名函数，即没有函数名的函数，是基于数学中的λ演算得名。在java中，从java8开始引入，使用它来设计代码会更加简洁。下面在Android项目中举两个例子来直观感受一下Lambda语法的使用。

以下是一个很常见的设置点击事件的例子，先看看不用Lambda表达式时的情况：

 mTextView.setOnClickListener(new View.OnClickListener() {
     @Override
     public void onClick(View v) {
         Log.i("songzheweiwang", "test lambda");
     }
 });

在采用Lambda表达式后，就是下面这种情况：

 mTextView.setOnClickListener(onClickListener -> {
             Log.i("songzheweiwang", "test lambda");
     });

其中“onClickListener”是随意取的一个字符串，我们取名的时候便于识别就可以了。可见整个代码简洁了很多，阅读起来也非常简单。

另外再看一个更加明显的例子，不使用Lambda表达式时是这样：

 Runnable runnable = new Runnable() {
     @Override
     public void run() {
         Log.i("songzheweiwang", "test lambda");
     }
 };

使用Lambda表达式后，就成了这样：

1 Runnable runnable2 = () -> Log.i("songzheweiwang", "test lambda");

如上的“->”符号可以读作“go to”。使用Lambda表达式来代替匿名的内部类，确实是非常的方便，但是使用的时候需要注意java的版本号，前面说了，是在java8中才引入的，否则在编译时会报如下的错误：

如上内容参考【Lambda表达式_百度百科】

三、SystemUI的启动时机

在【【乘风破浪】Android系统启动篇】中，我介绍过Android系统的大致流程，在第6步中讲到了SystemServer进程的启动。SystemServer进程启动时，会执行下面的代码：

 //=========SystemServer.java=========
 public static void main(String[] args) {
     new SystemServer().run();
 }
 private void run() {
     ......
     //创建消息Looper
     Looper.prepareMainLooper();
     // 加载动态库libandroid_servers.so，初始化native服务
     System.loadLibrary("android_servers");
     ......
     //初始化系统context
     createSystemContext();
     //创建SystemServiceManager
     mSystemServiceManager = new SystemServiceManager(mSystemContext);
     ......
     //启动引导服务，如AMS等
     startBootstrapServices();
     //启动核心服务
     startCoreServices();
     //启动其它服务，如WMS，SystemUI等
     startOtherServices();
     ....
 }

在执行完第18、20行的代码后，会启动引导服务和一些核心服务，如AMS等，然后第22行中就会启动其他服务，其中SystemUI就在其中。

 //======SystemServer.java======
 private void startOtherServices() {
         ......
         // We now tell the activity manager it is okay to run third party
         // code.  It will call back into us once it has gotten to the state
         // where third party code can really run (but before it has actually
         // started launching the initial applications), for us to complete our
         // initialization.
         mActivityManagerService.systemReady(() -> {
             ......
             traceBeginAndSlog("StartSystemUI");
             try {
                 startSystemUi(context, windowManagerF);
             } catch (Throwable e) {
                 reportWtf("starting System UI", e);
             }
             traceEnd();
             ......
         }, BOOT_TIMINGS_TRACE_LOG）;
         ......
 }

在第9行中，前面讲过AMS先启动了，mActivityManagerService调用systemReady方法，这里就用到了前面介绍过的Lambda表达式，systemReady方法的源码如下：

 public void systemReady(final Runnable goingCallback, BootTimingsTraceLog traceLog) {
       ......
       if (goingCallback != null) {
           goingCallback.run();
       }
       ......
 }

这里参照前面介绍的Lambda表达式的使用方法就容易理解了，实际上就是执行Runnable的回调而已，这里其实就等同于如下代码：

 mActivityManagerService.systemReady(new Runnable(){
    new Runnable() {
         @Override
         public void run() {
            //Lambda表达式中的回调代码
         }
      }
 },BOOT_TIMINGS_TRACE_LOG);

实际上在Lambda表达式还未引入前，即早期的代码中就是这样写法。

当一切就绪后，回调开始执行，就开始执行第13行的startSystemUI方法了。该方法的源码如下：

 static final void startSystemUi(Context context, WindowManagerService windowManager) {
     Intent intent = new Intent();
     intent.setComponent(new ComponentName("com.android.systemui",
                 "com.android.systemui.SystemUIService"));
     intent.addFlags(Intent.FLAG_DEBUG_TRIAGED_MISSING);
     //Slog.d(TAG, "Starting service: " + intent);
     context.startServiceAsUser(intent, UserHandle.SYSTEM);
     windowManager.onSystemUiStarted();
 }

第3、4行中给出了包名和类名，这样就开始启动SystemUI了。从这段代码可以看到，SystemUI是通过Service来启动的，而且是以系统的身份来启动它的。

四、Service启动流程浅析

上节中startSystemUI方法中开始启动SystemUIService，Service的启动流程比较复杂，这里不做详细分析，仅简单介绍一下其中和本节息息相关的关键流程。

上节代码第7行startSystemUI方法的调用者看起来是Context类型的context，Context是一个抽象类，实际执行者其实是ContextImpl。调用流程会通过Binder方式从ContextImpl跳转到AMS中，再通过Binder方式跳转到ActivityThread中的内部类ApplicationThread中的scheduleCreateService方法。在该方法中会发送给Handler H来处理，Handler H的实例化是使用的主线程的Looper，所以其回调方法handleMessage就是在主线程中执行的，此时会在该方法中调用handleCreateService方法，咱们从这个方法开始看。

 private void handleCreateService(CreateServiceData data) {
     ......
     Service service = null;
     try {
         ......
         service = packageInfo.getAppFactory()
                 .instantiateService(cl, data.info.name, data.intent);
     } catch (Exception e) {
         ......
     }
     try {
         ......
         ContextImpl context = ContextImpl.createAppContext(this, packageInfo);
         context.setOuterContext(service);
         Application app = packageInfo.makeApplication(false, mInstrumentation);
         service.attach(context, this, data.info.name, data.token, app,
                 ActivityManager.getService());
         service.onCreate();
         ......
     } catch (Exception e) {
         ......
     }
 }

第6行创建了service的实例，第13行创建上下文，第15行创建Application，并在其中执行了Application的onCreate方法，第18行执行了service的onCreate方法。这里进入到第15行的makeApplication方法。下面截取了关键代码：

 public Application makeApplication(boolean forceDefaultAppClass,
         Instrumentation instrumentation) {
     ......
     Application app = null;
     String appClass = mApplicationInfo.className;
     if (forceDefaultAppClass || (appClass == null)) {
         appClass = "android.app.Application";
     }
     try {
         ......
         ContextImpl appContext = ContextImpl.createAppContext(mActivityThread, this);
         app = mActivityThread.mInstrumentation.newApplication(
                 cl, appClass, appContext);
         appContext.setOuterContext(app);
     } catch (Exception e) {
         ......
     }
     mActivityThread.mAllApplications.add(app);
     ......
     if (instrumentation != null) {
         try {
             instrumentation.callApplicationOnCreate(app);
         } catch (Exception e) {
             ......
         }
     }
     ......
     return app;
 }

因为是初始启动，所以会走到第7行。第12行的newApplication源码如下：

 public Application newApplication(ClassLoader cl, String className, Context context)
             throws InstantiationException, IllegalAccessException,
             ClassNotFoundException {
         Application app = getFactory(context.getPackageName())
                 .instantiateApplication(cl, className);
         app.attach(context);
         return app;
     }

继续追踪instantiateApplication方法：

 public @NonNull Application instantiateApplication(@NonNull ClassLoader cl,
         @NonNull String className)
         throws InstantiationException, IllegalAccessException, ClassNotFoundException {
     return (Application) cl.loadClass(className).newInstance();
 }

这里就通过类加载器的形式创建了Application的实例。可见前面的makeApplication方法第12行的作用就是创建Application实例了，然后走到该方法的第22行，进入该方法：

 public void callApplicationOnCreate(Application app) {
     app.onCreate();
 }

该方法中Application执行了onCreate方法。

到这里service的大致启动流程就明了了，这里咱们需要记住一个执行顺序（因为我看过不少资料容易在这里犯错，说是Application会比Service先实例化，通过这个流程我们可以看到这种说法是错误的，所以这里着重提出来）：

（1）实例Service；

（2）实例Application；

（3）Application实例执行onCreate方法；

（4）Service实例执行onCrate方法。

五、SystemUIApplication中onCreate方法处理逻辑

上一节我们分析了，会先执行Application的onCreate方法，在执行Service的onCreate方法，这里先分析SystemUIApplication中onCreate方法的执行逻辑。

 //============SystemUIApplication.java========
 private SystemUI[] mServices;
 @Override
 public void onCreate() {
     super.onCreate();
     ......
     //设置主题
     setTheme(R.style.Theme_SystemUI);
     ......
     if (Process.myUserHandle().equals(UserHandle.SYSTEM)) {
         IntentFilter bootCompletedFilter = new IntentFilter(Intent.ACTION_BOOT_COMPLETED);
         bootCompletedFilter.setPriority(IntentFilter.SYSTEM_HIGH_PRIORITY);
         registerReceiver(new BroadcastReceiver() {
             @Override
             public void onReceive(Context context, Intent intent) {
                 if (mBootCompleted) return;

                 if (DEBUG) Log.v(TAG, "BOOT_COMPLETED received");
                 unregisterReceiver(this);
                 mBootCompleted = true;
                 if (mServicesStarted) {
                     final int N = mServices.length;
                     for (int i = 0; i < N; i++) {
                         mServices[i].onBootCompleted();
                     }
                 }
             }
         }, bootCompletedFilter);

         IntentFilter localeChangedFilter = new IntentFilter(Intent.ACTION_LOCALE_CHANGED);
         registerReceiver(new BroadcastReceiver() {
             @Override
             public void onReceive(Context context, Intent intent) {
                 if (Intent.ACTION_LOCALE_CHANGED.equals(intent.getAction())) {
                     if (!mBootCompleted) return;
                     // Update names of SystemUi notification channels
                     NotificationChannels.createAll(context);
                 }
             }
         }, localeChangedFilter);
     } else {
         ......
         startSecondaryUserServicesIfNeeded();
     }
 }

这里说一下第9行的if-else逻辑，我们知道Linux是多用户操作系统，所以这个if-else语句就是判断是系统用户，还是切换到了其它用户。SystemUI大多数功能对所有用户都是一样的，只有少部分功能会因为不同的用户而表现不一样，比如通知、多任务功能等，这里后面会再讲到。如果是系统用户就会走if中的流程，这里注册了两个广播接收器，用于监听Intent.ACTION_BOOT_COMPLETED和Intent.ACTION_LOCALE_CHANGED。

Intent.ACTION_BOOT_COMPLETED是监听开机启动，这里分析的Android9.0的系统源码，当前系统中使用的是FBE加密方式（读者请自行查阅FBE加密方式，这里不做详细介绍），这种方式下，要等到系统启动并锁屏界面解锁后，在进入到桌面过程中，系统才会发送发送该广播，所以接收该广播的处理逻辑会比较延后。通过第15行和第18行可以看到，该广播只会处理一次，就会反注册该广播，以后就不会再接收了。在这个逻辑当中，第20行到第25行，判断mServicesStarted变量，该变量表示SystemUIService是否已经启动了，实际上由于该广播接收的时机比较延后，会在SystemUIService启动完后才接收到该广播，所以这里面的代码会在此时执行。第23行的mService[]数组存储的是SystemUI的子服务，当整个系统启动完成后，这里面的每个子服务都会执行onBootCompleted()方法，让各个子服务知道系统启动完成了，要做自己该做的事情了。mService[]的赋值以及它存储的SytemUI子服务，下一节会详细讲解，这里我们只需要知道，这个过程发生在SystemUIService的启动阶段即可。

Intent.ACTION_LOCALE_CHANGED广播是用于监听设备当前区域设置已更改时发出的广播，简单来说就是修改语言时发出的广播（暂时不知道其它动作是否也会发送该广播）。

第42行就是在当前用户不是系统用户时的情况，即切换用户后的场景，该动作发生时系统是已经启动了的，不会再触发Intent.ACTION_BOOT_COMPLETED广播。这里看一看它的执行过程：

 void startSecondaryUserServicesIfNeeded() {
     String[] names =
               getResources().getStringArray(R.array.config_systemUIServiceComponentsPerUser);
     startServicesIfNeeded(names);
 }

第2行和第4行其实就是启动资源文件指定的功能，如下所示：

 <string-array name="config_systemUIServiceComponentsPerUser" translatable="false">
     <item>com.android.systemui.Dependency</item>
     <item>com.android.systemui.util.NotificationChannels</item>
     <item>com.android.systemui.recents.Recents</item>
 </string-array>

可以看到包含了通知（第3行）和多任务（第4行），这几个功能会因用户不同而异，第2行是什么功能暂时不清楚，读者可以自己查阅。另外我们会发现，实际上这几个子服务，在下一节的 config_systemUIServiceComponents数组资源中也都是包含的，也就正好对应了前面说的，切换到个人用户后这几个功能会因用户不同而表现不同，需要重新加载一次。startSecondaryUserServicesIfNeeded方法的处理逻辑，在下一节会详细讲到，这里咱们只需要清楚这一块的功能即可。

六、SystemUIService中onCreate方法处理逻辑

如前文所述，SystemUI通过“com.android.systemui.SystemUIService”这个服务来启动，在Application的onCreate方法执行完后，就会执行自己的onCreate方法。下面看看SystemUIService启动过程中做了哪些工作：

 public class SystemUIService extends Service {
    @Override
    public void onCreate() {
       super.onCreate();
       ((SystemUIApplication) getApplication()).startServicesIfNeeded();
        ......
    }
   ......
 }

该类中关键代码是第5行代码，其它的没有什么重要逻辑，继续追踪startServicesIfNeeded()方法：

 //===========SystemUIApplication==========
 public void startServicesIfNeeded() {
       String[] names = getResources().getStringArray(R.array.config_systemUIServiceComponents);
       startServicesIfNeeded(names);
 }

第3行在资源文件中对应的数组如下所示，每一项都对应了一个子服务（这里并不是表示它们是Service，而是指某项功能模块），实际上在Android O及以前的版本中，这些类都是以数组的形式保存在代码中的。

 <string-array name="config_systemUIServiceComponents" translatable="false">
     <item>com.android.systemui.Dependency</item>
     <item>com.android.systemui.util.NotificationChannels</item>
     <item>com.android.systemui.statusbar.CommandQueue$CommandQueueStart</item>
     <item>com.android.systemui.keyguard.KeyguardViewMediator</item>
     <item>com.android.systemui.recents.Recents</item>
     <item>com.android.systemui.volume.VolumeUI</item>
     <item>com.android.systemui.stackdivider.Divider</item>
     <item>com.android.systemui.SystemBars</item>
     <item>com.android.systemui.usb.StorageNotification</item>
     <item>com.android.systemui.power.PowerUI</item>
     <item>com.android.systemui.media.RingtonePlayer</item>
     <item>com.android.systemui.keyboard.KeyboardUI</item>
     <item>com.android.systemui.pip.PipUI</item>
     <item>com.android.systemui.shortcut.ShortcutKeyDispatcher</item>
     <item>@string/config_systemUIVendorServiceComponent</item>
     <item>com.android.systemui.util.leak.GarbageMonitor$Service</item>
     <item>com.android.systemui.LatencyTester</item>
     <item>com.android.systemui.globalactions.GlobalActionsComponent</item>
     <item>com.android.systemui.ScreenDecorations</item>
     <item>com.android.systemui.fingerprint.FingerprintDialogImpl</item>
     <item>com.android.systemui.SliceBroadcastRelayHandler</item>
 </string-array>

在Android Q上将第21行修改为了

 <item>com.android.systemui.biometrics.BiometricDialogImpl</item>

就是将指纹识别功能改成了生物识别功能，在Android Q上开始，除了指纹识别外，还增加了人脸识别。在原来的基础上另外再添加了3条：

 <item>com.android.systemui.SizeCompatModeActivityController</item>
 <item>com.android.systemui.statusbar.notification.InstantAppNotifier</item>
 <item>com.android.systemui.theme.ThemeOverlayController</item> 

打开这每一个类后，会发现它们都继承自SystemUI类，SystemUI类是一个抽象类，提供了如下接口：

 public abstract class SystemUI implements SysUiServiceProvider {
     ......
     public abstract void start();

     protected void onConfigurationChanged(Configuration newConfig) {
     }

     public void dump(FileDescriptor fd, PrintWriter pw, String[] args) {
     }

     protected void onBootCompleted() {
     }
     ......
     }
 }

startServicesIfNeeded(names)方法源码如下：

 private SystemUI[] mServices;
 private void startServicesIfNeeded(String[] services) {
     ......
     mServices = new SystemUI[services.length];
     ......
     final int N = services.length;
     for (int i = 0; i < N; i++) {
         String clsName = services[i];
         Class cls;
         try {
             cls = Class.forName(clsName);
             mServices[i] = (SystemUI) cls.newInstance();
         } catch (ClassNotFoundException ex) {
             throw new RuntimeException(ex);
         } catch (IllegalAccessException ex) {
             throw new RuntimeException(ex);
         } catch (InstantiationException ex) {
             throw new RuntimeException(ex);
         }
         ......
         mServices[i].mContext = this;
         mServices[i].mComponents = mComponents;
         ......
         mServices[i].start();
         ......
         if (mBootCompleted) {
             mServices[i].onBootCompleted();
         }
     }
 }

实际上就是通过反射的方式将前面的各个子服务类实例化，并执行这些对象中的start()方法，来启动这些服务。这样整个SystemUI就算启动了，上述逻辑还是比较简单的。

我们需要注意的是，这里使用了模板模式。SystemUI是一个基类，其中定义了4个抽象或空方法，作为模板指定了子类的行为模式。资源文件中定义的众多子服务类都是SystemUI的子类，既然都继承自SystemUI类，那么这些子类就有一些共同的行为模式，在某些阶段应该有什么表现，只是具体如何表现因不同子类而异。比如说，在上述代码中第24行和27行分别规定了SystemUI子类们在启动时要执行start()方法，系统启动后要执行onBootCompleted()方法，所以在这些子类中都重写了这两个方法，到一定的阶段都会以回调的方式执行，但是具体要在这些方法中干什么，子类们自己说了算。这就是典型的模板模式使用，至于具体介绍和使用模板模式，这里不展开讲，读者可以自行查资料，该模式在Android系统中使用还是很常见的，读者最好能好好掌握。

到这里为止，SystemUI的启动流程就介绍完了，这里归纳起来就是执行了如下几个阶段：

（1）系统启动就绪后，SystemServer进程下达启动SystemUIService的命令；

（2）SystemUI的SystemUiApplication中执行onCreate方法，注册系统启动广播和区域设置更改广播。

（3）SystemUI的SystemUIService中执行onCreate方法，启动公共用户的各项服务，各子服务执行onStart()回调方法。

（4）系统启动后，第二步注册的广播会接收到系统启动广播，然后各个子服务执行onBootCompleted()回调方法。

（5）在切换都个人用户时，再次加载因人而异的子服务功能。

七、SystemUI包含的功能模块

上一节中通过数组的形式列出了SystemUI的子服务类，这些类都分别表示什么功能呢？下面我简单介绍其中几项，读者可以根据名称来对号入座。至于更详细的介绍，有需要的话会专门写一篇文章来做介绍。

（1）Status bars（状态栏）

（2）Navigation bars（导航栏）

（3）Notification（通知）

（4）Keyguard（锁屏）

（5）Quick settings（快速设置）

（6）Recent task panel（最近任务面板）

（7）VolumeUI（音量UI）

（8）Screenshot（截屏）

（9）PowerUI（电量UI）

（10）RingtonePlayer（铃声播放器）

（11）StackDivider（分屏）

（12）PipUI（画中画UI）

（13）Biometrics（生物识别解锁功能，如指纹解锁、人脸解锁、虹膜解锁等）

结语

SystemUI的启动流程就介绍到这里，由于讲得还算比较详细，所以涉及的内容及细节不少，一定会有些描述不准确或者不妥的地方，如果发现，请读者不吝赐教。另外由于篇幅有限，有些地方还是仅提到或者简单介绍而已，比如FBE加密，模板模式，Lambda表达式等，在平时系统开发中都会经常碰到，读者都可以继续拓展深入学习。