1. 为什么要使用HTML5开发?
1.1 apk 的特点
1.1.1 能够调用系统硬件,能够或得系统分配的更多的资源。
http://www.blaze.io/mobile/ios5-top10-performance-changes/
这个网页里面有提到,JavaScript Performance 和 Rendering Performance 的一些数据,网页上也指出了JavaScript Performance browser,home screen , uiwebview 中性能的区别:
OS/BROWSER MOBILESAFARI HOME SCREEN PAGES UIWEBVIEW
iOS 4 4052 10528 10044
iOS 5 3574 4551 12101
The test measures duration, so lower numbers are better。
也就是说分数越低,越好,可见中间也是有差别的。
能够调用系统的硬件资源:
可以调用本地应用,当然通过对方的一定支持,网页也能实现,不多比较麻烦而已。
可以调用摄像头,可以访问本地文件,这个在Android上不存在这个问题,但是IOS存在这个问题,他有严格的sandbox 模型。Android 系统部存在这个问题,而且chrome beta for android 将会让这个操作更加简单(filesystem)
可以使用系统的默认信息,比如系统版本,IMEI等,用户信息,网页就不行了,不能使用,系统的版本信息可以从UA里面或得,但是IMEI和一些更底层的信息就不行了。
缺点只有一个,得开发多套差别很大的程序,现在来看,至少三套:ios ,android,触屏。
有这个问题,就会引起很多其他的问题,比如,更细不方便,测试页麻烦,比如一个新功能,就需要开发三套东西。
1.2 HTML5 特点
主要特点就是:
1.2.1 css3 的布局非常方便,布局整个页面比较容易。
1.2.2 开发成本比较低,开发一套代码,可以适应不同系统
1.2.3 JavaScript 的性能高于本地应用
主要的缺点:
1.2.4 不能很好的调用系统硬件和用户信息。
1.2.5 用户的使用不便捷,没有快捷方式。
1.2.6 浏览器的分辨率适配,还有操作系统的适配,也并不是一件十分容易的事情。
2. 未来的发展道路
2.1 本地应用内嵌网页,也就是使用UIWebView。
但是这个存在一个开发模式,和交互程度的问题。
Facebook 通过了一些技术,实现了browser ,home screen ,UIWebView 同样的效果和UI展示,但是他也作出很多的研究,内部应该是使用了同一套mustache 的模板,实现的,他为了这个业务,写了这么一个模板语言来做这个事情。它这样的做法,有自己的时代特性所决定的,可能并不是未来的最优选择。
2.2 home screen 的模式
这种模式,现在看起来,前途并不明朗,这需要用户主动添加到主屏,而且只有IOS做的很好,Android就做的一塌糊涂,操作很麻烦,而且体验很差劲。而且android 自身的浏览器选择框,本身就是一个让开发头疼的问题(要适配很多第三方的浏览器)。而且没有全屏的体验。
这种模式还有一个问题,就是用户没办法主动退出,这也是个不大不小的问题。
这种模式同样存在不能调用系统硬件和用户信息的问题。
2.3 网页的模式
这种模式只能是提供给用户一个快速浏览信息的功能,用户也只能通过保存书签等方式来保存网页,所以体验不好啊。
2.4 HTML5 应该做什么
2.4.1 加强缓存,提升性能
2.4.1.1 使用appCache 缓存静态文件
2.4.1.2 使用模板语言,不刷新页面,并加强History的管理。
2.4.1.3 使用 sqlite和indexedDB 使用本地存储,缓存数据,加快网页的响应速度。
2.4.1.4 区分使用 cookie sessionStorage localStorage sqlite 和 indexedDB,不同的存储,对应的性能消耗不同。
Cookie 对应的是网络请求的请求量的性能消耗。
Dom Storage 对应的会增加网页的解析加载时间,也会增加内存消耗。
WebSqlDataBase 对应的是,请求速度会比较慢,但是对于内存的消耗会小一些,毕竟是个异步的过程。
2.4.1.5 调整脚本的加载和执行时机,不同作用的脚本,会放在不同的位置,twitter 的js 就放在了Header里面,所以面对WebAPP时候,js 存放的位置,并不是按照常理的。
2.4.1.6 调整脚本的内容,大量使用WebWorker ,减少对于UIthread 的消耗,尽可能多的使用后台运行,更多使用setTimeout(),提高用户的响应速度。
2.4.1.7 大量使用CSS3 的内容,在样式中不使用图片,并把DOM的数量减少到最少。
2.4.1.8 大量使用字体和SVG,减少图片的适配问题。
2.4.1.9 写css 文件时,多使用media 标签,增强用户体验。Link 标签的Media属性,和写在CSS文件里面,没有大的区别。
1.1 apk 的特点
1.1.1 能够调用系统硬件,能够或得系统分配的更多的资源。
http://www.blaze.io/mobile/ios5-top10-performance-changes/
这个网页里面有提到,JavaScript Performance 和 Rendering Performance 的一些数据,网页上也指出了JavaScript Performance browser,home screen , uiwebview 中性能的区别:
OS/BROWSER MOBILESAFARI HOME SCREEN PAGES UIWEBVIEW
iOS 4 4052 10528 10044
iOS 5 3574 4551 12101
The test measures duration, so lower numbers are better。
也就是说分数越低,越好,可见中间也是有差别的。
能够调用系统的硬件资源:
可以调用本地应用,当然通过对方的一定支持,网页也能实现,不多比较麻烦而已。
可以调用摄像头,可以访问本地文件,这个在Android上不存在这个问题,但是IOS存在这个问题,他有严格的sandbox 模型。Android 系统部存在这个问题,而且chrome beta for android 将会让这个操作更加简单(filesystem)
可以使用系统的默认信息,比如系统版本,IMEI等,用户信息,网页就不行了,不能使用,系统的版本信息可以从UA里面或得,但是IMEI和一些更底层的信息就不行了。
缺点只有一个,得开发多套差别很大的程序,现在来看,至少三套:ios ,android,触屏。
有这个问题,就会引起很多其他的问题,比如,更细不方便,测试页麻烦,比如一个新功能,就需要开发三套东西。
1.2 HTML5 特点
主要特点就是:
1.2.1 css3 的布局非常方便,布局整个页面比较容易。
1.2.2 开发成本比较低,开发一套代码,可以适应不同系统
1.2.3 JavaScript 的性能高于本地应用
主要的缺点:
1.2.4 不能很好的调用系统硬件和用户信息。
1.2.5 用户的使用不便捷,没有快捷方式。
1.2.6 浏览器的分辨率适配,还有操作系统的适配,也并不是一件十分容易的事情。
2. 未来的发展道路
2.1 本地应用内嵌网页,也就是使用UIWebView。
但是这个存在一个开发模式,和交互程度的问题。
Facebook 通过了一些技术,实现了browser ,home screen ,UIWebView 同样的效果和UI展示,但是他也作出很多的研究,内部应该是使用了同一套mustache 的模板,实现的,他为了这个业务,写了这么一个模板语言来做这个事情。它这样的做法,有自己的时代特性所决定的,可能并不是未来的最优选择。
2.2 home screen 的模式
这种模式,现在看起来,前途并不明朗,这需要用户主动添加到主屏,而且只有IOS做的很好,Android就做的一塌糊涂,操作很麻烦,而且体验很差劲。而且android 自身的浏览器选择框,本身就是一个让开发头疼的问题(要适配很多第三方的浏览器)。而且没有全屏的体验。
这种模式还有一个问题,就是用户没办法主动退出,这也是个不大不小的问题。
这种模式同样存在不能调用系统硬件和用户信息的问题。
2.3 网页的模式
这种模式只能是提供给用户一个快速浏览信息的功能,用户也只能通过保存书签等方式来保存网页,所以体验不好啊。
2.4 HTML5 应该做什么
2.4.1 加强缓存,提升性能
2.4.1.1 使用appCache 缓存静态文件
2.4.1.2 使用模板语言,不刷新页面,并加强History的管理。
2.4.1.3 使用 sqlite和indexedDB 使用本地存储,缓存数据,加快网页的响应速度。
2.4.1.4 区分使用 cookie sessionStorage localStorage sqlite 和 indexedDB,不同的存储,对应的性能消耗不同。
Cookie 对应的是网络请求的请求量的性能消耗。
Dom Storage 对应的会增加网页的解析加载时间,也会增加内存消耗。
WebSqlDataBase 对应的是,请求速度会比较慢,但是对于内存的消耗会小一些,毕竟是个异步的过程。
2.4.1.5 调整脚本的加载和执行时机,不同作用的脚本,会放在不同的位置,twitter 的js 就放在了Header里面,所以面对WebAPP时候,js 存放的位置,并不是按照常理的。
2.4.1.6 调整脚本的内容,大量使用WebWorker ,减少对于UIthread 的消耗,尽可能多的使用后台运行,更多使用setTimeout(),提高用户的响应速度。
2.4.1.7 大量使用CSS3 的内容,在样式中不使用图片,并把DOM的数量减少到最少。
2.4.1.8 大量使用字体和SVG,减少图片的适配问题。
2.4.1.9 写css 文件时,多使用media 标签,增强用户体验。Link 标签的Media属性,和写在CSS文件里面,没有大的区别。