2012年5月3日星期四

电子阅读器之争:The New iPad VS Kindle

  新一代 iPad 搭配的 Retina 显示屏使得其阅读体验有了很大的提升,同时可以作为电子阅读器的 New iPad 相比纯粹的电子阅读器 Kindle 又如何呢?

  我们都知道新一代 iPad 最大的卖点就是其搭配的分辨率为 2048*1536 的 Retina 显示屏,除了你知道的像素数量是 iPad 2 的 4 倍外,根据最具权威的独立影像品质测试机构 DisplayMate 评测,New iPad 的屏幕色彩饱和度也比 iPad 2 提升了 44%(色域达到了 sRGB 标准色域的 99%,几乎重合。作为对比,iPad 2 是 61%, iPhone 4 是 64%,MBA 低于60%),因此 DisplayMate 的结论是,新一代 iPad 的屏幕(显示质量、色彩精确度和灰度)不但比其它移动设备好的多,而且也比大多数的高清电视,显示器,笔记本屏幕都好得多。那么有着如此好屏幕的 New iPad 的阅读体验能否赶得上亚马逊的电子阅读器 Kindle 呢?那么新一代的 iPad 视网膜屏幕的显示效果的阅读体验是否更上一层楼呢,它与 Kindle 的电子墨水屏幕效果对比又是如何呢。

  其实 iPad 和 Kindle 是两个定位不同的产品,一个为采用 IPS 屏幕的平板电脑,阅读只是它部分功能。另一个是采用 E-Ink 电子墨水屏幕的纯粹电子阅读器。因此本文的对比多是从阅读体验上的一种评估。

  Retina 与 ppi

  众所周知 E-Ink 电子墨水的显示原理与印刷品一致,靠光线折射到纸张上的空白位置到眼睛中从而达到阅读的效果,因此有着媲美纸质书本的显示效果。那么搭配有 Retina 视网膜屏幕的全新 New iPad 的 264 ppi 像素密度已经触及人眼的极限,也已经达到了印刷级别,不少人甚至都已经惊呼新一代的 iPad Retina 将掀起阅读革命,那么对等同样是印刷级别的 Kindle 其阅读效果又如何呢? 在此之前我们需要先了解一下关于 ppi 和 Retina 。

  在数码时代,有个参数叫做 ppi(pixels per inch)用来描述每英寸所拥有的像素数目,它是屏幕分辨率的单位, ppi 值越高说明屏幕的显示细节就越丰富。当屏幕的 ppi 值达到 300 或以上的时候,人眼在正常观看距离下已经难以分辨单个像素,苹果在发布 iPhone 4 的时候将其称为 Retina Display,也就是我们所说的视网膜屏幕。

ppi-电子阅读器-新 iPad - Kindle-分辨率

  但实际情况并非如此,因为实际视觉效果上的锐利程度取决于角分辨率,而不是屏幕本身的线性分辨率,因此需要考虑角距和视距的因素,综合考虑上这些因素后最终大致参数如下表所示(因不同设备和不同用户有着不同习惯,部分值为估值),这也是新一代 iPad 的屏幕 ppi 值仅为 264 也被称为视网膜屏幕的原因。(注:Kindle 采用的是 E-Ink 屏幕,因此其相应的标准并不遵循 ISP 屏幕的计算方式)

 
 
iPhone 3 GS
 iPhone 4
 iPad 2
New iPad
Kindle 3
14 寸笔记本
 
分辨率
 480x320
980x640
1024×768
2048 x 1536
800x600
 1440x900
 
正常视距
11-12
11-12
 15-16
15-16
15-16 
22-25
 
ppi
164 
326
 132 
264 
167
90-102
 
Rentina 标准 
312
312 
240 
240
100-150
约 150 
 
是否 Rentina
 否
 是
 

   

  New iPad 的 Retina 屏幕带来了什么?

  在新一代 iPad 的 9.7 英寸的屏幕空间内,其像素数量达到了 310 万,甚至比 HDTV(超高清电视) 甚至还多 100 万像素。这些像素非常密集,人眼在正常观看距离下已经难以分辨单个像素。 当你无法看到像素颗粒时,就会看清整张图片、整篇文章或是整个游戏画面。

  对于字体:

  Retina 屏幕使原来的文字显示更加清晰明锐,充分释放出了苹果一直以来的字体渲染技术。从最开始,苹果对于字体的渲染就一直保持独树一帜。如果同时对比 Windows 系统 和苹果系统(Mac & iOS)的字体的话,你就会发现苹果的字体给人一种毛茸茸的感觉,边界不是很清晰。这其是因为它的渲染算法更忠实于字体的原始设计,在高清晰度状态下能够像印刷品那样呈现出字体设计的细微差别,这样在屏幕上呈现的结果与印刷品更加接近。(对于这一点相信用过 MacType 的 Windows 用户会深有感触)但是一直以来,低 ppi 在一定程度上限制了其字体渲染的效果,这次 Retina 屏幕的出现使得系统的字体渲染效果比以前要更好。

