前端页面渲染机制是什么意思-前端页面渲染过程

本文介绍《移动前端开发和Web前端开发有什么区别》的相关知识。 在实际案例的操作过程中，很多人都会遇到这样的困境。 这些情况怎么处理！ 希望大家仔细阅读，有所收获！

回顾：前端发展史

▐ 第一阶段：刀耕火种

十多年前的前端，开发者还在为兼容IE6而苦恼，而jQuery是框架中的佼佼者。 追求前端开发可能会使用 Zepto.js 来减少网页的大小。 这个时候前端页面主要是基于PC的。 这时候完全没有移动前端的概念，手机小屏上有流量的页面主要是纯文本。

▐ 第二阶段：工程

在 2011 年到 2014 年的历史时期，模块化的思想占主导地位。 当时为了设计Assets资源加载器，制定了模块化的协议规范。 当时比较流行的模块化协议有AMD（RequireJS）、CMD（以Seajs为代表）、KMD（以Kissy为代表）。 在淘宝和天猫，Kissy很受欢迎，所以KMD一统天下； 在支付宝和外部社区，Seajs很受欢迎，所以CMD一统天下，Yubo的知名度和声望在前端圈子里特别高； AMD在国外比较流行，但是被后来出现的CommonJS规范逐渐弱化了。

▐ 第三阶段：流动性

随着3G、4G的发展和iOS、Android手机在市场上的普及前端页面渲染机制是什么意思，PC业务的主战场正逐渐向移动端过渡。 前端思维模式从PC端转向移动端，符合App的用户体验。 移动端HTML5协议支持不完善，前端制作支持不完善，安卓画面碎片化，所以当时前端开发和移动端页面适配的痛苦远超PC时代。

▐第四阶段：构图

在前端社区，Angular、React、Vue、RN（React Native）等MV*框架相继出现，让前端接受了数据驱动思维的洗礼，也完成了体验升级移动端借助RN，包括后来的Weex，Flutter。

这个阶段前端开始有了终端的底层架构组，开始构思前端页面在移动端的加载性能和用户体验性能。 在阿里巴巴内部，为了解决多端复用的问题，Rax使用了VDOM来连接WebView和Weex的两端，一套代码跑遍了全世界。

▐ 第五阶段：垂直化

随着第一代iPhone的发布，大屏手机逐渐成为主流，移动终端需求开始爆发。 在淘宝天猫，双十一移动端成交额逐年增长，逐渐占据绝对领先地位。 前端领域也按照这个趋势逐渐细分。 按照场景可以简单分为移动端（无线）前端开发和中后台前端开发。

移动前端开发面向消费端Web和轻App业务场景。 在这种场景下，淘喜经过多年的营销活动，逐渐形成了一套独特的轻量级移动端解决方案，以及模块维度、运营导向的页面构建体系。

中后台前端针对企业ERP、CRM、OA等业务场景，比如商户后台系统。 在此场景下，借助飞冰、Fusion Design等中台素材，形成可视化中台搭建方案前端页面渲染机制是什么意思，为前端、开发或产品角色提供一站式中台制作解决方案。这生意。

移动前端：混合技术的前世今生

曾几何时，移动客户端开发和前端开发是两条没有交集的平行线，但现在我们越来越拥抱两者合作的产物：混合（Hybird）应用开发，或者说已经流行起来的一个概念最近--大前端技术。

从技术表现上看，客户端开发和前端开发本质上都是终端技术，其特点是直接面向用户的UI编程。

▐ 同样是UI编程，我们面临的痛点是什么？

传统Web前端技术的技术局限

1、资源加载：HTML、JS、CSS、图片等静态资源存储在远程服务器上，需要动态异步拉取，然后拉取数据进行展示。 初始化效率比Native慢很多

2、渲染机制：在浏览器的设计中，JS的执行、页面的布局、Paint都在同一个主线程中，无法并行。 另外，JS 的性能跟不上 AOT 语言，导致执行复杂逻辑时卡顿，通常 UI 阻塞，再加上冗长的渲染管线，浏览器的渲染体验在同等情况下与 Native 相比并不占优金额。

