本文要点

WebAssembly是一种新的客户端技术，可以在所有现代浏览器（包括移动浏览器）中实现近乎原生的性能，而且不需要插件。
许多语言，包括C、C#、Go和Rust，都可以编译成面向基于栈的WebAssembly虚拟机的代码。
.NET代码可以在任何地方运行，包括浏览器内部。
Blazor是一个客户端库，它在WebAssembly上使用.NET来支持借助Razor模板使用C#编写的单页应用程序。
Blazor支持代码重用和将遗留代码移植到现代Web应用程序的能力。

在2019年4月中旬，微软悄悄地推出了一个年轻的框架，从“一切皆有可能”的实验阶段过渡到“我们致力于实现这一目标”的预览版。这个框架名为Blazor，因为它在浏览器中运行，并利用了一个名为Razor的模板系统或“视图引擎”，促成了这个.NET开发人员几乎放弃了的场景。它不仅允许开发人员使用C#构建客户端代码（不需要JavaScript），还允许开发人员在没有插件的情况下在浏览器中运行现有的.NET标准DLL。

Blazor有两种托管模式。本文主要关注客户端版本。你可以阅读“Blazor服务器端托管模型”了解更多关于服务器端版本的信息。

Silverlight的希望

在任何地方运行.NET的梦想始于2006年，当时有一个名为“Windows Presentation Foundation/Everywhere（WPF/E）”的应用程序框架以Silverlight的形式向公众发布。第一个版本支持通过WPF引入的声明性用户界面，即可扩展应用程序标记语言（Extensible Application Markup Language，简称XAML）。该平台提供了对UI元素的细粒度控制，并提供了自己的文档对象模型（DOM），可以通过JavaScript访问。

当Silverlight 2在2008年发布时，它通过一个作为浏览器插件运行的公共语言运行时（CLR）实现.NET的完全支持，从而加快了采用速度。开发人员可以使用任何.NET语言来构建Web应用程序，利用成熟的数据绑定模式，如Model-View-ViewMode（MVVM），并使用REST或Windows Communication Foundation（WCF）客户端与Web API通信。看起来，.NET开发人员可以摆脱JavaScript的束缚，不用再担心跨浏览器测试，而是专注于一个具有公共代码库的平台来交付他们的应用程序。

Silverlight开发者不知道的是，2007年对于这个平台来说是艰难的一年。两个看似不相干的事件发生了，最终导致了它的灭亡。首先，Web超文本应用技术工作组（WHATWG）和万维网联盟（W3C）之间开始着手合作编写将于2008年发布的HTML5规范初稿。

第二，2007年6月29日，苹果发布了iPhone。

每隔一段时间，我们就会有一件革命性的产品横空出世，并彻底改变一切。
——史蒂夫•乔布斯

比赛开始了。手机几乎是在一夜之间从带有联系人列表的翻盖手机发展到带有游戏和内置网络浏览器的便携式电脑。在很短的一段时间内，Silverlight的未来似乎充满了希望。微软对iPhone的回应是Windows Phone 7，支持以Silverlight作为开发平台。Chrome支持即将到来。如果微软能够找到一种将Silverlight应用到iPhone和Android手机上的方法，那么“一次编写，到处运行”的圣杯将最终被发现。

只是，它没有找到。

出于许多原因，包括运行“浏览器中的虚拟机”的安全性考虑，以及潜在的电池消耗，通向浏览器插件的大门砰地关上了，特别是在移动设备上。业界开始期待HTML5在打造移动体验方面的前景。微软改变了自己的关注点，到2011年Silverlight 5发布时，大多数开发人员已经看到了不祥之兆：不会再有新版本了。

HTML5和JavaScript继续赢得Web开发人员的青睐。jQuery等工具对DOM进行了标准化，使构建多浏览器应用程序变得更加容易，同时，浏览器引擎开始采用通用的DOM标准，使“一次构建，到处运行”变得更加容易。Angular、React和Vue.js等前端框架的爆炸式增长使单页应用程序（SPA）成为主流，并巩固了JavaScript作为浏览器操作系统首选语言的地位。

JavaScript即平台

2013年3月，asm.js正式推出。其文档把它描述为JavaScript的一个严格子集，可以用作编译器的一种低级、高效的目标语言。该规范本质上定义了一组JavaScript约定，这些约定使通过提前编译优化代码成为可能，并提供了强类型（JavaScript本身是一种动态语言）和基于堆的内存模型。