iPad 2 vs The New iPad

  此外高清屏幕也使得之前受限于低 ppi 的衬线字体可以在一定程度上缓解长时间注视背光 IPS 屏幕带来的眼睛疲劳问题。

  对于图像:

  Retina 显示屏对于图像的提升更是无容置疑的了,除了显示更加细腻外,其色彩还原也几乎达到了移动设备的最高水平。

  综合:

  无论对于文字、图像甚至视频都在新 iPad 的 Retina 视网膜屏幕上得到了很大的提升,这也意味着另一个阅读场景-网页浏览的体验也变得更好。之前在 iPad 和 iPad 2 的屏幕看网页文字的时候有明显的像素颗粒, 小号字体无法清晰显示导致需要来回缩放。而在新一代的 iPad 视网膜屏幕下能够锐利地显示网页上的小号字体,使得网页阅读的效果几乎得到很大改观。此外对于像 iDaily、摄影画报等这样的图文应用来说体验更是极佳。可以说在展示多媒体和多彩内容方面,新 iPad 要远远超过采用电子墨水( E-ink )技术的亚马逊阅读器 Kindle。

  The New iPad vs Kindle Touch

 
 
Kindle (Touch)
3rd Gen iPad
像素密度
167 ppi
264 ppi
色彩
16 阶灰度
99% sRGB 覆盖
字体渲染
天然字体平滑、反锯齿
子像素渲染
屏幕
6寸
9.7寸
重量
213 克
680 克
亮度
反射显示
421 坎德拉/平方米
可视角度
180 度
与 iPad 2 一致
对中文支持
较差(见备注1)
较好
电池续航(WIFI 开启)
约 3 周
约 10 小时
阅读场景(见备注2)
室外
室内

  Kindle 因为采用的是不同的于 IPS 背光技术的 E-Ink 电子墨水屏幕,因此并不主打 ppi 。不过由于其具有的高对比度特性,字体边缘可以用灰度平滑来提升显示效果。其 16 阶灰度显示更是使其具备舒适的类纸质显示效果,无背光低反光,显示效果如纸质书籍般清晰柔和,在阳光下亦可清晰阅读,完全可以等同于印刷品。因此在文字阅读上即使升级为印刷级别的 Retina 屏幕的 New iPad 在阅读体验上依旧是无法超越同为印刷级别的 Kindle 。

  同时 E-Ink 黑白灰和低刷新特性,也使其仅支持图片和文字的浏览阅读,在网页浏览上甚至不支持有 Ajax 的页面。因此在文字阅读之外,Kindle 是无法与 iPad 相提并论的。Kindle 的专一性基本也限定了其单一性,也注定拥有这个需求的市场不会太大。最近调查报告显示,消费者对亚马逊 Kindle 设备的需求量正在下滑,这也一定程度上表示其市场正在逐渐达到饱和。

  如何选择?

  阅读分多种,如果你想找一个能够随时长时间阅读线装书的电子阅读器话,Kindle 无疑是最好的选择,因为虽然新 iPad 在文字阅读体验上有了很大提升,在长时间阅读方面依旧远没有 Kindle 更加舒适持久。但是,除此之外,只能选择 New iPad。其实对于大部分人来说这两者是互相补充的,无论是 Kindle 还是 New iPad 都值得你拥有。

  备注1:

  因为亚马逊的 Kindle 目前只在美国等主要以英语为主要语言的国家发售,因此默认对中文的支持不是很友好,在 Kindle 3 和之前甚至根本没有内置 CJK (中日韩统一表意文字),因此很多情况下中文都会成“□□□□”。此外 Kindle 中文显示一直采用的是无衬线字体,长时间阅读会造成眼睛疲劳,丧失部分 E-Ink 的优点,并且,默认的中文字体没有标准、粗体、斜体、粗斜体的区分,无论是标题还是正文还是注释,一律是同样的样式。还有一点需要注意的,因为中英文的不同,用户需要调整行距等才能获得较好的中文阅读体验。

  在 Kindle 4 / Touch 虽然不需要任何修改既可以正常显示中文,但是其默认简体中文字体依旧为为“MHeiGB18030C-Medium_E”(类似雅黑)无衬线字体,此外,默认情况下中文显示还会出现字体粗细不均的现象(源于中文字体和日文字体混杂显示导致的匹配错误)

  所以国内 Kindle 用户要想获得中文较好的阅读体验首要的事情就是修改字体(Front Hack),不过好在 Kindle 入华已经有望,相信之后 Kindle 对中文的支持将会比现在要好。

  备注2:

  我们知道液晶屏幕在阳光下效果往往惨不忍睹,那么最新的视网膜屏幕会不会表现得好一点呢?答案是否定的,新 iPad 依旧是“惨不忍睹”。

