《深入理解Android 卷III》即将公布，作者是张大伟。此书填补了深入理解Android Framework卷中的一个主要空白，即Android Framework中和UI相关的部分。在一个特别讲究颜值的时代，本书分析了Android 4.2中WindowManagerService、ViewRoot、Input系统、StatusBar、Wallpaper等重要“颜值绘制/处理”模块

第7章 深入理解SystemUI（节选）

本章主要内容：

·  探讨状态栏与导航栏的启动过程

·  介绍状态栏中的通知信息、系统状态图标等信息的管理与显示原理

·  介绍导航栏中的虚拟按键、SearchPanel的工作原理

·  介绍SystemUIVisibility

本章涉及的源码文件名称及位置：

·  SystemServer.java

frameworks/base/services/java/com/android/server/SystemServer.java

·  SystemUIService.java

frameworks/base/packages/SystemUI/src/com/android/systemui/SystemUIService.java

·  PhoneWindowManager.java

frameworks/base/policy/src/com/android/internal/policy/impl/PhoneWindowManager.java

·  PhoneStatusBar.java

frameworks/base/packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java

·  BaseStatusBar.java

frameworks/base/packages/SystemUI/src/com/android/systemui/statusbar/BaseStatusBar.java

·  StatusBarManager.java

frameworks/base/core/java/android/app/StatusBarManager.java

·  StatusBarManagerService.java

frameworks/base/services/java/com/android/server/StatusBarManagerService.java

·  NotificationManager.java

frameworks/base/core/java/android/app/NotificationManager.java

·  NotificationManagerService.java

frameworks/base/services/java/com/android/server/NotificationManagerService.java

·  KeyButtonView.java

frameworks/base/packages/SystemUI/src/com/android/systemui/statusbar/policy/KeyButtonView.java

·  NavigationBarView.java

frameworks/base/packages/SystemUI/src/com/android/systemui/statusbar/phone/NavigationBarView.java

·  DelegateViewHelper.java

frameworks/base/packages/SystemUI/src/com/android/systemui/statusbar/DelegateViewHelper.java

·  SearchPanelView.java

frameworks/base/packages/SystemUI/src/com/android/systemui/SearchPanelView.java

·  PhoneWindow.java

frameworks/base/policy/src/com/android/internal/policy/impl/PhoneWindow.java

·  InputMethodService.java

frameworks/base/core/java/android/inputmethodservice/InputMethodService.java

·  View.java

frameworks/base/core/java/android/view/View.java

·  ViewRootImpl.java

frameworks/base/core/java/android/view/ViewRootImpl.java

·  WindowManagerService.java

frameworks/base/services/java/com/android/server/wm/WindowManagerService.java

7.1初识SystemUI

顾名思义，SystemUI是为用户提供系统级别的信息显示与交互的一套UI组件，因此它所实现的功能包罗万象。

屏幕顶端的状态栏、底部的导航栏、图片壁纸以及RecentPanel（最近使用的APP列表）都属于SystemUI的范畴。SystemUI中另一个名为TakeScreenshotService的服务。用于在用户按下音量下键与电源键时进行截屏操作。在第5章曾介绍了PhoneWindowManager监听这一组合键的机制，当它捕捉到这一组合键时便会向TakeScreenShotService发送请求从而完毕截屏操作。SystemUI还提供了PowerUI和RingtonePlayer两个服务。前者负责监控系统的剩余电量并在必要时为用户显示低电警告，后者则依托AudioService为向其它应用程序提供播放铃声的功能。

SystemUI的博大不止如此，读者能够通过查看其AndroidManifest.xml来了解它所实现的其它功能。本章将着重介绍当中最重要的两个功能的实现：状态栏和导航栏。

7.1.1 SystemUIService的启动

虽然SystemUI的表现形式与普通的Android应用程序大相径庭，但它却是以一个APK的形式存在于系统之中，即它与普通的Android应用程序并没有本质上的差别。无非是通过Android四大组件中的Activity、Service、BroadcastReceiver接受外界的请求并执行相关的操作，仅仅只是它们所接受到的请求主要来自各个系统服务而已。

SystemUI包罗万象，而且大部分功能之间相互独立。比方RecentPanel、TakeScreenshotService等均是按需启动。并在完毕其既定任务后退出，这与普通的Activity以及Service别无二致。比較特殊的是状态栏、导航栏等组件的启动方式。它们执行于一个称之为SystemUIService的一个Service之中。

