Lyric.im

上周有用户向我反应，他们已经在 Chrome Web Store 中发现了测试中的 Hotot 3。然后我才发现，Google 已经开始在 Web Store 中上线 new Packaged App了。只不过只在 Chrome Dev Channel for Windows 和 Chrome OS 中是可见的。

在新版的 Web Store 中，所有的之前的被称为网站快捷方式 Chrome App 都被移到了 「Website」 这一标签下（1.0 版的 Hotot 也被移到这里），而 「App」 标签下仅包含 new packaged app。

这个现象表达了 Google 的态度，我想也就是他们的战略，即 Chrome 是未来。长期在 Chrome 的生态中开发，我之前已经多次对 Chrome 表达了赞美之情，人们最初认为 Chrome OS 是一个没了网络就啥都不能干的系统的看法是完全错误的。我想说的是 Chrome OS 实际上是一个增强版的 iOS，在诸多方面，Chrome/Chrome OS 都与名声赫然的 iOS 有很高的相似之处，本质上，new Package App 就是 Chrome/Chrome OS 上的 Native App。当然，作为一个「增强版 iOS」，Chrome OS 拥有一些在 iOS 上被翘首企盼但是还没有的特性。

考虑到 Chrome OS 和 Chrome 浏览器的一致性，下文如未特殊说明，统一用 Chrome 指代 Chrome 浏览器和 Chrome OS，用 App 指代 iOS 中的 App 和 Chrome 的 new Packaged App

一致的 App 范式

在 iOS 中，每个 App 都运行与独立的沙盒中，App 的数据不得直接进行交互，也没有全局的文件系统访问能力。在 Chrome 中也有类似的机制。下图分别描述了在 iOS 上的 App 和 Chrome 上的 App 与网络服务交互的方式。

可以看出，Chrome 中 fileSystem 和 storage.local 相当于 iOS 中 App 的沙盒文件系统；syncFileSystem 和 storage.sync 则负责同步到 Google Cloud （也就是 Google Drive），与 iCloud 类似。

在这个模式上，Chrome 值得一提，即只要在 Chrome 中登录过账户，那么所有使用 syncFileSystem 和 storage.sync API 的 App 数据都会无缝地同步到 Google Drive，而无需额外授权。

两者有类似的通知机制

在 iOS 中，由于 App 没有后台运行的能力，因此需要 App Notification Push 来接收更新。而在 Chrome 中也有类似的能力，那就是 Google Cloud Messaging。GCM 不但提供 Android 设备的通知，也提供 Chrome 设备的通知。

一个折衷的后台进程

准确地说，Chrome 中没有 Daemon。取而代之的是 event page。这是一个基于事件的 App 控制方式。官方希望通过 API 引导开发者去保存 App 的状态，而不是一个持续运作的后台进程。

更好的进程间通讯机制

iOS 的进程间通讯机制一直被开发者诟病，需要将 URI 硬编码到 App 中才能实现那么一丁点交互能力，更别提各个 App 分开授权对体验的破坏了。

在 Chrome 中则有一套消息机制，这套消息机制可以作用于 App 内部，也可以作用于整个 Chrome，用于多个 App 之间的通讯。

最后

作为新一代 OS，Chrome OS 没有 OS X 和 Windows 在设计上所背负的历史包袱，因此可以有机会像 iOS 一样轻装前行。我很高兴看到 Chrome 走在正确的道路上。

前段时间 forecast.io 家的 App 挺火挺热（请用 iPhone Safari 打开链接 http://forecast.io，然后添加到桌面看看效果 ）。接着官方博客释出了一篇文章，可以认为是当前 Mobile Web App 开发的最佳实践，我先总结一下：

1. 不要刻意模仿 iOS 的默认样式和交互。毕竟是 Web App，肯定会有模仿不到位的地方，这样会很快露出马脚；用自己的风格和交互则不会有这样的问题，没有参照物也就不容易察觉错误，容易糊弄过去。
2. 不要做得像个网站。
3. 只用硬件加速的 CSS 3 属性做动画效果。说白了，只使用 translate3d 系属性，而且使用 transition 时也不可以应用到没有硬件加速的属性上。
4. 不要自己实现滚动条。使用 -webkit-overflow-scrolling: touch 而不是采用类似 iScroll 这样的东西。
5. Web 技术上还做不好的事情就别JB做。
6. 用 FastClick 和 AppCache 提升用户体验。
7. 吃自己狗粮。

