这篇文章还是在于一位前辈的交流过程中汲取到的，之前也有看网上的关于SystemUI的内容，但是都没有从架构角度去琢磨SystemUI，我一位SystemUI小白就先在这里班门弄斧了，希望各位看官们抱着批评的态度去读文章，也希望能够把我认知的错误指点出来。

1. SystemUI的架构图

这里的这个架构图与以往的不同，我是从程序耦合关联的紧密程度的角度上去看SystemUI的。

可以通过StatusBarManagerService跨进程调用SystemUI里面的服务，其主要桥梁就是CommandQueue，关于CommandQueue.Callbcks的类图：

2. 对我的架构图的解释

2.1 为什么要将SystemUIService和SystemUIApplication放在一层？

我是这样考虑的，在AMS的onSystemReady中启动了SystemUIService，同时又调用了startServicesIfNeeded，但是SystemUIApplication中要启动的这些抽象服务，相对于SystemUIApplication这个类来讲，它是完全不知道有哪些服务的，因为这些服务是从string-array中获取的，然后通过反射来调用执行的。

也就是说，如果我要实现一个与Android原生的SystemUI完全不同的SystemUI，我只需要将这个string-array的内容修改掉，改成我们定制的SystemUI具有的一个抽象服务。比如我们的Android系统是给盲人用到，那么我们定制的SystemUI完全可以没有Keyguard（锁屏）、SystemBars（系统栏）…，我们的SystemUI完全可以只有一个语音服务（VoiceAssist），由接受音频信息作为输入，发出音频内容作为输出。

这一层的作用其实就是保证进程中只有一个SystemUIService。

2.2 抽象服务层

在架构图中我将SystemUI单独分出一个抽象服务层，是因为这些服务是由SystemUIApplication启动起来的，但是这些类又不是真正的服务，它们继承的是抽象类SystemUI，而SystemUI则是实现了一个接口SysUiServiceProvider，里面有两个方法，是参数不同的同名方法getComponent，这里看就有点类似于工厂模式了，因为getComponent获取的其实传入的Class参数对应的对象。

这一层则是提供了SystemUI关键功能，都是伴随着SystemUIService的启动而运行起来的，但是它们又具有各不相同的功能，对外就像是一个服务。

2.3 功能层

这一层很简单明了，就是对外提供SystemUI的一些实际功能。

1. 当按下了电源键和音量下键之后，就会通过层层调用，使用到处于SystemUI内部的TakeScreenShotService来实现一个截图功能；
2. 当插入sim卡之后，手机网络状态变化，StatusBarWindowView就会根据当前的网络状态来刷新当前状态栏上的一个现实效果；

当然还有很多功能，如音量调节Dialog的展示、下拉快捷开关、通知的展示、分屏、画中画等。

分出这一层是为了与抽象服务层做区分，因为我觉得有了抽象服务层提供的支持，这一层的功能才能够实现。