接上篇《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才能更新它们的界面。