The New iPad vs Kindle Touch

  苹果正在想办法弥补 IPS 显示屏的这个缺点。据悉苹果已经申请 IPS 屏幕融合 E-ink 技术的专利,虽然最先的 The New iPad 没有用上,但是估计下一代将会用上。

  而对于 Kindle 来说,确实给人纸质般的阅读体验,但其 E-ink 屏幕也有的非常明显的不足,那就是它只能在明亮的地方观看,在光线暗的地方和晚上只能靠第三方光源,非常不便。

Kindle-Nest and Nook Touch

  不过 Barnes & Noble 的新版 Nook Simple Touch 已经解决了弱光源环境下 E-Ink 设备的阅读难题,其采用的是将 LED 灯和防眩光屏幕保护器结合在一起的 GlowLight 专利技术。The Verge 测评显示其非常均匀的发光媲美普通液晶显示屏,但光的强度要比背光柔和许多,并且没有明显的漏光现象。消息称之前亚马逊收购的光导技术厂商也持有此项技术,相信下一代 Kindle 很有可能也将搭配此项技术。

  无论是对于阅读场景、是否便携、阅读模式上,总体来说 Kindle 更适合室外阅读,iPad 更适合室内阅读。

  来源:GeekPark投稿,原文链接

2012年5月2日星期三

移动互联网真的进入了“拼爹”时代吗?

  年前有专家预测说移动互联网获得用户的成本将大大增加“获取成本远大于PC产品的成本”,“移动互联网进入“拼爹”时代,新用户获取成本将翻倍飙升,没背景没资源的草根创业基本没机会”,这让众多看好移动互联网机会的创业公司和从业者感到畏惧。难道移动互联网的秩序还是PC固定互联网时代的秩序吗?

  当时笔者就对“移动互联网用户获取成本远大于PC产品的成本”提出了异议,但没有展开说出自己的论据。现在把笔者的依据罗列一下,希望能够鼓励到正在移动互联网领域奋斗的PM们!

  一、移动终端会比PC多很多倍,这是显而易见的,目前尤其处在智能移动终端用户量的快速增长期;

  二、移动终端开机时间长,给企业发展新用户提供了更多时间窗口,也为用户使用服务提供了更多时间窗口(比如在界面上向用户展示广告的机会大大增加了);

  三、位置信息以及移动终端私隐性等特点带来固定互联网不具备的众多新业务类型;

  四、移动终端作为人类服务易得性很强的工具,会让固定互联网上的一些原有业务使用频率大大增加,产生质变, 比如VOIP和IM服务,成为移动VOIP和移动IM之后,用户使用频率将大增,这方面的趋势可能会吃掉全球电信运营商的很大一块业务,最终可能使“基础 电信业务沦为一种互联网增值服务”http://blog.sina.com.cn/s/blog_7aa21e010100tzlo.html

  五、在移动终端是人的工具的同时,人也成为移动终端的工具,即人成为移动终端的智能外设或者说是智能接口, 把外界的人、事、物转换为移动终端可以识别的数据输入到移动终端,通过人这个智能外设,终端和无处不在的人物和事件发生交互,并进行必要的处理,由此,移 动终端可能会对人类的生活方式产生重大影响,尤其是过去看来是线下的人事物,也能被移动互联网来进行处理了——这个意义非常重大。

  六、移动终端功能配备更加标准化,为移动互联网业务普适于终端创造了更好的条件,比如移动IM的voice message功能,在智能移动终端的audio标配下,更加容易开展(pc客户端开展voice message业务,就存在某些PC没有麦克风,甚至没有音箱而无法使用的问题)。

  移动互联网业务丰富,潜在用户量巨大,只要业务适合,用户获得成本会非常低。移动互联网业务大有可为!

  要提醒PM们的一句话是:移动互联网业务比固定互联网业务更容易发展用户,而不是更难,除非是你不顾移动终端的优势特点,仍以固定互联网的思路来设计产品

  以上浅见,与业者共勉!

  来源:投稿,作者:同淮,作者微博

