关于AppWidget的深入理解2

上一篇是对Dev  Guide中关于SDK的翻译，这篇文章的目的就是对AppWidget有一个深入的介绍。

一、首先介绍一下在开机过程中系统对AppWidget做了什么

当SystemServer.java运行到init2()的时候，通过SystemManager.addService(Context.AppWidget_Service,appWidget)将AppWidgetService服务加到服务队列里面，当所有服务加载完毕后会调用appWidgetF.systemReady(safeMode)进入到AppWidgetService.java，在这个方法中做了三件事：

1、遍历所有的安装包，找到符合条件的ACTION：ACTION_APPWIDGET_UPDATE和<meta-data android:name="android.appwidget.provider"/>的receiver，解析相关信息，保存到本地数据成员中。

2、读取本地文件数据：/data/system/appwidgets.xml，所有已安装到桌面的widget的信息都保存在这个文件里。读出来，也保存到本地数据成员里。

3、注册了三个消息：ACTION_BOOT_COMPLETED（系统启动到桌面就会发送此消息），ACTION_PACKAGE_ADDED（有新 APK包安装到系统），ACTION_PACKAGE_REMOVED（有APK包被删除）。当系统启动到桌面后，AppWidgetService接收 到了ACTION_BOOT_COMPLETED消息，它会去检查本地数据成员，如果有已经安装到桌面的widget,它会上发 ACTION_APPWIDGET_ENABLED和ACTION_APPWIDGET_UPDATE消息。如果有widget设置了updatePeriodMillis的属性，它就会开始计时（这个是通过AlarmManager来实现的），到时间时，就会再次发送ACTION_APPWIDGET_UPDATE消息。



二、与AppWidget相关的类有：

RemoteViews.java   

* A class that describes a view hierarchy that can be displayed in
* another process. The hierarchy is inflated from a layout resource
* file, and this class provides some basic operations for modifying
* the content of the inflated hierarchy

上面是Google给的关于RemoteViews的解释，大家不要被它的名字给欺骗了，说白了它就是作为一个描述view信息的载体，通过它可以在进程间传递，在另一个进程中由AppWidgetHostView去获取RemoteViews所承载的信息并且显示出来。

AppWidgetProvider.java

这个类继承BroadcastReceiver，并且重写了它里面的方法，里面通常使用的是onUpdate()方法对AppWidget更新

AppWidgetManager.java

* Updates AppWidget state; gets information about installed AppWidget providers and other
* AppWidget related state.



AppWidgetHost.java

* AppWidgetHost provides the interaction with the AppWidget service for apps,
* like the home screen, that want to embed AppWidgets in their UI.

AppWidgetHostView.java

* Provides the glue to show AppWidget views. This class offers    automatic animation
* between updates, and will try recycling old views for each incoming
* {@link RemoteViews}.

AppWidgetService.java

具体实现AppWidgetHost和AppWidgetManager中的方法。





对上图的一个解释：

当我们把一个AppWidget放在桌面的时候其实这个AppWidget是停靠在Launcher的一个View上面，被停靠的这个Activity我理解为“宿主”，而AppWidget是运行在一个独立的进程中，所以AppWidget要与这个“宿主”通信的话就需要IPC。

当RemoteViews把AppWidget的View信息传递“宿主”的时候，通过AppWidgetHost获得AppWidgetHostView的实例，这样 按照RemoteViews中的信息将AppWidget的View绘制到“宿主”中来。至此，我们的Widget就显示在“宿主”上了。

下图是对AppWidgetManager和AppWidgetHost做的解释，作为管理类，各自完成不同的管理任务。





在网上看到这么一段关于AppWidget的比喻，贴来大家看看

Android AppWidget框架妄析： Android中的借尸还魂




Android, AppWidget, 借尸还魂
由于初识Android不久，所以一切分析皆可有误，故而只能为之妄析。 题目起的比较恐怖，然非我本意。 只是实在找不到更加贴切的，可以对AppWidget框架一针而见血的比喻了。 闲话少说，且看如何个借尸还魂。

首看魂者何来。 大家都知道Widget的宗旨，就是要在同一屏幕（界面上）运行多个具有独立功能的小插件，从而丰富功能的同时简化操作。那么，在Android的4大组件中，何人可以充当该角色，抑或需要再独立设计一个组件？ Activity？ 非也！！ Activity是UI呈现和用户交互的一个组件，具有独特的Task管理机制，同一时刻，框架只允许一个Activity与用户交互并呈现。 而Widget的特点是，多实例的并发交互性。 所以，Activity不能满足，不能满足同时多个Widget的并发交互和呈现。 既然不能前台，那么只能在后台Running， Service or BroadCastReceiver？ 由于Widget需要处理众多的事件交互，所以，BroadCastReceiver更加合适。 既然找到了合适的，那么也就没有必要再创造新的。 够用就可以，不是越多越好，这也是软件设计的准则。 OK， AppWidget的魂已经找到，BroadCastReceive也， 所以，Android中的AppWidget其本质就是一个BroadCastReceive组件。

再看尸者何来。 尸者，阳间之物也。 虽已死（本身无用），却能见光（呈现）也。 任何一个期望在其之上运行Widget的前台的应用（Activity），其实就是一个Widget宿主。 其本身而言，无任何Widget功能，但却可以和用户交互并呈现，从此点而言，可谓尸也。 Android中的AppHost即为尸也。

最后我们看如何还魂。 AppWidget为魂，功能强大，为所欲为，但却始终位于阴间（后台运行），无法见日，故而众人不可观之。 AppHost为尸，虽见天日，却已无所可为。 我们何不将此二者互补那？？ 但是，阴阳两隔，必须使用特殊的方式， 此即为还魂术。 通过还魂术，可使得魂寄于尸而见天日。 还魂术就是阴间通往阳间的大道。 Android中的还魂术即为RemoteView。 在Android中，由于进程边界的存在，使得AppWidget与AppHost也阴阳两隔，默认是无法直接沟通的。 采用RemoteView，让AppWidget将一切需要呈现的描述构建到RemoteView中，AppHost中再基于该描述，重新创建于属于自己进程中的View进而显示。