Asm.js的推出使将C/C++代码编译成JavaScript成为可能，从而开启了一个新的可能性领域。对约定的限制使得“支持asm.js”的引擎可以有效地将JavaScript编译成高性能的本地代码。为了更好地理解这是如何实现的，请考虑下面的C代码片段：

int find(char *buf, char test) {
    char *cur = buf;
    while (*cur != 0 && *cur != test) {
        cur++;
    } 
    if (*cur == 0) {
        return -1;
    }
    return (cur - buf);
}

该代码有效地扫描一个字符串，寻找标记其结束的测试字符或零字节，并计算偏移量。C++已经可以使用一个名为Clang的工具编译成字节码，该工具与LLVM工具链兼容。LLVM是一组支持快速跨平台编译代码的技术。一个名为Emscripten的项目利用该工具链来生成asm.js。

使用Emscripten编译C++代码可以生成几十行高度优化的JavaScript。以下代码经过简化，用于说明生成的内容：

function find(buf, test) {
    buf = buf|0;
    var cur = buf|0;
    var result = -1|0;
    while (1) {
        var check = HEAP8[cur>>0]|0;
        var foundZero = (check) === (0);
        if (foundZero) {
            break;
        }
        var foundTest = (check) === (test|0);
        if (foundTest) {
            result = (cur - buf)|0;
            break;
        }
    }
    return result|0;
}

生成的JavaScript与所有浏览器兼容并且运行良好。带零操作的异或（|0）可以很容易地将任何数字转换为带符号整数。在较老的浏览器中，这可以确保数字没有小数部分。在现代浏览器中，该约定可以提前通知编译器使用32位整数（使数学运算更快），而不是默认的64位浮点值。0右移（>>0）可以防止溢出，它还声明了一个“索引”整数类型，该类型在HEAP8上迭代，而HEAP8是一个可以在asm.js中使用的类型化的字节缓冲区。

在asm.js中没有定义for循环。所有内容都被转换为while(1)循环。这使得应用编译器优化变得更容易。这些优化非常有效，以至于一个团队能够将Unreal 4引擎移植到Web浏览器中，以近乎原生的性能直接运行3D第一人称视角游戏。

WebAssembly：新希望

时间很快来到2017年，WebAssembly发布了，这是一种基于栈的虚拟机的二进制指令格式。WebAssembly提供了一个可移植的编译目标（简称Wasm），与asm.js相比，它有几个优点：

作为字节码格式，不需要解析脚本和预编译来进行优化。代码可以直接翻译成本机指令。与asm.js相比，加载和开始执行代码的启动时间要快几个数量级。
字节码格式是一种更紧凑的代码交付方式。
Wasm实现了自己的指令集，因此不受JavaScript语言的限制。

任何编译成asm.js的代码都可以把WebAssembly作为目标。对于前面的示例，编译器标志的一个简单修改就会生成一个扩展名为.wasm的文件。该文件只有116字节长。尽管该文件包含字节码，但也存在代码的标准化文本表示形式，名为WebAssembly文本格式。这是WebAssembly中find模块的文本表示：

