最新版本
http://www.w3.org/Mobile/mobile-web-app-state/
当前版本
http://www.w3.org/2012/08/mobile-web-app-state/
上个版本
http://www.w3.org/2012/05/mobile-web-app-state/
随着网页技术的成熟,我们已经可以用它来构建全功能常规应用了。这在传统的PC领域已经实现了一段时间,现在在移动设备上也日渐成熟。
本文总结介绍W3C开发的各种增强Web App功能的技术,特别是它们在移动设备环境的应用。
1 图形
2 多媒体
3 设备兼容
4 表单
5 用户交互
6 数据存储
7 个人信息管理
8 传感器和硬件集成
9 网络
10 通信和发现
11 封装打包
12 性能和优化
现状及变更
本文是移动Web App技术概论的第七版。上个版本在2012年5月发布。在W3C维基有本文的实时版。
可将对本文任何方面的意见发给作者(dom@w3.org),作为下个迭代版本的参考。
它包含了以下自2012年5月以来Web平台的变更
· CSS媒体查询(CSS Media Queries) 已作为"W3C推荐"发布
· 导航调度(Navigation Timing) 已经达到"提议推荐"的状态,距离成为标准仅一步之遥。
· 性能时间线(Performance Timeline),用户调度(User Timing),还有页面可视性API(Page Visibility API)正在寻求实例反馈,已经达到"候选推荐"的状态。
· 新的规范已经被提交到W3C咨询委员会,以开展近场通信NFC(Near-Field Communications)和系统应用(System Applications)(如利用Web技术构建的原生应用)的工作。
· HTML媒体捕获(HTML Media Capture)已作为最后修订的工作草案发布。
· SVG 2.0,全屏API(Fullscreen API),联网服务搜寻及消息传送(Networked Service Discovery and Messaging),媒体捕获及数据流(Media Capture and Streams),配额管理API(Quota Management API),近距离感应事件(Proximity Events),环境光感事件(Ambient Light Events),Web Intents已作为首版公开工作草案发布。
· 联系人API(Contact API)以及相册API(Gallery API)被重新修订为使用Web Intents作为基础机制。
· 专利咨询小组召集并讨论了被公开的触摸事件API(Touch Events API)专利,并发布让小组继续推荐流程的相关工作。
· 自适应图片元素<picture>被作为编辑草案提交到HTML工作组。
· WAI教育及拓展工作组(WAI Education and Outreach Working Group)发布了当前移动设备可用性(Mobile Accessibility)工作的总结报告。
文档结构
这些技术为Web平台增加的特性归纳为以下分类:图形,多媒体,设备兼容,表单,用户交互,数据存储,个人信息管理,传感器及硬件集成,网络,通信及搜寻,封装打包,性能及优化。
Web应用程序开发平台
在每个类别中,每个特性表格都总结了:
· 定义了该项特性的W3C规范
· 负责该项规范的W3C小组
· 该项规范在W3C推荐流程中的状态(请参考下文)
· 相应文档的稳定性评估,如文档可能的变化范围,由本文的作者评估,有三个等级:低(文档已经接近稳定),中(文档一些部分稳定,其他部分可能会有较大变化),高(文档可能有较大变化)
· 一些移动设备实现情况的质量指标,综合了从Can I Use和mobile HTML5收集的数据,从Mozilla开发者网络补充的数据,QuirksMode以及作者个人对移动设备市场的理解。(请参考用来生成支持情况图标的代码)
· 最新编辑草案的链接地址
· 该特性对应的测试套件的链接地址
需要提醒的是,W3C通过一系列推荐流程来处理文档最终形成Web标准。一般包含以下步骤:
· "编辑草案"表示规范是当前编辑者的看法,它还没有标准化的资格。
· "工作草案"表示该规范是工作组工作进程早期的里程碑。
· "最终提议工作草案"表示工作组认为规范已经符合相关要求并且所有已知问题都已经得到解决,并寻求广大社区的反馈。
· "候选推荐"表示发布邀请寻求开发商对其进行实现和反馈;工作组将通过运行测试方案来验证该规范已被实现。
· "提议推荐"表示工作组已经收集到了充分的实践检验,并提交给W3C成员做最后审查。
· "W3C推荐"表示该规范是稳定且完善的Web标准。除了通过"推荐校订"流程,作为工作组收集的错误修订,否则这些文档极少更新。
一项标准订立前,必须先成立一个由W3C成员组成的工作小组。成员一般由研讨会组织,或W3C成员提交申请。
W3C建立了社区小组,一个允许任何人在W3C框架内做实验性工作的机构,并且在遵循知识产权条例的同时,能将工作过渡到W3C标准化进程。
1、图形
SVG,可缩放向量图形(Scalable Vector Graphics),一种用来描述二维向量图形的XML语言。SVG图像使用几何图形的集合来描述,它们可以按用户的要求缩放,这使得它们非常适合在屏幕空间有限的移动设备上创建图形。而且它们可以轻松地进行动画渲染,为创建更先进、灵活的用户界面提供了基础。
HTML5对SVG的集成带来了更多新的可能,例如,给视频等多媒体内容添加图像滤镜(通过SVG过滤器)。SVG 2.0 的目标即是促进这部分集成并完善SVG的功能。
作为对SVG描述性方法的补充,HTML5新增的<canvas>元素提供了对内存需求更少的2D编程API。这套API不仅可以用来渲染图形,还可以用来做图像处理和分析。
SVG和HTML都可以利用CSS 层叠样式表(Cascading Style
Sheets)修饰样式;而且,CSS3(该标准第3级)设计时,就引入很多新功能,使得创建图形特效更加容易,如圆角,多重背景图像,阴影效果(CSS Backgrounds and Borders),内容旋转(CSS 2D Transforms),动画(CSS Animations, CSS Transitions),甚至是3D特效(CSS 3D Transforms)。
动画可能是资源密集型的,对此,脚本动画时钟控制API(Timing control for script-based animations API)提供了管理动画更新频率的方法,以帮助控制资源使用。
字体在构建具有吸引力的图形界面中充当了很重要的角色,但移动设备通常只包含有限的几款字体。网页开放字体格式WOFF(Web Open Font Format)用通过样式表自动下载字体的方法解决了这个问题,并且将字体限制为渲染页面需要的实际大小。
图形密集型应用(如游戏)的另一个重要方面是利用整个屏幕渲染所需图形的能力。全屏API(Fullscreen API)为Web应用程序提供了全屏模式请求和检测的支持。
同样的,在这些场景中,锁定屏幕旋转的功能也很重要,为此,屏幕旋转API(Screen Orientation API),提供了检测屏幕方向还有锁定特定状态屏幕方向的方法。
注:一套名叫WebGL的3D图形API的定义工作已经在W3C外部展开,并作为Khronos Group的一部分。这套API被设计为和OpenGL ES兼容,如嵌入式系统,目的是支持在移动设备上工作。
特性 | 规范 | 工作组 | 成熟度 | 稳定性 | 最新草案 | 当前实现情况 | 测试套件 |
2D向量图形 2D Vector Graphics | SVG 工作组 | 推荐 | 完成 | SVG (SVG 2.0) 新版正在计划中 | 广泛部署 | ||
工作草案 | 初期草案 | N/A | N/A | ||||
2D编程接口 2D Programmatic API | HTML 工作组 | 工作草案 | 接近稳定 | 广泛部署 | |||
圆角 Rounded Corners | CSS 背景及边框 | CSS 工作组 | 候选推荐 | 接近完成 | 大部分浏览器以扩展方式部署
| 无 | |
多重背景图像 Complex background images | 部署稳定增长
| ||||||
阴影 Box shadow effects | 广泛部署
| ||||||
2D特效 2D Effects | 工作草案 | 接近完成 | 广泛部署
| ||||
3D特效 3D Effects | 稳定 | 部署稳定增长
| |||||
动画 Animations | 工作草案 | 初期草案 | 部署稳定增长
| 无 | |||
工作草案 | 初期草案 | 部署情况非常好
| 无 | ||||
最终提议 工作草案 | 稳定 | 部署有限
| |||||
可下载字体 Downloadable fonts | 候选推荐 | 接近稳定 | 部署情况良好
| ||||
全屏显示 Fullscreen display | 工作草案 | 初期草案 | 部署有限
| 无 | |||
转向锁 Orientation Lock | 工作草案 | 初期草案 | 部署有限
| 无 |
2、多媒体
HTML5增加了两个显著改善多媒体内容和网页集成的标签:<video>和<audio>标签。这两个标签分别支持在网页中嵌入视频和音频,并让Web开发者能够比使用插件更自由地操作嵌入的内容。它们让多媒体成为网页的一等公民,就如图像在过去15年所担当的一样。
为了满足一些内容提供商的需求,HTML工作组(HTML Working Group)正在考虑一个支持保护内容播放的提案,媒体加密扩展正是待审的API之一。
Pick Media Intent提供了一套基于网页搜索并获取本地或远程存储的媒体内容的方法,而联网服务发现及消息传送API(Networked Service Discovery and Messaging API) 开启了集成DLNA托管内容到Web应用中的大门。
除了支持媒体播放的新HTML5标签,HTML媒体捕获(HTML Media Capture)定义了一套基于标记语言来获取内置摄像头和麦克风捕获到的多媒体内容的机制。另外,Web实时通信工作组(Web Real-Time Communications Working Group)和设备API工作组(Device APIs Working Group)正合作创建一套用来直接操作摄像头和麦克风数据源的API(getUserMedia)。
除了记录数据,还有两个API为Web平台增加了多媒体处理的功能。我们已经提到过的Canvas 2D ContextAPI,它支持图像处理,因此也为视频剪辑处理提供了可能。
同样的,音频工作组(Audio Working Group)正在开发一套支持音频分析、修改、合成的API–Web音频API(Web Audio API),与之竞争的提案–媒体流处理API(MediaStream Processing API)则被放弃了。
所有这些功能的组合标志了Web成为消费、生产的综合性多媒体处理平台的开端。随着连接网络和电视世界兴趣的提升,(如W3C网页和电视工作组(Web and TV Group)展示的那样),必将在接下来的数月中推动这个趋势。移动设备将在用户的电视体验中扮演越来越重要的角色,并为用户提供"第二屏幕"的体验,让用户可以在其中找到所看电视节目的更多信息,或与之交互。
功能 | 规范 | 工作组 | 成熟度 | 稳定性 | 最新草案 | 当前实现情况 | 测试套件 |
视频播放 Video playback | HTML工作组 | 工作草案 | 稳定 | 部署情况良好
| |||
音频播放 Audio playback | 最终提议 工作草案 | 部署情况良好
| |||||
保护内容播放 Protected content playback | 媒体加密扩展 | N/A | 初期提议 | 无
| 无 | ||
多媒体库访问 Multimedia Gallery access | 工作草案 | 初期,基于Web-intents方法 | 最近在2012年8月更新 | 无
| N/A | ||
工作草案 | 初期草案 | 最近在2012年8月更新 | 无
| 无 | |||
视频、音频 捕获 Capturing audio/video | HTML媒体捕获 | 最终提议 工作草案 | 稳定 | 最近在2012年7月更新 | 部署有限,但稳定增长
| 无 | |
Web实时通信工作组 及设备API工作组 合作项目 | 工作草案 | 稳定但可能还有较大更改 | 少数实验性部署
| ||||
图像及视频 分析,编辑 Image & Video analysis, modification | HTML工作组 | 工作草案 | 接近稳定 | 广泛部署
| |||
音频分析, 编辑 Audio analysis, modification | 工作草案 | 工作初期 | 几个部署
| 无 | |||
废弃 | 废弃 | N/A | 无
| 无 |
3、设备兼容
移动设备不仅和传统电脑有很大区别,它们之间也有很多不同。例如屏幕大小,分辨率,键盘类型,媒体存储能力等等。
设备描述资源库API是一个统一的服务器端API。它允许Web开发者从各种设备信息数据库中检索当前正在请求页面的设备的数据。
媒体捕获专案组(Media Captrue task force)当前正在评估能否以及如何暴露摄像头和麦克风的功能,以便更好利用手机提供的各式各样的媒体捕获设备。
CSS媒体查询(CSS Media Queries)提供了基于设备特性调整网页页面排版和行为的机制,如屏幕分辨率。CSS设备兼容(CSS Device Adaptation)定义了一套用来定义特定布局所依赖的屏幕大小的指令,而这又与底层的设备相关–目前指通过<meta
name="viewport">元素实现的功能。
自适应图像社区小组(Responsive Images Community Group)一直在试探索何在HTML中加载并显示最适合当前设备分辨率的图片。他们当前正尝试为HTML5加一个<picture>元素。
作为补充,WHATWG正讨论加入srcset属性的提案,它让Web开发者定义图像存在的各种分辨率,以便浏览器能自动选择最符合当前屏幕分辨率的图像。
特性 | 规范 | 工作组 | 成熟度 | 稳定性 | 最新草案 | 当前实现情况 | 测试套件 |
设备信息 Device information | 简易设备描述库API (服务器端) | 设备描述工作组(已解散) | 推荐 | 完成 | N/A | 有限部署 | |
媒体捕获功能API | N/A | 未开始 | N/A | N/A | N/A | ||
基于CSS的 适配 CSS-based adaptation | CSS工作组 | 推荐 | 完成 | 最近在2012年4月更新 | 广泛部署
| ||
CSS设备适配 | 工作草案 | 初期 草案 | 最近在2012年4月更新 | 部署非常有限
| N/A | ||
自适应图像 Adaptive images | picture元素 | HTML工作组 | N/A | 已提议 | 最近在2012年8月更新 | 无
| N/A |
srcset属性 | N/A | 已提议 | 无
| 无 |
4、表单
HTML中创建表单的功能是许多基于Web的应用程序实现用户输入的基础。然而因为设备键盘限制,对很多用户来说,在移动设备上输入文本是一件麻烦的事情。HTML5通过加入新类型的表单控件来改善用户输入数据的方式,以此解决这个问题。
· 日期及时间入口可以使用一些专用的表单控件(如,<input type="date">),让用户能使用原生的日历控件;
· <input type="email">,<input type="tel">以及<input type="url">用来改善这些输入通常比较麻烦的数据的输入方式。如通过专用的虚拟键盘,或通过获取设备上相应数据的记录(通过通信录,书签等等。);
· pattern属性既可用来引导用户输入,以及避免服务器端(需要网络来回通信)或者基于JavaScript的验证(消耗更多的资源);
· placeholder属性通过在文本控件插入提示内容来引导用户输入。
· 新的<datalist>元素允许构建无需文本输入,而从包含的预定义值中选择输入的控件。
特性 | 规范 | 工作组 | 成熟度 | 稳定性 | 最新草案 | 当前实现情况 | 测试套件 |
日期和时间输入 Date and time entries | HTML5 输入元素的日期及时间状态 | HTML 工作组 | 工作草案 | 稳定 | 部署有限
| ||
自定义文本输入(电话,邮件,链接) Customized text entries (tel, email, url) | 工作草案 | 稳定 | 部署有限,但稳定增长
| 无 | |||
输入模式 Input pattern | 工作草案 | 稳定 | 部署非常有限
| ||||
输入提示 Input hint | 工作草案 | 稳定 | 部署情况非常好
| 无 | |||
文本输入预定义值 Pre-defined values for text entries | 工作草案 | 稳定 | 部署非常有限
| 无 |
5、用户交互
越来越多的移动设备依赖触摸这种交互方式。虽然Web平台识别的传统交互方式(键盘,鼠标)依旧可以使用,但由基于DOM的触控事件(Touch Events in the DOM)支持的对触控事件的专门处理是构建更具适应性的用户检验的关键。这方面的相关规范已经接近完成,而且已公开的有关专利也被决定不会使用。
另一方面,许多移动设备通过触觉反馈(如振动)来构建新的交互方式(如游戏);这方面,设备API工作组(Deviece APIs Working Group)振动API(vibration API)的相关工作进展顺利。
随着Web扩展到更多的设备上,以及设备获得更多新的用户交互机制,如何让Web开发者处理更加抽象的用户交互变得尤为重要。相对响应"click","key press","touch event"等事件,响应如"undo"命令、"next page"命令而不管用户是如何触发它的,将更有利于独立于设备的Web App开发。解决这个问题的DOM虚拟事件(abstract DOM events)的相关工作已经加入网页事件工作组(Web Events Working Group)和独立UI工作组(Indie UI Working Group)的合作小组工作计划。
移动设备常常与用户如影随形,同时许多用户又依赖这些设备的事件提醒和通知,如消息提醒。Web通知(Web Notifications)规范即提议将这项特性添加到Web环境中。
移动设备,特别是移动电话,在很多情况下特别适合通过语音交互的方式互动。语音API社区小组(Speech API Community Group)正探索开始一套JavaScript API的标准化工作,让用户可以通过语音命令与Web页面交互。
移动设备的硬件限制,还有它们不同的使用环境,常常让用户像残障人士一样感到不便。这些不便的相似性意味着可以用类似的方案解决它们,让网站既方便残障人士也方便移动用户使用便成为一个很自然的目标。
如何使网页内容可用性指南WCAG(Web Content Accessibility Guidelines )还有客户端可用性指南UAAG(User Agent Accessibility)对移动设备可用性提供指导,即如何使网站和应用更方便残障人士使用移动设备和其他设备的问题,在移动设备可用性(Mobile Accessibility)这份资料中讨论。
WAI-ARIA提供了移动设备控件的语义信息,以及结构和行为的调控方法,使得Web App可用性更好。
特性 | 规范 | 工作组 | 成熟度 | 稳定性 | 最新草案 | 当前实现情况 | 测试套件 |
基于触控的交互 Touch-based interactions | 候选推荐 | 接近完成 | 多数部署
| ||||
振动 Vibration | 候选推荐 | 稳定 | 实验性实现
| ||||
基于Intent的 事件 Intent-based events | N/A | N/A | 未开始 | 还未起步 | 无
| 无 | |
提醒 Notification | 工作草案 | 初期草案 | 少数实验部署
| 无 | |||
基于语音的交互 Speech-based interactions | N/A | N/A | N/A | N/A
| N/A | ||
基于模型的用户界面 Model-based user interfaces | N/A | N/A | N/A | N/A | N/A | ||
可用性 Accessibility | 移动网页最佳实践工作组及教育与拓展工作组 | 工作组记录 | 完成 | N/A | N/A | N/A | |
候选推荐 | 稳定 | 最近在2012年5月更新 | 部署稳定增长
| 无 |
6、数据存储
保存状态,导出数据,以及整合其他文件或系统服务数据的能力,是很多应用程序的关键组成部分。
对于简单的数据存储,Web存储规范(Web Storage)提供两种基本机制:localStorage和sessionStorage,前者可以无限期存储信息,而后者基于浏览器会话周期存储信息。
对于更多的数据操作方式,Web平台拥有一套越来越来完善的设备文件系统API:File Reader API提供了载入文件内容的方法,File Writer API提供了保存或修改文件的方法,而新的FileSystems API则提供了更通用的文件操作方法,包括目录管理功能。
基于这种文件机制之上,索引数据库API(Indexed Database API)定义了基于原生JavaScript接口的值与分层对象数据库,它支持快速高效的查询和更新。而另外一套从2009年开始,致力于提供客户端类SQL数据库的方案则被放弃。
随着数据存储需求的增加(如离线存储),如何让开发者获得可靠的存储空间变得尤为重要。而这也是配额管理API(Quota Management API)的提案将为Web应用程序提供的。
特性 | 规范 | 工作组 | 成熟度 | 稳定性 | 最新草案 | 当前实现情况 | 测试套件 |
简单数据存储 Simple data storage | 候选推荐 | 稳定 | 部署情况非常好
| ||||
文件读取 File reading | 工作草案 | 稳定 接近发布 | 部署稳定增长
| 无 | |||
文件写入 File writing | 工作草案 | 初期草案(但接近稳定) | 无
| 无 | |||
文件系统操作 Filesystems operations | 文件API: 目录及系统 | 工作草案 | 初期草案 | 无
| 无 | ||
数据库查询、 更新 Database query/update | 最终提议 工作草案 | 稳定 | 部署稳定增长
| ||||
工作组记录 | 废弃 | N/A | 有部署一些,但不会再有新部署
| N/A | |||
存储配额 Quota for Storage | 工作草案 | 工作初期 | N/A | N/A |
7、个人信息管理
与现有数据记录的集成也能很好改善应用程序。在移动设备上,通讯录还有日历都是特别有用的信息来源,而通讯录API(Contacts API)和日历API(Calendar API)就对这种信息源提供访问支持。
现有(访问数据)的JavaScript API将逐步被基于Web Intents的方法替代。一套完全基于编程的方法也是新系统应用工作小组的一部分。
特性 | 规范 | 工作组 | 成熟度 | 稳定性 | 最新草案 | 当前实现情况 | 测试套件 |
通信录数据 Address book data | 工作 草案 | 基于Web-intents方法的早期实现; 一套更完善的API将由新成立的系统应用工作组实现 | 无
| ||||
日历数据 Calendar data | 工作 草案 | 可能有较大更改 | 无
| 无 |
8、传感器和硬件集成
移动设备通常已集成了传感器,使得它们成为现实世界与虚拟世界之间良好的沟通桥梁。如GPS、加速器、环境光源感应器、麦克风、摄像头、温度计等等。
为了更好的在移动Web应用程序利用这些传感器,Web开发人员需要一套可操作的接口。
地理位置API(Geolocation API)提供了定位设备的通用接口,它独立于底层的技术(GPS,WIFI网络识别,蜂窝网络三角测量法等等)。然而这套API的第二版,还有原本要加入的根据用户当前地理位置获取城市位置信息的功能,由于缺乏需求而被废弃。
Web应用程序还可以通过设备旋转事件规范获取旋转以及加速数据。
一套通用传感器API的工作也因设计各种具体类型的传感器API的工作而搁置,如近距离感应事件API(Proximity Events API),环境光源事件API(Ambient Light Events API)还有已提议的环境湿度事件API(Ambient Humidity Events API)。
正如前面多媒体一节所提到的,访问摄像头和麦克风数据流API的工作也正在开展。
增加Web应用近场通信NFC(Near-Field Commuunications)支持的讨论促成了成立新工作组的提案,而且极有可能促成专门的工作组,现正在W3C成员审核当中。
而更加全局的传感器和硬件(包括USB和蓝牙)访问方法也将是提议的新系统应用工作小组(System Applications Working Group)的研究范围,当前也正在W3C成员的审核当中。
特性 | 规范 | 工作组 | 成熟度 | 稳定性 | 最新草案 | 当前实现情况 | 测试套件 |
地理位置 Geolocation | 工作组 | 提议推荐 | 接近完成 | 广泛部署
| |||
废弃 | 废弃 | N/A | 无 | N/A | |||
动作传感器 Motion sensors | 最终提议 工作草案 | 稳定 | 部署稳定增长
| ||||
电池状态 Battery Status | 工作组 | 候选 推荐 | 稳定 | 实验性实现
| 无 | ||
近距离感应 传感器 Proximity sensors | 近距离感应事件 | 工作草案 | 初期草案 | 少数实验性实现
| |||
环境光源传感器 Ambient Light sensor | 工作草案 | 初期草案 | 无
| ||||
湿度传感器 Humidity sensor | 环境湿度事件 | N/A | 非官方草案 | 无
| N/A | ||
摄像头和话筒流 Camera & Microphone streams | 工作草案 | 稳定 但依然有可能有大更改 | 少数实验性实现
|
9、网络
网络链接能力代表了移动设备的优势之一:网络是一个巨大的内容存储空间,也是一个无穷的计算能力来源,它克服了移动设备的两项不足。
Web平台正在添加一些在不同环境中建立网络连接的API。
XMLHttpRequest(AJAX中的"X")是一个广泛应用的利用HTTP和HTTPs协议从Web服务器加载内容的API:此项W3C规范(即熟知的XMLHttpRequest第2级)完善了现有已部署的接口,支持从不同域的服务器请求数据、网络操作中的程序回调,以及更有效率的二进制数据处理。另一方面,为已部署的API(XMLHttpRequest第1级)添加文档的工作也被加速开发新API的工作取代。
默认情况下,浏览器并不允许一个普通Web页面的跨域请求(或更明确地说,跨源访问;"源"指协议、域名及端口的组合)。这项规定防止某个网站滥用用户证书,并窃取用户在其他网站上的数据。网站可以选择跨源资源分享(Cross-Origin Resource Sharing)机制来规避这项规定,以实现不同Web应用和服务之间的广泛合作。
XMLHttpRequest对于客户端发起的网络请求十分有用,但对于只有有限网络链接以及对请求操作引起的电池消耗敏感的移动设备(有时甚至是对用户的花费敏感)往往可以更好地利用服务器发起的请求。对此,服务器推送事件API(Sever-Sent Events API)将允许通过推送消息触发DOM事件(通过HTTP或其他协议)。
推送API(Push API)的早期工作已经支持Web应用程序接收服务器发送的消息,不论该程序在浏览器窗口中是否处于激活状态。
基于IETF WebSocket协议的WebSocket API(WebSocket API),提供了一个双向,并且比XMLHttpRequest更灵活、更低资源消耗的网络链接。
Web实时通信(Web Real-Time Communications)方面的工作,将实现浏览器之间的点对点链接,开启了多设备Web应用程序合作的可能。
当然,使用网络连接的一个方面便是依赖对网络连接是否存在和网络类型的检测。HTML5 DOM在线标记(HTML5 onLine DOM flag)(以及它关联的变化事件,ononline)在网络连接存在时,会自动向网页环境发送(激活)信号。
网络信息API(network-information API)解决发现网络特性的问题,它允许检测当前连接的大致带宽。
特性 | 规范 | 工作组 | 成熟度 | 稳定性 | 最新草案 | 当前实现情况 | 测试套件 |
HTTP(s)网络API HTTP(s) network API | 工作草案 | 依然在变化,但开始接近稳定 | 第1级部署广泛,第2级稳定增长
| ||||
跨域请求 Cross-domain requests | 最终提议 工作草案 | 稳定 | 部署稳定增长
| ||||
服务器推送请求 Server-pushed requests | 最终提议 工作草案 | 稳定 | 部署稳定增长
| 无 (?) | |||
推送API | N/A | 非常初步的草案 | 无 | N/A | |||
双向链接 Bidirectional connections | 最终提议 工作草案 | 稳定 | 部署稳定增长
| ||||
P2P数据链接 P2P data connections | WebRTC 1.0: 浏览器间的实时通信 | 工作草案 | 初期草案 | 无
| 无 | ||
在线状态 on-line state | HTML 工作组 | 工作草案 | 接近稳定 | 经常更新 | 部署有限
| 无 | |
网络特性 Network characteristics | 工作草案 | 初期草案 | 部署非常有限
| 无 |
10、通信和发现
除了和在线服务连接(的功能),用户与用户之间、设备与设备之间以及程序与程序之间的通信也是移动开发平台的一个重要方面。而要与未知的设备或先前存在的服务通信,一个发现组件非常重要。
消息传送API(Messaging API)完善了现有通过链接(如sms:,mms:,和mailto: URI方式)创建及发送消息的功能,并增加了附件管理、消息成功发送回馈等功能。当前,这套接口很可能会被基于Web Intents的新方法完全代替。
HTML5网页消息传送(Web Messaging)的postMessage API允许Web应用程序相互通信。
设备接口和网页应用工作组的联合工作已经开始,这项工作通过Web Intents的机制,开启了网页应用之间以及网页和原生应用之间更紧密集合的可能。
联网服务发现及消息传送API(Networked Service Discovery and Messaging API)提供了发现本地网络服务(如经由DLNA提供的服务)的功能,使Web应用程序能与这些服务无缝集成。
网页实时通信工作组(Web Real-Time Communications Working Group)涵盖了具有更多通信方法的规范:
· 跨设备的点对点链接,
· 允许用户之间实时交流的P2P音视频流
特性 | 规范 | 工作组 | 成熟度 | 稳定性 | 最新草案 | 当前实现情况 | 测试套件 |
带有生成附件的邮件,SMS和MMS Emails, SMS and MMS with generated attachments | 工作草案 | 计划用基于WebIntents的方法替代 | 无
| 无 | |||
应用内通信 Inter-app communications | 网页消息传送 | 工作组 | 候选推荐 | 稳定 | 部署情况非常好
| ||
应用内触发 Inter-app triggers | 工作草案 | 初期草案 | 实验性部署
| 无 | |||
联网服务发现 Networked services discovery | 工作草案 | 初期草案 | 无
| 无 | |||
P2P链接 P2P connections | WebRTC 1.0: 浏览器间的实时通信 | 工作草案 | 初期草案 | 无
| 无 | ||
P2P视、音频流 P2P Video/Audio streams |
11、封装打包
用户在应用体验的一个重要方面是用户感觉到应用随时可用(甚至是在断网的时候,这对移动设备尤其重要),还有应用应该能被发行和共享,甚至可以从应用商店里购买,而这可以通过打包应用很好地解决。
Web平台提供了两套互补的应用打包方案:
· HTML5的应用缓存(ApplicationCache)允许通过浏览器所需缓存文件的清单来支持离线访问Web应用。
· W3C小部件系列规范规定了以Zip文件发行Web应用程序的技术,其中包含了一个配置文件(请参考资料小部件打包及配置);这个配置文件允许添加额外的特性,如应用签名、高级API访问控制、网络使用限制等特性。除了作为客户端Web应用程序开发的辅助之外,W3C小部件还被用作服务器端应用、独立应用、守护进程、Web/Native混合程序入口以及浏览器扩展。
作为新规范的组成部分,Web App工作组正考虑基于JSON格式开发小部件配置文件的改进版,不过最新的讨论形成了对已提案的新系统应用工作组的依赖。
特性 | 规范 | 工作组 | 成熟度 | 稳定性 | 最新草案 | 当前实现情况 | 测试套件 |
应用缓存 Application Cache | HTML5 应用缓存 | 工作组 | 工作草案 | 依然在变化,但接近稳定 | 部署情况非常好
| 无 | |
小部件 Widgets | 推荐 | 完成 |
| ||||
提议推荐 | 完成 | ||||||
小部件访问请求办法(WARP) | 推荐 | 完成 | |||||
封装的网页 应用 Packaged Web App | 网页应用清单格式及管理API | N/A | N/A | N/A | N/A |
12、性能及优化
由于有限的CPU性能,以及电池方面苛刻的限制,移动设备对性能(能耗)有更高的要求。
由Web性能工作组在导航调度(Navigation Timing),资源调度(Resource Timing),以及最近的性能时间线(Performance Timeline)和用户调度(User Timing)上开展的工作,为Web开发人员提供了优化Web应用程序的工具。
已提议的有关快速事件响应(Efficient Script Yielding)的工作为Web开发人员提供了使用更高效的异步编程的可能。
检测网页页面是否显示的API(页面可视性API(Page Visibility API))也可用来根据Web应用程序的需要调节资源的使用,如在页面被最小化时,减少网络调用。类似的,脚本动画时钟控制API可以辅助减少播放动画需要的资源。
电池API(battery API)允许根据当前移动设备电池的电量级别来调节资源的使用。
除了资源的优化之外,应用对用户的响应也是移动用户检验的一个重要组成。通过Web Workers实现的类线程机制(thread-like mechanism)允许将对资源敏感的操作放到后台进程,以保证用户界面响应。
移动网页应用最佳实践(Mobile Web Application Best Practices)这份资料在涵盖了优化方面的需求的同时,提供了更多关于如何构建能在移动设备上良好运行的网页应用的建议。
特性 | 规范 | 工作组 | 成熟度 | 稳定性 | 最新草案 | 当前支持情况 | 测试套件 |
时钟操作 Timing hooks | 导航调度 | 提议推荐 | 接近完成 | 开始部署
| |||
资源调度 | 候选推荐 | 稳定 | 无
| 无 | |||
性能时间线 | 候选推荐 | 稳定 | 无
| 无 | |||
用户调度 | 候选推荐 | 稳定 | 无
| 无 | |||
优先级管理 Priority handling | 快速事件响应(Efficient Script Yielding) | N/A | Early draft | 部署非常有限
| 无 | ||
页面可视性 检测 Page Visibility detection | 候选推荐 | 稳定 | 部署非常有限
| ||||
动作优化 Animation optimization | 最终提议 工作草案 | 稳定 | 部署非常有限
| ||||
多线程 Threading | 候选推荐 | 稳定 | 部署稳定增长
| ||||
电池状态 Battery Status | 候选推荐 | 稳定 | 部署非常有限
| 无 | |||
调优最佳 实践 Optimization Best Practices | 移动网页最佳实践工作组(已解散) | 推荐 | 完成 | N/A | N/A | N/A |
原文地址:http://www.w3.org/Mobile/mobile-web-app-state/