看到第 3 点没？其实现在做 Web App 门槛挺高，应付奇葩的 Javascript 实现所导致奇葩范式还算好，关键在于面对这么一坨从 Web 诞生至今延续下来的开发环境。换言之，假如现在微软释出一套大一统 SDK，包含从 MS DOS 到 .Net 4 的所有 API，会好学到哭么。奇迹，但是 W3C 做到了。

另外在 Chrome Dev Tools 里打开 Show paint rectangles 和 Show composited layer borders 选项就能直观地看到浏览器是怎么渲染你的 Web App 的。对于观察硬件加速的优化效果来说很有帮助。

言归正传，对于第 4 点，可能对 Mobile Web App 更适用。桌面 Web App 使用大数据的动态列表还是用 iScroll 这样的实现吧，效果比原生滚动强不是一点半点。

接下来几点是我总结的，面向基于 Angular.js 框架的大型 Web App 的优化实践，不过我想某些点对别的框架也适用。

1. 不要写…大型… Web App …（有气无力）
2. Model 的观察者要小要短.
3. 高频事件（例如 WebSocket ）的回调函数中需要对 View 进行修改的，用 throttle 控制事件频度。
4. 一个页面中不要超过 2000 条 Angular 表达式。
5. Angular.js 使用 dirty check 实现数据绑定，因此在 digest cycle 中尽量减少深度比较，仅仅包含会导致 View 变化的操作。
6. 除非万不得已，不要操作 DOM。
7. 局部性原理：操作 DOM 的语句尽可能连续地放在一起。
8. 多条语句连续地操作 DOM 时，用 setTimeout 分割它们可以得到明显效果。
9. 不要滥用 setTimeout。
10. 程序很慢，但是人类更慢。除非有明显的性能问题，否则不要过度优化（例如使用以上优化方式），只会搞得更糟。

不过话说回来，总算看到了 Web App 的一线曙光，其诸多优势让人没法忽视。所以先从 Hybird App 开始吧。别说你讨厌 Hybird App，其实它早就潜入我们身旁你都不一定感觉得到。例如 Tweetbot（最初的 OS X 版），SpeedTao 还有 …… 微信。其实吧，说不喜欢的，只不过是技术性偏执罢了。

经过在叽喳上的简单调研，做 PRD 的各种图时，除了海量的 Axure 派系，还有 PPT 派系、 Keynote 派系、OmniGraffle 派系、Photoshop 派系、Fireworks 派系、Balsamiq 派系、Evolus Pencil 派系、基本靠代码派系、基本靠纸折派系、基本靠手画派系等海量的各类派系。

不过很难理解啊，作为一个致力于创造更好的产品的职业，居然有那么多从业者依赖 Axure 这样既难用又丑陋的行业软件，这是一种很不科学的现象……似乎大部分的PM都是坚忍的PM，因为他们都喜爱这款与「易用」两字完全不沾边的 Axure。

但是Neo老师安慰我说：

@ilrcat 我觉得对产品有美学追求的人都忍不了那货…

于是我释然了。

OmniGraffle 我觉得特遗憾，因为如果伊能像 Axure 那样导出所有 canvas，并且能自动处理事件，我会很爱它的。话说回来，目前所有的绘图工具，其连线操作的便捷性没有一个能比得上 yEd 的，是我的习惯太变态么。

被评论说文章写得太技术看不懂，今天先说非技术部分。

首先，对用户的影响：

• 这一改进主要在技术层次上，会使得Chrome和Chromium更高更快更强。
• Google以后会拿出一整套和微软直接抗衡的解决方案。

看，非技术的部分两句话说完了，也就是整个分析的结论。作为一个风水师，我发现通过技术变迁来给产品的战略看风水也是蛮有趣的。

然后是技术部分，换引擎的理由倒是很显然：

• 因为Webkit性能不够
• 因为不适合Chromium/Chrome的多进程架构
• 清晰的codebase有利于以后Chromium的发展