2012年5月1日星期二

耗电量将成为4G智能手机的硬伤

  你最喜欢智能手机的哪方面呢?是迷你的外形?流畅的网络?高清显示屏?各种应用以及4G的网络?还是强大的云支持系统?又或者所有这些你都很喜欢?对我来说,我那个用了一年半的iPhone4手机有很多让我满意的地方,我喜欢它的iOS,屏幕,以及众多供我消磨时光的应用。

  但并不是iPhone4全部装配都令我满意,回顾每天的使用情况后,我发现它最大的好处在于,几乎随时随地我都可以用它做任何我想做的事情。而当一天结束,夜幕降临,手机电池开始发出“电量不足”的警告– 这时,“随时做我想做的事”这句话就有点讽刺了。

  很明显,即使智能手机拥有再多应用和功能,电池才是它致命的限制。如果手机没电了,神马都是浮云。

  本周由美国资讯公司 J.D. Power发布了2012年智能手机用户满意度调查报告,调查结果也表明手机电池是智能手机的使用瓶颈。该调查还显示,手机电池的耗电量是决定客户是否对手机满意的最重要因素之一。相比3G手机用户,4G手机的使用者就没那么开心了,因为4G手机耗电量更大从而缩短了手机使用时间。更重要的是,用过4G手机的用户会将电池耗电量作为是否继续购买同一品牌手机的决定性原因。如果你给你手机的电池打满分的话,很有可能下次你还会购买同一品牌的手机;相反的,你肯定会转向其他品牌。

  电池耗电量应该是智能手机制造商首要解决的问题,不然它将给制造商带来很大困扰,并影响未来几年后PC革命的发展。每年,除了电池,手机其他各项功能都趋于更新进步。这正是问题的症结所在–制造商们不停地给手机增加各种需要更强大支持(包括处理器,屏幕和网络)的新功能,而电池使用寿命却没有改变。

  4G LTE手机的出现将这个问题更加清晰地呈现在大家面前,如果你之前使用的是3G手机或非智能手机,当你换成4G手机时,你一定会发现两者电池耗电量的巨大差别。你要考虑的是,用更短的使用时间换来更强大的网络是否值得?J.D. Power的调查结果明显是否定的,而我也坚决支持他们的观点。如果我必须比往常提前一小时就给手机充电,以便能继续使用LTE,我宁愿继续用我的3G手机。

  几乎每个手机制造商都会说,手机电池问题的产生是因为他们没有遵循摩尔定律。电池这个古老发明是科学家们对化学物质进行优化组合的产物;而电池改良将是一个增值产业–正如Seth Fletcher在Bottled Lightning一书中所描述的超级电池,电力车,以及新兴的锂经济,行业的诸多革新将随着超级电池的发明而发生(但这些似乎都不可能发生)。

  智能手机电池使用寿命的改进主要由处理器和操作系统的节电科技来实现。但,这些功能本身能节约的电力也只有这么多,并不能完全解决问题。目前,制造商们似乎没法做出一款手机在满足高性能显示的情况下,同时保证手机电池使用时间。总有些东西需要被舍弃,而用户们并不想看到这个结果。

  那制造商们到底该怎么做呢?他们不可能放弃4G手机,每个人都想拥有更流畅的网络,即使手机电池使用时间很短。而手机制造商和运营商们也决心给用户提供更好的手机功能。John Gruber猜测如果电池问题没有解决,苹果可能放弃在新iPhone上增加LTE功能,我对此表示怀疑,在如此激烈的市场竞争下,苹果怎么可能去冒这个险呢?如果说最终会有一家制造商能成功解决电池问题,那一定是苹果。比起其他制造商,它投入了更多资金和精力在节约手机耗电的技术上。值得注意的是,具有LTE功能的新iPad的电池耗电量与iPad2相比并没有缩短。

  现在的问题是,苹果能否用更小的电池再创奇迹,而这也将是用户们十分乐见的。如果它做到了,那么它就实现了向LTE的成功过渡;如果失败,那么第六代iPhone不会比 4S好到哪去。

  随着时间的推移,LTE覆盖面扩大且4G手机芯片有所改进,新的网络应用或许将不再像现在这样耗电。而4G手机也会像3G手机一样在市场上经久不衰。但目前,电池问题仍未得到解决,J.D. Power的调查结果也说明电池使用时间太短是人们最不能忍受的。去年开始已经有人在研究这个问题,这就意味着在不久的将来,这个行业或许会有一个大的飞跃。

  不管是现有的手机制造商,还是博士学历的新兴创业者,只要解决了手机电池问题,他将得到巨大的回报。如今,电池已经是智能手机发展的瓶颈,希望不会再有其他问题的出现。

  英文原文:Pandodaily雷锋网编译

