浅谈跨端技术 | 青训营笔记
这是我参与「第五届青训营 」伴学笔记创作活动的的第6天。
跨端是什么？
Write once, run everywhere。（美好的梦想T_T）
产生的背景
当然是，随着业务的发展，产生了越来越多的业务场景，同时随着技术的发展，产生了 越来越多的 端。
常见痛点（跨端要解决的问题）：
-
各端功能几乎一致，各端需要单独配置研发人员
-
开发、维护成本高
-
安卓、ios 的发版周期长
跨端技术
"跨端技术" 指的是在多个终端设备上构建和运行应用程序的技术。这些终端设备可能包括桌面计算机、笔记本电脑、平板电脑、智能手机等。
跨端技术的目的是创建一个统一的用户体验，使得应用程序在任何设备上都能顺畅运行。
常见的跨端场景有：
- 跨PC和移动端
- 跨多native平台：例如安卓，iOS，鸿蒙，甚至于windows
- 跨多个app投放同一个页面：不少偏营销类型的页面会存在说在多款app中同时进行投放
- 跨web与app：这基本上就是平时所说的RN, WEEX等能直接在app与web同步开发的应用
- 跨web，小程序，quickapp等：对于小程序等自闭环的环境，由于各自app厂商不同，为了凸显各自的特点，所以导致各api没有完全对其的情况
- 其他端的跨端诉求：例如跨 POS 机，手表等
跨端技术方案目标
- 学习成本低，多端—致性高
- 稳定性高，性能体验好
- 支持动态化下发，满足日益增长的业务需求
常见的跨端技术方案
前提知识：webview
Hybrid 方案
基于 WebView 渲染，通过 JS Bridge 把一部分系统能力开放给 JS 调用。
由于我们绝大多数端上（甚至包括封闭的小程序生态）都支持 Webview，所以只要开发网页然后投放到多个端即可，在桌面端对应的方案就是 Electron。
工作原理：
WebView容器的工作原理是基于Web技术来实现界面和功能，通过将原生的接口封装、暴露给 JavaScript调用，JavaScript编写的页面可以运行在系统自带的WebView中。
优势：
- 对于前端开发者比较友好，可以很快地实现页面跨端
- 保留调用原生的能力，通过搭建桥接层和原生能力打通
缺点：
- 跨端的能力受限于桥接层，当调用之前没有的原生能力时，就需要增加桥
- 浏览器内核的渲染独立于系统组件，无法保证原生体验，渲染的效果会差不少
原生渲染（React-Native/Weex 类）方案
使用 JS 开发，通过中间层桥接后使用原生组件来渲染 UI 界面。
举几个栗子：
- 在Android 开发中是使用Kotlin或Java 来编写视图
- 在 iOS 开发中是使用Swift 或Objective-C 来编写视图。
- 在React Native中,则使用React组件通过JavaScript来调用这些视图。在运行时,React Native为这些组件创建相应的Android和iOS视图。由于React Native组件就是对原生视图的封装,因此使用React Native编写的应用外观、感觉和性能与其他任何原生应用一样。
我们将这些平台支持的组件称为原生组件。
知其所以然
在移动平台上尤其是早期 WebView 的性能体验非常糟糕，这种差距主要来自于 Web 生态本身沉重的历史负担。
而 React-Native/Weex 这类方案是一个取长补短的方案，将动态化，逻辑能力都扔给JS去执行，而绘制页面的能力依旧是让native去执行，这样做的好处是，在结合JSB的基础上，让页面UI的体验与native保持同步，而逻辑处理全部交给native自身的js执行引擎来进行执行并返回出相应的结果。
工作原理：
自渲染(Flutter）方案
利用 Skia 重新实现渲染管线，不依赖原生组件。可以配合这篇文章进行理解。
前言：
可以说RN类型的框架他还是拥抱了部分web的生态，却又不是完全的拥抱，但是flutter这个框架从出生就是不打算继续借着web来发展
它本身是使用skia绘制到屏幕上的，也就是说，通过自建绘制能力，来保证多端的统一性，这样做的好处在于能够完全的减少双端差异的人力投入，也不需要使用native跟js进行bridge的交互从而得到对应的页面，讲到比较熟悉的一个古老方案就是QT
工作原理：
小程序跨端框架方案
使用小程序 DSL + JS 开发，通过中间层桥接后调用原生能力，使用webview 来渲染 UI 界面。
小程序比较有意思，改天会再发一篇文件进行讲解。
跨端技术方案对比
参考博客：