3、页面切换：浏览器中没有路由的概念，导致页面之间的切换体验完全依赖浏览器Shell提供的能力，切换页面时会重复加载。 当然，前端社区也出现了单页面应用的概念，但是多页面的资源也大大增加了JSBundle的体量，这也让页面的开发变得更加复杂。

4、API能力：浏览器的安全机制是基于同源策略的沙盒机制。 这种沙箱机制阻止前端开发人员使用本机系统功能。 只能使用 W3C 标准定义的函数，而终端碎片化由于本地化问题，往往不能直接使用这些接口。 这在PC端的场景下是没有问题的，但是在移动端，恰恰相反。 开发者希望有调用系统接口的能力，实现一些更具交互性的场景。

5、交互性能：浏览器实时交互性能体验差，复杂交互场景下的大规模重排限制了UI帧率。 这种限制在低端和中端移动设备中尤为严重。

6. 脚本语言、动态分析与执行

JS是一种JIT语言，即需要动态解析和执行。 与预编译机器码的AOT语言相比，执行性能要差很多。

传统客户端技术的局限性？

1. 动态：客户端开发通常有固定的版本发布计划，受苹果App Store审核规则约束。 版本发布的不确定性也会受到政策的影响。 Android在国内有很多渠道，每次发布渠道都要反复查看。 一旦发现线上问题，需要依赖重新发布，容错成本非常高，也大大增加了业务的局限性。

2、开发成本：客户端开发成本高，但生态不如Web丰富。 npm社区数以万计的开源包，加上更活跃的开发者社区，导致客户端的开发成本高于企业Web开发。 .

3、跨端一致性：在传统客户端上开发一套业务，需要实现两套代码，Android+iOS，由于Android和iOS操作系统能力的差异，要求相同往往以不同的愿景和交互方式实施，这也导致了高昂的业务成本。

▐ 混合前端开发

为什么要进行混合前端开发？

随着iOS+Android确立了移动操作系统的霸主地位，前端开发者也在寻找一种利用操作系统提供的能力进行业务开发的模式。 Web的开发方式远比iOS和Android方便和高效，Web上涌现的各种库和框架也远比Android和iOS的各种库和框架方便。 在Web上，我们可以方便的使用各种前端框架，并及时预览效果（想想Android/iOS大型项目的编译时间）。

在阿里巴巴看来，随着中心化理念逐渐被接受：业务需要追求快速发展，前端UI和需求会随着业务决策快速迭代，前端和客户端的不同定位——双方还形成了分工合作的研发模式。

前端向上，前端是业务端的唯一接口，逐渐演变为大前端的业务层。 在这一层，其职责是定义规范，通过框架规范业务开发流程，同时封装统一的解决方案和工程能力，分离重复性工作。

将客户端拉下来，与业务需求解耦，变成一个大的前端架构层，为上层业务开发者提供能力支持。 通过将客户端的系统级API和宿主应用的能力暴露给前端上层，提升前端页面对更丰富的交互场景的承载能力。

在这样的背景下，各种混合开发技术层出不穷。 这里我们简单的将混合应用的开发定义为三个阶段：

▐ 第一阶段：JSBridge

现阶段以WebView为主，配合JSBridge，提供Naive与JS的沟通纽带。 基于这个通信基础，Native可以对外暴露一些标准的服务API，供JS调用。 同样的JS也可以作为这样封装一些基础的API，供Native调用。 前端开发者使用传统的JS+HTML+CSS开发页面，调用JSBridge API驱动客户端能力。 现阶段Apache Cordova是业界的佼佼者，大部分互联网公司也都有自己的JSBridge框架实现。 可以说，JSBridge让前端开发者第一次拥有了调用Native的能力。

但JSBridge方案的主要缺点在于性能和扩展高级组件的能力不足，流畅度永远无法与Native相提并论。

▐ 第二阶段：原生 UI

虽然Web的动态性和高效的开发效率是原生开发所望尘莫及的，但是浏览器技术的瓶颈也非常明显：

1. W3C作为一个开放的技术标准，历史悠久，包袱重重，大大拖慢了浏览器的性能。

2、WebView渲染引擎设计的缺陷，渲染管线很长，导致浏览器对合成器动画和非合成器动画的区别对待，非合成器动画的表现不好。