因此讨论状态栏与导航栏的启动过程事实上就是SystemUIService的启动过程。

1．SystemUIService的启动时机

那么SystemUIService在何时由谁启动的呢？作为一个系统级别的UI组件，自然要在系统的启动过程中来寻找答案了。

在负责启动各种系统服务的ServerThread中，当核心系统服务启动完毕后ServerThread会通过调用ActivityManagerService.systemReady()方法通知AMS系统已经就绪。这个systemReady()拥有一个名为goingCallback的Runnable实例作为參数。顾名思义，当AMS完毕对systemReady()的处理后将会回调这一Runnable的run()方法。而在这一run()方法中能够找到SystemUI的身影：

[SystemServer.java-->ServerThread]

进一步地，在startSystemUI()方法中：

[SystemServer.java-->ServerThread.startSystemUi()]

可见。当核心的系统服务启动完毕后，ServerThread通过Context.startServiceAsUser()方法完毕了SystemUIService的启动。

2．SystemUIService的创建

參考SystemUIService的onCreate()的实现：

[SystemUIService.java-->SystemUIService.onCreate()]

除了onCreate()方法之外，SystemUIService没有其它有意义的代码了。显而易见。SystemUIService是一个容器。在其启动时，将会逐个实例化定义在SERVICIES列表中的继承自SystemUI抽象类的子服务。在调用了子服务的start()方法之后，SystemUIService便不再做不论什么其它的事情。任由各个子服务自行执行。而状态栏导航栏则是这些子服务中的一个。

值得注意的是，onCreate()方法依据IWindowManager.hasSystemNavBar()方法的返回值为状态栏/导航栏选择了不同的实现。

进行这一选择的原因为了能够在大尺寸的设备中更有效地利用屏幕空间。

在小屏幕设备如手机中，因为屏幕宽度有限，Android採取了状态栏与导航栏分离的布局方案，也就是说导航栏与状态栏占用了很多其它的垂直空间。使得导航栏的虚拟按键尺寸足够大以及状态栏的信息量足够多。

而在大屏幕设备如平板电脑中。因为屏幕宽度比較大，足以在一个屏幕宽度中同一时候显示足够大的虚拟按键以及足够多的状态栏信息量。此时能够选择将状态栏与导航栏功能集成在一起成为系统栏作为大屏幕下的布局方案。以节省对垂直空间的占用。

hasSystemNavBar()的返回值取决于PhoneWindowManager.mHasSystemNavBar成员的取值。因此在PhoneWindowManager.setInitialDisplaySize()方法中能够得知Android在两种布局方案中进行选择的策略。

[PhoneWindowManager.java-->PhoneWindowManager.setInitialDisplaySize()]

在SystemUI中，分离布局方案的实现者是PhoneStatusBar，而集成布局方案的实现者则是TabletStatusBar。

二者的本质功能是一致的，即提供虚拟按键、显示通知信息等，差别仅在于布局的不同、以及由此所衍生出的定制行为而已。

因此不难想到，它们是从同一个父类中继承出来的。

这一父类的名字是BaseStatusBar。

本章将主要介绍PhoneStatusBar的实现，读者能够类比地对TabletStatusBar进行研究。

7.1.2 状态栏与导航栏的创建

如7.1.1节所述，状态栏与导航栏的启动由其PhoneStatusBar.start()完毕。參考事实上现：

[PhoneStatusBar.java-->PhoneStatusBar.start()]

參考BaseStatusBar.start()的实现。这段代码比較长。而且涉及到了本章随后会具体介绍的内容。

因此倘若读者阅读起来比較吃力能够仅关注那三个关键步骤。

在完毕本章的学习之后再回过头来阅读这部分代码便会发现十分简单了。

[BaseStatusBar-->BaseStatusBar.start()]

可见。状态栏与导航栏的启动分为例如以下几个过程：

·  获取IStatusBarService，IStatusBarService是执行于system_server的一个系统服务。它接受操作状态栏/导航栏的请求并将其转发给BaseStatusBar。为了保证SystemUI意外退出后不会发生信息丢失。IStatusBarService保存了全部须要状态栏与导航栏进行显示或处理的信息副本。