构建移动Web应用程序的技术堆栈

  编写web应用程序时,有很多的技术决策。笔者最近回来编写现代Web应用程序,并希望总结一些曾经在开发周期过程中做了记录零散的想法。这篇文章是关于一套对笔者最近开发的项目有帮助的框架。笔者重温了一些最重要的框架类型,其中每一个可以展开来写一篇文章。这并不是一个广泛的现有产品相比,只是一个笔者最近使用的部分技术。

  虽然笔者的重点是移动优先, 笔者认为,这套技术可以应用在一般的web应用程序。 笔者的决定和数据支持考虑了几个要求:

  • 基于JavaScript(CoffeeScript,Dart,绝对值得认真看看,但我想避免引起激进选择)
  • 必须在现代浏览器工作良好(IOS 5,Android 4)

  挑选一个MVC框架

  在本地UI的应用程序开发中模型视图控制器模式已经使用了几十年。其基本思路是分开表示层(用户界面,动画,输入)和数据层(存储,通讯,数据)。有其他类似的模式,如MVVM的(模型视图的ViewModel),但主要的想法是在展现和数据层之间有定义良好的分离,为了更干净的代码和长期的维护:

  有许多JavaScript模型视图控制器框架的产品。有一些如Backbone.jsSpine.js是用纯代码编写的,而其他像Knockout.jsAngular依靠DOM数据属性绑定。那些依赖HTML5数据DOM属性的分离视图和数据的MVC系统被认为是不对的。这不包括Knockout.js和Angular框架。 spine.js比 CoffeeScript更容易,根据我最初的要求排除了CoffeeScript。

  backbone.js比大多数框架更受欢迎(也许除JavaScriptMVC外,似乎像一个死的项目),还设有一个成长的开源社区。对于笔者的应用程序栈,笔者选择了Backbone.js。欲了解更多有关挑选一个MVC的信息,检出TodoMVC,它使用不同的MVC框架实现相同的Todo应用程序。还可以看到这个MVC框架的比较,它强烈赞成Ember.js,一个出现相对较晚的框架。笔者尚未有机会使用它,但它在我的清单上。

  选择一个模板引擎

  要在网络上建立一个严谨的应用程序,你不可避免地要建立大型的DOM树。如果使用JavaScript API来操作DOM,不如使用基于字符串的模板编写html来得更简单高效。JS模板已经逐步形成一个奇怪的约定,嵌入模板的内容到脚本标记内:<script id="my-template" type="text/my-template-language">... </script>。使用所有的模板引擎的基本做法是作为一个字符串来加载模板,构建模板参数,然后通过模板引擎模板和参数运行。

  backbone.js依赖于Underscore.js,它有一个有些局限的有详细语法的模板引擎。有其他可供选择,包括jQuery模板Handlebars.jsMustache.js和许多其他的。 jQuery模板已经被jQuery团队准备废弃了,所以我没有考虑这个选项。Mustache是一个跨语言的模板系统,具有简单和成熟的决定,以支持尽可能少的逻辑。事实上,在Mustache最复杂的构造是遍历一个对象数组的方式。 handlebars.js建于Mustache之上,加入一些不错的功能,如预编译模板和模板表达式。对于笔者而言,并不需要这些额外的功能,然后选择了笔者的模板平台Mustache.js。

  在一般情况下,笔者的印象是,现有的模板框架可比较的功能是很少的,因此决定在很大程度上是个人喜好的问题。

  选择一个CSS框架

  CSS框架是必不可少的工具,用来扩展CSS如变量等方便的功能集,创建分层的CSS选择器的方式,以及一些更先进的功能。这实质上是创建了一个新的语言:CSS的增强版本(姑且称之为它的CSS++)。为便于开发,一些框架在浏览器中实现了一个JavaScript的CSS+ +解释器,而一些其他框架让你监控一个CSS+ +文件,并每当有更改就编译它。所有的CSS框架应提供命令行工具来编译CSS++成CSS给开发。

  像模板语言一样,也有很多选择。笔者的选择是出于个人的语法偏好,笔者更喜欢SCSS,因为它避免了像@怪异的语法。 SCSS的一个缺点是,它并没有附带一个JavaScript解释器(有一个非官方的,笔者还没有试过),但可用命令行监视器。还有其他类似的CSS框架,包括LESSStylus

  如何布局视图Views

  HTML5提供了多种方式来布局内容,MVC框架对这些布局技术的使用无要求,留给开发者你一点困难。

  一般来说,对documents相对位置是合适的,但对apps除外。应避免绝对定位,像tables。许多Web开发人员已经转向使用float属性对准元素的,但是这只是第二理想的构建应用程序的观点,因为它没有类似应用程序的布局,导致许多奇怪的问题和臭名昭著的clearfix hacks

  经过多年来的布局与各种网络技术的实验,笔者认为一个固定的定位和flex box的模型相结合是移动互联网应用的理想选择。笔者使用的是将屏幕上的界面元素(页眉,侧边栏,页脚等)固定定位。flex box 模型对在页面上布局堆叠视图(Stacked views)是很棒的(水平或垂直的)。只有CSS盒模型明显地对界面设计进行了优化,非常类似Android的LinearLayout 管理器。对于有关flex box模型的更多信息,请阅读保罗的文章,并注意该规范正在由一个新的,非向后兼容的版本取代。

  自适应Web应用程序

  最后一节,在这个问题上:笔者大力提倡创建设备特定的用户界面。这意味着为不同的形式屏幕重新编写视图代码部分。幸运的是,MVC模式,使得它比较容易为多个视图(如平板电脑和手机)重用业务逻辑model。

  iOS Flipboard演示了这个想法很好,它为平板电脑和手机用户提供了为每个设备外形高度定制的体验。手机用户界面特别为垂直点击进行了优化,允许单手使用。平板的UI让两手反面持有设备工作良好。

  输入的考虑

  移动用户与您的应用程序进行交互的主要方式是通过用手指触摸屏幕。这与基于鼠标的互动相当不同,因为有额外9点在跟踪屏幕,这意味着开发人员编写移动应用程序时,需要抛弃移动鼠标事件。此外,在移动鼠标事件有300ms延迟点击的问题(有一个著名的触摸式的解决方法)。在移动浏览器使用这些事件的详细信息,请参阅我的触摸事件的文章

  只有S /mousedown/ touchstart/所有的事件处理程序是不够的。有 一套全新的用户期待的触摸设备手势,如点击、通过浏览图像列表导航。虽然苹果公司有一个鲜为人知的手势API,但没有在网页上做手势检测的开放规范。我们真的需要一个JavaScript手势检测库,去处理一些较常见的手势

  如何使其离线工作

  对于一个应用程序脱机工作,你需要确保两件事情真实:

  • Assets资产可用(通过AppCache,文件系统API等)
  • 数据是可用的(通过LocalStorage,WebSQL,IndexedDB等)

  实践中,在网络上建立离线应用是一个棘手的问题。一般来说脱机功能应从一开始就加入你的应用程序。让现有Web应用程序没有显着的重写代码运行在离线状态下是特别困难的。此外,脱机技术还有各种未知的存储限制,而且未知超出限制时会发生什么不确定的行为。最后,在离线的技术堆栈还有一些技术问题,最显着的是AppCache,正如我在以前的文章提到。

  写真正的离线功能的应用程序是一个非常有趣的方法是“离线优先”。换句话说,如果没有互联网连接全部写入本地,当存在互联网连接,实现同步数据同步层。在Backbone.js MVC模型,这可以很好地适应自定义Backbone.sync适配器。

  单元测试

  单元测试您的UI是有困难的。然而,因为你使用MVC的模型,它是完全隔离的UI和数据结果,因此,可方便测试。QUnit是一个相当不错的选择,特别是因为它允许使用它的start()和stop()方法单元测试异步代码。

  总结

  总之,笔者使用Backbone.js 作为 MVC 框架,Mustache.js做为模板,SCSS作为CSS框架,CSS的Flex box展现界面views,自定义触摸事件和QUnit单元测试工具,来写笔者的移动Web应用程序。脱机支持,笔者仍然尝试用各种技术,并希望未来继续写篇文章。虽然笔者强烈相信有必要在这里列出每种工具(如MVC),笔者也相信,笔者在这里描述的许多具体的技术是可以互换的(如Handlebars 和 Mustache)。

  还有一件事:2012年1月17日,Thorax宣布发布。这是一个基于Backbone一套开发库,非常类似我在这篇文章里描述的思想。笔者还没有在任何深度研究,但名称是伟大的:)

  使用一套类似的框架吗?有你最喜欢的?觉得笔者缺少一个重要的框架吗?让笔者知道!

  来源:英文原文,中文编译:IT瘾