3、单线程模型无法充分发挥现代硬件架构，尤其是ARM架构的多核性能。

4. 异步光栅化的设计，滚动长列表时，难免会出现白屏。

**有没有办法两全其美？

React Native/Weex 的出现，给前端开发者带来了曙光。 **

React Native/Weex使用JS引擎调用Native端的组件实现相应的功能。 React Native 和 Weex 都允许前端开发者使用 JS 进行业务逻辑开发，使用 VDOM 来描述文档结构，配合 CSS 的子集来自定义样式，分离样式和模板。

在Weex系统中，JS在JS Thread中执行，Layout在独立的Layout Thread中执行，渲染在系统的MainThread中执行。 三个线程相互独立，并行执行。

在WebView系统中，JS、Layout、Paint的执行都在MainThread中，在执行复杂任务时相互影响，导致界面卡顿。

该方案的优势在于最大限度的复用了前端生态和Native生态。

在阿里巴巴，Weex 的大规模应用甚至支撑了双 11 亿的流量。

▐ 第三阶段：自绘引擎

什么是自绘引擎？

所谓自绘引擎，就是不依赖于操作系统提供的布局和原生组件能力，直接调用GPU或底层抽象层进行绘图的渲染引擎。

前一阶段，前端开发者已经可以使用JS引擎来驱动原生UI，为什么还需要自绘引擎呢？

React Native/Weex 将 Native View 系统完全输出到前端系统。 在封装Android/iOS Native View的过程中，有很多难以逾越的障碍。 比如：难以磨平的双端一致性问题，复杂样式能力难以实现，Layout动画需要执行两次（WeexCore Layout和Android Native自带的Layout）。 随着复杂度的增加，组件的封装成本越来越高，很难提供超出Native View限制的更详细的W3C标准能力。

Flutter 诞生于 2018 年，它使用 Dart 语言构建了一套跨平台开发组件。 所有组件均基于Skia引擎自绘，性能可与Native平台的View相媲美。 问题。 引起了广泛的关注，充分验证了通过绘制和构建组件来媲美Native View的UI渲染引擎的可行性。

但是，Flutter 本身缺乏动态更新的特性。 社区中也有一些项目在探索 Flutter 的动态特性。 我们团队也在实现一个面向前端的动态 Flutter 引擎：Kraken。 与其他解决方案不同，Kraken 并非基于 Flutter。 扩展了内置的Widgets框架，但从底层扩展了W3C标准API，使其更像一个浏览器，也大大降低了Web开发者对Flutter的使用门槛。

未来：回归本源

天下大势，久分必合，久合必分。 移动前端开发本质上是终端开发的一种形式。 不管容器、框架、语言怎么变，只有前端开发者中的W3C标准是永远不变的。 笔者认为，随着Web的发展，浏览器技术在解决了一系列性能和体验问题后，将成为更通用的UI编程标准。

▐PWA

早些年，谷歌在该领域发力，引入了PWA（Progress Web Application）的概念。

PWA 通过在移动浏览器上提供标准化的框架，在 Web App 中实现接近 Native App 的用户体验。 它的特性实际上是W3C标准和私有标准的集合。 简单来说，PWA 支持：

▐PHA

当然，当标准能力不完善，业务需要定制能力时，混合应用会继续发展。

PHA（Progress Hybrid Application）的概念由此诞生。 PHA是一种渐进式混合应用增强策略，为端测提供辅助能力，提升WebView的渲染性能和体验。 广义上讲，现在流行的小程序、快应用都是PHA的实现。

在淘系内部，我们也在推行一套轻量化的PHA解决方案，在大促中取得了不错的效果。 我想我稍后会单独发表一篇关于 PHA 的文章。

对于未来，随着技术方案的多样化和终端边界的扩大，我们认为最重要的问题是效率和性能。

基于大数据的机器学习能力，移动端将拥有更高效的UI编排能力，最终实现UI渲染的实时个性化。

基于最近流行的WebAssembly能力，浏览器​​可以突破JavaScript的局限，拥有更大的想象空间。

《移动前端开发和Web前端开发有什么区别》的内容就介绍到这里，感谢阅读。 想要了解更多行业相关知识，可以关注易速云官网，小编将为您输出更多优质实战文章！