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
数组的长度始终为 1
Garfish
框架无法有效区分哪些副作用需要销毁
render
函数,因此无法区分哪些副作用是实际应用 render
过程中创建的还是其他基础库造成的Garfish
框架在缓存模式下仅会收集和清除:样式副作用、环境变量具体使用如何使用缓存模式请参考:Garfish.loadApp
手动加载提供了 cache
功能,以便复用 app
,避免重复的编译代码造成的性能浪费,在 Garfish.loadApp
时,传入 cache
参数就可以。
例如下面的代码:
实际上,对于加载的 promise
也会是同一份,例如下面的 demo