·  将一个继承自IStatusBar.Stub的CommandQueue的实例注冊到IStatusBarService以建立通信，并将信息副本取回。

·  通过调用子类的createAndAddWindows()方法完毕状态栏与导航栏的控件树及窗体的创建与显示。

·  使用从IStatusBarService取回的信息副本。

7.1.3 理解IStatusBarService

那么IStatusBarService的真身怎样呢？它的实现者是StatusBarManagerService。因为状态栏导航栏与它的关系十分密切，因此须要对其有所了解。

与WindowManagerService、InputManagerService等系统服务一样，StatusBarManagerService在ServerThread中创建。參考例如以下代码：

[SystemServer.java-->ServerThread.run()]

再看其构造函数：

[StatusBarManagerService.java-->StatusBarManagerService.StatusBarManagerService()]

这基本上是系统服务中最简单的构造函数了，在这里并没有发现能够揭示StatusBarManagerService的工作原理的线索（由此也能够预见StatusBarManagerService的实现十分简单）。

接下来參考StatusBarManagerService.registerStatusBar()的实现。这种方法由SystemUI中的BaseStatusBar调用。用于建立其与StatusBarManagerService的通信连接。并取回保存在当中的信息副本。

[StatusBarManagerService.java-->StatusBarManagerService.registerStatusBar()]

可见StatusBarManagerService.registerStatusBar()的实现也十分简单。主要是保存BaseStatusBar中的CommandQueue的Bp端到mBar成员之中。然后再把信息副本填充到參数里去。

虽然简单，可是从事实上现中能够预料到StatusBarManagerService的工作方式：当它接受到操作状态栏与导航栏的请求时。首先将请求信息保存到副本之中。然后再将这一请求通过mBar发送给BaseStatusBar。以设置系统状态区图标这一操作为例，參考例如以下代码：

[StatusBarManagerService.java-->StatusBarManagerService.setIcon()]

纵观StatusBarManagerService中的其它方法，会发现它们与setIcon()方法的实现十分相似。从而能够得知StatusBarManagerService的作用与工作原理例如以下：

·  它是SystemUI中的状态栏与导航栏在system_server中的代理。全部对状态栏或导航来有需求的对象都能够通过获取StatusBarManagerService的实例或Bp端达到其目的。仅仅只是使用者必须拥有能够完毕操作的相应权限。

·  它保存了状态栏／导航栏所需的信息副本，用于在SystemUI意外退出之后的恢复。

7.1.4 SystemUI的体系结构

完毕了对SystemUI的启动过程的分析之后便能够对其体系结构做出总结，如图7-1所看到的。

·  SystemUIService，一个普通的Android服务，它以一个容器的角色执行于SystemUI进程中。在它内部执行着多个子服务，当中之中的一个便是状态栏与导航栏的实现者——BaseStatusBar的子类之中的一个。

·  IStatusBarService，即系统服务StatusBarManagerService是状态栏导航栏向外界提供服务的前端接口，执行于system_server进程中。

·  BaseStatusBar及其子类是状态栏与导航栏的实际实现者，执行于SystemUIService中。

·  IStatusBar，即SystemUI中的CommandQueue是联系StatusBarManagerService与BaseStatusBar的桥梁。

·  SystemUI中还包括了ImageWallpaper、RecentPanel以及TakeScreenshotService等功能的实现。它们是Service、Activity等标准的Android应用程序组件，而且互相独立。对这些功能感兴趣的使用者能够通过startService()/startActivity()等方式方便地启动相应的功能。

图 7 - 1 SystemUI的体系结构

在本章将主要介绍SystemUI中最经常使用的状态栏、导航栏以及RecentPanel的实现。ImageWallpaper将在第8章中进行具体地介绍。而SystemUI其它的功能读者能够自行研究。

7.2 深入理解状态栏

如7.1.1节所述。SystemUI中存在两种状态栏与导航栏的实现——即状态栏与导航栏分离的布局的PhoneStatusBar以及状态栏与导航栏集成布局的TabletStatusBar两种。除了布局差异之外。二者并无本质上的差别，因此本节将主要介绍PhoneStatusBar下的状态栏的实现。

作为一个将全部信息集中显示的场所。状态栏对须要显示的信息做了下面的五个分类。

