Garfish 的设计的初衷并不是为了取代 iframe,而是为了将一个单体应用拆分成多个子应用后也能保证应用一体化的使用体验,Garfish 为了提升应用的渲染性能,提供了缓存渲染模式。
缓存的形式分为两种,一种是缓存 App 的实例,缓存 App 的实例比较容易理解,Garfish 在通过 loadApp 加载子应用后可以保留 App 的实例,另外一种则是缓存子应用的执行上下文,第二遍执行时不执行所有代码来提升整体的渲染速度。
为什么 Garfish 的子应用需要提供 provider 函数呢?原因是通过提供 provider 生命周期,我们可以尽可能的优化渲染速度。
hook 也可以正常触发html 下载=> html 拆分=> 渲染 dom => 渲染 style => 执行 JS => 执行 provider 中的函数html 内容=> 执行 provider 中的渲染函数。因为子应用的真实执行环境并未被销毁,而是通过 render 和 destroy 控制对应应用的渲染和销毁Garfish 框架的沙箱依赖于浏览器的 API,无法做到物理级别的隔离。由于 JavaScript 语法的灵活性和闭包的特性,第二次重复执行子应用代码可能会导致逃逸内容重复执行render ,将会避免逃逸代码造成的内存问题缓存模式下的弊端
render 中的逻辑获取的还是上一次的执行环境并不是一个全新的执行环境,下面代码中在缓存模式时和非缓存模式不同的表现
list 数组的值持续增长,并导致影响业务逻辑list 数组的长度始终为 1Garfish 框架无法有效区分哪些副作用需要销毁
render 函数,因此无法区分哪些副作用是实际应用 render 过程中创建的还是其他基础库造成的Garfish 框架在缓存模式下仅会收集和清除:样式副作用、环境变量具体使用如何使用缓存模式请参考:Garfish.loadApp
手动加载提供了 cache 功能,以便复用 app,避免重复的编译代码造成的性能浪费,在 Garfish.loadApp 时,传入 cache 参数就可以。
例如下面的代码:
实际上,对于加载的 promise 也会是同一份,例如下面的 demo