http://mobile.51cto.com/widget-316886.htm
Widget与移动设备
Widget是什么？
Widget 是一个广泛的概念，从其字面意思可以翻译成小物件，小工具，小软件。Widget的实现可以多种多样，但是都有一个共同特性，即可以源码复用。换句话 说，Widget软件只要开发一次，便可以在具有该Widget运行引擎平台下完美的运行，具有完全一样的功能，UI风格和用户体验方式。
从 Widget的实现方式上来说主要有两种，一种是基于DHTML, JAVASCRIPT和CSS技术的Widget。另一种是基于Adobe Flash技术的Widget。目前大多数Widget实现还是基于前者，尤其是目前日渐流行的移动设备上的Widget技术均指Web Widget。
Widget的特点
- 小尺寸：Widget的尺寸通常都不大，并且运行速度比较快，占用的系统资源也较少。
- 形式多样：Widget的展现方式可以多种多样，可以是一个悬浮在窗口里的小图标，可以是占用全屏的全屏应用，也可以是插入某个应用子窗口中的小程序。
- 功能多样：Widget应用可以提供的功能可以多种多样(依赖Widget引擎提供的功能)，如提供新闻资讯阅读，视频观看，系统状态监视，天气预报，股票信息，时钟，联系人管理，短信接收发送等。
- 美观：Widget应用设计的一般都比较漂亮，并且具有很好的用户体验和操作方式。
- 个性化强：由于Widget的小尺寸和多样的形式和功能，因此用户可以随意的安装、摆放和设置Widget，达到个性化的Widget展示和使用效果。
- 开发方便：由于大多数Widget都是基于Web技术或者Flash技术，并且这两种技术都已经发展成熟，提供大量的集成开发环境以及可以复用的代码。因此，开发人员可以很快速的开发出功能强大、界面美观的Widget应用。
Widget应用
- 桌面电脑上的Widget
-
- Yahoo Widget
- Mac OS dashbord
- Windows Vista侧边栏
- Windows 7桌面小工具
- 移动终端上的Widget
- 个性化首页中的Widget
-
- Netvibes
- iGoogle
- 博客中的Widget
移动平台上的Widget规范(Web Widget)
目前，移动平台上支持的Widget运行环境主要遵循三套规范：W3C Widget规范、BONDI Widget规范和JIL Widget规范。
- W3C Widget规范
该规范是由W3C组织制定，包含6个子规范，主要定义了Widget的运行时状态，打包和配置，数字签名，自动升级，以及核心API和事件处理。
- BONDI Widget规范
该规范由OMTP组织制定，对W3C Widget规范进行了扩充。严格定义了Widget的安全验证体系，丰富了API接口。目前W3C组织考虑将BONDI规范纳入到标准中。
- JIL Widget规范
该规范是由中国移动、沃达丰、软银以及Verizon共同提出和定义的Widget规范。该规范目前主要是被中国移动的BEA平台所支持。
Widget引擎
Widget引擎的作用
Widget引擎为安装、运行、管理、升级，验证Widget应用提供了一整套完整的框架体系。
- 安装
Widget的发布方式可以多种多样，可以是基于Web页面的发布方式也可以是基于安装包的发布方式，因此Widget引擎需要对各种发布方式兼容，将用户的Widget应用安装和部署到当前的Widget运行环境中。
- 运行
Widget应用有其自身的生命周期(初始化，运行，暂停，恢复，终止)，因此Widget引擎有责任管理每个Widget应用的生命周期，在Widget不同的阶段执行Widget内部定义的事件处理代码。
- 管理
Widget引擎负责像用户提供已安装Widget应用的管理功能，用户可以通过Widget引擎查看当前运行的Widget运行状态，占用的系统资源，终止应用，运行应用以及删除应用。
- 升级
Widget引擎会根据Widget的配置文件定期的检测Widget的版本，并且动态的更新Widget应用。
- 验证
出于安全性的考虑，Widget应用都需要进行签名，并且需要显示的声明其需要使用的特殊功能接口。并且在运行时刻，Widget引擎需要对Widget调用受限接口的合法性进行验证。
Widget引擎与浏览器的关系
由于Web Widget应用采用DHTML、JAVASCRIPT和CSS技术实现，因此运行Widget需要浏览器引擎作为支持。但是通常的浏览器引擎不足以支撑 Widget的应用。比如：Widget规范中严格的定义了Widget的打包方式，尤其固有的配置和部署方式，通常的浏览器引擎是无法识别并且按照规范 要求正确安装和部署的。某些Widget规范中定义了Widget应用对设备能力的访问，这也是通常浏览器引擎所不支持的。因此，如果浏览器需要支持某个 特定Widget规范需要对浏览器引擎进行扩展，对Widget规范中定义的打包发布、升级安装、安全验证以及设备相关的API进行扩展和支持。
这里还有一类Widget不需要访问设备功能，并且并不遵循某套特定的Widget规范，而只是以Web页面中的一个小控件或者小程序形式出现，该 Widget应用是不需要对浏览器做扩展。但由于没有一套标准统一的规范标准作为支持，因此只能由该站点开发者自己去设计并且开发，不具有广泛性。
Widget引擎框架设计
这里的Widget引擎框架主要是以Android平台上的Widget引擎的设计为基础，所支持的标准不限(可包括W3C，BONDI，JIL规范)。
Widget引擎框架
- Widgets
如上图所示，Widget表示该Widget引擎所支持的各种Widget应用，该应用采用DHTML, JAVASCRIPT， CSS技术编写和实现。该Widget引擎所支持的Widget种类完全依赖于APIs Implement部分。
- Widget Module Loader
模块载入器的主要作用有两个：第一，负责各个已实现的Widget规范API模块的初始化。第二，负责在浏览器DOM树中注册载入的API模块对象，以使得Widget应用中可以使用相应的接口、对象和属性。
- Application Management
应用程序管理模块负责Widget应用的生命周期管理、应用程序的下载安装，以及应用程序的删除。应用程序管理模块与Widget DOM对象有紧密联系。比如：Widget应用在初始化阶段为resume事件注册了回调函数，在该函数中会对暂停时的应用数据进行恢复操作。应用程序管 理模块在接收到Widget的恢复事件时，有责任调用该应用注册的resume回调函数，并且执行其定义的恢复操作。
- Security Management
安全管理模块负责Widget应用的安全验证。比如在Widget应用安装时，安全管理模块需要对Widget应用签名的合法性进行验证，并且对 Widget声明的设备接口使用权限进行验证。当Widget运行时，Widget应用访问某个设备接口(比如Camera)，安全管理模块需要对该应用 是否有权访问该设备接口进行验证。
- APIs Implement
API实现包含了各个Widget引擎需要支持的Widget规范的底层实现。该部分的实现可以是纯JAVA实现、可以是JAVASCRIPT和JAVA混合实现、可以是JAVA和C/C++混合实现、亦可以是纯C/C++实现。
Widget引擎实现方式
基于WebKit引擎的扩展实现
该实现方式直接修改和扩展WebKit引擎，在引擎内部创建widget的DOM对象，并且提供抽象的调用方法。除此之外，需要在WebKit引擎中实现对各个规范模块的调用机制。
- 基于JAVA语言的模块调用
该实现方式需要对WebKit引擎实现JAVASCRIPT语言和JAVA语言之间的平滑调用机制。即Widget应用访问widget对象的某个 API接口时，WebKit引擎需要将该SCRIPING对象动态的转换成相应的JAVA对象，并且调用其相应的方法。并且，将该JAVA方法执行后的结 果动态的转换成JAVASCRIPT对象，并且返回给Widget应用。
采用该机制实现的API模块均用可采用JAVA语言来实现。因此，该实现方式具有实现速度快的特点，但是也正因为与JAVA语言的紧密关系移植性不好。
- 基于C/C++语言的模块调用
所有的API模块的扩展均采用C/C++语言来实现，这类似gears的实现方式。引擎内幕会将Widget应用使用的JAVASCRIPT方法动态转换成定义的C/C++对象，并且执行相应的方法。而后将返回结果转换成JAVASCRIPT方法返回给Widget对象。
采用该机制实现的API模块均采用C/C++语言来实现，因此开发周期相对较长，但是具有良好的移植性。
采用WebKit引擎扩展实现方式，可以让浏览器引擎原生的对Widget应用进行支持，但是在每次WebKit升级时，需要对修改的代码进行合并和再发布。
基于WebKit插件的扩展实现
该实现方式基于NPAPI插件扩展技术的基础之上。将Widget的DOM对象实现包含在NPAPI插件中，当浏览器检测到该对象的访问时，动态的载入该NPAPI插件，并且将所有对Widget DOM对象的访问操作均转发给NPAPI插件来完成。
NPAI插件的实现方式如WebKit引擎扩展实现一样，也有JAVA和C/C++两种实现方式，这里不再重复。
采用该实现方式的扩展无需对WebKit引擎修改，但是需要按照NPAPI规范，实现完整的SCRIPTING插件。
基于C/S架构的扩展实现
该实现方式采用借用了C/S设计模式的思想。在Widget引擎初始化阶段会启动一个内部的服务，该服务会监听系统中某个端口。Widget引擎运 行时，如果访问Widget对象的某个方法时，封装的Widget JS对象会向服务端口发送方法请求。服务端接受请求后，首先会对请求进行合法性验证和分析，然后调用相应的接口来完成实际的操作。并且将结果以异步的方式 返回给封装的Widget JS对象，而由该对象通知Widget应用操作结果。
C/S架构的扩展实现也可以采用JAVA和C/C++实现方式，这里不再重复。
采用该方式实现的扩展有良好的灵活性，不同的Widget规范定义的Widget应用只需要包含相应的Widget封装JS包即可正确运行。但是由于采用C/S模式的调用方式，因此在执行效率上略低于直接调用的方式。
Browser&Widget
这部分对Browser的设计提出一个概念层面上的设计。如下图所示：
- Table Manager
负责管理浏览器中各个Table页面，每个Table页面是一个独立的Web页面或者Widget应用。
- Bookmark Manager
负责管理书签，该书签包括用户收藏的网站URL以及喜爱的RSS频道和文章信息。
- RSS Manager
负责RSS频道的订阅、RSS新闻列表、RSS频道退订
- Plugin Manager
负责管理已经安装的浏览器插件
- Notification Manager
负责事件通知管理，比如RSS新闻数据的更新通知，浏览器插件的升级通知，Widget升级通知等。
- History Manager
负责记录当前Table的运行数据，包括访问的URL历史，当前窗口大小位置信息，可用于当浏览器crash后的状态恢复操作。
- Download Manager
负责浏览器的下载管理，包括android软件的下载、安装，Widget软件的下载、安装
- Gesture Manager
负责手势操作的自定义操作管理。
- Thread Manager
为了加快浏览器的载入效率，每个Table在一个单独的线程中运行，因此对线程的运行状态需要一个统一管理机制。
- Skin Manager
负责Browser外观的管理，用户可以通过该模块动态的给系统更换皮肤和显示方式。
- Widget Manager
负责Widget引用的下载、安装、删除、以及运行时环境的支持。