对生态圈的影响：

• Google的目标就是让Web更快。
  1. 最初是觉得浏览器都太烂于是坑了Mozilla，出了Chrome
  2. 其次是觉得Javascript的VM太慢，所以出了V8引擎
  3. 然后觉得V8还是不给力啊，本质上还是Javascript太渣了，搞个Dart语言看看；
  4. 之后Google发现好像是ISP跟不上我们的脚步了，于是开始给用户铺光纤
  5. 觉得HTTP太低效了于是推出SPDY…
  6. 实验性的Chrome OS和Chromebook
  7. 攻击性很强的新Chrome App API发布
  8. 再到今天的Blink代替Webkit
• 总之就是要让网速不是障碍，让网络服务速度不是障碍，最后让Web App速度赶上本地App，然后就可以正面开战了。
• 所有这一切都被称为「Google的野望」，大概描述了一个屌丝青年Google：先小敲小打地重新做轮子，大家都觉得伊是个大好人；然后放一块儿就构建自己的生态系统；最后在眼皮底下干翻以微软为首的老一辈革命家的全景。
• 嗯，在攻击性很强的new Chrome App API的加持下，Web App能做的事情已经非常多，类似一个本地程序了，大家快来一改现在Chrome App渣一样的局面。

对开发者的影响：

• 对Angular.js这样的JS框架是利好消息，对所有的Web App来说也是利好消息，因为目前对新引擎的野望中，有3项的改进会让DOM操作变得更快，并且明确说明会重写整个webkit的DOM实现。考虑到现在DOM操作速度如此之慢，已经是Web App发展的瓶颈了，Google拿它开刀是理所当然。
  1. 提升DOM 3 Event和UI Event的性能
  2. 解决目前Webkit对DOM的向后兼容性所导致的性能问题
  3. DOM移到Javascript heap
• 对前端工程师来说不需要太担心，
  1. Blink fork 自 Webkit，以后也会兼容已经成为标准的-webkit-*私有特性。
  2. Chromium 团队渐进性更新很靠谱。
  3. 考虑到Google的操性，如果要往Chromium/Chrome加私货，一定会加到Chrome App和Chrome extension里；如果实在要往通用web里加，一定会先折腾成标准或者至少是标准草案，然后自己先拿出实现来；因此不会形成IE里的ActiveX那种东西。

大约在6年前离开了博客托管商，开始建设独立博客。初衷之一是我认为有必要对自己写的文章保持控制力，而不能寄期望于任何BSP。

去年因为Cache（Cash）的缘故，我用 Tattoo 代替 Wordpress 。初衷之一是我认为有必要对自己文章的评论保持控制力，而不能寄期望于Disqus（现在看来是过于苛刻了）

今天JB Google 宣布了自家 Reader 的死期 再一次印证了我的看法：任何时候都应该假设单一在线服务是不可靠的。当然，这与技术无关，只要将服务交与了某个服务提供商，就意味着正在失去对他们的控制力。

虽然是机器学习与个性化推荐的支持者，但是在我最关心的事物上，我坚持要最 old-fashioned 的方式去做。因为这是唯一能够让我保持控制力的方式。

像 RMS 那样苦行僧般地活着我做不到也不会去做，像 Linux 那样的桌面我也不会有太多机会去用，但是并不代表他们就不重要。相反，他们很重要，他们的存在本身就是底线。只有支持他们，当我想从某个团体中收回控制时，才有选择的权力。

虽说技术总是螺旋式发展的嘛，但是毕竟再也回不到过去，享受了现代科技创造的问题的解决方案的人类，欲望总是那么多。这也是为什么我会看好 NimbusBase 这样的基础设施，为什么我不喜欢App.net，为什么我希望有开放的Social networking service标准，也许世界应该换种方式回到之前的面貌才对。

对了，自从 AdSense 不做 Feed Ad 业务，到今天 Reader 已将死，看样子 Google 已经不玩 old-fashioned 的 web feed 生态圈了，那我也废除掉 Feedburner 。如果读者你还在使用订阅器，有劳换用 http://lyric.im/feed 这个原始 feed 地址，原地址只工作至 Feedburner 被砍的那天。