·  通知信息：它能够在状态栏左側显示一个图标以引起用户的主意，并在下拉卷帘中为用户显示更加具体的信息。这是状态栏所能提供的信息显示服务之中最灵活的一种功能。它对信息种类以及来源没有做不论什么限制。使用者能够通过StatusBarManagerService所提供的接口向状态栏中加入或移除一条通知信息。

·  时间信息：显示在状态栏最右側的一个小型数字时钟，是一个名为Clock的继承自TextView的控件。

它监听了几个和时间相关的广播：ACTION_TIME_TICK、ACTION_TIME_CHANGED、ACTION_TIMEZONE_CHANGED以及ACTION_CONFIGURATION_CHANGED。当当中一个广播到来时从Calendar类中获取当前的系统时间。然后进行字符串格式化后显示出来。时间信息的维护工作在状态栏内部完毕。因此外界无法通过API改动时间信息的显示或行为。

·  电量信息：显示在数字时钟左側的一个电池图标，用于提示设备当前的电量情况。

它是一个被BatteryController类所管理的ImageView。

BatteryController通过监听android.intent.action.BATTERY_CHANGED广播以从BetteryService中获取电量信息。并依据电量信息选择一个合适的电池图标显示在ImageView上。

同一时候间信息一样，这也是在状态栏内部维护的。外界无法干预状态栏对电量信息的显示行为。

·  信号信息：显示在电量信息的左側的一系列ImageView。用于显示系统当前的Wifi、移动网络的信号状态。用户所看到的Wifi图标、手机信号图标、飞行模式图标都属于信号信息的范畴。它们被NetworkController类维护着。NetworkController监听了一系列与信号相关的广播如WIFI_STATE_CHANGED_ACTION、ACTION_SIM_STATE_CHANGED、ACTION_AIRPLANE_MODE_CHANGED等，并在这些广播到来时显示、更改或移除相关的ImageView。同样，外界无法干预状态栏对信号信息的显示行为。

·  系统状态图标区：这个区域用一系列图标标识系统当前的状态。位于信号信息的左側。与状态栏左側通知信息隔岸相望。通知信息相似。StatusBarManagerService通过setIcon()接口为外界提供了改动系统状态图标区的图标的途径。而然它对信息的内容有非常强的限制。

首先，系统状态图标区无法显示图标以外的信息。另外。系统状态图标区的对其所显示的图标数量以及图标所表示的意图有着严格的限制。

因为时间信息、电量信息以及信号信息的实现原理比較简单而且与状态栏外界相对隔离。因此读者能够通过分析上文所介绍的相关组件自行研究。本节将主要介绍状态栏的一下几个方面的内容：

·  状态栏窗体的创建与控件树结构。

·  通知的管理与显示。

·  系统状态图标区的管理与显示。

7.2.1 状态栏窗体的创建与控件树结构

1. 状态栏窗体的创建

在7.1.2节所引用的BaseStatusBar.start()方法的代码中调用了createAndAddWindows()方法进行状态栏窗体的创建。非常显然，createAndAddWindow()由PhoneStatusBar或TabletStatusBar实现。

以PhoneStatusBar为例，參考其代码：

[PhoneStatusBar.java-->PhoneStatusBar.createAndAddWindow()]

在addStatusBarWindow()方法中。PhoneStatusBar将会构建状态栏的控件树并通过WindowManager的接口为其创建窗体。

[PhoneStatusBar.java-->PhoneStatusBar.addStatusBarWindow()]

此方法提供了非常多重要的信息。

首先是状态栏的高度，由getStatusBarHeight()从资源com.android.internal.R.dimen.status_bar_height中获得。这一资源定义在frameworks\base\core\res\res\values\dimens.xml中。默觉得25dip。

此资源同样在PhoneWindowManager中被用来计算作为布局准绳的八个矩形。

然后是状态栏窗体的LayoutParams的创建。LayoutParams描写叙述了状态栏是怎样的一个窗体。TYPE_STATUS_BAR使得PhoneWindowManager为状态栏的窗体分配了较大的layer值。使其能够显示在其它应用窗体之上。

FLAG_NOT_FOCUSABLE、FLAG_TOUCHABLE_WHEN_WAKING和FLAG_SPLIT_TOUCH则定义了状态栏对输入事件的响应行为。

在makeStatusBarView()完毕控件树的创建之后，WindowManager.addView()将依据控件树创建出状态栏的窗体。显而易见，状态栏控件树的根控件被保存在mStatusBarWindow成员中。

createStatusBarView()负责从R.layout.super_status_bar所描写叙述的布局中实例化出一棵控件树。并从这个控件树中取出一些比較重要的控件并保存在相应的成员变量中。

因此从R.layout.super_status_bar入手能够非常easy地得知状态栏的控件树的结构：

2.状态栏控件树的结构

參考SystemUI下super_status_bar.xml所描写叙述的布局内容，能够看到其根控件是一个名为StatusBarWindowView的控件。它继承自FrameLayout。在其下的两个直接子控件例如以下：

·  @layout/status_bar所描写叙述的布局。

这是用户平时所见的状态栏。

·  PenelHolder：这个继承自FrameLayout的控件是状态栏的卷帘。在其下的两个直接子控件@layout/status_bar_expanded以及@layout/quick_settings分别相应于卷帘之中的通知列表面板以及高速设定面板。

在正常情况下，StatusBarWindowView中仅仅有@layout/status_bar所描写叙述的布局是可见的，而且状态栏窗体为com.android.internal.R.dimen.status_bar_height所定义的高度。当StatusBarWindowView截获了ACTION_DOWN的触摸事件后。会改动窗体的高度为MATCH_PARENT，然后将PenelHolder设为可见并尾随用户的触摸轨迹，由此实现了卷帘的下拉效果。

因此状态栏控件树的第一层结构如图7-2所看到的。

图 7 - 2状态栏控件树的结构1

再看status_bar.xml所描写叙述的布局内容。其根控件是一个继承自FrameLayout的名为StatusBarView类型的控件，makeStatusBarView()方法会将其保存为mStatusBarView。其直接子控件有三个：

·  @id/notification_lights_out，一个ImageView，而且普通情况下它是不可见的。

在SystemUIVisiblity中有一个名为SYSTEM_UI_FLAG_LOW_PROFILE的标记。当一个应用程序希望让用户的注意力很多其它地集中在它所显示的内容时，能够在其SystemUIVisibility中加入这一标记。SYSTEM_UI_FLAG_LOW_PROFILE会使得状态栏与导航栏进入低辨识度模式。低辨识度模式下的状态栏将不会显示不论什么信息。仅仅是在黑色背景中显示一个灰色圆点而已。而这一个黑色圆点即是这里的id/notification_lights_out。

·  @id/status_bar_contents，一个LinearLayout。状态栏上各种信息的显示场所。

·  @id/ticker，一个LinearLayout，当中包括了一个ImageSwitcher和一个TickerView。

在正常情况下@id/ticker是不可见的。

当一个新的通知到来时（比如一条新的短信），状态栏上会以动画方式逐行显示通知的内容，使得用户能够在无需下拉卷帘的情况下了解新通知的内容。这一功能在状态栏中被称之为Ticker。

而@id/ticker则是完毕Ticker功能的场所。makeStatusBarView()会将@id/ticker保存为mTickerView。

至此，状态栏控件树的结构能够扩充为图7-3所看到的。

图 7 - 3状态栏控件树的结构2

再来分析@id/status_bar_contents所包括的内容。如前文所述，状态栏所显示的信息共同拥有5种。因此@id/status_bar_contents中的子控件分别用来显示这5种信息。

当中通知信息显示在@id/notification_icon_area里。而其它四种信息则显示在@id/system_icon_area之中。

·  @id/notification_icon_area，一个LinearLayout。包括了两个子控件各自是类型为StatusBarIconView的@id/moreIcon以及一个类型为IconMerger的@id/notificationIcons。IconMerger继承自LinearLayout。通知信息的图标都会以一个StatusBarIconView的形式存储在IconMerger之中。而IconMeger和LinearLayout的差别在于，假设它在onLayout()的过程中发现会其内部所容纳的StatusBarIconView的总宽度超过了它自身的宽度，则会设置@id/moreIcon为可见。使得用户得知有部分通知图标因为显示空间不够而被隐藏。

makeStausBarView()会将@id/notificationIcons保存为成员变量mNotificationIcons。因此当新的通知到来时，仅仅要将一个StatusBarIconView放置到mNotificationIcons就可以显示此通知的图标了。

