跨端容器-青训营
核心原则和目标：一套代码，多端运行，效果一致
跨端原理
实现一个容器，抹平底层差异，而任何跨端or跨平台的根本就是如何基于系统的原生能力，为上层开发者提供统一的api。
对于web开发人员，浏览器就是一种跨平台方案，浏览器为我们实现了一个容器，我们只需要编写html、css和js，就可以实现windows、mac、linux的跨平台。
对于跨端方案，也就是跨web、Android、ios等，跨端可以拆分为渲染跨端和逻辑跨端。
渲染跨端目的是为不同平台提供统一的ui，ui的实现要么依靠原来的浏览器渲染引擎，基于html和css实现，要么实现自己的绘制api，例如rn利用原生能力进行绘制，flutter基于skia绘图库进行绘制。
逻辑跨端目的是其他逻辑代码执行的一致，也就是如果你用js调用某个api，该api应该保持一致，至于如何在各个端实现该api，我们需要利用其他手段。要么利用jsBridge注入原生能力，要么跨端方案里又提供了一个容器，一层包装，使得我们可以不用关心该api如何实现。
常见的跨端方案
webview
小程序
webview
数据通信：native转发
rn & Weex
渲染：组件——自己的virtual dom——借助原生能力实现
jsBridge
Flutter
渲染：基于绘图库skia
逻辑：dart vm，dart语言写逻辑
electron
内置chromium，并注入了node的api和一些gui相关的api
支持用前端技术开发桌面端
关于跨平台
浏览器
作为容器，提供了统一的api（dom api）
docker
操作系统上加一个虚拟层，虚拟层上可存在多个容器
实现硬件软件的分离，可以动态分配硬件资源给容器
容器也可保存成镜像
jvm
java编译成jvm可以解释的字节码，由jvm进行解释执行
node和deno
electron
内置chromium，并注入了node的api和一些gui相关的api
支持用前端技术开发桌面端
jsBridge和WebView
WebView
android.webkit.WebView组件
ios：WKWebView
JSBridge
构建js和native的通信通道
通信原理
以webview+jsBridge场景为例，js运行在单独的context中，
js调用native
注入api：向js的context（window对象）中注入对象or方法，js可直接调用
window.webkit.messageHandlers.方法name.postMessage(message);
window.方法name.postMessage(message);
拦截url scheme：web端发送url scheme请求（iframe.src等），native拦截，并获取到参数，进行操作
url scheme：例如: qunarhy://hy/url?url=ymfe.tech，protocol 是 qunarhy，host 则是 hy。类似url，但protocol和host自定义，方便app相互调用，
native调用js
通过native api执行js字符串形式的代码，需挂载在window下
jsBridge接口
向native发送消息
接受native消息，并执行对应回调
注入方式
native端注入：native端执行js代码，不用兼容多版bridge，但js无法感知bridge，需要判断是否注入成功
js端注入：直接和js一起执行，js端需要兼容多版native bridge