2012年4月30日星期一

社交网络营销的最佳时间点

  随着社交网络在人们生活占据的时间越来越大,商家们已经开始尝试用各种手段在社交网络上推广自己的产品。内容有趣固然重要,营销的时间如果选的正确,则可以让你的内容获得最大程度的曝光,事半功倍。

  邮件营销

  我们还是先从最传统的邮件营销说起,一周7天,一天24小时里,哪天,那个时间段是人们打开邮件的高峰期呢?请看图:

每天邮件营销的最佳时间点

每周邮件营销的最佳时间点

pic via: sign-up.to

  从打开邮件的数量来看,可以说明邮件营销的黄金时间是周二至周四,10:00 – 17:00。不过这个调查的受众人群是英国人,可能和国人还有一些差别,但我相信人类的行为方面还是具有有一致性的。

  博客

  人们又习惯在什么时候阅读博客呢:

阅读博客的时间点

  答案是早上,博主最喜欢的事情之一就是吃着早餐,打开Google Reader看自己喜欢的博客。

  Facebook

  Facebook营销的最佳时间是上午和晚上,大约是7:00 – 12:00以及19:00 – 21:00点

Facebook营销的时间点

  调查还显示,大家在周五至周日间会更容易参与社交的活动。不过博主认为,国内的新浪微博等社交网络还是工作日的中午最为活跃。

  Twitter

  Twitter营销的最佳时间是12:00 – 20:00点,周三至周五。

