webassembly 和远程通信_asm 和webassembly - CSDN
精华内容
参与话题
  • WebAssembly——从入门到入门

    万次阅读 2018-08-19 17:37:08
    WebAssembly官网上,提出一种观点:传统的网络架构可以分为两层,一层是运行web app的虚拟机,一层是web API。可以理解为虚拟机层用于计算,实现交互功能,而web API层负责实现展示 JS性能瓶颈 一直以来,虚拟机层...

    文章内容来自于在腾讯MIG实习时我在组内做的技术分享

    产生背景

    WebAssembly官网上,提出一种观点:传统的网络架构可以分为两层,一层是运行web app的虚拟机,一层是web API。可以理解为虚拟机层用于计算,实现交互功能,而web API层负责实现展示

    JS性能瓶颈

    一直以来,虚拟机层只需要加载js就够了。因为js的功能足够强大,而且随着这20多年的发展历史,js自身也得到了很充分的扩展,形成了完善的生态系统。但是,功能提升的同时,js也慢慢变得臃肿了起来。并且,随着web应用范围的逐渐扩大,js逐渐显得力不从心
    比如,我们在google上搜索“js 性能“,有将近两千万条结果。前端面试中也常见到性能优化问题。这充分说明了js性能问题始终是前端方向的热点问题。
    虽然现在有了node和高效的v8引擎,但是在计算复杂性任务上,js性能还是远远落后于传统编译型语言

    Web应用范围扩大

    如今,web的应用范围已经不再是简单的资源展示和提供了。近些年来,基于web的VR,AR技术,3D游戏等都有蓬勃的发展,例如我们818活动“发烧星球”玩法,就是一个web VR的实用例子
    虽然也有类似WebGL这样的高性能框架出现,通过连接OpenGL的底层接口,为原本极度十分耗时的h5 canvas渲染提供3D硬件加速,大大提高了js在图像处理上的能力。但是我们日常面对的很多业务,由于面向用户范围很大,必须要考虑到兼容性的问题。在很多场景上我们并不能使用新技术,只能用canvas来保证兼容。从这个角度看来,js依旧存在着很大的劣势
    总结一下,js的问题主要来源于以下两点:
    - js作为一门动态语言,缺少编译过程,直接由浏览器解释执行。虽然对于开发者十分友好,但与此同时,js运行时需要大量的类型推导,也就是说需要在运行时动态决定的计算量太大(需要做大量分支预测),造成其效率远低于传统编译型语言。这也就是所谓的“牺牲了部分性能,换取了更强的表现力”
    - web应用范围的扩大使得js必须面对更多更复杂的场景。这远远不是js设计时所预想到的(毕竟第一版js只用了10天就做出来了……)

    WebAssembly - 入门

    WebAssembly是一种小体积,高加载速度的二进制编码格式
    从名字就能知道,这是一门底层汇编级的语言。有了WebAssembly,我们的虚拟机层就将会同时加载和运行两种类型的代码——JavaScript和WebAssembly。
    这两种代码可以通过WebAssembly所提供的js api实现互相调用。事实上,WebAssembly代码的基本单元被称作一个模块,并且这个模块在很多方面都和ES2015的模块是等价的。所以我们可以认为WebAssembly模块是一个“高性能的JS函数”
    WebAssembly不是用来取代JavaScript的。它被设计为和JavaScript一起协同工作,从而使得网络开发者能够利用两种语言的优势
    WebAssembly设计的目的不是为了手写汇编级别代码,而是为诸如C、C++等低级源语言提供一个高效的编译目标,使得以各种语言编写的代码都可以以接近原生的速度在web中运行。这一点具有重大的意义,这意味着所有由传统语言编写的客户端app都可以在web上高效运行,也就是说在未来客户端全面web化,未来可能不再需要客户端app
    同时,WebAssembly也是一个W3C标准,制定过程中得到了各大浏览器厂商积极参与。各大厂商都参与到标准制定里并不常见,像js引擎,css标准,每个浏览器实际都有一套自己的标准。而获得各个厂商支持的WebAssembly在我看来,是未来的标准风向,会被广泛采用

    WebAssembly优势

    • 高效,跨平台
      WebAssembly是二进制的,可以直接在WebAssembly虚拟机上的机器代码(可以类比于jvm 字节码)
      类比于汇编,如果机器的指令集和架构相同,则机器码可以直接执行,不关心上层os环境。Webassembly也一样能在不同平台上获得高效执行
    • 沙箱化执行环境
      WebAssembly被限制运行在一个虚拟的的沙箱执行环境中,运行时产生的变化可以随后删除,不会对系统产生永久性影响。并且它严格遵循浏览器的同源策略和授权策略,进一步确保了安全性
    • 有文本格式,可读可调试
      类比于汇编。每一条指令有对应的二进制值
    • 无版本,标准化
      WebAssembly是无版本,向后兼容的。这一点很有意义,相信大家在开发中也很经常碰到版本带来的一些很坑爹的问题。由于系统体积很大,依赖繁杂,且高级依赖往往不兼容低版本,造成升级时的巨大困难
      其次,WebAssembly无论是在PC端还是移动端,都支持各种浏览器平台

    几个常见概念

    • Module
      一个“代码单元”。包含编译好的二进制代码。可以高效的缓存、共享
      未来可以像一个ES2015模块一样导入/导出
    • Memory
      连续的,可变大小的字节数组缓冲区。可以理解为一个“堆”
    • Table
      连续的,可变大小的类型数组缓冲区
      现在table只支持函数引用类型,可以类比为一个“栈”
    • Instance
      在Module基础上,包含所有运行时所需状态的实例
      如果把Module类比为一个cpp文件,那么Instance就是链接了dll的exe文件

    构建方法

    • 直接汇编文本编写
      WebAssembly使用S-表达式作为文本格式
      S表达式用于表示一棵树。树上的每个一个节点都有一对小括号包围。括号内的第一个标签告诉你该节点的类型,其后跟随的是由空格分隔的属性或孩子节点列表
      劣势显而易见,编码逻辑不容易理解

    • 移植一个C/C++程序
      构建流程
      这张图是官网上的构建流程图,构建过程中使用了Emscripten——一个基于llvm的编译器,目的是把c/c++编译为asm.js(js的一个真子集)
      我们知道,c和js语法十分相似。所以在c到js的编译过程中,要解决的最重要的问题主要是两点:

    • C/C++是静态类型,js是动态类型
    • C/C++需要程序员手动管理内存,js则有自己的一套垃圾回收机制

    因此,就出现了asm.js。asm.js只有两种静态类型(i32, f64),并取消js的垃圾回收(手动管理内存)。浏览器加载到asmjs时,不进行语法分析,直接翻译为机器码执行
    实际上,asm.js就是WebAssembly的一种文本格式,但不同于之前提到的s表达式。这一点类比于c,汇编语言,机器码之间的关系
    由于WebAssembly当前不能直接调用Web API(如存取DOM),它只能调用JavaScript,因此需要一段js胶水代码使WebAssembly能够调用到Web API
    移植代码缺点在于需要较复杂的依赖,相比之下,汇编编写依赖都由程序员自己定义

    使用方法

    WebAssembly的模块在很大程度上和ES2015模块类似。在使用上也是分为两步:加载和调用

    • 加载
      • 获取.wasm二进制模块文件
      • 编译为Module
      • 实例化为Instance
        由于获取,编译和实例化都是异步的,所以实际使用中为了方便,可以直接构建一个异步的loader对wasm进行加载
    • 调用:从Instance中获取函数接口

    性能对比

    使用斐波那契数列作为计算函数
    (C代码如下)

    void fibonacci(int n)
    {
        int first = 0, second = 1, next;
        for (int i = 0; i < n; i++)
        {
            next = first + second;
            first = second;
            second = next;
        }
    }

    重复计算一百万次斐波那契数列46项(47项会溢出),结果如下:
    - C:3ms
    - JS: 70ms
    - WebAssembly:11ms
    可以看出,WebAssembly在计算复杂型任务中效率远胜过原生JS

    (性能测试部分代码详见WebAssembly_test_demo

    展开全文
  • 在 Rust 中创建一个简单的 WebAssembly 应用程序,然后从 JavaScript 调用这个程序 本文所涉及的所有代码可以在 https://github.com/second-state/wasm-learning/tree/master/browser/triple 中找到。 系列教程 ...

    在 Rust 中创建一个简单的 WebAssembly 应用程序,然后从 JavaScript 调用这个程序

    本文所涉及的所有代码可以在 https://github.com/second-state/wasm-learning/tree/master/browser/triple 中找到。

    WebAssembly 入门教程
    系列教程

    1. WebAssembly 快问快答
    2. Rust 的 Hello world

    在本教程中,我们将创建一个非常简单但很完整的 WebAssembly 应用程序。

    Webassembly 应用程序通常由两部分组成。

    • 运行在 WebAssembly 虚拟机内部以执行计算任务的字节码程序

    • 提供 UI、networking、数据库,以及调用 WebAssembly 程序以执行关键计算任务或业务逻辑的主机应用程序

    在本教程中,主机应用程序是用 JavaScript 编写的,并在 web 浏览器中运行。 Webassembly 字节码程序是用 Rust 编写的。

    现在,先让我们看看 Rust 程序是如何编写的。

    在 Rust 中的 WebAssembly 程序

    在这个例子中,Rust 程序将输入数字简单地增加了三倍并返回结果。 首先将 WebAssembly 工具安装到 Rust 编译器。

    # Install Rust
    
    $ sudo apt-get update
    $ sudo apt-get -y upgrade
    $ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
    $ source $HOME/.cargo/env
    
    # Install WebAssembly tools
    
    $ rustup target add wasm32-wasi
    $ rustup override set nightly
    $ rustup target add wasm32-wasi --toolchain nightly
    

    接下来,创建一个新的 cargo 项目。
    由于这个程序是从主机应用程序调用的,而不是作为独立的可执行文件运行,因此我们将创建一个 lib 项目。

    $ cargo new --lib triple
    $ cd triple
    

    编辑 Cargo.toml 文件以添加[lib]节。 它会告诉编译器在哪里可以找到库的源代码,以及如何生成字节码输出。

    [lib]
    name = "triple_lib"
    path = "src/lib.rs"
    crate-type =["cdylib"]
    

    下面是 Rust 程序 src/lib.rs 的内容. 实际上,你可以在这个库文件中定义多个外部函数,并且所有这些函数都可以通过 WebAssembly 在 JaveScript 主机上使用。

    #[no_mangle]
    pub extern fn triple(x: i32) -> i32 {
      return 3 * x;
    }
    

    接下来你可以用下面的命令行编译 Rust 的源代码到WebAssembly的字节码中。

    $ cargo +nightly build --target wasm32-wasi --release
    

    WebAssembly 字节码文件是 target/wasm32-wasi/release/triple_lib.wasm

    JavaScript 主机

    我们使用 JavaScript 加载 WebAssembly 字节码程序并调用它的函数。 由于大多数浏览器已经支持 WebAssembly, JavaScript 实际上可以作为一个网页运行。

    无须赘述,下面是 JavaScript 模块的相关部分,用于加载、导出和调用 WebAssembly 函数。 完整的网页源文件在这里

    <script>
      if (!('WebAssembly' in window)) {
        alert('you need a browser with wasm support enabled :(');
      }
      (async () => {
          const response = await fetch('triple_lib.wasm');
          const buffer = await response.arrayBuffer();
          const module = await WebAssembly.compile(buffer);
          const instance = await WebAssembly.instantiate(module);
          const exports = instance.exports;
          const triple = exports.triple;
          
          var buttonOne = document.getElementById('buttonOne');
          buttonOne.value = 'Triple the number';
          buttonOne.addEventListener('click', function() {
            var input = $("#numberInput").val();
            alert(input + ' tripled equals ' + triple(input));
          }, false);
      })();
    </script>
    
    

    可以看到 JavaScript 代码加载了 WebAssembly 虚拟机的 triple_lib.wasm 文件, 导出其外部函数,然后根据需要调用这些函数。

    将这个 HTML 文件和 triple_lib.wasm 文件放在web 服务器上,你就可以访问网页,在网页上输入的任何数字会自动乘以三。

    那么字符串呢

    现在你注意到了,这个例子并不是一个 hello world。 WebAssembly函数计算数字,但不会像 hello world 那样操作字符串。

    这是为什么呢? 我们将在下一个教程中回答这个问题,并给出一个真实的 hello world 示例。

    展开全文
  • 原文链接:《Why WebAssembly is a big deal》 译者与来源:敖小剑,敖小剑的博客 本文已获得译者转载授权 编者按:Michael van der Gulik 在《Why WebAssembly is big deal》一文中,详尽探索了 WebAssembly 在...

    本文作者:Michael van der Gulik

    原文链接:《Why WebAssembly is a big deal》

    译者与来源:敖小剑,敖小剑的博客

    本文已获得译者转载授权

    编者按:Michael van der Gulik 在《Why WebAssembly is big deal》一文中,详尽探索了 WebAssembly 在浏览器的实际用处,比如可以直接从网络获取应用,无需下载。但更为重要的是,Michael van der Gulik 在本文中还探索了 WebAssembly 在硬件与云计算的巨大潜力。

    以下为正文:

    WebAssembly 是每个程序员都应该关注的技术。WebAssembly 会变得更流行。WebAssembly 将取代 JavaScript。WebAssembly 将取代 HTML 和 CSS。WebAssembly 将取代手机应用。WebAssembly 将取代桌面应用。在 10 年内,我保证每个程序员至少需要知道如何使用工具来操作 WebAssembly 并理解它是如何工作的。

    你可能会说,“太离谱了!” 好吧,请继续阅读。

    什么是 WebAssembly

    当前形式的 WebAssembly 是 Web 浏览器的新扩展,可以运行预编译代码…快速地。在 C 中编写了一些小代码,然后使用 Emscripten 编译器将该代码编译为 WebAssembly。通过一些 Javascript 粘合,就可以在 Web 浏览器中调用这一小段代码,例如,运行粒子模拟

    WebAssembly 文件,扩展名为.wasm,本身是包含可执行指令的二进制格式。要使用该文件,必须编写一个运行某些 Javascript 的 HTML 文件来获取、编译和执行 WebAssembly 文件。WebAssembly 文件在基于堆栈的虚拟机上执行,并使用共享内存与其 JavaScript 包装器进行通信。

    到目前为止,这似乎并不有趣。它看起来只不过是 JavaScript 的加速器。但是,聪明的读者会对 WebAssembly 可能成为什么有所了解。

    WebAssembly 将成为什么?

    第一个重要发现是 WebAssembly 是一个安全的沙盒虚拟机。可以从 Internet 运行喜欢的 WebAssembly 代码,而确保它不会接管 PC 或服务器。四个主流 Web 浏览器对它的安全性非常有信心,它已经默认实现并启用了。它的真正安全性还有待观察,但安全性是 WebAssembly 的核心设计目标。

    第二个重要发现是 WebAssembly 是一个通用的编译目标。它的原始编译器是一个 C 编译器,这个编译器很好地指示了 WebAssembly 虚拟机的低级和可重定向性。许多编程语言都使用 C 语言编写虚拟机,其他一些语言甚至使用 C 本身作为编译目标。

    此时,有人整理了一个可以编译为 WebAssembly 的编程语言列表。这份名单将在未来很多年中继续增长。

    WebAssembly 允许使用任何编程语言编写代码,然后让其他人在任何平台上安全地运行该代码,无需安装任何内容。朋友们,这是美好梦想的开始。

    部署问题

    我们来谈谈如何将软件提供给用户。

    为新项目选择编程语言的一个重要因素是如何将项目部署到客户。您的程序员喜欢用 Haskell,Python,Visual Basic 或其他语言编写应用程序,具体取决于他们的喜好。要使用喜欢的语言,他们需要编译应用,制作一些可安装的软件包,并以某种方式将其安装在客户端的计算机上。有许多方法可以提供软件 - 包管理器,可执行安装程序或安装服务,如 Steam,Apple App Store,Google Play 或 Microsoft store。

    每一个安装机制都意味着痛苦,从应用商店安装时的轻微疼痛,到管理员要求在他的 PC 上运行一些旧的 COBOL 代码时的集群头痛。

    部署是一个问题。对于开发人员和系统管理员来说,部署一直是一个痛点。我们使用的编程语言与我们所针对的平台密切相关。如果大量用户在 PC 或移动设备上,我们使用 HTML 和 Javascript。如果用户是 Apple 移动设备用户,我们使用……呃…… Swift?(我实际上不知道)。如果用户在 Android 设备上,我们使用 Java 或 Kotlin。如果用户在真实计算机上并且愿意处理掉他们的部署问题,那么我们开发人员才能在我们使用的编程语言中有更多选择。

    WebAssembly 有可能解决部署问题。

    有了 WebAssembly,您可以使用任何编程语言编写应用,只要这些编程语言可以支持 WebAssembly,而应用可以在任何设备和任何具有现代 Web 浏览器的操作系统上运行。

    硬件垄断

    想购买台式机或笔记本电脑。有什么选择?好吧,有英特尔,有 AMD。多年来一直是双寡头垄断。保持这种双寡头垄断的一个原因是 x86 架构只在这两家公司之间交叉许可,而且通常预编译的代码需要 x86 或 x86-64(也就是 AMD-64)架构。还有其他因素,例如设计世界上最快的 CPU 是一件很艰难但也很昂贵的事情。

    WebAssembly 是一种可让您在任何平台上运行代码的技术(之一)。如果它成为下一个风口,硬件市场将变得商品化。应用编译为 WebAssembly,就可以在任何东西上运行 - x86,ARM,RISC-V,SPARC。即便是操作系统市场也会商品化;您所需要的只是一个支持 WebAssembly 的浏览器,以便在硬件可以运行时运行最苛刻的应用程序。

    编者注:Second State 研发的专为服务端优化的 WebAssembly 引擎 SSVM 已经可以运行在高通骁龙芯片上。Github 链接:https://github.com/second-state/SSVM

    云计算

    但等等,还有更多。云计算成为IT经理办公室的流行词已有一段时间,WebAssembly 可以直接迎合它。

    WebAssembly 在安全沙箱中执行。可以制作一个容器,它可以在服务器上接受和执行 WebAssembly 模块,而资源开销很小。对于提供的每个服务,无需在虚拟机上运行完整的操作系统。托管提供商只提供对可以上传代码的WebAssembly 容器的访问权限。它可以是一个原始容器,接收 socket 并解析自己的 HTTP 连接,也可以是一个完整的 Web 服务容器,其中 WebAssembly 模块只需要处理预解析的HTTP请求。

    这还不存在。如果有人想变得富有,那么可以考虑这个想法。

    编者注:目前已经有人正在实现这个想法,Byte Alliance 计划将WebAssembly 带到浏览器之外,Second State 已经发布了为服务端设计的WebAssembly 引擎开发者预览版

    不是云计算

    WebAssembly 足以取代 PC 上本地安装的大多数应用程序。我们已经使用 WebGL(又名OpenGL ES 2.0)移植了游戏。我预测不久之后,受益于WebAssembly,像 LibreOffice 这样的大型应用可以直接从网站上获得,而无需安装。

    在这种情况下,在本地安装应用没什么意义。本地安装的应用和 WebAssembly 应用之间几乎没有区别。WebAssembly 应用已经可以使用屏幕,键盘和鼠标进行交互。它可以在 2D 或 OpenGL 中进行图形处理,并使用硬件对视频流进行解码。可以播放和录制声音。可以访问网络摄像头。可以使用 WebSockets。可以使用 IndexedDB 存储大量数据在本地磁盘上。这些已经是 Web 浏览器中的标准功能,并且都可以使用 JavaScript 向 WebAssembly 暴露。

    目前唯一困难的地方是 WebAssembly 无法访问本地文件系统。好吧,可以通过 HTML 使用文件上传对话,但这不算。最终,总会有人为此创建 API,并可能称之为 “WASI”。

    “从互联网上运行应用程序!?胡说八道!“,你说。好吧,这是使用 Qt 和 WebAssembly 实现的文本编辑器 (以及更多)。

    这是一个简单的例子。复杂的例子是在 WebBrowser 中运行的 Adobe Premier Pro 或 Blender。或者考虑像 Steam 游戏一样可以直接从网络上运行。这听起来像小说,但从技术上说这并非不能发生。

    它会来的。

    让我们裸奔!

    目前,WebAssembly 在包含 HTML 和 Javascript 包装器的环境中执行。为什么不脱掉这些?有了 WebAssembly,为什么还要在浏览器中包含 HTML 渲染器和 JavaScript 引擎?

    通过为所有服务提供标准化 API,这些服务通常是 Web 浏览器提供的,可以创建裸 WebAssembly。就是没有 HTML和 Javascript 包装来管理的 WebAssembly。访问的网页是 .wasm 文件,浏览器会抓取并运行该文件。浏览器为WebAssembly 模块提供画布,事件处理程序以及对浏览器提供的所有服务的访问。

    这目前还不存在。如果现在使用 Web 浏览器直接访问 .wasm 文件,它会询问是否要下载它。我假设将设计所需的 API 并使其工作。

    结果是 Web 可以发展。网站不再局限于 HTML,CSS 和 Javascript。可以创建全新的文档描述语言。可以发明全新的布局引擎。而且,对于像我这样的 polyglots 最相关,我们可以选择任何编程语言来实现在线服务。

    可访问性

    但我听到了强烈抗议!可访问性怎么样??搜索引擎怎么办?

    好吧,我还没有一个好的答案。但我可以想象几种技术解决方案。

    一个解决方案是我们保留内容和表现的分离。内容以标准化格式编写,例如 HTML。演示文稿由 WebAssembly 应用管理,该应用可以获取并显示内容。这允许网页设计师使用想要的任何技术进行任意演示 - 不需要 CSS,而搜索引擎和需要不同类型的可访问性的用户仍然可以访问内容。

    请记住,许多 WebAssembly 应用并不是可以通过文本访问的,例如游戏和许多应用。盲人不会从图像编辑器中获得太多好处。

    另一个解决方案是发明一个 API,它可以作为 WebAssembly 模块,来提供想在屏幕上呈现的 DOM,供屏幕阅读器或搜索引擎使用。基本上会有两种表示形式:一种是在图形画布上,另一种是产生结构化文本输出。

    第三种解决方案是使用屏幕阅读器或搜索引擎可以使用的元数据来增强画布。执行 WebAssembly 并在画布上呈现内容,其中包含描述渲染内容的额外元数据。例如,该元数据将包括屏幕上的区域是否是菜单以及存在哪些选项,或者区域是否想要文本输入,以及屏幕上的区域的自然排序(也称为标签顺序)是什么。基本上,曾经在 HTML 中描述的内容现在被描述为具有元数据的画布区域。同样,这只是一个想法,它可能在实践中很糟糕。

    可能是什么

    1995年,Sun Microsystems 发布了 Java,带有 Java applets 和大量的宣传。有史以来第一次,网页可以做一些比和 GIF 动画更有趣的事情。开发人员可以使应用完全在用户的 Web 浏览器中运行。它们没有集成到浏览器中,而是实现为繁重的插件,需要安装整个 JVM。1995年,这不是一个小的安装。applets 也需要一段时间来加载并使用大量内存。我们现在凭借大量内存,这不再是一个问题,但在 Java 生命的第一个十年里,它让体验变得令人厌烦。

    applets 也不可靠。无法保证它们会运行,尤其是在用户使用 Microsoft 的实现时。他们也不安全,这是棺材里的最后一颗钉子。

    以 JVM 为荣,其他语言最终演变为在 JVM 上运行。但现在,那艘船航行了。

    FutureSplash / Macromedia / Adobe Flash 也是一个竞争者,但是是专有的,具有专有工具集和专有语言的专有格式。我读到他们确实在2009年开启了文件格式。最终从浏览器中删除了支持,因为它存在安全风险。

    这里的结论是,如果希望您的技术存在于每个人的机器上,那么安全性就需要正视。我真诚地希望 WebAssembly 作为标准对安全问题做出很好的反应。

    需要什么?

    WebAssembly 仍处于初期阶段。它目前能很好的运行代码,而规范版本是 1.0,二进制格式定型。目前正在开展SIMD 指令支持。通过 Web Workers 进行多线程处理也正在进行中。

    工具可用,并将在未来几年不断改进。浏览器已经让你窥视 WebAssembly 文件。至少 Firefox 允许查看WebAssembly 字节码,设置断点并查看调用堆栈。我听说浏览器也有 profiling 支持。

    语言支持包括一套不错的语言集合–C,C 和Rust是一流的公民。C#,Go和Lua显然有稳定的支持。Python,Scala,Ruby,Java和Typescript都有实验性支持。这可能是一个傲慢的陈述,但我真的相信任何想要在21世纪存在的语言都需要能够在 WebAssembly 上编译或运行。

    在访问外部设备的 API 支持方面,我所知道的唯一可用于裸 WebAssembly 的 API 是 WASI,它允许文件和流访问等核心功能,允许 WebAssembly 在浏览器外运行。否则,任何访问外部世界的 API 都需要在浏览器中的 Javascript 中实现。除了本地机器上的文件访问,打印机访问和其他新颖的硬件访问(例如非标准蓝牙或USB设备)之外,应用所需的一切几乎都可以满足。“裸WebAssembly”并不是它成功的必要条件; 它只是一个小的优化,不需要浏览器包含对 HTML,CSS 或 Javascript 的支持。

    我不确定在桌面环境中让 WebAssembly 成为一等公民需要什么。需要良好的复制和粘贴支持,拖放支持,本地化和国际化,窗口管理事件以及创建通知的功能。也许这些已经可以从网络浏览器中获得; 我经常惊讶与已经可能的事情。

    引发爆炸的火花是创建允许现有应用移植的环境。如果创造了“用于 WebAssembly 的 Linux 子系统”,那么可以将大量现有的开源软件移植到 WebAssembly 上。它需要模拟一个文件系统 - 可以通过将文件系统的所有只读部分都缓存为 HTTP 请求来完成,并且所有可写部分都可以在内存中,远程存储或使用浏览器可以提供的任何文件访问。图形支持可以通过移植 X11 或 Wayland 的实现来使用 WebGL(我理解已经作为 AIGLX 存在?)。

    一些 SDL 游戏已经被移植到 WebAssembly - 最着名的是官方演示。

    一旦 JVM 在 WebAssembly 中运行,就可以在浏览器中运行大量的 Java 软件。同样适用于其他虚拟机和使用它们的语言。

    与 Windows 软件的巨大世界一样,我没有答案。WINE 和 ReactOS 都需要底层的 x86 或 x86-64 机器,所以唯一的选择是获取源代码并移植它,或者使用 x86 模拟器。

    尾声

    WebAssembly 即将到来。
    它来得很慢,但现在所有的部分都可以在你正在使用的浏览器上使用。现在我们等待构建用于从各种编程语言中定位 WebAssembly 的基础设施。一旦构建完成,我们将摆脱 HTML,CSS 和 Javascript 的束缚。

    相关阅读

    展开全文
  • 在浏览器之争中,Chrome凭借JavaScript的卓越性能取得了市场主导地位,...本文从WebAssembly的起源到开发实践对其做全面探究,帮助开发者对WebAssembly有全面的了解。 缘起 让我们从浏览器大战说起。微软凭借W

    在浏览器之争中,Chrome凭借JavaScript的卓越性能取得了市场主导地位,然而由于JavaScript的无类型特性,导致其运行时消耗大量的性能做为代价,这也是JavaScript的瓶颈之一。WebAssembly旨在解决这一问题。本文从WebAssembly的起源到开发实践对其做全面探究,帮助开发者对WebAssembly有全面的了解。

    缘起

    让我们从浏览器大战说起。微软凭借Windows系统捆绑Internet Explorer的先天优势击溃Netscape后,进入了长达数年的静默期。而Netscape则于1998年将Communicator开源,并由Mozilla基金会衍生出Firefox浏览器,在2004年发布了1.0版本。从此,第二次浏览器大战拉开帷幕。这场大战由Firefox浏览器领衔,Safari、Opera等浏览器也积极进取,Internet Explorer的主导地位首次受到挑战。2008年Google推出Chrome浏览器,不但逐步侵蚀Firefox的市场,更是压制了老迈的Internet Explorer。在此次大战之后的2012年,StatCounter的数据指出Chrome以微弱优势超越Internet Explorer成为世界上最流行的浏览器。

    分析Google Chrome浏览器战胜Internet Explorer的原因,除了对Web标准更友善的支持外,卓越的性能是其中相当重要的因素,而浏览器性能之争的本质则体现在JavaScript引擎。此前,JavaScript引擎的实现方式经历了遍历语法树到字节码解释器等较为原始的方式,将每条源代码翻译成相应的机器码并执行,并不保存翻译后的机器码,使得解释执行很慢。2008年9月,Google发布了V8 JavaScript引擎。V8被设计用于提高Web浏览器中JavaScript的执行性能,通过即时编译JIT(Just-In-Time)技术,在执行时将JavaScript代码编译成更为高效的机器代码并保存,下次执行同一代码段时无需再编译,使得JavaScript获得了几十倍的性能提升。

    然而,JavaScript是个无类型(untyped,变量没有类型)的语言,这直接导致表达式c=a+b有多重含义:

    • a、b均为数字,则算术运算符+表示值相加;
    • a、b为字符串,则+运算符表示字符串连接;
    •  …

    表达式执行时,JIT编译器需要检查a和b的类型,确定操作行为。若a、b均为数字,JIT编译器则将a、b确认为整型,而一旦某一变量变成字符串,JIT编译器则不得不将之前编译的机器码推倒重来。由此可见,JavaScript的无类型特性建立在消耗大量性能代价的基础之上。即便JIT编译器在对变量类型发生变化时已进行相应优化,但仍然有很多情况JavaScript引擎未进行或无法优化,例如for-of、try-catch、try-finally、with语句以及复合let、const赋值的函数等。

    由此可见,JavaScript的无类型是JavaScript引擎的性能瓶颈之一,改进方案有两种:一是设计一门新的强类型语言并强制开发者进行类型指定;二是给现有的JavaScript加上变量类型。

    微软开发的TypeScript属于第一种改进方案。它是扩展了JavaScript特性的语言,包含了类型批注,编译时类型检查,类型推断和擦除等功能,TypeScript开发者在声明变量时指定类型,使得JavaScript引擎能够更快将这种强类型的语言编译成弱类型。

    看看第二种方案:

    图片描述

    代码1

    代码1表示带有两个参数(a和b)的JavaScript函数,和通常JavaScript代码不同的地方在于a=a | 0及b=b | 0,以及返回值后面均利用标注进行了按位OR操作。这么做的优点是使JavaScript引擎强制转换变量的值为整型执行。通过标注加上变量类型,JavaScript引擎就能更快地编译。

    既然增加变量类型能够提升Web性能,有没有办法将静态类型代码例如C/C++等转换成JavaScript指令的子集呢?上面的这段代码恰恰是作为JavaScript子集的asm.js,由代码2的C语言编译而来:

    图片描述

    代码2

    事实上,早在1995年起就已经有Netscape Plugin API(NPAPI)在内的可以使用浏览器运行C/C++程序的项目在开发。而2013年问世的asm.js是目前较为广泛的方案。asm.js是一种中间编程语言,允许用C/C++语言编写的计算机软件作为Web应用程序运行,并保持更好的性能,而Mozilla Firefox从版本22起成为第一个为asm.js特别优化的网页浏览器。

    Google也同样在为原生代码运行在Web端而努力。Google Native Client(NaCl)采用沙盒技术,让Intel x86、ARM或MIPS子集的机器码直接在沙盒上运行。它能够在无需安装插件的情况下从浏览器直接运行原生可执行代码,使Web应用程序可以用接近于机器码运作的速度来运行。而Google Portable Native Client(PNaCl)则稍有变化,通过一些前端编译器将C/C++源代码编译成LLVM的中间字节码而不是x86或ARM代码,并且进行优化以及链接(如表1所示)。

    图片描述

    有了类型支持,第二种方案性能提升潜力远远大于第一种。

    然而,无论是asm.js或现有PNaCl的解决方案,都面临着一些缺陷(例如1KB的C源码编译生成asm.js后的大小有480KB)或其他浏览器不支持的窘境,而2016年10月对Chromium问题跟踪代码的评论更是表明,Google Native Client小组已被关闭。

    作为Web浏览器性能和代码重用的解决方案,asm.js及PNaCl都没能被普遍接受,那么有没有上述表格中的特性全部占优,且跨厂商的解决方案呢?

    WebAssembly旨在解决这个问题。

    新时代

    WebAssembly(简称Wasm)是一种新的适合于编译到Web的,可移植的,大小和加载时间高效的格式。这是一个新的与平台无关的二进制代码格式,目标是解决JavaScript性能问题。这个新的二进制格式远小于JavaScript,可由浏览器的JavaScript引擎直接加载和执行,这样可节省从JavaScript到字节码,从字节码到执行前的机器码所花费的即时编译JIT(Just-In-Time)时间。 作为一种低级语言,它定义了一个抽象语法树(Abstract Syntax Tree,AST),开发人员可以以文本格式进行调试。

    WebAssembly描述了一个内存安全的沙箱执行环境,可以在现有的JavaScript虚拟机中实现。 当嵌入到Web中时,WebAssembly将强制执行浏览器的同源和权限安全策略。因此,和经常出现安全漏洞的Flash插件相比,WebAssembly是一个更加安全的解决方案。

    WebAssembly可由C/C++等语言编译而来。此外,WebAssembly由Google、Mozilla、微软以及苹果公司牵头的W3C社区组共同努力,基本覆盖主流的浏览器厂商,因此其可移植性相较Silverlight等有极大提升,平台兼容问题将不复出现。

    在Web平台的很多项目中,对于原生新功能的支持需要Web浏览器或Runtime提供复杂的标准化的API来实现,但是JavaScript API往往较慢。使用WebAssembly,这些标准API可以更简单,并且操作在更低的水平。例如,对于一个面部识别的Web项目,对于访问数据流我们可以由简单的JavaScript API实现,而把面部识别原生SDK做的事情交由WebAssembly实现。

    需要了解的是,WebAssembly不是将C/C++等其他语言编译到JavaScript,更不是一种新的编程语言。

    探究

    asm.js

    上文的C语言求和代码经由编译器生成asm.js后如代码3所示。

    图片描述

    代码3

    上述代码转换为WebAssembly的文本格式稍显复杂,为了理解方便,我们从精简的asm.js开始(见代码4)。

    图片描述

    代码4

    wast文本文件

    将asm.js代码转换为WebAssembly的文本格式 add.wast(转换工具见本文工具链章节,如代码5所示)。

    图片描述

    代码4

    WebAssembly中代码的可装载和可执行单元被称为一个模块(module)。在运行时,一个模块可以被一组import值实例化,多个模块实例能够访问相同的共享状态。目前文本格式中的module主要用S表达式来表示。虽然S表达格式不是正式的文本格式,但它易于表示AST。WebAssembly也被设计为与ES6的modules集成。

    一个单一的逻辑函数定义包含两个部分:功能部分声明在模块中每个内部函数定义的签名,代码段部分包含由功能部分声明的每个函数的函数体。WebAssembly是带有返回值的静态类型,并且所有参数都含有类型。上面的add.wast可以解读为:

    • 声明了一个名为$add的函数;
    • 包含两个参数ab,两者都是32位整型;
    • 结果是一个32位整型;
    • 函数体是一个32位的加法:
    • 上面是局部变量$a得到的值;
    • 下面是局部变量$b得到的值;
    • 由于没有明确的返回节点,因此return是该加法函数的最后加载指令。

    二进制Wasm文件

    如图1所示,由C语言求和代码经过编译生成二进制文件,通读文件可以找到相应的头部、类型、导入、函数以及代码段等。通过JavaScript API载入Wasm二进制文件后,最终转换到机器码执行。

    图片描述

    图1 经过编译的二进制文件

    工具链

    开发人员现在可以使用相应的工具链从C / C ++源文件编译WebAssembly模块。WebAssembly由许多工具支持,以帮助开发人员构建和处理源文件和生成的二进制内容。

    Emscripten

    Emscripten是其中无法回避的工具之一,如图2所示。在图2中,Emscripten SDK管理器(emsdk)用于管理多个SDK和工具,并且指定当前正被使用到编译代码的特定SDK和工具集。

    图片描述

    图2 Emscripten工具链流程图及生成JavaScript(asm.js)流程

    Emscripten的主要工具是Emscripten编译器前端(emcc),它是例如GCC的标准编译器的简易替代实现。

    Emcc使用Clang将C/C++文件转换为LLVM(源自于底层虚拟机Low Level Virtual Machine)字节码,使用Fastcomp(Emscripten的编译器核心,一个LLVM后端)把字节码编译成JavaScript。输出的JavaScript可以由Node.js执行,或者嵌入HTML在浏览器中运行。这带来的直接结果就是,C和C++程序经过编译后可在JavaScript上运行,无需任何插件。

    WABT和Binaryen

    除此之外,对于想要使用由其他工具(如Emscripten)生成的WebAssembly二进制文件感兴趣的开发者,目前http://webassembly.org/官方额外提供了另外两组不同的工具:

    • WABT ——WebAssembly二进制工具包;
    • Binaryen——编译器和工具链。

    WABT工具包支持将二进制WebAssembly格式转换为可读的文本格式。其中wasm2wast命令行工具可以将WebAssembly二进制文件转换为可读的S表达式文本文件。而wast2wasm命令行工具则执行完全相反的过程。

    Binaryen则是一套更为全面的工具链,是用C++编写成用于WebAssembly的编译器和工具链基础结构库(如图3所示)。WebAssembly是二进制格式(Binary Format)并且和Emscripten集成,因此该工具以Binary和Emscript-en的末尾合并命名为Binaryen。它旨在使编译WebAssembly容易、快速、有效。它包含且不仅仅包含下面的几个工具。

    图片描述

    图3 Binaryen生成WebAssembly流程

    • wasm-as:将WebAssembly由文本格式(当前为S表达式格式)编译成二进制格式;
    • wasm-dis:将二进制格式的WebAssembly反编译成文本格式;
    • asm2wasm:将asm.js编译到WebAssembly文本格式,使用Emscripten的asm优化器;
    • s2wasm:在LLVM中开发,由新WebAssembly后端产生的.s格式的编译器;
    • wasm.js:包含编译为JavaScript的Binaryen组件,包括解释器、asm2wasm、S表达式解析器等。

    Binaryen目前提供了两个生成WebAssembly的流程,由于emscripten的asm.js生成已经非常稳定,并且asm2wasm是一个相当简单的过程,所以这种将C/C ++编译为WebAssembly的方法已经可用(如图4所示)。

    图片描述

    图4 Emscripten+Binaryen生成WebAssembly的完整流程

    由此可见,Emscripten以及Binaryen提供了完整的C/C++到WebAssembly的解决方案。而Binaryen则帮助提升了WebAssembly的工具链生态。

    提示

    由于WebAssembly正处于活跃开发阶段,各项编译步骤和编译工具会有大幅变更和改进,相信最终的编译工具和步骤会趋于便捷,开发者需要留意官方网站的最新动态。

    实战

    Linux和mac OS平台编译原生代码到WebAssembly可由如下步骤实现。

    编译环境准备

    操作系统必须有可以工作的编译器工具链,因此需要安装GCC、cmake环境,此外Python、Node.js及Java环境也是需要的(其中Java为可选,如图5所示)。

    图片描述

    图5 编译环境安装

    如果是以其他方式安装了Node.js,可能需要更新~/.emscripten文件的NODE_JS属性。

    安装正确的emscripten分支

    要编译原生代码到WebAssembly,我们需要emscripten的incoming分支。由于emscripten不仅仅是用于WebAssembly的编译工具链,选择正确的分支尤为重要(如图6所示)。

    图片描述

    图6 安装emscripten的incoming分支

    其中URLTO具体的URL是https://s3.amazonaws.com/mozilla-games/emscripten/releases/emsdk-portable.tar.gz

    处理安装异常

    可运行emcc -v命令进行验证安装。如果遇到如图7所示的错误,表明带有JavaScript后端的LLVM编译器并未被生成。

    图片描述

    图7 emcc -v命令报错

    图片描述

    图8 emcc -v命令报错解决方案

    通过图8步骤,可以解决该问题,并且在~/.emscripten 文件中修改如下配置:

    图片描述

    开始编译程序

    现在一个完整的工具链已经具备,我们可以使用它来编译简单的程序到WebAssembly。但是,还有一些其他注意事项:

    • 必须通过参数-s Wasm=1到emcc(否则默认emcc将编译出asm.js);
    • 除了Wasm二进制文件和JavaScript wrapper外,如果还希望emscripten生成一个可直接运行的程序的HTML页面,则必须指定一个扩展名为.html的输出文件。

    在编译之前,首先准备一个最基本的add.c程序,见代码6。

    图片描述

    代码6

    按代码7所示的命令编辑好add.c程序并编译:

    图片描述

    运行WebAssembly应用

    以Chrome浏览器为例,如果直接在浏览器内本地打开HTML文件,会有图9所示的错误: 
    图片描述

    图9 XMLHttpRequest本地访问的跨域请求错误

    由于XMLHttpRequest跨域请求不支持file://协议,必须经由HTTP实际输出,可以由Python的SimplHTTPServer改进,见代码8:

    图片描述

    代码8

    在浏览器中输入http://127.0.0.1:8080并打开add.html,就能直接看到转换成WebAssembly的应用程序输出结果。

    创建独立WebAssembly

    默认情况下,emcc会创建JavaScript文件和WebAssembly的组合,其中JS加载包含编译代码的WebAssembly。对于C/C++开发人员,他们可能更倾向于创建独立的WebAssembly,用于JavaScript开发人员调用,见代码9。

    图片描述

    代码9

    上述命令运行后,我们可以得到独立的Wasm文件。需要说明的是,该参数仍然在开发中,可能随时发生规范和实现变更。

    JavaScript API调用

    从C/C++程序编译获得一个.wasm模块之后,JavaScript开发人员可以通过如下方式进行载入.wasm文件并执行。WebAssembly社区组也有计划通过Streams使用streaming以及异步编译,见代码10。

    图片描述

    代码10

    最后一行调用导出的WebAssembly函数,它反过来调用我们导入的JS函数,最终执行add(201700, 2),并且在控制台获得期望的结果输出(如图10所示)。

    图片描述

    图10 WebAssembly求和函数在控制台的输出

    性能

    那么,WebAssembly的真实性能如何呢?首先我们用一直被用来作为CPU基准测试的斐波那契 (Fibonacci)数列来进行对比,这里使用的是性能较差的递归算法,在Node.js v7.2.1环境下,能够看到WebAssembly性能优势越发明显(如图11所示)。

    图片描述

    图11 CPU基准测试反应WebAssembly的真实性能

    再看看最基本的1000毫秒时间内,求和计算的运算量统计,在同一台计算机的Firefox 50.1.0版本的运算结果如图12所示。

    图片描述

    图12 1000毫秒内求和计算的运算量统计

    尽管重复测试时结果不尽相同,重启浏览器并多次测试取平均值后依然可以看到WebAssembly的运算量比JavaScript快了近一个量级。

    Demo

    图13展示了Angry Bots Demo,它是由WebAssembly项目发布的一个Demo,由Unity游戏移植而来。

    图片描述

    图13 Angry Bots Demo / Google Chrome 55.0.2883.87

    通过如下方式可以体验WebAssembly在浏览器中的强大性能。即便Google Chrome较新的稳定版也已支持WebAssembly,还是推荐使用canary版及Firefox的nightly版进行测试。

    1. 下载浏览器: 
      1-1. Google Chrome; 
      1-2. Mozilla Firefox; 
      1-3. Opera; 
      1-4. Vivaldi。
    2. 打开 WebAssembly支持 : 
      2-1. Google Chrome:chrome://flags/#enable-webassembly; 
      2-2. Mozilla Firefox:about:config→接受→搜索javascript.options.wasm→设置为true; 
      2-3. Opera:opera://flags/#enable-webassembly; 
      2-4. Vivaldi:vivaldi://flags#enable-webassembly。

    访问:http://webassembly.org/demo/

    使用W、A、S、D等键实现移动操作,点击鼠标进行射击。该WebAssembly游戏在浏览器中运行相当流畅,媲美原生性能。

    除了最新的浏览器开始对WebAssembly逐步支持外,Intel开源技术中心开发的Crosswalk项目(https://crosswalk-project.org/)早在2016年11月初的Crosswalk 22稳定版(Windows及Android 平台)即已加入对WebAssembly实验性的支持,开发者可以使用该版本体验Angry Bots Demo。

    开发者

    WebAssembly对于Web有显著的性能提升,对于开发者尤其是前端或者JavaScript开发人员而言,并不意味着WebAssembly将会取代JavaScript(如图14所示)。

    图片描述

    图14 WebAssembly与JavaScript引擎的关系

    WebAssembly被设计为对JavaScript的补充,而不是替代,是为了提供一种方法来获得应用程序的关键部分接近原生性能。随着时间的推移,虽然WebAssembly将允许多种语言(不仅仅是C/C++)被编译到Web,但是JavaScript的发展势头不会因此被削弱,并且仍然将保持Web的单一动态语言。此外,由于WebAssembly构建在JavaScript引擎的基础架构上,JavaScript和WebAssembly将在许多场景中配合使用。

    那么WebAssembly是不是仅仅面向C/C++开发者呢?答案依旧是否定的。WebAssembly最初实现的重点是C/C++,由Mozilla主导开发的注重高效、安全和并行的Rust也能在2016年末被成功编译到WebAssembly了,未来还会继续增加其他语言的支持,见代码11。 
    图片描述

    代码11

    在未来,通过ES6模块接口与JavaScript集成,Web开发人员并不需要编写C++,而是可以直接利用其他人编写的库,重用模块化C++库可以像使用JavaScript中的modules一样简单。

    进展

    依据开发路线图,2016年10月31日,WebAssembly到达浏览器预览的里程碑。Google Chrome V8引擎及Mozilla Firefox SpiderMonkey引擎都已经在trunk上支持WebAssembly浏览器预览。2016年12月下旬,Microsoft Edge浏览器使用的JavaScript引擎ChakraCore v1.4.0启用了WebAssembly浏览器预览支持。而Webkit JavaScriptCore引擎对于该支持也在积极进行中。

    目前,WebAssembly社区组已经有初始(MVP)二进制格式发布候选和JavaScript API在多个浏览器中实现。作为浏览器预览期间的一部分,WebAssembly社区组(WebAssembly Community Group)现在正在征求更广泛的社区反馈。社区组的初步目标是浏览器预览在2017年第一季度结束,但在浏览器预览期间的重大发现可能会延长该周期。当浏览器预览结束时,社区组将产生WebAssembly的草案规范,并且浏览器厂商可以开始默认提供符合规范的实现。预计在2017年上半年,四大主流浏览器对原生的WebAssembly支持将到达稳定版。

    具体到Google V8引擎的最新进展,asm.js代码将不再通过Turbofan JavaScript编译器而是编译到WebAssembly后,在WebAssembly的原生执行环境中执行最终的机器码。这种改变带来的好处有,为asm.js将预先编译(AOT,Ahead Of Time Compilation)带到了Chrome,且完全向后兼容。新的WebAssembly编译渠道重用了一些Turbofan JavaScript编译器后端部分,因此能够在少了很多编译和优化消耗的前提下,产生类似的代码。在Google Chrome中,WebAssembly将很快在Canary版中默认启用,开发团队也期望能够发布到2017年第一季度末的稳定版中。

    社区

    包含所有主要浏览器厂商代表的W3C Web——Assembly社区组于2015年4月底成立。该小组的任务是,在编译到适用于Web的新的、便携的、大小和加载时间高效的格式上,促进早期的跨浏览器协作。该社区组也正在将WebAssembly设计为W3C开放标准。目前,除了文中所述主流浏览器厂商Mozilla、Google、微软、及苹果公司之外,Opera CTO及Intel的8位该领域专家均参与了该社区组。当然,并不是只有社区组成员才能参与标准的制定,任何人都可以在https://github.com/WebAssembly做出贡献。

    展望

    由于主要的浏览器厂商对WebAssembly支持表现积极,并且都在实现WebAssembly的各项功能,因此在Web中高性能需求的应用例如在线游戏、音乐、视频流、AR/VR、平台模拟、虚拟机、远程桌面、压缩及加密等都能够获得接近于原生的性能。相信WebAssembly将会开创Web的新时代。

    作者:张敏,Intel开源技术中心Web团队软件技术经理,原Opera Software软件经理,在浏览器及Web Runtime领域工作10年,专注于Web及开源技术。 

    展开全文
  • 再次强调,Blazor 是一套前端框架, Vue/Angular/React 三大框架是一回事。不同的是 Blazor 采用的是 C# 作为编程语言,而它可以基于 .NET Core 的体系,与 MVC / Razor Page / WebApi 框架进行混用,并且开发人员...
  • by fanxiushu 2018-08-21 转载或引用请注明原始作者。 到目前为止,包括本文发布了六个系列,能坚持到现在也属不易。 第一篇:https://blog.csdn.net/fanxius...
  • 音视频技术开发周刊 | 160

    千次阅读 2020-09-07 00:06:32
    每周一期,纵览音视频技术领域的干货。新闻投稿:contribute@livevideostack.com。架构WebRTC 1.0 标准中更新了 Candidate 筛选优先级内容Web...
  • go技术文章精选(2019)

    千次阅读 2020-01-03 00:52:06
    gocn_news_set_2019 gocn_news_2019-12-31 Go 系列教程:https://dev.to/digitalocean/how-to-code-in-go-32p0 Go modules:最小版本选择 ...部署服...
  • go技术文章梳理(2018)

    千次阅读 2020-01-03 09:50:29
    gocn_news_2018-12-31 Go 入门简介:http://t.cn/EbjzeSt Go GraphQL 新手指南: https://tutorialedge.net/golang/go-graphql-beginners-tutorial/ 你需要 Go web 框架吗:...
  • 在上一篇文章《只需5分钟,教你如何编写并执行一个 Rust WebAssembly 程序》,我们对 Rust 到 Wasm 的编译以及简单的浏览器内 Wasm 执行的案例做了演示。 在另外一篇文章《区块链、硬件与面向服务的架构,WASM 即将...
  • 前端开发中的基础思考题

    千次阅读 2018-08-27 00:38:00
    前些日子在忙着面试,拿了心仪的 offer 以后闲下来整理了一些面试相关的基本概念。由于很多关于代码细节的东西之前的博客都有更详细的解释,所以本文涉及代码细节比较少,主要是面试相关的概念,也是前端比较零碎的...
  • 2020 年软件开发趋势预测!

    千次阅读 2019-12-23 01:13:01
    再过几周,2019年行将结束,我们将迎来新的2020年。对于软件开发行业来说,即将过去的2019年是个伟大的一年,因为软件数字化深入地影响到了每个行业。这一趋势将延续下去,并将在202...
  • 前端开发面试题及答案

    万次阅读 2016-04-11 17:03:09
    本文由我收集总结了一些...前端还是一个年轻的行业,新的行业标准, 框架, 库都不断在更新新增,正如赫门在2015深JS大会上的《前端服务化之路》主题演讲中说的一句话:“每18至24个月,前端都会难一倍”,这些变化使
  • WTF_Daily_Blog

    千次阅读 2017-10-25 18:57:09
    徒步中的程序猿-重庆出发 TensorFlow练习27: 验证码生成器-从文本生成图像 从2D图片生成3D模型(3D-GAN) TensorFlow练习26: AI操盘手 随机器学习兴起的Julia编程语言 TensorFlow练习25: 使用深度学习做阅读...
  • 音视频技术开发周刊 | 140

    千次阅读 2020-04-20 10:54:50
    每周一期,纵览音视频技术领域的干货新闻投稿:contribute@livevideostack.com。架构为什么您的视频会议系统不互相集成主要是因为当大多数公司希望成为 SaaS ...
  • 这是一个 Go 相关的框架,库软件的精选清单,引用自awesome-go项目,并翻译补充而来这是一个 Go 相关的框架,库软件的精选清单,引用自awesome-go项目,并翻译补充而来 如果看到不再维护的项目,请及时联系...
  • AMF(Action Message Format)在开发Flash/Flex应用中使用频率是非常...本文将结合FluorineFx来提供通信服务接口,在客户端通过Flex来访问,简单的介绍下关于使用FluorineFx的AMF(Action Message Format)协议通信的用法。
  • 大会简介TLC 腾讯直播大会(Tencent Live Conference,简称 TLC),是由腾讯看点团队打造,由IVWEB团队(https://ivweb.io/)主办的面向全球大...
  • 前端html+css+js面试题

    千次阅读 2018-10-07 15:57:31
    amp;CSS: 对Web标准的理解(结构、表现、行为)、浏览器内核、渲染原理、依赖管理、兼容性、CSS语法、层次关系,常用属性、布局、选择器、权重、盒模型、 ...amp; 存储、Histoy,多媒体、WebGL\SVG\Canvas);...
  • 译者:楚人Leo译文:http://www.cnblogs.com/leolion/p/10585834.html原文:https://msdn.microsoft.co...
1 2 3 4 5 ... 8
收藏数 146
精华内容 58
关键字:

webassembly 和远程通信