Android11 Notification功能解析

       我们知道，当手机有通知时，下拉通知中心中会显示所有的通知，该功能是在SystemUI中实现的，接着上篇文章 Android11 SystemUI解析 ，本文对通知相关的功能逻辑进行分析，基于Android11 CarSystemUI的通知功能逻辑展开分析。

       关于通知功能逻辑，简单来说，无非就是四步，注册、发送、接收、显示，那么接下来针对以上四步进行源码详细分析。

       关于CarSystemUI启动及相关逻辑可以参考文章 Android11 SystemUI解析 ，本文就不赘述了，直接以NotificationPanelViewController类为入口进行分析：

       从构造方法来看：

       可以看到，在创建以上实例时，会通过Inject的方式来创造对应参数的实例，该功让隐能是通过dagger2来实现，具体对应的Module为CarNotificationModule类，看一下CarNotificationListener实例创造时的实现，关于NotificationViewController后面再分析：

       可以看到，在provideCarNotificationListener()提供CarNotificationListener实例时，还执行了registerAsSystemService()方法，接下来看一下CarNotificationListener类：

       CarNotificationListener继承了NotificationListenerService类，该类继承了Service，是framework内部的组成部分，通过registerAsSystemService()来看一下该类的实现：

       该方法内部主要执行了两项 *** 作：

       a.创建了NotificationListenerWrapper对象，该类继承了INotificationListener.Stub，主要用来接收回调，后面在显示环节进行详细分析；

       b.将以上对象作为参数通过INotificationManager的registerListener进行注册；

       通过getNotificationInterface()的是实现可以知道，registerListener()执行到了NotificationManagerService里面去了，接下来一起看一下：

       mListeners是NotificationListeners实例，是在init()中好颤进行初始化的，NotificationListeners是其内部类，看一下具体实现：

       NotificationListeners继承了ManagedServices，registerSystemService方法是在ManagedServices里面实现的，看一下：

       根据调用关系，registerServiceImpl()方法内友滑败先将前面创建的INotificationListener(mWrapper)作为参数创建了ManagedServiceInfo实例info，然后执行linkToDeath进行死亡监测，最后将info加入mServices中进行管理，执行完后再执行onServiceAdded(info)，该方法是在NotificationListeners类内部实现的，再回去看一下该方法，最终会调用到CarNotificationListener.java里面的onListenerConnected()方法。

       以上注册过程逻辑比较绕，用一张图来总结一下：

       发送过程比较简单，按照系统提供的方法来发送即可，主要涉及NotificationChannel、Notification、NotificationManager这三个类，简单看一下：

       首先某个应用在发送通知前需要创建该应用对应的NotificationChannel，然后在通知中传入对应channel ID就可以了，创建如下：

       在创建NotificationChannel时需要传入唯一的id、name和importance，创建如下：

       创建完NotificationChannel后，再创建Notification，Notification创建采用的是Builder模式，主要涉及的内容比较多，创建如下：

       Notification涉及的内容比较多，可以根据需要进行设定；

       创建完Notification后，通过NotificationManger来进行发送就可以了：

       执行完notify后续的逻辑处理过程，在接收环节进行分析；

       发送时会调用到notify()方法：

       跟随调用关系，会调用到notifyAsUser()方法：

       在notifyAsUser()会调用到NotificationManagerService中的enqueueNotificationWithTag()方法，先看一下fixNotification()方法：

       需要注意一下：当应用targetSdkVersion大于22时，在创建Notification时需要传入smallIcon，否则会抛异常导致发送不成功；接下来看一下enqueueNotificationWithTag()方法：

       NotificationManagerService继承了SystemService，在SystemServer中会进行启动，在start()方法内部会执行publishBinderService来进行Binder注册提供服务：

       可以看到，enqueueNotificationWithTag()会调用到enqueueNotificationInternal()，该方法是真正的逻辑实现：

       该方法中主要做了以下几件事：

       1.进行各种check来确保notification的合法性；

       2.将Notification作为参数创建StatusBarNotification；

       3.获取Notification对应的channel id，根据channel id 来获取应用对应的NotificationChannel，如果为空的话，就直接返回了，因此应用在发送notification前需要先创建对应NotificationChannel；

       4.通过Handler post EnqueueNotificationRunnable来执行后续逻辑；

       在EnqueueNotificationRunnable内部会将r(NotificationRecord)加入mEnqueuedNotifications进行管理，然后判断该NotificationRecord是否已经存在过，最后执行PostNotificationRunnable；

       PostNotificationRunnable的run()中主要处理逻辑如下：

       1.从mEnqueuedNotifications中找到跟key对应的NotificationRecord；

       2.通过indexOfNotificationLocked()看mNotificationList里面是否已经包含该NotificationRecord，如果不存在，说明是新的record，需要加入mNotificationList进行管理；否则的话，将mNotificationList中index对应的NotificationRecord进行更新；

       3.将要处理的NotificationRecord放入mNotificationsByKey进行管理；

       4.执行mListeners.notifyPostedLocked(r, old)来进行通知；

       5.在finally里面将要处理的NotificationRecord从mEnqueuedNotifications里面移除；

       6.如果在加入后有取消 *** 作，需要立刻执行取消 *** 作，并将NotificationRecord从mDelayedCancelations中移除；

       前面讲到，在PostNotificationRunnable中会执行mListeners.notifyPostedLocked(r, old)进行通知，mListeners是NotificationListeners实例：

       跟随调用关系：

       通过getServices()来找到已经注册过的ManagedServiceInfo列表，最后执行notifyPosted()；

       在notifyPosted()内部通过info.service来找到对应的INotificationListener实例，对应NotificationListenerService内部的NotificationListenerWrapper，然后将StatusBarNotification封装成StatusBarNotificationHolder，最后执行NotificationListenerWrapper的onNotificationPosted()方法：

       最终会通过Handler来发送消息来进行处理；

       onNotificationPosted(sbn, rankingMap)是在CarNotificationListener内部实现的；

       在CarNotificationListener内部会将StatusBarNotification封装成AlertEntry，然后执行notifyNotificationPosted()：

       一步一步调用：

       先将alertEntry存入mActiveNotifications进行管理；然后执行sendNotificationEventToHandler发送NOTIFY_NOTIFICATION_POSTED消息；

       该Handler是通过setHandler来赋值的，具体是在什么地方呢？

       这个需要回到最前面NotificationPanelViewController里面了，前面说到NotificationViewController是在显示环节进行分析，轮到NotificationViewController登场了；

       NotificationViewController是在NotificationPanelViewController实例化，并执行enable()方法，先看一下构造方法：

       在构造方法内部，会传入CarNotificationView、CarNotificationListener、PreprocessingManager等实例，都是跟显示有关的核心类；

       1.CarNotificationView：负责处理通知显示；

       2.PreprocessingManager：负责管理通知，通过CarNotificationListener来获取通知；

       3.CarNotificationListener：跟NotificationManagerService间接交互的类；

       可以看到Handler是在NotificationViewController里面实现的，当有消息到来时，如果CarNotificationView显示时执行updateNotifications()来直接显示通知；不显示时执行resetNotifications()来对通知进行管理；

       以上就是Notification的整个工作过程，最后用一张流程图来总结一下：

经常有人有以下的说法：

notify只会通知一个在等待的对象，而notifyAll会通知所有在等待的对象，并且所有对象都会继续运行

并且，好像都有例子可以证明。上面的说法，可以说对，也可以说不对。究其原因，在于其中有一点很关键，官方的说法如下所示：

wait,notify,notifyAll:

此方法只应由作为此对象监视器的所有者的线程来调用。通过以下三种方法之一，线程可以成为此对象监视器的所有者：

通过执行此对象的同步实例方法。

通过执行在此对象上进行同步的 synchronized 语句的正文。

对于 Class 类型的对象，可以通过执行该类的同步静态方法。

一次只能有一个线程拥有对象的监视器。

以上说法，摘自javadoc。意思即，在调用中，帆慧必须持有对象监视器(即锁），我们可以理解为需要在synchronized方法内运行。那么由此话的隐含意思，即如果要继续由同步块包含的代码块，需要重新获取锁才可以。这句话，在javadoc中这样描述：

wait

此方法导致当前线程（称之为 T）将其自身放置在对象的等待集中，然后放弃此对象上的所有同步要求。出于线程调度

目的，在发生以下四种让慎情况之一前，线程 T 被禁用，且处于休眠状态：

其他某个线程调用此对象的 notify 方法，并且线程 T 碰巧被任选为被唤醒的线程。

其他某个线程调用此对象的 notifyAll 方法。

其他某个线程中断线程 T。

大约已经到达指定的实际时间。但是，如果 timeout 为零，则不考虑实际时间，在获得通知前该线程将一直等待。

然后，从对象的等待集中删除线程 T，并重新进行线程调度。然后，该线程以常规方式与其他线程竞争，以获得在该对

象上同步的权利；一旦获得对该对象的控制权，该对象上的所有其同步声明都将被恢复到以前的状态，这就是调用 wait

方法时的情况。然后，线程 T 从 wait 方法的调用中返回。所以，从 wait 方法返回时，该对象和线程 T 的同步状态与调

用 wait 方法时的情况完全相同。

即必须重新进行获取锁，这样对于notifyAll来说，虽然态滑答所有的线程都被通知了。但是这些线程都会进行竞争，且只会有一个线程成功获取到锁，在这个线程没有执行完毕之前，其他的线程就必须等待了（只是这里不需要再notifyAll通知了，因为已经notifyAll了，只差获取锁了）有如下一个代码，可以重现这个现象。

这里的只是权限御喊衫的管理，系统允不允许你产生通知的控制中心而已。如果只是简单的要产生使用通知栏产生一条消息，你可以参考如渗颂下代码(该代码的功能是点击通知栏后跳转某个Activity，里面一些参数根据需要来替换)：镇腔

Context context = XXX（某个context）

targetIntent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK)

PendingIntent contentIntent = PendingIntent.getActivity(context,

NOTIFICATION_ID,

targetIntent,

PendingIntent.FLAG_UPDATE_CURRENT)

NotificationCompat.Builder notifyBuilder = new NotificationCompat.Builder(

context)

notifyBuilder.setSmallIcon(R.drawable.ic_launcher)

notifyBuilder.setContentTitle(title)

notifyBuilder.setContentText(content)

notifyBuilder.setAutoCancel(true)

notifyBuilder.setWhen(System.currentTimeMillis())

notifyBuilder.setDefaults(Notification.DEFAULT_ALL)

notifyBuilder.setContentIntent(contentIntent)

Notification noti = notifyBuilder.build()

(NotificationManager) context.getSystemService(Context.NOTIFICATION_SERVICE)).notify(NOTIFICATION_ID, noti)

 0

---