·  @id/system_icon_area，也是一个LinearLayout。它容纳了除通知信息的图标以外的四种信息的显示。在当中有负责显示时间信息的@id/clock，负责显示电量信息的@id/battery，负责信号信息显示的@id/signal_cluster以及负责容纳系统状态区图标的一个LinearLayout——@id/statusIcons。当中@id/statusIcons会被保存到成员变量mStatusIcons中。当须要显示某一个系统状态图标时，将图标放置到mStatusIcons中就可以。

于是能够将图7-3扩展为图7-4。

图 7 - 4状态栏控件树的结构3

另外，在@layout/status_bar_expanded之中有一个类型为NotificationRowLayout的控件@id/latestItems，而且会被makeStatusBarView()保存到mPile成员变量中。它位于下拉卷帘中，是通知信息列表的容器。

在分析控件树结构的过程中发现了例如以下几个重要的控件：

·  mStatusBarWindow。整个状态栏的根控件。它包括了两棵子控件树。各自是常态下的状态栏以及下拉卷帘。

·  mStatusBarView，常态下的状态栏。它所包括的三棵子控件树分别相应了状态栏的三种工作状态——低辨识度模式、Ticker以及常态。这三棵控件树会随着这三种工作状态的切换交替显示。

·  mNotificationIcons。继承自LinearLayout的IconMerger控件的实例，负责容纳通知图标。

当mNotificationIcons的宽度不足以容纳全部通知图标时，会将@id/moreIcon设置为可见以告知用户存在未显示的通知图标。

·  mTickerView。实现了当新通知到来时的动画效果。使得用户能够在无需下拉卷帘的情况下了解新通知的内容。

·  mStatusIcons，一个LinearLayout，它是系统状态图标区。负责容纳系统状态图标。

·  mPile，一个NotificationRowLayout。它作为通知列表的容器被保存在下拉卷帘中。因此当一个通知信息除了须要将其图标加入到mNotificationIcons以外，还须要将其具体信息（标题、描写叙述等）加入到mPile中，使得用户在下来卷帘中能够看到它。

对状态栏控件树的结构分析至此便告一段落了。接下来将从通知信息以及系统状态图标两个方面介绍状态栏的工作原理。希望读者能够理解本节所介绍的几个重要控件所在的位置以及其基本功能，这将使得兴许内容的学习更加轻松。

7.2.2 通知信息的管理与显示

通知信息是状态栏中最经常使用的功能之中的一个。依据用户是否拉下下拉卷帘，通知信息表现为一个位于状态栏的图标，或在下拉卷帘中的一个条目。

另外，通知信息还能够在其加入入状态栏之时发出声音，以提醒用户注意查看。

通知信息即能够表示一条事件，如新的短消息到来、出现了一条未接来电等，也能够用来表示一个正在后台持续进行着的工作，如正在下载某一文件、正在播放音乐等。

1.通知信息的发送

不论什么使用者都能够通过NotificationManager所提供的接口向状态栏加入一则通知信息。通知信息的具体内容能够通过一个Notification类的实例来描写叙述。

Notification类中包括例如以下几个用于描写叙述通知信息的keyword段。

·  icon，一个用于描写叙述一个图标的资源id，用于显示在状态栏之上。

每条通知信息必须提供一个有效的图标资源，否则此信息将会被忽略。

·  iconLevel，假设icon所描写叙述的图标资源存在level，那么iconLevel则用于告知状态栏将显示图标资源的那一个level。

·  number，一个int型变量用于表示通知数目。比如，当有３条新的短信时。没有必要使用三个通知，而是将一个通知的number成员设置为３。状态栏会将这一数字显示在通知图标上。

·  contentIntent。一个PendingIntent的实例。用于告知状态栏当在下拉卷帘中点击本条通知时应当执行的动作。contentIntent往往用于启动一个Activity以便让用户能够查看关于此条通知的具体信息。比如。当用户点击一条提示新短信的通知时，短信应用将会被启动并显示短信的具体内容。

·  deleteIntent，一个PendingIntent的实例。用于告知状态栏当用户从下拉卷帘中删除本条通知时应当执行的动作。

deleteIntent往往用在表示某个工作正在后台进行的通知中，以便当用户从下拉卷帘中删除通知时，发送者能够终止此后台工作。