(module
  (type $t0 (func (param i32 i32) (result i32)))
  (import "env" "memory" (memory $env.memory 256 256))
  (func $a (type $t0) (param $p0 i32) (param $p1 i32) (result i32)
    (local $l0 i32) (local $l1 i32) (local $l2 i32) (local $l3 i32)
    get_local $p0
    set_local $l0
    loop $L0
      get_local $l0
      i32.load8_s
      tee_local $l2
      i32.eqz
      set_local $l1
      get_local $l0
      i32.const 1
      i32.add
      set_local $l3
      get_local $l1
      i32.const 1
      i32.xor
      get_local $p1
      i32.const 24
      i32.shl
      i32.const 24
      i32.shr_s
      get_local $l2
      i32.ne
      i32.and
      if $I1
        get_local $l3
        set_local $l0
        br $L0
      end
    end
    i32.const -1
    get_local $l0
    get_local $p0
    i32.sub
    get_local $l1
    select)

代码大小进行了优化，因此函数被重命名为了a。

WebAssembly现在是1.x稳定版，支持所有的现代浏览器，包括手机。若干语言都以Wasm作为有效的编译目标。你可以使用C、C++、Go、Rust、TypeScript和许多其他语言来构建WebAssembly程序。它已经应用于计算机视觉、音频混合、视频编解码器支持、数字信号处理、医学成像、物理模拟、加密、压缩等解决方案中。

但是C#呢？

在WebAssembly推出之后，将. NET框架的工作版本（包括它的公共语言运行时）移植到WebAssembly上运行的工作就立即开始了。

这一努力取得了成功。

浏览器和Razor视图引擎

2017年底，微软软件工程师Steve Sanderson在他的个人博客上宣布了Blazor的消息。当时，它“只是一个实验”，并不是正式产品。它始于这样一个问题：“我们如何让.NET在WebAssembly中运行？”第一个答案是比较老的简化版.NET运行时，他能够在几个小时内将其编译成Wasm二进制文件。.NET本身在浏览器中并不是非常有用：你需要一个UI和某种与用户交互的方式。Razor文件将标记和C#结合起来创建Web模板，基于这项扎实的工作，Blazor添加了大量的服务，从数据绑定和依赖注入到可重用组件、布局，以及调用JavaScript和从JavaScript调用。所有这些服务结合使得使用.NET和C#构建单页面应用程序（SPA）成为可能。

图1 默认Blazor应用程序

为什么会有人在意呢？开发人员最初对Blazor的反应非常积极，这主要是因为：

它允许开发人员使用他们已经熟悉的语言（C#）和框架（.NET）来构建以前深深扎根在JavaScript中的客户端应用程序。
它可以在所有现代浏览器中运行，包括移动浏览器，而且不需要插件。
它使开发人员能够进入.NET生态系统并“按原样”使用现有的库。例如，如果你正在构建一个使用Markdown的博客引擎，那么你可以为现有的Markdown引擎安装NuGet包，并将Markdown直接转换为HTML，以便在浏览器中预览。
.NET的性能会随着时间的推移不断提高，因此在浏览器的Wasm上运行已经足够了。
Blazor是一个真正的单页应用程序，它从一组静态资产运行，可以使用Azure Storage静态网站等服务以非常低的成本托管这些静态资产。

现在，你已经了解了Blazor背后的历史和动机，让我们来研究一些技术细节。

本文中的所有代码示例都可以在Blazor WebAssembly GitHub存储库中找到。

安装Blazor并开始使用所需要了解的所有内容都可以在Blazor入门这篇文章中找到。在安装了Blazor之后，你可以选择只创建客户端或带有ASP.NET Core后端的客户端。对于现有的基于MVC的服务器端项目来说，该项目看起来非常熟悉。但是，生成的DLL直接加载到浏览器中，并由.NET的WebAssembly版本运行。

图2 Blazor应用中的网络活动

Mono.js JavaScript动态加载mono.wasm并开始在浏览器中运行.NET。其余的加载是组成应用程序的实际DLL文件。

浏览器中的C#（带依赖注入）

默认模板包含一个获取模拟天气信息的页面。这是Razor视图，完全由Wasm在客户端上渲染。

<h1>Weather forecast</h1>

<p>This component demonstrates fetching data from the server.</p>

@if (forecasts == null)
{
    <p><em>Loading...</em></p>
}
else
{
    <tableclass="table">
        <thead>
            <tr>
                <th>Date</th>
                <th>Temp. (C)</th>
                <th>Temp. (F)</th>
                <th>Summary</th>
            </tr>
        </thead>
        <tbody>
            @foreach (var forecast in forecasts)
            {
                <tr>
                    <td>@forecast.Date.ToShortDateString()</td>
                    <td>@forecast.TemperatureC</td>
                    <td>@forecast.TemperatureF</td>
                    <td>@forecast.Summary</td>
                </tr>
            }
        </tbody>
    </table>
}

在模板的上部，一组指令决定了页面的路径，声明了一个using指令，并使用依赖注入来获取.NET Framework的HttpClient副本，该副本可以在浏览器中使用。

@page "/fetchdata"
@using GetStarted.Shared
@inject HttpClient Http

最后，页面上的一小段代码嵌入到@functions块中。这里需要注意的是，代码完全是C#的。你可以使用熟悉的HttpClient执行网络操作，并且支持async/wait。

WeatherForecast[] forecasts;

protected override async Task OnInitAsync()
{
    forecasts = await Http.GetJsonAsync<WeatherForecast[]>("api/SampleData/WeatherForecasts");
}

视图模板渲染一个页面，但是控件呢？

可重用组件

Blazor基于分层组件的可组合UI。天气预报组件与其他组件的唯一区别是提供路由的页面指令。下面是一个名为LabelSlider.razor的组件的模板，使用一个显示当前值的span扩展内置的HTML Input Range。

<inputtype="range"min="@Min"max="@Max"bind-value-oninput="@CurrentValue"/>
<span>@CurrentValue</span>

绑定语法的格式为bind-{property}-{event}。事件是可选的，触发事件时绑定会更新。如果没有这个，滑块只会在用户停止移动滚动条时更新span。通过连接到oninput，该值将随着滑块的移动而刷新。

关联的代码暴露了参数，这些参数允许父组件设置最小和最大范围值，并将数据绑定到当前值。Action属性暴露一个与CurrentValue关联的事件，并按照约定将其命名为CurrentValueChanged，以方便双向数据绑定（父组件可以“侦听”更改事件并相应更新绑定值）。

[Parameter]
int Min { get; set; }

[Parameter]
int Max { get; set; }

private int _currentValue;

[Parameter]
int CurrentValue
{
    get => _currentValue;
    set
    {
        if (value != _currentValue)
        {
            _currentValue = value;
            CurrentValueChanged?.Invoke(value);
        }
    }
}

[Parameter]
Action<int> CurrentValueChanged { get; set; }

注意，没有使用Parameter属性标记的属性只对组件可见。组件重用非常简单，只需把组件名置入标签并提供必要的参数，用法如下：

<LabelSlider Min="0" Max="99" bind-CurrentValue="@currentCount"/>

在本例中，一个与父组件上的currentCount属性之间的双向绑定建立起来了。

使用现有的库

Blazor的一个非常强大的优点是能够“按原样”集成现有的类库。例如，考虑一个使用Markdown的博客引擎，它能够在浏览器中预览生成的HTML。在Blazor中构建它就像安装一个NuGet包一样简单，在本例中是开源的MarkDig处理器。然后，可以直接调用库：

var html = Markdig.Markdown.ToHtml(SourceText);

NuGet DLL像其他项目引用一样被导入浏览器，并且可以从客户端应用程序调用。

图3 浏览器中的Markdown转换

调用JavaScript/从JavaScript调用

Blazor提供的一个重要服务是能够从.NET调用JavaScript，反之亦然。你希望从Blazor调用的任何JavaScript方法都必须能够从全局window对象访问，调用方法如下：

window.jsAlert = msg => alert(msg);

该互操作功能的使用方式如下：

await JsRuntime.InvokeAsync<object>("jsAlert", "Wow!");

InvokeAsync方法支持传递和返回值，这些值将自动在JavaScript与.NET之间转换并由Blazor运行时编组。使用JsInvokable属性来暴露C#方法，以便可以从JavaScript调用它。下面是一个例子，它封装了Markdown转换调用：

public static class Markdown
{
    [JSInvokable]
    public static string Convert(string src)
    {
        return Markdig.Markdown.ToHtml(src);
    }
}

从JavaScript调用DotNet.invoke方法并传递程序集名称、暴露的方法名称和任何参数。

图4 从JavaScript调用.NET

这使得扩展遗留应用程序和使用现有的JavaScript库成为可能。你甚至可以从Blazor应用程序调用其他WebAssembly模块。

Blazor在发展

微软将Blazor移出了实验阶段，进入了官方预览版。使用组件模型进行服务器端渲染的Blazor版本将与.NET Core 3的最终版本一起发布（请参阅.NET Core路线图），客户端版本将在随后不久发布。还有工作要完成：调试体验极其有限，必须改进；有机会通过提前编译生成本机Wasm来优化代码性能；在将未使用的代码库发送到浏览器之前，需要从库中删除未使用的代码，从而降低总体大小（这个过程称为树抖动）。对WebAsssembly的兴趣和采用与日俱增，借助Blazor，编写可以在任何地方运行的C#和.NET代码的梦想终于实现了。

关于作者

Jeremy Likness是微软Azure的云推广专员。Jeremy在1982年编写了他的第一个程序，并且已经开发企业应用程序25年了。他是四本科技书籍的作者，曾做过8年微软MVP，是国际性的主题演讲家。Jeremy的饮食以植物为主，在大部分空闲时间里，他都在太平洋西北部他的家附近跑步、徒步旅行和露营。关注Jeremy的博客。

查看英文原文：：WebAssembly and Blazor: A Decades Old Problem Solved

创作场景

WebAssembly 和 Blazor：解决了一个存在十年的老问题