这是我参与 [第五届青训营] 伴学笔记创作活动的第7天
业务场景越来越多以及技术发展，产生了越来越多的端，如PC端、移动端、IOT设备端等等。在传统场景上，会在每个不同的端配置不同的环境、不同技术、不同研发人员——然而各端的业务、功能等几乎一致,却付出了几倍的研发、维护成本
希望在不同端使用一套开发与业务逻辑，各端对齐便是跨端的诉求
跨端方案
hybrid
基于webView渲染，类似浏览器渲染，通过Js Brid将系统的API开放给webView，
使用通用bridge与平台交互，调用webview渲染，以及调用系统服务
原生渲染方案
通过JS开发，视图通过原生组件渲染，成熟的原生渲染方案有 React Native
开发者还是通过bridge桥接，与hybrid不同的是使用OEM widgets原生组件渲染，渲染效率更高——不过通过安卓、IOS等提供的原生组件比起webView有限，在css等方面部分功能有缺失。并且由于各端提供的组件有所不同，一致性一般
如React Native，通过JSI接口操作c++对象
自渲染方案
更加底层实现，利用开源渲染引擎Skia实现渲染管线——抛弃安卓、IOS等提供的原生组件，自己定制渲染内容。不过渲染内容仍是css子集，并且需要学习新语言，开发成本更高
Flutter框架正基于此。如图，通过widgets绘制，channels进行通信，不在依赖于系统而是自己绘制，对平台的依赖性更低了——开发者通过widgets开发，将各个widgets组合起来实现一个应用
小程序方案
使用小程序DSL+JS开发，通过中间层调用原生能力，并用webView渲染UI——与hybrid很类似，但有所优化
如字节小程序，可以投放到抖音、头条等App内，方便的获取与调用
逻辑层使用JSC，是一个可以在各端运行的JS的环境，开发者代码会运行在逻辑层——而Native平台层面则使用平台自身的功能如蓝牙等等
总结
前端的跨端方案大致如此，可以使用webview、或者是原生组件渲染；使用JS线程，JS引擎，或是Dart处理逻辑。不同方案应用场景不同——需要快速解决业务需求时使用hybrid，性能要求极高的场景使用原生渲染或自渲染，产品与平台方案则是小程序
