客户端UI框架Blazor的特性和技术内幕
在过去一两年里，如果你一直在关注.NET世界的最新发展，则有可能听说过Blazor提到过这个词有两次左右。 Blazor是来自 ASP.NET团队的新的客户端UI框架。 它的最大卖点是能够使用HTML、CSS和C＃，而不是JavaScript编写丰富的Web UI体验，这是许多开发人员梦寐以求的。
自JavaScript诞生以来，JavaScript就已经成为事实上的前端Web开发标准，但我们似乎从未真正对此感到满意过。 我的意思是，这些年来涌现了多少种超集或可转换为JavaScript语言，来帮助改进JavaScript并使其更易于维护？ 比如CoffeeScript、Dart、Elm和Scala 等。
根据最受欢迎的语言的图表来看，TypeScript位居榜首。 设计C＃的人添加了诸如接口、类、编译时类型检查甚至泛型之类的功能。 但是，所有这些功能以及C＃本身已经存在的很多功能已经使用了很多年。 C＃是一种功能强大、灵活并且功能丰富的语言，易于学习。
但是Blazor已经开始显示出它的潜力，即作为其原始设计之外的高效编程模型，它是JavaScript单页应用程序（SPA）框架的直接竞争对手。
微软已经在Blazor上进行了多次实验，并使用 Electron 和WebWindow （Electron的实验性轻量级替代品）。 但是最近，对于本地移动应用程序开发，Blazor编程模型却与本地 Xamarin 表单控件混合在一起。
我们是否可以看到一个统一的UI框架的开始，而该框架就可以使用.NET构建任何类型的应用程序，无论是Web、桌面还是移动应用程序？ 就比如我不认识你，但我肯定会找到一个令人兴奋的前景。
Blazor易用的原因
要回答这个问题，我们需要了解Blazor是如何设计的。
本质上，Blazor在如何计算UI更改（应用程序/组件模型）与如何应用这些更改（渲染器）之间是有区别的。 这使Blazor与只能创建基于Web技术的UI的其他UI框架（例如Angular或ReactJS / React Native）区分开。 通过使用不同的渲染器，Blazor不仅可以创建基于Web的UI，而且还可以创建本机移动UI。
这确实需要对组件进行不同的创作，因此为Web渲染器编写的组件不能与本机移动渲染器一起使用。 但是，编程模型是相同的。 这就意味着开发人员一旦熟悉它，便可以使用任何渲染器创建UI。
Render/Hosting模式
Blazor的应用程序/组件模型的核心是负责计算UI的更改，但是您可以使用不同的渲染器来控制UI的实际显示和更新方式。 这些渲染器通常被称为托管模型。 在撰写本文时，Blazor在开发的不同阶段中有四种托管模式。
Blazor服务器（远程渲染器）
- Platform: Web
- Status – GA/Production Supported
Blazor WebAssembly （WebAssembly渲染器）
- Platform: Web
- Status: Preview (Committed Product)
Blazor Electron （电子渲染器）
- Platform: Desktop (Windows, Mac, and Linux)
- Status: Experimental (Not Committed)
移动Blazor绑定（MobileBlazorBindings渲染器）
- Platform: Mobile (iOS and Android)
- Status: Experimental (Not Committed)
在撰写本文时，Blazor Server是唯一受生产支持的模型。 Blazor WebAssembly将于2020年5月左右发布-我希望这可能是 Build 上的重要公告。 Blazor Electron和Mobile Blazor绑定都被标记为实验性的，Microsoft尚未承诺将其交付。
App/Component 模式
这是框架的引擎室。 在这里，我们可以找到使Blazor工作的所有非UI特定元素。 编程模型、路由、导航以及渲染树，这是Blazor用于计算UI更改的机制。
我要重点关注的部分是编程模型。 在上面我提到的四种托管模型中，前三种具有一个共同点：它们都了解Web标准。 针对这些托管模型而编写的组件将使用HTML和CSS。 但是第四个模型Mobile Blazor绑定完全不了解网络标准。 为此托管模型构建的应用程序将需要使用本机移动控件编写其组件。
为了提供更直观的示例，我们来看一下为Blazor WebAssembly编写的相同组件，该组件使用符合Web标准的渲染器，而Mobile Blazor Bindings则使用基于非Web标准的渲染器。
// WebAssembly Renderer
Current count: @currentCount
@code {
private int currentCount = 0;
private void IncrementCount()
{
currentCount++;
}
}
// MobileBlazorBindings Renderer
@code {
private int currentCount = 0;
private void IncrementCount()
{
currentCount++;
}
}
可以很容易地看到示例的两个代码之间的差异，但是我希望你能着重关注介绍的相似之处。
这两个样本都有一个标记部分和一个代码块。 实际上，样本之间的代码块是相同的。 它们每个都有一个带有指定处理程序的“ OnClick”事件，并且都使用表达式来输出当前计数字段的值。
我在这里要指出的是编程模型是相同的。 这就是Blazor的强大功能，可以学习编程模型，并在各处进行一些调整，你可以在任何平台上为任何类型的应用程序生成UI，而这是我们无法做到的 .NET之前要做的事情。
现在，我们对Blazor的组合方式有了更多的了解，我想谈谈Blazor Server和Blazor WebAssembly这两种主要的托管模型。
Blazor 服务器
Blazor服务器托管模型是当前Blazor开发的唯一受生产支持的选项。 它于.NET Conf期间于2019年9月与.NET Core 3一起发布。
在此模型中，Blazor应用程序在完整的.NET Core运行时之上的服务器上运行。 当用户加载应用程序时，将下载一个小的JavaScript文件，该文件将建立实时的双向 SignalR 与服务器的连接。 然后，用户与该应用程序进行的任何交互都会通过SignalR连接传输回服务器，以供服务器处理。 服务器完成后，所有UI更新都将传输回客户端，并应用于DOM。
我知道你现在在想什么。 这是不可能的，所有这些交互和UI更新都会不断地来回发送。 但实际上，我认为你会感到惊讶。
该团队在Blazor Server上进行了一些负载测试，以确定它可以处理和无法处理的内容，这就是他们发现的内容。
测试1 – Azure上的标准D1 v2实例（1vCPU和3.5GB内存）
该应用程序可以处理 5000个并发活动用户，而性能不会明显下降。
测试2 – Azure上的标准D3 v2实例（4vCPU和14GB内存）
该应用程序可以处理 20,000个并发活动用户，而性能不会出现任何明显下降。
这些数字令人印象深刻，我想你会同意的。 这些实验得出的主要发现是内存和延迟是Blazor Server应用程序的主要瓶颈。 如果延迟时间超过200毫秒，则性能会受到打击，并且扩展空间会受到包装盒上可用内存的限制。
优点
- 在完整的.Net核心上运行
- 快速的开发周期
- 小的下载大小
- 代码保存在服务器上，而不是下载到客户机
缺点
- 在高延迟环境中不能很好地工作
- 没有脱机支持—需要到服务器的持续连接
- 服务器上的大量资源需求
运行在完整的.Net核心运行时上快速开发周期小下载大小。代码保存在服务器上，而不是下载到客户机disadvantages。在高延迟环境中不能很好地工作-没有离线支持-需要不断连接到服务器上的服务器沉重的资源需求交易用例
理想的用例
事实上，我认为Blazor Server可以用于很多情况，但其利基市场将在Intranet应用程序或面向公众的低需求应用程序中。 由于所有内容都在服务器上，因此使用此托管模型的开发速度是非常快的。 速度快是因为不需要单独的API项目，例如，你可以直接在组件中使用应用程序服务。 起初，我对Blazor Server表示怀疑，但是我不得不说，我对它的功能是感到非常的惊讶。
Blazor WebAssembly
这是一个很大的原因，通常是引起人们最大兴趣的托管模型，这些都是有充分理由的。 该模型是Angular、VueJS和React等JavaScript SPA的直接竞争对手。
通过使用WebAssembly，我们可以使用C＃而不是JavaScript编写UI逻辑。 目前处于预览状态，预计于2020年5月左右发布。
编译为WebAssembly的 Mono .NET运行时的版本与应用程序DLL和所有依赖项一起下载到客户端的浏览器中 。 一旦所有内容都放入浏览器中，Mono运行时将被引导，然后依次加载并执行应用程序DLL。
听到上述解释后，我要解决的第一个问题通常是下载大小是多少？ 好吧，当前的预览重约2.4mb，考虑涉及到.NET运行时，这确实令人印象深刻。 但是，与某些JavaScript框架相比，这并不奇怪。 到五月份发布WebAssembly托管模型时，团队希望大幅缩减该规模。 Blazor的第一个原型使用了非常紧凑的.NET运行，该运行仅编译为60k的WebAssembly代码。 我相信大尺寸的改进只是时间问题。
当前，Blazor WebAssembly使用解释模式加载和运行你自己的应用程序。 在这种模式下，Mono IL解释器将在浏览器内执行你的应用程序.NET DLL。 编译为WebAssembly的过程的唯一部分是Mono运行时。 将来，该团队希望允许开发人员选择是否将自己的应用程序或应用程序的更具可能部分也编译为WebAssembly，这称为AOT或Ahead of Time编译。 此模式的好处是性能，但要权衡较大的下载大小。
优点
- 编译成静态文件，这意味着在服务器上不需要.Net运行
- 工作从服务器转移到客户机
- 应用程序可以在离线状态下运行
- 代码共享，c#对象可以很容易地在客户端和服务器之间共享
缺点
- 有效载荷。如果你现在创建一个全新的Blazor项目，它的重量大约是2.4mb。研究小组希望在5月份能大幅削减这一比例。
- 加载时间。由于下载的大小，连接不良的设备可能会经历更长的初始加载时间。
- 受限制的运行时。应用程序必须在浏览器的沙箱中运行，并受到与任何JavaScript应用程序相同的安全限制。
理想用例
Blazor WebAssembly旨在与现代JavaScript框架直接竞争。 因此，在你希望使用这些框架之一的任何地方，都可以考虑使用Blazor。 将Blazor WebAssembly应用程序制作为PWA（渐进式Web应用程序）也很简单。 实际上，五月份将有一个开箱即用的模板。
同样重要的是要指出，使用Blazor WebAssembly不需要你在服务器上使用.NET。 这意味着，如果你有用Node、PHP或Rails编写的后端，则可以愉快地将Blazor用作前端，因为Blazor WebAssembly可以编译为静态文件，因此没有任何问题。
Blazor的未来规划
现在已经有一种托管模型投入生产，另一种即将投入生产，让我们一起将注意力转向未来。
我看到的Blazor去哪了？ 回到我早先关于Blazor成为任何.NET应用程序的单个UI框架的想法中来。 我认为这是Blazor的发展方向。 如果当前所有的Blazor托管模型都投入生产（现在我不知道为什么不这样做），那么开发人员将可以选择学习一个编程模型，并可以在任何地方创建UI。 这是一个大的问题。
该平台的新开发人员在围绕进入.NET的障碍中进行了大量讨论的同时，不得不面对众多选择。Blazor可以在 任何地方，比如UI、单一编程模型、一次学习并应用的过程中提供清晰的信息。 对我来说，这就是Blazor的炒作。