·  tickerText。一条文本。当通知信息被加入时，状态栏将会在其上逐行显示这条信息。

其目的在于使用户无需进行卷帘下拉操作就可以从高速获取通知的内容。

·  fullScreenIntent。一个PendingIntent的实例，用于告知状态栏当此条信息被加入时应当执行的动作，一般这一动作是启动一个Activity用于显示与通知相关的具体信息。

fullScreenIntent事实上是一个替代tickerText的设置。当Notification中指定了fullScreenIntent时，StatusBar将会忽略tickerText的设置。因为这两个设置的目的都是为了让用户能够在第一时间了解通知的内容。只是相对于tickerText，fullScreenIntent强制性要明显得多。因为它将打断用户当前正在进行的工作。因此fullScreenIntent应该仅用于通知非常重要或紧急的事件。比方说来电或闹钟。

·  contentView/bigContentView，RemoteView的实例，能够用来定制通知信息在下拉卷帘中的显示形式。

一般来讲，相对于contentView，bigContentView能够占用很多其它空间以显示更加具体的内容。状态栏将依据自己的判断选择将通知信息显示为contentView或是bigContentView。

·  sound与audioStreamType，指定一个用于播放通知声音的Uri及其所使用的音频流类型。在默认情况下，播放通知声音所用的音频流类型为STREAM_NOTIFICATION。

·  vibrate，一个float数组。用于描写叙述震动方式。

·  ledARGB/ledOnMS/ledOffMS，指定当此通知被加入到状态栏时设备上的LED指示灯的行为，这几个设置须要硬件设备的支持。

·  defaults，用于指示声音、震动以及LED指示灯是否使用系统的默认行为。

·  flags，用于存储一系列用于定制通知信息行为的标记。

通知信息的发送者能够依据需求在当中加入这种标记：FLAG_SHOW_LIGHTS要求使用LED指示灯。FLAG_ONGOING_EVENT指示通知信息用于描写叙述一个正在进行的后台工作，FLAG_INSISTENT指示通知声音将持续播放直到通知信息被移除或被用户查看，FLAG_ONLY_ARLERT_ONCE指示不论什么时候通知信息被加入到状态栏时都会播放一次通知声音，FLAG_AUTO_CANCEL指示当用户在下拉卷帘中点击通知信息时自己主动将其移出。FLAG_FOREGROUND_SERVICE指示此通知用来表示一个正在以foreground形式执行的服务。

·  priority，描写叙述了通知的重要性级别。通知信息的级别从低到高共分为MIN(-2)、LOW(-1)、DEFAULT(0)以及HIGH(1)四级。

低优先级的通知信息有可能不会被显示给用户。或显示在通知列表中靠下的位置。

在随后的讨论中将会具体介绍这些信息怎样影响通知信息的显示与行为。

当通知信息的发送者依据需求完毕了Notification实例的创建之后。便能够通过NotificationManager.notify()方法将通知显示在状态栏上。

notify()方法要求通知信息的发送者除了提供一个Notification实例之外，还须要提供一个字符串类型的參数tag，以及int类型的參数id，这两个參数一并确定了信息的意图。

当一条通知信息已经被提交给NotificationManager.notify()而且仍然显示在状态栏中时，它将会被新提交的拥有同样意图（即同样的tag以及同样的id）通知信息所替换。

參考NotificationManager.notify()方法的实现：

[NotificationManager.java-->NotificationManager.notify()]

NotificationManager会将通知信息发送给NotificationManagerService，并由NotificationManagerService对信息进行进一步处理。注意Notification将通知发送者的包名作为參数传递给了NotificationManagerService。对于一个应用程序来说。tag与id而这一起确定了通知的意图。因为NotificationManagerService作为一个系统服务须要接受来自各个应用程序通知信息。因此对NotificationManagerService来说。确定通知的意图须要在tag与id之外再添加一项：通知发送者的包名。因此因为包名的不一样，来自两个应用程序的具有同样tag与id的通知信息之间不会发生不论什么冲突。

另外将包名作为通知意图的元素之中的一个的原因出于对信息安全考虑。

而将一则通知信息从状态栏中移除则简单得多了，NotificationManager.cancel()方法能够提供这一操作，它接受tag、id作为參数用于指明希望移除的通知所具有的意图。