每天twitter营销的最佳时间点

每周twitter营销的最佳时间点

  移动营销

  智能手机用户使用手机频率最高的时间点是12:00 – 20:00之间,所以在这个时间段做移动营销的效果可能最好。

移动营销的最佳时间点

  来源:读者投稿,原文链接

手机浏览器HTML5支持情况调查

  最近过去的几个月中,手机浏览器领域的口水战不断,UC、海豚、欧朋、腾讯都或多或少的卷入了些许。抛开是非不谈,他们共同关注的一个非常重要的领域就是对HTML5的跑分支持。

  前端时间Facebook的移动开发者关系部门主管Pearce也向TechCrunch表示,只有移动浏览器的进步才能带动HTML5应用的发展,苹果和谷歌在浏览器对HTML5应用的支持上做的还不够。那么我们就来看看现在中国市场的手机浏览器对HTML5的支持情况吧。

  正如笔者年初在一篇文章中提到的,目前对浏览器HTML5兼容性测试做的最好的是html5test.com.浏览器在这个网站上取得的得分越高说明对HTML5的支持越好。这个网站最近一次升级是在2012年4月2日,目前的满分是500分。(感觉我好像总是在给这个网站的升级做广告。)

  整体情况

HTML5跑分
UC浏览器
欧朋HD
百度手机浏览器
海豚浏览器
Q立方浏览器
天天浏览器T9体验版
Android 2.3
321+8
369+11
189+1 / 317+3*
189+1
271+1
224+13
Android 4.0
338+8
367+11
275+3 / 317+3 *
275+3 / 364+10 *
不支持
不支持

  在测试的过程中发现,只有UC和欧朋是支持Android 4.0的系统的,天天和QQ在Android 4.0仍然是跑不起来。而今年新进加入HTML5跑分争夺的百度和海豚都采取了偷巧的方式,用户需另外再下载一个内核才能获得更好的支持体验,用户体验上还是差了不少。

  从总跑分来看,欧朋的HTML5跑分最高,使用了最新版的Presto内核。其次是UC,新做的这个U3内核相当有冲击力,短短三个月就将跑分提高了近一百分。百度的表现也不错,突破了300分。海豚在4.0上虽然能跑出364的高分,但是还不支持2.3,有不小的硬伤。而去年年底炒的风生水起的Q立方和天天都没有再发过新版,跑分变动完全是因为html5test网站升级带来的。

  从市场份额看,UC浏览器是已经公开发布的正式版产品,据UC的公开数据,已经有超过5千万Android平台的用户在使用。欧朋HD在这个月刚刚去掉了后面的beta标识开始正式向市场推广,不过依据Opera的行事风格,市场份额还有待观察,但是应该不错。百度手机浏览器在2月份发布正式版之后,已经开始发力做一些市场推广活动,似乎也是百度无线开放平台的重要一环。海豚的自有内核目前只能在Android4.0平台上运行,而现在装载4.0系统的手机份额大约只有3%,市场空间可能还很小。

  跑分细节

  上面看的是总分,接下来让我们看一下这几款浏览器在html5test.com上各个项目的跑分情况:

