浏览器新实用功能开发研究:启动到浏览器(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化应用方案有一些缺点:

  1. 可能性能不够;(这可能是JS引擎的JIT还不够好)
  2. 可能无法实现用原生UI框架(Android/iOS)能够做到的效果,比如说,自定义布局?灵活的多列+图文环绕的布局?
  3. 缺少某些原始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文件系统及快速的版本化快照可以视为容器技术的核心特色,那么“浏览器容器化”呢? 

你可能感兴趣的:(虚拟机,浏览器,Web应用,编译器,容器化)