接上篇《android开发艺术探索》读书笔记（四）--View工作原理

No1：

RemoteViews使用场景：通知栏和桌面小部件

No2：

通知栏主要通过NotificationManager的notify方法来实现的

桌面小部件是通过AppWidgetProvider来实现的，AppWidgetProvider本质上是一个广播

No3：

通知的实现可以看我的另外一篇Notification通知

桌面小部件的实现可以看我的另外一篇桌面小部件开发

No4：

PendingIntent的了解可以看我的另外一篇PendingIntent

No5：

RemoteViews支持的类型如下：

Layout：FrameLayout、LinearLayout、RelativeLayout、GridLayout

View：AnalogClock、Button、Chronometer、ImageButton、ImageView、ProgressBar、TextView、ViewFlipper、ListView、GridView、StackView、AdapterViewFlipper、ViewStub

RemoteViews不支持它们的子类以及其他View类型，故也不支持自定义View

No6：

RemoteViews的一系列set方法是通过反射来完成的

No7：

通知栏和桌面小部件中的布局文件实际上是在NotificationManagerService以及AppWidgetService中被加载的，而它们运行在系统的SystemServer中，这就和我们的进程构成了跨进程通信的场景

No8：

RemoteViews的作用是在其他进程中显示并更新View界面。

No9：

RemoteVeiws会通过Binder传递到SystemServer进程，这是因为RemoteViews实现了Parcelable接口，因此它可以跨进程传输，系统会根据RemoteViews中的包名等信息去得到该应用的资源。然后会通过LayoutInflater去加载RemoteViews中的布局文件

No10：

通知栏和桌面小部件分别由NotificationManager和AppWidgetManager管理，而NotificationManager和AppWidgetManager通过Binder分别和SystemServer进程中的NotificationManagerService以及AppWidgetService进行通信。

No11：

从理论上来说，系统完全可以通过Binder去支持所有的View和View操作，但是这样做的话代价太大，因为View的方法太多了，另外就是大量的IPC操作会影响效率。

为了解决这个问题，系统并没有通过Binder去直接支持View的跨进程访问，而是提供了一个Action的概念，Action代表一个View操作，Action同样实现了Parcelable接口。

这样的好处是不需要定义大量的Binder接口，其次避免了大量的IPC操作，提高了程序的性能。

No12：

远程进程通过RemoteViews的apply方法来进行View的更新操作，RemoteViews的apply方法内部则会去遍历所有的Action对象并调用它们的apply方法，具体的View更新操作是由Action对象的apply方法来完成的。

No13：

RemoteViews的apply方法首先会通过LayoutInflater去加载RemoteViews中的布局文件（通过getLayoutId获得），加载完布局文件后会通过performApply去执行一些更新操作。

No14：

Action对象的apply方法就是真正操作View的地方。

No15：

调用RemoteViews的set方法时，并不会立刻更新它们的界面，而必须通过NotificationManager的notify方法以及AppWidgetManager的updateAppWidget才能更新它们的界面。