Android系统应用---SystemUI之一：SystemUI概述和创建启动流程分析

SystemUI概述

自android2.2开始,原本存在与framework-res.apk中的状态栏和下拉通知栏界面控制被分割出一个单独的apk文件,命名为SystemUI.apk,保存在System/priv-app/SystemUI/文件夹中。在SystemUI.apk中,存在着状态栏的图标,XML和控制文件等,这样的划分,使我们可以更方便地去修改UI的显示，也就说在目前的Android代码中，它与普通的应用程序并没有本质上的区别，都是通过四大组件来接受外界的请求并执行相关的操作，不过它所接受的请求主要来自各个系统服务，我们可以用分析标准应用程序的方法分析SystemUI，以AndroidManifest文件和layout布局文件入手进行深入分析。
SystemUI即系统的UI，是为用户提供系统级别的信息显示与交互的一套UI组件，所实现的功能包罗万象。屏幕顶端的状态栏、底部的导航栏、图片壁纸以及RecentPanel（最近使用的APP列表）都属于SystemUI的范围。SystemUI中还包含 TakeScreenshotService， PowerUI和 RingtonePlayer等服务，分别负责截屏，电池监控，铃声播放等功能。
我们从代码结构和AndroidManifest.xml文件开始分析来看，SystemUI涉及到的功能模块有：
●System bar(StatusBar && NavigationBar && CombinedBar)
●Notifications
●RecentPanal
●ScreenShot
●QuickSetting
●Power
●USB
●Volume
如下图:



SystemUI大部分功能之间相互独立，比如RecentPanel、TakeScreenshotService等均是按需启动，并在完成其既定任务后退出，这与普通的Activity以及Service没有区别。比较特殊的是状态栏、导航栏等组件的启动方式,它们运行于 SystemUIService。
SystemUI有如下特性，这样的特性也决定了它的实现方式
●有UI界面，在launcher之前启动，无法在manifest中没有注册从launcher启动，所以所有的程序启动都是外部启动的。
●常驻内存，随时可以做出响应

状态栏启动流程分析

以状态栏为例说明SystemUI的运行方式
相关代码分为两个部分：
Service部分： /frameworks/base/services/java/com/android/server/
应用部分：/frameworks/base/packages/SystemUI/
具体过程如下：
（1）状态栏需要显示UI，添加窗口到WindowManager，需要实时反馈系统状态，那么它就会长存系统中，通过service控制，状态栏就是一个长存系统进程空间运行的Service，它是一个系统服务。
（2）SystemServer中，当核心系统服务启动完成后会调用mActivityManagerService.systemReady()方法通知AMS系统已经准备就绪，可以启动其它的Service了，SystemUIService就是在此时启动

static
final void startSystemUi(Context context) {
Intent intent = new Intent();
intent.setComponent(newComponentName("com.android.systemui",
"com.android.systemui.SystemUIService"));
//Slog.d(TAG, "Starting service: " +intent);
context.startServiceAsUser(intent, UserHandle.OWNER);
}

(3)在SystemUIService中，实例化它的子服务，并调用mServices[i].start();启动这些服务
每一个子服务都继承自SystemUI这个抽象类，并重载其中的start方法，这样就实现了一种灵活的编程方式，便于系统的扩展或重构.

private
final Class<?>[]SERVICES =new
Class[]{
com.android.systemui.recent.Recents.class,
com.android.systemui.statusbar.SystemBars.class,
com.android.systemui.usb.StorageNotification.class,
com.android.systemui.power.PowerUI.class,
com.android.systemui.media.RingtonePlayer.class,
com.android.systemui.settings.SettingsUI.class,
};

SystemUIService是一个容器,在SystemUIService启动时，将会逐个实例化定义在SERVICIES列表中的继承自SystemUI抽象类的子服务。在调用 了子服务的start()方法之后，SystemUIService便不再做任何其他的事情，都交给子服务自己运行。

(4)接下来就会启动SystemBars.java这个包含了状态栏和导航栏的子服务
在SystemBars的createStatusBarFromConfig()方法中会从res/value/config.xml 中读取它要启动的
SystemBar 类型,TV /tablet Bar/Phone Bar。我们手机系统的 Config.xml中的内容是:

<!-- Component to be used as the status barservice. Must implement the IStatusBar
interface. This name is in theComponentName flattened format (package/class) -->
<stringname="config_statusBarComponent"translatable="false">com.android.systemui.statusbar.phone.PhoneStatusBar</string>

这样做的目的是根据不同的配置显示不同类型的SystemBar，节省屏幕空间，显示达到最优化

（5）SystemBars 类读出配置的类名后会调用它的 start()方法,来启动PhoneStatusBar。PhoneStatusBar 的Start()方法又调用了父类 BaseStatusBar 的start()方法,二者协同完成了以下的工作
①获取 WindowManager，需要自己管理窗口，状态栏窗口不属于任何一个Activity，所以需要WindowManager进行窗口的创建
mWindowManager=
(WindowManager)mContext.getSystemService(Context.WINDOW_SERVICE);
状态栏的存在对窗口的布局有重要的影响，所以需要将状态栏的变化通知给WMS
mWindowManagerService=WindowManagerGlobal.getWindowManagerService();
②创建PhoneStatusBarPolicy系统图标和通知图标的设置策略
mIconPolicy =
newPhoneStatusBarPolicy();
③创建导航栏窗口
addNavigationBar();
④获取IStatusBatService实例
mBarService=IStatusBarService.Stub.asInterface(ServiceManager.getService(Context.STATUS_BAR_SERVICE));
随后BaseStatusBar将自己注册到IStatusBarService，以此声明本实例才是状态栏的真正实现者，IStatusBatService会将其接受到的请求转发给BaseStatusBar
IStatusBarService是一个系统服务，由ServerThread启动并常驻system_server进程。IStatusBarService为那些对状态栏感兴趣的的其他系统服务定义了一系列的API。状态栏中的状态并不属于SystemUI自己，SystemUI意外终止时，需要有一个系统服务去记录，备份，保存和恢复这样的副本，从状态栏注册的过程就能体现状态栏所能显示的信息的类型。
mBarService.registerStatusBar(mCommandQueue,iconList,switches,binders);
⑤调用了 抽象方法createAndAddWindows()由子 类 PhoneStatusBar 实 现
最 后 createAndAddWindows()调用了addStatusBarWindow()和makeStatusBarView()并加载了状态栏的布局，完成状态栏的绘制和显示
mStatusBarView=
(PhoneStatusBarView)mStatusBarWindow.findViewById(R.id.status_bar);

具体的时序图：