您现在的位置是:主页 > 数据库技术 > 数据库技术

前端开发中怎么正确地跨端

IDCBT2022-01-12服务器技术人已围观

简介这期内容当中小编将会给大家带来有关前端开发中怎么正确地跨端,文章内容丰富且以专业的角度为大家分析和叙述,阅读完这篇文章希望大家可以有所收获。 跨端 Write once, run everywh

这期内容当中小编将会给大家带来有关前端开发中怎么正确地跨端,文章内容丰富且以专业的角度为大家分析和叙述,阅读完这篇文章希望大家可以有所收获。

跨端

Write once, run everywhere。

我们都听说过这句经典的宣传用语,后来我们都知道,没有什么东西是可以真正 run everywhere 的,充其量也只能做到 debug everywhere。

而当我们谈论一次编写多端运行时,显然不可能真的指跨一切所有端,大多数情况下你不会需要在电脑和手环上同步开发一个功能。

    跨 PC 和无线端。

    跨多 Native 平台:例如跨 Android 和 iOS,甚至跨 Windows。

    跨投放 APP:随着超级 APP 越来越多,很多业务需要在多个 APP 中投放同一个页面。

    跨 Web 和 APP:Web 在很多情况下仍然是不可避免的,我们的页面可能需要分享、SEO 或者投放到 M 站上等等,这时候就需要同时能在 Web 和 APP 内运行。

    跨 Web、多小程序、QuickApp 等:其实本来类似跨 APP,但是奈何小程序本身是各家控制的封闭生态,故而有了开发一次适配到多种封闭生态的诉求。

    其他端的跨端诉求:例如跨 POS 机,手表等。

    与我们多种多样的跨端诉求相对应的,是百花齐放的跨端方案。

    百花齐放的跨端方案以 Web 为基础的 H5 Hybrid 方案

    这类方案最为直接,简单来说就是用网页来跨端。由于我们绝大多数端上(甚至包括封闭的小程序生态)都支持 Webview,所以只要开发网页然后投放到多个端即可,在桌面端对应的方案就是 Electron。

    为什么不直接全用 Web?

    从开发成本低、标准统一、生态繁荣上来说,H5 Hybrid 方案基本是不二之选。然而这种方案难以避免在性能和体验上存在差距。Web 的生态繁荣来自于其良好的历史兼容性,也意味着沉重的历史包袱。

      W3C 标准作为开放技术标准,历史包袱多,逻辑复杂。

      Web 标准在设计上不是 Design for Performance 的,导致很多地方难以进一步改善,例如 JS 执行和 Layout、渲染互斥无法并行,导致过长的 JS 执行任务会执行正常的渲染导致卡顿。

      Web 的标准化在推进上也比较慢,新的能力可能要比较长的时间才能使用。

      React-Native/Weex 类方案

      在移动平台上尤其是早期 WebView 的性能体验非常糟糕,前面我们也提到这种差距主要来自于 Web 生态本身沉重的历史负担。

      而 React-Native/Weex 这类方案通过尽可能的取长补短,通过结合 Web 的生态和 Native 的组件,让 JS 执行代码后用 Native 的组件进行渲染。由于抛弃了 Web 的历史包袱,这类方案可以做一些大刀阔斧的改动。

      例如 RN 就如下图中,把 JS 执行、布局(Yoga)和渲染(Native 组件)放在三个进程分开执行,避免了 JS 执行复杂任务时界面卡顿。通过抛弃 CSS 中的大量标准,只支持部分 flex 布局能力来减少布局和渲染的复杂度。

      标签:

      很赞哦! ()

本栏推荐