手机浏览器HTML5支持情况调查

  从各项上看,各大浏览器对canvas、video、Location and Orientation等基础项目支持的都已经不错了,但是在一些项目上有不小的差异。

  比如可以为绘图提供硬件加速的WebGL项目上面,目前只有UC、欧朋和天天能支持的较好,这个会是游戏类应用比较关注的点。

  在Communication项目上,各家的支持程度也不尽相同,UC和海豚都已经做到了支持WebSocket,其他家的支持还有待提高。

  在Local multimedia项目上,目前只有UC和欧朋可以做到支持调用本地的多媒体设备接口。

  在Form项目上,欧朋依然保持着领先的势头,拥有超过100分的跑分,不愧是语义化的倡导者。

  后记

  随着各家浏览器对HTML5支持度的提升,对基于HTML5应用的兼容性和稳定性都有了一定的优化。一些对性能要求略高的应用,比如2011 Google I/O时播放的倒计时demo,用UC、百度、海豚打开都能够获得流畅的体验。

  而从开发者角度,越来越多的人开始了解并接受Web应用也能够在移动平台上大展身手。在近期HTML5小组的Code jam上的作品水平也是越来越高,不少作品已经可以在做一些稳定性优化之后都是可以拿出来当做商业产品发布的。现在阿里云、盛大、新浪、百度都在搭建云服务平台,供开发者使用,其中也涌现出一些优秀Web App RAD工具。

  不错的浏览器支持环境已经有了,良好的开发者支持体系也出现了,HTML5应用的爆发,可能就在一触之间。或许,就是明天。

  来源:读者投稿

2012年4月26日星期四

实测Dropbox和Google Drive上传速度对比

  随着Dropbox的走红,微软Google都推出了云存储软件,这些云存储软件在美国等网络环境下是非常快的,但是在中国的网络环境下,究竟哪个软件的速度最快呢,我这里做了一个测试,实地比较一下Dropbox和Google Drive在中国网络环境下的上传速度。

  整个测试思路和早先我测试Dropbox和SugarSync的一样,测试环境是,中国电信的100M共享宽带,在同一台Windows电脑上安装运行这两个软件(Dropbox和Google Drive客户端),不设置代理,不设置VPN。同步同一个文件夹,文件夹内共有191张个人拍摄照片,292M容量,保证全部是新内容上传,测试两个工具的实际上传同步速度。

  在软件配置上,在Dropbox的上传控制中,选择“不限制上传速度”,Google Drive客户端并没有上传速度设置,因此默认设置,由于Google Drive客户端在正常网络环境下是被屏蔽的,因此在hosts文件中,增加了一条drive.google.com的IP数据,该IP使用的是北京的一个IP地址。

实测Dropbox和Google Drive上传速度对比

  我从11点10开始测试,将191个文件(293M大小)复制到指定的同步目录下,本以为要测试很长时间,但结果令人惊讶。

  Google Drive在修改了Google的Hosts情况下,上传速度惊人,在不到10分钟的时间内,就上传完全部292M文件,而此时此刻,Dropbox的上传进度还没有进行到20%,两者上传速度相差非常悬殊,Google Drive的上传速度完胜Dropbox。

  Google Drive的上传速度这么快,完全出乎了我的意料,我估计这里面的主要原因有:

  1、和中国的Hosts设置有关,走国内网络速度加快。

  2、Google Drive目前用户量少,而Dropbox用户量庞大,因此导致速度有较大差距。

  3、Dropbox用的是Amazon的云存储,其服务器数量以及存储技术和Google有一定差距。

  总的来看,Google Drive的确是Dropbox强有力的一个竞争对手,不过其容量只有5G还是比较少,目前我的免费Dropbox已经有19G的空间,如果Google Drive的免费空间也能达到这个数字,相信会有很多用户会从Dropbox转到Google Drive的。