《android开发艺术探索》读书笔记(五)--RemoteViews

接上篇《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方法来完成的。

《android开发艺术探索》读书笔记(五)--RemoteViews

No13:

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

No14:

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

No15:

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

上一篇:ASP.Net请求处理机制初步探索之旅 - Part 4 WebForm页面生命周期


下一篇:JS三元运算符