主题：【原创】浏览器是怎么变成操作系统的 -- 美人他爹

【4】 ChromeOS与Android，云在哪里？

Google的核心技术是什么？作为以搜索为主业的公司，Google对于搜索算法的投入当然很着力，但是搜索算法比较容易模仿，所以搜索是Google的强项，但不是其它公司无法望其项背的核心技术。Google的云计算平台是百万台规模的服务器集群，如此超大规模的集群，迄今为止，世界上还没有其它公司能够匹敌。云计算才是Google的核心技术。

所以，Google不惜余力地鼓吹云计算技术，这是合乎逻辑的。至于Google研发ChromeOS和Android的意义，不仅说明Google急于扩大自己的根据地，而且是把战火烧向其它公司的传统领地的战略部署，犹如当年老毛坐稳了延安根据地以后，就指派刘邓大军千里挺进大别山，是同出一辙的战略意图。

奇怪的是，从目前收集到的资料看，ChromeOS和Android，似乎都没有强调如何与云计算平台对接。具体来讲，ChromeOS和Android这两个OSes里面，都没有明确包含可移动式文件系统（Mobile File System）。

或许有人会争辩，不需要可移动式文件系统，因为只要给定一个URL，ChromeOS和Android操作系统就可以读写存放在网络云计算平台上的文件了。

在回答这个问题以前，我们先回顾一下，把云计算与ChromeOS和Android紧密联系在一起，有什么好处。ChromeOS和Android这些OSes存在的意义，首先在于方便应用程序的开发，其次在于支持应用程序高效率地运行。所谓高效率，关键在于节省计算资源的消耗。而节省计算资源，无非是找到CPU，Memory，Disk，以及网络带宽这四方面消耗的最优分配，以最快的速度和最低的总量消耗，响应用户的需求。

把云计算和本地OS紧密联系在一起，从终极意义上讲，是以带宽消耗的增加为代价，换取CPU，Memory，Disk消耗的降低。从具体做法上讲，有两个模式，一是前店后厂模式，云计算负责完成半成品，把半成品交给本地OS，本地应用程序完成后续加工，最后呈现给用户。另一个是资源外延，把云计算当成是本地CPU，Memory和Disk的外延，而应用程序把这些外延资源都当成本地CPU，Memory和Disk使用。

这两种模式的区别在于，如果使用前店后厂模式，应用程序需要明确地指挥，哪些工作转发给云计算平台处理，哪些留在本地处理。如果使用资源外延模式，应用程序不知道云计算的存在，似乎本地有无限的CPU，Memory和Disk。

如何把上网本和手机本地的CPU和Memory，与云计算无缝对接，这个问题比较复杂，以后专文探讨。把本地Disk空间与云计算存储空间对接，难度小得多。可移动式文件系统的目的，就是把本地Disk空间，外延至云计算平台。

或许有人会争辩，把本地Disk空间，外延至云计算平台，无非是把本地Disk空间，看成是云计算存储空间的一个缓存（cache），一个子集。只需要在本地文件系统加一个LRU（Least Recent Use）模块，管理哪些文件值得保留，哪些应该删除就可以了。

粗略想想似乎的确是这么回事儿，但是仔细想想，还有其它问题需要解决。

1. 移动设备的网络连接不稳定，时常发生中断。如果沿用传统的TCP/IP协议，假如一个文件的传输尚未结束，网络连接就中断了，那么等到网络连接恢复时，尤其是超过相当长的时间间隔后，需要从头到尾重新传输整个文件。有没有可能实现断点续传？有没有可能参考P2P文件共享的做法，先把大文件分割成若干小碎片，然后陆续传输这些碎片？但是假如在传输碎片的过程中，原文件发生更改，该怎么办？

2. 在传输过程中，防范原文件发生更改的关键，在于设定正确的读和写的锁机制。传统的写的锁机制，是排他性的，即一人在写，其他人都不能读。假如一个人在写的过程中，网络连接中断，写的过程迟迟不结束，那么就会造成其他人长久不能读的状态。能不能参考CVS的办法，在写以前，先checkout出一个拷贝，在这份拷贝上写，等写完以后，再checkin，这样就不会妨碍其他人读文件了。但是如果这样做，假如有多个人同时写，那么checkin的时候，需要不需要合并他们的更改呢？

3. 如果传输过程需要加密，沿用传统的SSL/TSL办法，绕不开使用公钥和私钥的握手的过程，这个过程很耗时。假如网络连接时常中断，每一次连接恢复时，需要重复握手的过程。有没有办法回避过多的握手，又不造成安全隐患？

4. 本地文件系统是云计算存储系统的一个子集，本地与云计算之间需要同步。如果云计算存储的文件发生更改，如何通知本地文件系统？如果采用本地文件系统主动的方式，定期向云计算申请核对的做法，有可能造成本地文件更新不及时。如果采用云计算平台主动的方式，通知本地文件系统及时更新，那么云计算平台势必要记住每个移动设备的文件系统里存放了哪些文件。如果移动设备很多，就不免给云计算平台造成很大负担。

5. 把云计算平台的某个文件夹，整体mount到本地文件系统，有没有必要支持这样的功能？

6. 当云计算平台存储的文件发生更改时，本地文件需要更新。最简单的更新方式是，删除本地文件，重新下载更改过的新文件。但是假如新文件和旧文件相差不多，最好在云计算平台预先算好新文件和旧文件之间的差额，然后让本地下载这个差额，最后在本地把差额叠加到旧文件，就实现了文件更新。这样做的好处是降低了下载量，问题是如何计算这个差额？使用Edit Distance算法是一个思路（http://en.wikipedia.org/wiki/Levenshtein_distance），但是假如文件尺寸很大，完成这个算法会消耗很长时间和大量内存空间。有没有办法加快速度，节省内存？

------

关于ChromeOS和Android闲言碎语就讲到这里。与其说这几篇文章澄清了一些疑惑的问题，不如说引出了更多悬而未决的问题。悬念，不仅是希区柯克吸引观众的伎俩，也是技术讨论的驱动力。

【全文完】