Skip to content

Instantly share code, notes, and snippets.

@chenzx

chenzx/20141026-启动到浏览器（Fire OS, Chrome OS, Web OS）与浏览器容器化

Created October 26, 2014 15:09
Show Gist options
  • Save chenzx/5157534ebae559dbf153 to your computer and use it in GitHub Desktop.
Save chenzx/5157534ebae559dbf153 to your computer and use it in GitHub Desktop.
Download ZIP
启动到浏览器（Fire OS, Chrome OS, Web OS）与浏览器容器化
Raw
20141026-启动到浏览器（Fire OS, Chrome OS, Web OS）与浏览器容器化
启动到浏览器（Fire OS, Chrome OS, Web OS）与浏览器容器化
本文试图阐明2种不同的技术方案：一个是启动到浏览器（如Fire OS, Chrome OS, HP Web OS, Tizen Web Rutime），另外一个我称为浏览器容器化
启动到浏览器相信大家多少已经有了解，它就是通过底层的驱动支持、HTML5 Device API等等，把浏览器内核做成整个操作系统的应用运行时，使用用户的所有应用都可以通过HTML + CSS + JavaScript的方式编写，这无疑节省了程序员大量的时间精力，但问题是，浏览器厂商不思进取，这种Web化应用方案有一些缺点：
可能性能不够；（这可能是JS引擎的JIT还不够好）
可能无法实现用原生UI框架（Android/iOS）能够做到的效果，比如说，自定义布局？灵活的多列+图文环绕的布局？
缺少某些原始TCP/UDP Socket创建功能，WebSocket理论上是纯TCP的，但它不够通过，且依赖于HTTP本身完成会话初始化
来看后一种方案：浏览器容器化，这里的意思是说，不需要“启动到浏览器”，OS还是原来的OS，浏览器作为容器，托管了Web化的应用。照理来说，Emscripten这款LLVM到JS的编译器应该解决了大部分的问题，但它还不够成熟：容器化实际上要求对CPU/IO资源进行可控的管理（灵活调度、按需分配、配额限制），比方说，要能够允许Web应用可以动态调整它可以并发打开的Socket连接、JS执行应该不抢占太多CPU、。。。等等
基本上这2者的差别就相当于Xen/KVM这些虚拟机与Docker这种轻量级容器的差别，只不过一个对应OS和原生应用，一个对应浏览器和Web应用。
顺带说一句，Docker所使用的Overlay文件系统及快速的版本化快照可以视为容器技术的核心特色，那么“浏览器容器化”呢？
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment