把本文从美团技术沙龙第83期《前端新动向》B站视频进行了整理, 时间长了情况下, 要是容器想达成动态化以及双端复用的目的, 那么不可避免地会舍弃部分性能, 有没有途径能够让动态化容器的性能尽量和原生相近, 美团金服大前端团队给出了一种解决办法, 试着突破动态化容器的上限。4 Recce的一些细节问题5 总结和展望6 Q A注释1 动态化容器的天花板从2015年React推出开始直至如今历经9年时间, 各种各样的容器方案, 这里说的各种容器是动态化容器的简称, 以下均同, 已然成为业界前端普遍采用的选择。在业界存在微信也就是那个小程序, 还有抖音即Lynx, 拼多多为Lego, 支付宝对应/, 京东则是Taro-这类东西。美团同样有着MRN、MMP/MSC等诸般容器。能够这么讲容器是前端工程里关键的基石, 也是根本绕不过去的话题。过去我们做动态化改造主要为了解决以下问题通过容器达成多端合一, 实现避免每一端针对同一需求重复开展研制工作, 以此来优化研发资金组成架构, 从而降低研发所需成本。伴随 NEXT 的不断拓展, 此项长处表现得更为显著。回避App集中集成, 借助动态发布来增添部署效率, 让业务能够在移动端独立进行部署与发布, 达成211迭代, 从而提高业务迭代面向客户的效率。然而, 任何事情, 只要存在益处, 必然会伴有弊端, 只要具备用处, 必然会产生耗费。动态化容器, 在对上述问题予以解决的情形下, 也引出了如下问题:致使页面成功降低, 动态化容器纳入了动态部署、解释器等诸多环节, 于增添整体复杂度这一刻, 众多附加环节亦引致更多错误以及涉及计算的开销, 具体呈现于页面出现白屏状况以及页面加载所需时间增长方面。导致用户体验受损: 动态化容器对更多硬件算力有需求, 在业务复杂度相同的状况下, 容器化页面相较于原生页面, 呈现出更迟缓、更卡顿、不灵活顺畅的表现, 且这一凸显现象在下沉市场的设备上更为明显, 甚至从卡顿演变成直接卡死。目前, 原生应用是动态化容器的绝对天花板, 而当下的事实天花板是, 它是React /。从定性的角度去看待前端容器天花板方面的问题, 此处引用我们美团处于容器领域的一位资历较深者的理论, 性能、效能、动态化属于动态化容器的不可能三角所处图片为下图左部分, 现具备的常用的容器方案均是在这三个维度进行“三选二”的操作。从定量的角度去看待处于动态化状态的容器, 在下图右之中呈现出了一个具备3000个相同视图节点的简单页面, 此页面不存在额外的逻辑, 并且也没有网络请求, 以React作为例子, 在同一台设备之上, 于React框架基础上制作这样一个页面, 该动态化页面的加载所耗费的时间大概是原生页面的5倍。这一测试结果不见得轻易能被接纳, 然而清晰易懂。于相同业务复杂度情形下, 动态化容器为达成动态化, 引入了一个逻辑解释器, 增添了解释执行以及与解释器通信的额外计算耗费, 这便是动态化页面性能表现欠佳的主要缘由。既要享有动态化的益处, 又不损及用户性能体验, 仅在现有的方案里做抉择是无法达成的。不过金服大前端团队在此问题上却是获取了一些实质性进展。要先说一下子咱们现在所取得的成果, 美团金服前端团队打造出了一个全新的容器 Recce, 随后在一样的测试页里头, 我们把执行业务逻辑部分的速度加快到了 8 倍, 整体的页面加载速度提高了一倍。并且在实际的业务之中, 页面加载速度又达成了 3 倍的提升, 在兼顾动态化以及效能的条件之下, 达成了性能的大幅度提升, 其性能表现快要接近于原生状况。接下来文中会着重介绍 Recce 具体是怎样达成的, 期望能够给大伙一些帮助或者可借鉴之处。2 容器分类及前期思考其一, 在我们打算着手去做一个容器以前, 要先针对现有的容器树立起基本的认知。前端容器极为要紧的部分当中的一个在于描绘图形界面用来达成人机交互, 当下主要的容器方案依据描绘方式能够归纳成下面这三类:针对现有的容器再去做更进一步的结构分解, 以此方便我们在不同容器方案之间进行对比, 这里将其拆分为四层。那么接下来, 我们会以上图中关于现有容器的分类以及结构作为认知的基础, 结合之前所形成的, 影响容器性能表现的最大因素在于逻辑解释器执行效率以及逻辑解释器通信效率这样的认知, 然后再去思考, 实现一个满足性能、安全、动态化要求的容器方案该如何去做。3 Recce的选型与搭建那么要怎样去挑选UI框架、运行时支持、平台抽象层、渲染层, 以此来达成一个具备高性能、安全性的动态化容器呢。首先, 将渲染层置于最后面, 原因在于渲染层处在最底层, 并不会对上层的选型造成影响.接着, 我们首先探讨运行时支持该如何去选择, 确切地讲就是解释器以及编程语言要怎么去选, 这是因为编程语言会对上层的UI框架产生影响, 并且解释器同样对平台抽象层里的通信部分有影响, 所以接下来的讨论次序是: 解释器编程语言、UI框架、渲染层以及整体架构这四个部分。| 3.1 解释器编程语言的选择解释器以Wasm为主 为辅前文也有提及, 我们祈望能获取一个能够做到既达成性能要求, 又具备安全特性, 同时还能够实现动态化这样子的一种方案。既然必然要实现动态化, 那就必定得有逻辑解释器, 问题于是乎变成了该如何挑选一个性能突出且安全性能良好的解释器, 而且成本是处于可接受的范围极限。现成的解释器为数量不少的, 前端范畴之中存在V8、、等等解释器, 有契合后简称为Wasm规范的、大家日常工作期间会接触到的Ruby、还有游戏行业运用频率较高的Lua、C#。首先, Ruby以及这两个语言和解释器能够被排除掉, 这是因为, 不管是性能或是生态而言, 它们都比不过。再者, Lua和C#也能够被排除, 这个主要是源于, 游戏生态以及前端两者的差距特别大, 晚饭若想吃炸鸡, 在中午才刚刚开始孵蛋, 则显然已经来不及去做了。于解释器和成Wasm解释器这两个大范围当中, Wasm解释器在性能以及安全方面相较于解释器具备决定性的优势, 不过在生态方面上略微差一些, 然而二者皆是在W3C标准范围以内的, 同样是可以运行在H5以及小程序里面的, “晚饭若想吃炸鸡, 中午启动杀鸡流程还是赶得上的”。所以, 在解释器的选型这个方面就确定下来了, 以Wasm解释器为主, 以其他解释器为辅的基本的采用策略。而Wasm解释器具体的选择呢, 是Wasm3, 其原因存在两个方面: 其一, 这是在不支持JIT的这种情况下, 速度最快的Wasm解释器其二, 它对于包大小的占用非常少句号。编程语言选择在将 Wasm 解释器确定下来之后, 编程语言的挑选便成为了, 于支持 Wasm 的那些语言之中去挑选性能、安全以及成本最为优渥的, 理论上来看, 能够被编译从而去执行的语言数量极为众多, 然而真正成熟到足够能够应用于生产环境的却只有C、C、Rust、Go这四种, 首先是能够先把 C 排除掉, 虽性能良好但并不支持高级抽象只不过适宜用在嵌入式等极为极端的场景之中而并不适合用来在前端编写业务。接着能够排除C, 于性能表现方面, C与Rust不分伯仲, 二者都强过Go, 然而在错误管理以及内存安全方面, C比Rust差一些, 并且C在前端业务层的生态基本处于空白状态, 不像Rust在前端生态发展得特别迅速。最后能够排除Go, 在性能表现上、类型系统设计方面、错误管理方面、还有前端生态方面, Go都比Rust差。综上所述, 在运行的期间, 我们便挑选了Rust以及Wasm3, 并且是在后续的时候再展开介绍。| 3.2 UI 框架使用/的部分能够复用Vue或者React, 这些暂且不说。要是用Rust, 那就得为运行时的上层设计一套UI框架, 得确定页面该怎么编写。这项工作存在挑战之处在于, 它不像生态那样, 有多年积累能拿来参考或者复用, 就像经典的React和Vue那样的, 好处当然还是没有历史包袱啦, 所以不得不依据Rust语言特性去更好地完成这个任务。大约UI框架得做到这三点的情况: 其一就是要弄出声明式DSL专门之便供前端研发就来对界面进行描述其二必须要将组件的封装以及状态管理的能力给加以提供从而达成业务逻辑跟用户交互之间的衔接其三是性能方面相当出众卓越。当中的其一和其二在生态里已然都有做到实现的情形, 其三却不一定会这样, 不然的话也就不会有几十种Web UI框架一同并存此种局面出现了。这个问题的难点在于怎样经由Rust这门具有强类型性质的纯静态语言去达成弱类型动态语言所实现出来的功能, 并且还得去维持住Rust零开销这一抽象所拥有的优势。为把当前这个问题处置好, 我们对网上公开-方式弄出来的各类框架做了参照, 一方面参照了当中的DSL设计与UI捆绑, 另一方面还让Rust-观察者模式订阅变动那种的信息更新速率维持住了, 我们把这两项长处整合一块儿, 便有了Recce UI, 说到它的特性, 不存在Diff, 也没有VDOM, 就跟同样做到了实实在在的订阅, 我们还尽可能竭尽全力去保证能够效率高地搭建UI。以下呈现于图中的表格, 与之相对应的便是一些处于Web项目范畴内的性能比拼, 这之中也并未直接关联到具体付诸实践的容器里面, 源于我们同样做了一个相近似的渲染方面的事物因而这个表格针对我们而言具备相当不错的参考意义, 起码能够看到的更新效能还是颇为可观的。| 3.3 渲染层一个渲染层的选择, 相对而言是比较简单的, 就像前面所归纳的那样, 实现一个渲染层, 大概存在三种方式, 分别是复用, 自己构建渲染绘制器, 以及调用系统UI框架。复用: 要是追求高性能, 那么这条路就行不通, 复用意味着, 渲染指令以及视图树会以一种低效的方式。要以某个内容为跳板, 再去驱动进行渲染。这跟高性能完全背道而驰, 甚至比纯H5的性能表现还要差。自己构建渲染绘制器, 在技术层面而言是具备可行性的, 然而当下却不可行: 其一, 从代码数量方面观察, 内核存在数百万行C代码, 要是考量跨平台兼容, 代码行数会超过千万行如此规模以及复杂度超越了美团App自身, 即便依照原样编写一遍, 倘若没有数十名C领域的专业人员投入三到五年的时间精力, 是难以见到成效的。其二, 在当今世上只有和Apple具备做成此事的能力。新浏览器计划在中途夭折, 微软则直接选择放弃并转而投向其他方向。采用类似 RN 的途径调用系统 UI 框架, 在研发成本方面是我们可以承担的。其渲染样式虽不像 CSS 那般齐全, 不过 Flex 已足够满足业务需求并且保持为 W3C 的严格子集。RN 在性能方面的问题主要集中于通信层, 对此我们能够予以解决。最后且最为关键的是, 此选择并非单向的, 倘若我们具备了驾驭 blink 的能力, 那么便能以很低的成本平滑切换至 blink 上。如此一来, 渲染层乃是复用了React的部分, 我们打定主意要于这个“巨人”之肩膀上着手行动。毕竟React已然给出了极为出色的组件封装并且它也化解了与iOS在渲染层面的差异, 鉴于这些接口大体上都是于系统UI项下予以封装的, 所以我们有缘由确信这些接口自身的性能是优良的。接着, 剩余的问题便是设置属性、传递属性之类的成本了, 在实践进程当中, 它们一般会变成页面渲染的一个瓶颈, 实际上React也正致力于解决此问题。鉴于此, 我们决定留存下React的增、删、改等概念, 以及Yoga布局, 还有视图组件的封装, 我们把这些留存了下来。随后, 我们还会再探讨为何未采用React当前的属性转换方式, 此处不再详述。| 3.4 整体架构最后的最终, Recce呈现出来的概览就如同下面所展示的这样一幅图。在此特意着重来讲一讲之前并未被提及过的Recce Host平台抽象层面, 针对这一层面, 我们主要完成了两件事情: 头一桩, 是针对属性设置进行了优化也可以把它称作渲染通信的优化哒第二件呢, 就是开展了平台的抽象工作。属性设置在经过优化之后, 文当中会进行详细的介绍, 这里仅仅说平台抽象, 我们依据结合的设计以及LLVM的架构来理解, 在平台抽象层之上以及之下均实现了标准接口, 类似于llvm的MIR能够让编译器前端以及编译器后端做到独立迭代以及接入, 平台抽象层的标准接口设计致使只要是遵循渲染指令标准的解释器或者是渲染器都能够较为轻易地接入, 这便是我们能够很轻易地把 Vue/React支持了的缘由, Recce-js能够让线上的大部分以某为主的前端页面获取到更好的性能表现。同样, Recce针对鸿蒙进行适配时, 其成本是非常低的, 并非需要诸如上千或几千pd那般众多, 最重要的是, 在未来若要替换性能更为优良的解释器, 或者语言, 又或者UI框架, 都是简便可行的, 这其中, 通过Rust开展的实现, 达成了高效、安全的效果, 并且使得容器整体架构具备易于扩展以及易于维护的特性。综合上述选型以及搭建工作, 大体上已然完成了。接下来, 我们再度针对Recce之上的某些细节问题予以补充。前面讲的是道理, 要知道自己已经不容易, 而付诸行动更是困难重重。下文所说的“干货”, 或许才是决定一件事情到底是成功还是失败的起关键作用的详细环节。4 Recce的一些细节问题首先, 是上一节所提及的, 为何未采用React 的属性转换呢? 原因在于, 我们察觉到属性转换乃是React的一个性能限制所在, 实际上针对此问题予以评估。我们构建了一个拥有3000个节点的页面, 这个页面或许同我们平常所常见到的页面模样并非一致, 但它的.和布局成本与业务实际状况彼此较为贴近。我们把页面的逻辑写得尽可能简单, 同时去掉了React的启动时间, 接着启用了原生代码, 还调用了Yoga的布局计算, 并以此写了一个页面来做对比。最后发现, 二者的耗时差距极大, 由于我们的布局方式相同, 调用的UI也完全一样, 基于此, 大致就能认定剩下的93%的时间都是用于将设置页面的各类数据传递到具体平台, 也就是说属性转换会耗费大量时间。这里能够再往深入挖掘一番, 属性转换为何会花费如此多的时间呢。我们在对这个问题略微进行研究之后察觉到, 主要缘由在于React拥有多次序列化与反序列化, 这是一种类似字典的事物, 并且除了序列化所用时间外, 还得考量构建字典自身所需时间, 另外还有执行字典的一些查找、设置等操作所需时间, 最终我们需要频繁依据字典里的Key值进行查找, 查找到之后, 再将其设置到具体的属性设置上, 而上述这些操作都会白白消耗掉相当多的时间以及内存。实际上, React官方也正试着去解决这个问题, 在官方公布的一个新建立的有着实验性质的框架之内, React直接把一个转为了一个当作C静态类型的*Props, 而后在对应的各个平台之中, 直接运用了一个经过转换的静态类型。这样一来, 事实上仅需存储这样一次字典便可, 从开始创建直至最终设置, 始终都运用这个静态类型, 那么其余的操作都会变得极为高效了。同时, 我们会思考, 该如何去解决属性传递, 以及查找的问题。这里能简单看下, 我们常用的几种数据结构, 是基于数组、链表、哈希表、字典等之类。但事实上, 在这种场景下, 我们可选择的或许就只有字典和数组, 而React最常用的方式是基于字典去构建各式各样的属性。然而基于字典这种方式并没有很好的性能, 要是传递的载体还是JSON字符串时, 还得承担JSON本身解析的任务。给予再三考量以后, 我们最终下决定去采用依靠索引的数组建成一个个的属性值。若采取这种模式, 维护每个数组属性上的索引会变得极为复杂, 我们要借助一个属性定义去生成各端代码以维护此索引, 需在运行前约定好每个属性的索引值, 当然, 会放弃一定兼容性。其中一个放弃兼容性的例子是, 当约定好一个属性的索引值后, 便不能再去修改该属性的索引值本身, 不然会碰到属性设置可能出现错乱的问题。与之相似的是, 我们能够将组件注册的标识由字符串转变为索引。因该属性跟组件存在差异, 不能知晓客户端会供应哪些原生组件, 故而至少得在运行时借助字符串去获取一回组件信息。在获取完毕之后, 便能运用获取到的这个索引, 进而维持一种相对快速的匹配效率。近来, 我们另外制作了一个富文本的标签, 此标签相较于前两者而言, 变得更加不同了。这里实际输入的乃是一段HTML字符的串, 因此输入的内容极为自由, 我们没办法跟前两者那样运用某些静态的计算方法。不过即便为富文本, 仍旧能够存在一些已知内容, 诸如文本的样式、字符串之类, 这些内容是能够预先知道的。在此层面, 我们能够开展一些事情, 事实上可以依据所有输入的计算, 从而获得一个完美的哈希函数, 接着保证所有的输入不会出现碰撞, 并且, 于查找Key之际就将会快出许多。前面所述的内容, 便是我们于碰到属性传递之际所处理的各式各样的问题。而紧接着, 我们仍旧要去解决一个问题, 即跨语言的调用问题。理所当然, 在探讨这个问题以前, 我们先是把这些调用, 简简单单地划分成了四类:在此种场景当中, 我们会存在更多的转换工作, 还有一些编码约定的设置内容, 故我们定然要寻觅到一种基于字符串编码的方式, 用以传递各类复杂的数据。当具体应用至Recce内部时, 事实上并不存在类似于IPC场景那样的调用情况, 因而仅需处理每一层之间语言的调用事宜。然而实际上, 我们依旧面临着非常复杂的调用这一事实。参考下图, 能看到, 每层实际上涉及一个具体的跨语言调用, 同时, 有刚刚提到的性属性设置, 它会跨过中间所有层级, 直接设置到具体平台, 最后要强调一下, 涉及具体属性以及类似一些方法调用, 比如打开相机, 也会跨过中间层直接做调用, 而这个调用跟属性设置存在很多不一样的地方。针对不同的调用场景我们也采取了两种不同的解决方案具体来讲我们分成了以下4个场景属性设置, 将定义好的属性, 生成针对Recce Ul的操作代码, 还要生成Vue的操作代码, 以及React的操作代码, 此外包括iOS , 和更多 , 等各类各种属性的操作代码。通过Rust宏来对一些本地函数予以封装, 这些本地函数是UI操作接口, 并且还要实现自定义的二进制读写。业务方法进行调用, 平台抽象层参与交互, 借助mako达成接口的调用动作, 以及文档的生成工作。5 总结和展望最终, 我们获取到了一个像上图那样的, 具备高性能、安全特性的动态化容器, 它能够以Wasm的形式支持原生级别的性能, 还能够把前端工程的性能提高一些。从某一个相对特定的角度去看, 仿佛呈现出这样一种情形, 即好似是我们将RN运用Rust进行了重新编写, 并且增添了对于Wasm解释器的支持。然而要是从熟悉相关架构的那种视角来看, 也能够把它视作是一种类似“Lite”的存在, 仅仅是在竭尽全力去绘制暂时性所使用的系统UI。文章最后做一下回望和展望。回望, 我们做的全部架构工作, 能概括成, 区分本质复杂度与偶然复杂度, 恰当地回应本质复杂度, 降低偶然复杂度我们做的所有优化工作, 也能概括成, 区分本质复杂度跟偶然复杂度, 恰当地回应本质复杂度, 降低偶然复杂度。动态化容器的本质复杂度究竟是什么呢? 最主要的那一条脉络是这样的: 渲染管线它会以前端研发的编码逻辑以及数据作为输入, 然后在这个管线之中, 转变为组件树, 接着从组件树又变为虚拟文档树, 之后再从虚拟文档树到文档树, 再从文档树成为视图树或者样式树, 紧接着从视图树或者样式树到图层树, 最终从图层树变为呈现树, 最后绘制到屏幕上, 以此作为输出让用户能够看到视图。至于使用什么样的DSL、编程语言、解释器、编码方式等等, 实际上那属于偶然复杂度。Recce的选型步骤以及搭建进程, 其实质是针对渲染管线予以优化, 像是精简流程把VDOM等环节给去除掉了, 像是简化运行时, 选用执行效率更为高的解释器以及编码形式等, 又像是削峰填谷、消除瓶颈以此来提升渲染管线的整体效率等。而这些工作全都是为了降低容器自身的计算开销, 鉴于动态化容器相对于业务来讲也是偶然复杂度。把终端有限的软硬件计算资源更多地留给业务本质复杂度是容器迭代的正确走向。预想: 当下 Recce 依旧是在渐渐完备以及铺开推行的时期, 能够去做的事项存在不少:6 Q AQRecce的性能如何可以把这个问题更具象化一些吗当前, 就我们已实践的范畴而言, 于我们的业务场景里, 在所能找到的最低端的POS设备之上, Recce UI可拥有堪与之相匹配的性能表现, 并且我们进行的是动态解释运行, 并非原生运行, 也就是达成了原生级别的性能体现。Q以后JS没用了吗A: JS是有用处的, 然而针对这个问题需分两个层面给出回答。其一, Recce对这个JS运行时以及相应的生态系统予以支持。涵盖较为极端的情形像是POS机, 多见于下沉市场的那种低端机器又或者是对性能有着极高要求的情形诸如App的首页冷启动状况亦或是像支付收银台这类场景在这些场景里优化性能所带来的收益颇具规模, 此时呢就能够考虑采用Recce - rs这个方案。其二, 倘若并非如此极端的一般场景, 我们选用Recce - js这个方案同样能够达成低成本的目标, 并且获得性能方面的优化。性能优化不存在终点, 顺着围绕业务场景的需求展开挑选, 以Recce为依托, 能获取到数量与质量皆更有优势的择项并且这个择是较好的那种。第二层, 移动端开发从起始就存在着原生开发以及 H5/JS 开发此开发于 2009 年发布, 然而 JS 成为主流的时间点, 起始于 2015 年, 于此把 V8 适配上去了, 这儿并非是 JS的可与否之事, 而是鉴于 V8 有不错 的表现, 终端硬件方面的计算资源自始至终是处于 有限状态的, V8 通过解释器层面的 JIT/AOT 编译技术, 将 JS 的运行效率大幅度地进行了提升, 才使得 JS 的铺开具备了可能性。但最近几年, JS引擎不会再有大幅度的迭代了, 手机硬件算力的升级速度显著地放慢了, 这便致使了终端上面, 软硬件计算容量的提升速度根本赶不上业务复杂度的提升速度, 这才是当前JS技术栈所面临的问题, 也是为什么会有这么多JS框架热衷于在性能方面进行竞争的缘由。大家肯定不用格外悲观, JS以及Web向来都是互联网最为关键的基础设施的, 事物是呈现出螺旋式发展趋向的自然有人从事发展工作, 有人负责相关螺旋方面, 依赖着周期的演变过程, 崭新的软硬件技技术升级又会促使其朝着前方进而发展下去。比如说要是一个使用/的高性能解释器出现以后, 那么便具有使得当前的工程性能获得大幅力度提升的条件。总之前端线上当中的代码资产90%是以形式存在着的。Q为什么叫 Recce A: Recce这个名字, 其读音是/ˈrɛkiː/, 它源于海豹部队的一把枪。之所以给它取这个名字, 是因为在Recce - rs选型时, 目标有着接近原生的性能表现要求, 并且还要具备动态化特点, 如此一来, 必然得舍弃一部分开发体验而切换到Rust语言, 又会给研发同学增添学习成本、拉高门槛。鉴于提前预见到这个方面, 所以我们期望使用Recce的同学一直牢记, 自己是经过了更多训练的精英, 要去克服形形色色的困难, 进而完成具有高价值的任务。凡事有好处必然就有弊端, 具备用处相较于存在耗费, 对标需要借助Recce - rs予以优化的情景实例, 研习Rust这一行为并非隶属于顶级疑难的技术范畴问题。我们当为具备高价值的情景状况提供更为优质贴切的种种选择, 与此同时, 还借助Recce - js把一部分优化方面的能力回馈映射给予常规普通的业务场景层面之上。不同的情景实例伴随有各异独特的成本构成架构模式, 并不存在最为理想至极的, 仅仅唯独存在契合适配的方案举措。QRecce为什么要追求原生级别的性能A主要有三点原因。一、前端提升性能体验可以提升用户体验和业务获客效率前端部署之时, 面客那是与之重叠的过程, 前端部署而成的成功率这一情况会对业务进行面客产生影响效果当部署成功率处于较低水平的时候, 那就意味着, 客户会遭遇白屏现象或者其不愿意等待, 如此最终就会选择放弃要是能够提升相应性能, 就能够提升前端部署所对应的成功率, 进而呢可以提升用户体验以及业务方面的获客效率。存在这样一个环节, 这个环节被称作部署, 它是代码离开开发环境之后, 一直到在用户终端设备运行之前的这段时间里所经历的阶段。二、追求原生级别性能的动态化容器是公司业务的发展需要美团业务的特质首要为低毛利, 低毛利表明业务拓展得搞大规模, 得提升UE, 得提升复购。综上所述, 公司业务发展存在相关需求, 此需求进而决定了美团有对于原生级别性能的动态化容器的需要。三、部署是前端工程领域的核心问题容器是部署问题的主要答案把时间调回到2010年, 那时移动端开发正蓬勃兴起刚刚起步, 主要的技术栈只有以H5为代表这一状态, 其中存在性能表现良好却不能跨端, H5迭代效率较高然而性能体验欠佳的情况。随着时间不断向前发展, 其方向是为了解决跨端研发时所消耗的成本以及部署方面的效率问题, 之后发展出了多种方案等诸多选项, H5这一方向又是为了对性能予以改善和优化, 最终发展出了离线化技术、SSR/ESR技术、解释器的专项优化等等有关举措。能够讲两个方向是朝着彼此行进, 实际上这是一个问题的两个方面。追根溯源在于前端代码运行于不受我们把控且计算资源稀缺的用户设备之上, 这有别于后端, 后端的主要问题是高并发, 而前端的主要问题是怎样以低成本跨越物权界限将代码传送到大规模且各式各样的用户的设备上并使其高效运转起来。看一看往昔时光, 性能方面有着良好表现的原生, 需要去开展动态化操作, 以此来降低部署所产生的成本, 而部署成本较低的H5, 则要对性能加以优化, 从而提升用户所收获的体验。也就是说一回事情前端工程这个领域当中的核心问题, 乃是部署成本以及用户体验之间的平衡。举例来讲, 包的大小就是原生开发时部署成本偏高, 进而给客户端开发造成极大困扰的一个十分典型的实例。|| 注释 ||逻辑诠释工具, 于iOS里Apple不许JIT, 仅能够诠释执行。 亚马逊用做云原生的Wasm解释器。C#黑神话悟空就是用魔改跑的游戏逻辑。不支持 JIT Apple不允许在iOS上JIT。C、C、Rust、Go 这四种blink 的布局渲染器。