What is Blazor
What is Blazor
Blazor 是一个单页应用程序开发框架。Blazor 是单词 Browser 和 Razor (.NET HTML 视图生成引擎)。这意味着 Blazor 不需要在服务器上执行 Razor 视图来向浏览器显示 HTML,而是能够在客户机上执行这些视图。
Blazor 还支持在服务器上执行 SPA。
What Blazor is not
Blazor 不同于微软之前尝试托管浏览器内应用程序的 Silverlight。需要一个浏览器插件才能在客户端上运行,这使得它无法在 iOS 设备上运行。
Blazor 不需要在客户端安装任何类型的插件来在浏览器中执行。Blazor 要么运行服务器端,在这种情况下,它在服务器上执行,浏览器就像一个哑终端(a dumb terminal),要么利用 WebAssembly 在浏览器本身运行。
由于 WebAssembly 是一个网络标准,所有主流浏览器都支持它,这意味着客户端 Blazor 应用程序将在 Windows/Linux/Mac/Android 和 iOS 的浏览器中运行。
Blazor is open-source
Blazor 源代码可以在这里找到。源代码由 The .NET 基金会,这是一个非营利组织基金会,旨在支持基于 .NET 框架。
根据. NET 基金会的数据,在撰写本文时,它已经得到了3700家公司的支持,拥有61000名贡献者。
What is WebAssembly
WebAssembly (缩写为“ Wasm”)是一个指令集,设计用于在任何能够解释这些指令的主机上运行,或者将它们编译成本机代码并执行它们。
Wasm 是以特定的二进制格式格式化的指令集(binary format instractions)。因此,任何遵循此规范的主机(硬件或软件)都能够读取二进制文件并执行它们——或者解释,或者直接编译为特定于设备的机器语言。
类似于把 .NET 源代码编译成公共指令集(通用中间语言)。就像在 .NET 中,c#等高级语言可以生成Wasm。
Blazor 不需要在客户机上安装.NET 来运行 WebAssembly。
Blazor hosting models
Blazor 目前有两种托管模型,服务器端 Blazor 和 Web 程序集(sever-side Blazor and Web Assembly)。服务器端托管于2019年9月发布,Web Assembly 于2020年5月正式发布。
Blazor Web Assembly
Pros(优点)
Web Assembly 在客户机上运行,在浏览器内运行,因此可以将其作为静态文件部署。尽管如此,由于浏览器安全限制,Blazor Wasm 应用程序不能直接从本地文件系统运行。
Blazor Wasm 可以离线工作。当与服务器的网络连接丢失时,客户端应用程序可以继续运行(显然它不能与服务器通话来检索新数据)。
它也可以很容易地作为一个渐进式 Web 应用程序(PWA)运行,这意味着客户端可以选择将我们的应用程序安装到他们的设备上,并在任何时候运行它,根本不需要任何网络访问。
随着代码在客户机上运行,这意味着服务器负载显著减少。
Cons(缺点)
blazor.webassembly.js
文件引导客户端应用程序。它可以下载所有需要的内容 .NET DLL 程序集,它使应用程序的启动时间比第一次运行应用程序时的服务器端慢(然后由浏览器缓存 DLL,使后续的启动时间快得多)。
Mono Framework 解释 .NET 的中间语言比运行服务器端的 Blazor 要慢。计划在将来的版本中进行预先编译(AOT)。
Blazor Wasm 还不支持多于一个线程,因此所有处理都发生在 UI 线程上——尽管对服务器/JavaScript 等的调用是异步的,所以不要阻塞 UI 的响应。
此外,Blazor Wasm 只能在较新的浏览器上使用,并且不支持搜索引擎(除非我们启用服务器端预呈现)。
Blazor sever-side
Pros(优点)
Blazor 服务器端预先呈现 HTML 内容,然后再将其发送到客户端的浏览器。这使得它的搜索引擎友好,并没有可察觉的启动时间。
Blazor 服务器端的应用程序可以在老的浏览器上工作(比如 google Internet Explorer 11) ,因为它不需要 Web Assembly,只需要 HTML 和 JavaScript。当代码在服务器上执行时,也可以调试我们的 .NET 的代码。
Cons(缺点)
Blazor 服务器端为当前客户机设置内存会话,并使用 SignalR 维持 .NET 服务器与客户端浏览器的通信。对于所有用户来说,所有的内存和 CPU 使用都是服务器付出代价的。这也意味着客户机被绑定到第一个为其服务的服务器,因此无法进行负载平衡。
一旦初始页面被渲染并发送到浏览器,blazor.server.js
文件就会钩住浏览器中任何相关的用户交互事件,这样它就可以在用户和服务器之间进行中介。例如,如果呈现的元素注册了@onclick
事件,blazor.server.js
将挂接到它的 JavaScript onclick
事件,然后使用它的 SignalR 连接将该事件发送到服务器并执行相关的 .NET 代码。
<p>
Current count = @CurrentCount
</p>
<button @onclick=IncrementCount>Click me</button>
@code
{
private int CurrentCount;
public void Increment()
{
CurrentCount++;
}
}
在.NET代码完成后,Blazor将在页面上重新呈现组件,然后将HTML增量包发送回客户端浏览器,这样它就可以更新其显示,而不必重新加载整个页面。
Travel
如果我们运行一个标准的 Blazor 应用程序,单击菜单中的 Counter 链接,然后单击 Click me 按钮,我们就可以观察到与服务器之间的 SignalR 数据通信。
- 在 Chrome 浏览器中运行应用程序。
- 点击应用程序菜单中的 Counter 链接。
- 按 f12打开浏览器的开发工具。
- 在开发人员工具窗口中,单击“网络”选项卡。
- 重新加载页面
- 下一步,点击
WS
标签(WebSocket 的缩写) - 单击 _blazor 项以显示套接字数据。
- 单击 Click me 按钮将显示类似下面的网络流量(为便于阅读而删节和格式化)。
结果是服务器的响应如下:DispatchBrowserEvent
{
"browserRendererId": 0,
"eventHandlerId": 3,
"eventArgsType": "mouse",
"eventFieldInfo": null
}
{
"type": "click",
"detail": 1,
"screenX": 338,
"screenY": 211,
"clientX": 338,
"clientY": 109,
"button": 0,
"buttons": 0,
"ctrlKey": false,
"shiftKey": false,
"altKey": false,
"metaKey": false
}
注意: 突出显示的1表示增量 HTML,是计数器的新值。
如果客户端的浏览器和服务器没有关闭,或者它们之间的网络连接很慢,特别是在触发状态变化的事件频繁发生的情况下,这种往返可能会提供一种缓慢的体验。例如,像 onmousemove
这样的事件会经常发生。
此外,需要大量 HTML 增量更新的更改也可能很慢。例如,如果我们的页面中有一个 HTML <textarea>
组件,它在用户输入时更新显示区域以预览用户的输入,那么服务器中的增量 HTML 将随着每个字符添加到 <textarea>
而增加。当输入内容变大时,每次按键都会导致大量的网络传输。
不像 Blazor Wasm,一旦从浏览器到服务器的连接中断,应用程序就会失去响应能力。Blazor 将尝试重新建立到服务器的连接,但是,在成功之前,应用程序会显示消息“尝试重新连接到服务器…”并阻止所有与用户界面的鼠标交互。
Blazor Mobile Bindings
2020年1月,微软发布了 Blazor Mobile Bindings,这是一个实验性项目,允许开发者使用 Blazor 和 Xamarin 的 Razor 变体组合开发本地移动应用。表格(XAML)。
你可以在这里找到官方公告。