ice.js 的 Canvas 渲染缓存插件 ice/plugin-canvas从配置接入到 CacheCanvas 源码原理【免费下载链接】ice ice.js: The Progressive App Framework Based On React基于 React 的渐进式应用框架项目地址: https://gitcode.com/gh_mirrors/ice1/ice本文围绕 ice.js 官方插件ice/plugin-canvas展开它负责为 ice.js 应用注入 Canvas 渲染缓存能力使游戏、可视化等重度使用 Canvas 的页面在二次进入时可以直接复用已渲染的帧快照从而跳过昂贵的重绘。读完本文你将掌握该插件的接入方式、CacheCanvas组件的完整 API 与缓存读写机制并能从源码层面理解其2D Canvas 缓存能力的实现脉络包括 版本演进 中每一条变更背后的动机。一、插件定位为 ice.js 应用补齐 Canvas 渲染缓存能力ice/plugin-canvas是 ice.js 生态中专门面向 Canvas 类项目游戏、数据可视化、图形编辑器等的插件。它的package.json中对其职责的描述非常直白Provide canvas render support for ice.js为 ice.js 提供 Canvas 渲染支持。插件本体依赖ice/cache-canvas后者是一个支持缓存的 Canvas React 组件React component for supporting canvas for cache。需要先说明一个细节虽然仓库内该包的目录名是packages/plugin-cavans沿用了较早的拼写但其发布名称为ice/plugin-canvas见 package.json文档与示例代码中使用的也都是ice/plugin-canvas这一名称实际接入时请以下面的包名为准。从整体架构上看该插件解决的是这样一个现实问题Canvas 游戏或图形页面往往包含复杂的初始化与首帧绘制逻辑加载资源、初始化引擎、执行绘图指令每次进入页面都要重来一遍体感很差。ice/plugin-canvas的思路是——把 Canvas 的渲染结果以 base64 快照的形式缓存下来优先写入 App 容器的 KV 存储降级到localStorage下次进入时先用缓存快照直出画面再在后台悄悄完成真实的 Canvas 初始化与绘制做到秒开。插件的源码实现极小却关键ice/plugin-canvas的插件本体非常精简全部逻辑集中在 src/index.ts 中import type { Plugin } from ice/app/types; const PLUGIN_NAME ice/plugin-canvas; const plugin: Plugin () ({ name: PLUGIN_NAME, setup: async ({ generator }) { generator.addExport({ source: ice/cache-canvas, specifier: [CacheCanvas], }); }, }); export default plugin;可以看到插件通过 ice.js 的generator.addExport能力将ice/cache-canvas包中的CacheCanvas组件以顶层导出的形式注入到应用运行时。这意味着只要在ice.config.mts中注册该插件你的页面代码里就可以直接从ice包导入CacheCanvas而无需手动安装和引入ice/cache-canvas。插件不侵入任何页面逻辑职责单一——把能力挂到 ice.js 的运行时导出上。这也是它符合 ice.js 插件体系最小化、声明式设计理念的体现。二、快速接入安装与 ice.config.mts 配置1. 安装插件在 ice.js 项目中安装插件及其依赖组件插件本身已经依赖了ice/cache-canvas一般只需安装插件即可npm i ice/plugin-canvas -S2. 在 ice.config.mts 中注册参照 README 的官方用法在项目根目录的ice.config.mts中加入插件import { defineConfig } from ice; import canvasPlugin from ice/plugin-canvas; export default defineConfig(() ({ plugins: [canvasPlugin({ /* options */ })], }));仓库内的完整示例 examples/cavans-project/ice.config.mts 给出了一个真实可运行的配置import { defineConfig } from ice/app; import canvasPlugin from ice/plugin-canvas; export default defineConfig(() ({ plugins: [ canvasPlugin(), ], ssr: true, ssg: false, }));该示例同时开启了ssr: true服务端渲染并关闭了ssg静态站点生成。这里特意开启 SSR 是有讲究的CacheCanvas组件内部用universal-env的isNode判断运行环境见 cache-canvas/src/index.tsx在 SSR 阶段不会执行浏览器相关的 Canvas 绘制与缓存读取逻辑从而保证同构渲染不报错、不闪烁这一点在后面的源码分析中会展开。3. 页面中直接使用 CacheCanvas注册插件后CacheCanvas会作为 ice.js 运行时的顶层导出出现页面代码可以直接导入import { CacheCanvas } from ice;三、CacheCanvas 组件核心 API 与使用范式CacheCanvas是插件的价值核心其完整实现位于 packages/cache-canvas/src/index.tsx。我们先看它对外暴露的 Props 与 Ref 接口见 index.tsxProps类型默认值说明idstring必填Canvas 元素的 DOM id既是组件渲染canvas的标识也是生成缓存 keycache-canvas-${id}的依据bizIDstring业务标识写入 KV 存储时用于业务隔离避免不同业务间缓存串扰init() Promiseany必填Canvas 初始化/绘制函数必须返回 PromisePromise resolve 后组件才认为渲染完成useCacheBooleantrue是否启用缓存命中逻辑设为false时跳过缓存直接渲染真实 CanvasgetSnapshot() String无自定义快照获取函数默认使用canvas.toDataURL()fallbackReactElement无兜底 UI在既无缓存快照又尚未完成绘制的阶段展示style/classNameHTMLAttributes无透传给 Canvas / 快照图片的样式与类名通过ref暴露的方法RefCacheCanvasRef 方法说明cacheCanvasToStorage()手动将当前 Canvas 渲染结果以 base64 快照写入缓存存储组件内部的工作流程从 组件实现 可以还原出它的完整运行逻辑初始化状态useState(!useCache)决定初始是否直接渲染真实 Canvas。开启缓存默认时renderedCanvas初始为false此时组件不展示真实canvas而是先尝试用存储中的 base64 快照渲染一个img占位index.tsx。异步初始化useEffect中调用你传入的init()只有当返回的 Promise resolve 之后renderedCanvas才会被置为trueindex.tsx真实 Canvas 随即显示并接管画面——这期间用户看到的一直是缓存快照实现无感秒开。兜底降级fallback只在服务端渲染阶段或本地确实没有缓存快照时渲染index.tsx保证最坏情况下也有内容可看。手动/自动缓存调用 ref 上的cacheCanvasToStorage()可将当前帧写入存储index.tsx默认通过canvas.toDataURL()取整帧 base64也可用getSnapshot自定义快照内容。值得一提的是组件内联注入了一段 IIFE 脚本index.tsx用于在客户端异步探测 App 容器桥window.__megability_bridge__的userKVStorage.getItem能力一旦可用就用异步方式拉取缓存快照并替换占位图——这是为了适配小程序/混合 App 容器场景而设计的降级链路。四、缓存存取机制Storage 的多层降级策略快照的存取不直接操作localStorage而是封装在 packages/cache-canvas/src/storage.tsx 的Storage对象中采用**容器 KV 存储优先、localStorage 兜底、内存兜底**的三层策略第一层App 容器 KV 存储userKVStorage。通过window.__megability_bridge__.syncCall(ability, available, { ability: userKVStorage, ... })探测能力是否可用storage.tsx。写入时特意用asyncCall而非syncCall因为Canvas 的 base64 可能非常大同步调用会阻塞线程该问题正是 cache-canvas 0.0.13 的修复点读取时则优先走同步调用获取结果。第二层Web localStorage。容器桥不可用时回退到标准的window.localStorage.setItem/getItemstorage.tsx。第三层内存对象缓存。SSR/无 window 环境下getItem最终回退到模块级cache对象保证读取行为在服务端也不会抛错storage.tsx。setItem全程以 Promise 包裹写入失败会reject并console.error不会影响页面主流程getItem则对异常做了兜底返回空串。这套降级策略让同一套组件代码可以同时跑在 Web、SSR 与混合 App 容器中也解释了为什么示例项目 cavans-project 会同时开启 SSR。五、完整实战示例cavans-project仓库中的 examples/cavans-project 是一个端到端可运行的演示工程它的首页 src/pages/home.tsx 完整展示了CacheCanvas的典型用法import { definePageConfig, CacheCanvas } from ice; import { useRef } from react; export type RefCacheCanvas { cacheCanvasToStorage: () void; }; const GAME_CANVAS_ID canvas-id; export default function Home() { const childRef useRefRefCacheCanvas(); const initFunc () { return new Promise((resolve) { const canvas: HTMLCanvasElement | null document.getElementById(GAME_CANVAS_ID) as HTMLCanvasElement; if (canvas typeof canvas.getContext function) { let ctx: CanvasRenderingContext2D | null canvas.getContext(2d); ctx?.fillRect(25, 25, 100, 100); ctx?.clearRect(45, 45, 60, 60); ctx?.strokeRect(50, 50, 50, 50); } setTimeout(() { console.log(canvas paint ready!); resolve(true); }, 10000); }); }; return ( h2Home Page/h2 CacheCanvas bizID{test} ref{childRef} id{GAME_CANVAS_ID} init{initFunc} fallback{() divfallback/div} / button onClick{() { console.log(active cache!); childRef.current?.cacheCanvasToStorage(); }}cache canvas/button / ); }这个示例浓缩了三个关键实践init模拟昂贵的首帧绘制initFunc在 2D 上下文中绘制三个矩形并用setTimeout模拟 10 秒的初始化耗时。在这 10 秒内页面展示的是缓存快照或 fallback10 秒后真实 Canvas 接管用户几乎无感知。手动触发缓存点击cache canvas按钮调用childRef.current?.cacheCanvasToStorage()把当前帧 base64 写入存储下次进入页面时useCache默认开启即可直接命中缓存直出。页面级配置definePageConfig声明页面标题与 meta属于 ice.js 页面的常规配置与 Canvas 缓存能力互不干扰说明插件是可插拔的。示例页面通过 ref 类型RefCacheCanvas与组件暴露的 RefCacheCanvas 接口 严格对齐保证了 TypeScript 类型安全。六、版本演进解读从支持 2D 缓存到修复 sourceMap 发布packages/plugin-cavans/CHANGELOG.md 完整记录了插件的三个发布版本结合ice/cache-canvas的 CHANGELOG 可以还原出整条能力演进线0.0.3 —— 能力起点支持 2D Canvas 缓存018238f9: feat: support cache of 2d cavans支持 2D Canvas 的缓存依赖更新ice/cache-canvas0.0.9、ice/runtime1.2.6这是插件的首发功能版本。对应的ice/cache-canvas0.0.9同样以支持 2D Canvas 缓存为特性见 cache-canvas CHANGELOG同时将ice/runtime纳入依赖意味着该版本插件与 ice.js 运行时绑定负责在运行时导出缓存能力。0.0.4 —— 结构收敛移除 runtimef923c586: chore: remove runtime移除 runtime 依赖依赖更新ice/cache-canvas0.0.12这一版把ice/runtime从依赖中移除插件职责进一步收敛为纯导出形态——这也与当前 src/index.ts 中只调用generator.addExport的极简实现相互印证。同一时期ice/cache-canvas0.0.12完成了两项关键增强CHANGELOGb588f0a4: fix: native back修复原生返回场景下的缓存问题4d5112bf: feat: add storage for canvas为 Canvas 新增存储能力即 storage.tsx 中的 KV/localStorage 降级存取链。0.0.5 —— 发布修复sourceMap 与生产文件对齐b8b1d5e4: fix: sourceMap url in prod files but not publish with sourceMap file修复生产文件中引用 sourceMap url、但发布包未包含 sourceMap 文件的问题依赖更新ice/cache-canvas0.0.13这是当前仓库中的最新版本与 package.json 的version: 0.0.5一致。它修复了一个典型的 npm 发布问题构建产物中残留.map引用但发布包未携带 sourceMap 文件。可以印证的是插件 package.json 的files字段明确写入了!esm/**/*.map——即发布时主动排除所有 sourceMap 文件与本次修复的意图完全对齐。同期ice/cache-canvas0.0.13还修复了两个重要问题CHANGELOG1e4b20af: fix: The base64 of canvans may be too large, and the syncCall will block the threadCanvas base64 过大时同步调用阻塞线程改用异步调用——对应 storage.tsx 中asyncCall写入的实现a04cc002: fix: fix style not match when hydrate修复水合阶段样式不匹配问题——对应 index.tsx 中渲染阶段对style的差异化处理未渲染完成时display: none渲染完成后再应用完整样式。版本间的依赖演进关系插件版本关键变更依赖的 cache-canvas0.0.3feat: 支持 2D Canvas 缓存ice/cache-canvas0.0.9、ice/runtime1.2.60.0.4chore: 移除 runtimeice/cache-canvas0.0.120.0.5fix: sourceMap 发布问题ice/cache-canvas0.0.13三条版本记录共同勾勒出该插件的成熟轨迹从能力从零到一0.0.3到职责收敛、存储能力下沉0.0.4再到发布质量与容器适配打磨0.0.5。对于需要跟进该插件行为的开发者这份 CHANGELOG 配合ice/cache-canvas的 CHANGELOG 可以准确判断升级影响面。七、总结ice/plugin-canvas是 ice.js 插件体系中一个小而美的典型插件本体只有十几行通过generator.addExport把CacheCanvas注入运行时真正的复杂度被合理地沉降到ice/cache-canvas组件中由异步初始化 快照占位 多层存储降级共同支撑起 Canvas 页面的秒开体验。它的版本演进CHANGELOG也展示了 ice.js 生态对插件工程质量的一贯要求。如果你正在用 ice.js 开发 Canvas 类应用游戏、可视化大屏、图形编辑器建议按以下路径实践先在 cavans-project 示例 中跑通缓存直出 手动缓存的完整闭环再对照 CacheCanvas 源码 与 Storage 实现 理解其 SSR 与容器桥的兼容细节最后把init替换为你自己的引擎初始化逻辑如示例 README 中提到的 eva.js 封装场景即可获得开箱即用的 Canvas 渲染缓存能力。【免费下载链接】ice ice.js: The Progressive App Framework Based On React基于 React 的渐进式应用框架项目地址: https://gitcode.com/gh_mirrors/ice1/ice创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ice.js 的 Canvas 渲染缓存插件 @ice/plugin-canvas：从配置接入到 CacheCanvas 源码原理
ice.js 的 Canvas 渲染缓存插件 ice/plugin-canvas从配置接入到 CacheCanvas 源码原理【免费下载链接】ice ice.js: The Progressive App Framework Based On React基于 React 的渐进式应用框架项目地址: https://gitcode.com/gh_mirrors/ice1/ice本文围绕 ice.js 官方插件ice/plugin-canvas展开它负责为 ice.js 应用注入 Canvas 渲染缓存能力使游戏、可视化等重度使用 Canvas 的页面在二次进入时可以直接复用已渲染的帧快照从而跳过昂贵的重绘。读完本文你将掌握该插件的接入方式、CacheCanvas组件的完整 API 与缓存读写机制并能从源码层面理解其2D Canvas 缓存能力的实现脉络包括 版本演进 中每一条变更背后的动机。一、插件定位为 ice.js 应用补齐 Canvas 渲染缓存能力ice/plugin-canvas是 ice.js 生态中专门面向 Canvas 类项目游戏、数据可视化、图形编辑器等的插件。它的package.json中对其职责的描述非常直白Provide canvas render support for ice.js为 ice.js 提供 Canvas 渲染支持。插件本体依赖ice/cache-canvas后者是一个支持缓存的 Canvas React 组件React component for supporting canvas for cache。需要先说明一个细节虽然仓库内该包的目录名是packages/plugin-cavans沿用了较早的拼写但其发布名称为ice/plugin-canvas见 package.json文档与示例代码中使用的也都是ice/plugin-canvas这一名称实际接入时请以下面的包名为准。从整体架构上看该插件解决的是这样一个现实问题Canvas 游戏或图形页面往往包含复杂的初始化与首帧绘制逻辑加载资源、初始化引擎、执行绘图指令每次进入页面都要重来一遍体感很差。ice/plugin-canvas的思路是——把 Canvas 的渲染结果以 base64 快照的形式缓存下来优先写入 App 容器的 KV 存储降级到localStorage下次进入时先用缓存快照直出画面再在后台悄悄完成真实的 Canvas 初始化与绘制做到秒开。插件的源码实现极小却关键ice/plugin-canvas的插件本体非常精简全部逻辑集中在 src/index.ts 中import type { Plugin } from ice/app/types; const PLUGIN_NAME ice/plugin-canvas; const plugin: Plugin () ({ name: PLUGIN_NAME, setup: async ({ generator }) { generator.addExport({ source: ice/cache-canvas, specifier: [CacheCanvas], }); }, }); export default plugin;可以看到插件通过 ice.js 的generator.addExport能力将ice/cache-canvas包中的CacheCanvas组件以顶层导出的形式注入到应用运行时。这意味着只要在ice.config.mts中注册该插件你的页面代码里就可以直接从ice包导入CacheCanvas而无需手动安装和引入ice/cache-canvas。插件不侵入任何页面逻辑职责单一——把能力挂到 ice.js 的运行时导出上。这也是它符合 ice.js 插件体系最小化、声明式设计理念的体现。二、快速接入安装与 ice.config.mts 配置1. 安装插件在 ice.js 项目中安装插件及其依赖组件插件本身已经依赖了ice/cache-canvas一般只需安装插件即可npm i ice/plugin-canvas -S2. 在 ice.config.mts 中注册参照 README 的官方用法在项目根目录的ice.config.mts中加入插件import { defineConfig } from ice; import canvasPlugin from ice/plugin-canvas; export default defineConfig(() ({ plugins: [canvasPlugin({ /* options */ })], }));仓库内的完整示例 examples/cavans-project/ice.config.mts 给出了一个真实可运行的配置import { defineConfig } from ice/app; import canvasPlugin from ice/plugin-canvas; export default defineConfig(() ({ plugins: [ canvasPlugin(), ], ssr: true, ssg: false, }));该示例同时开启了ssr: true服务端渲染并关闭了ssg静态站点生成。这里特意开启 SSR 是有讲究的CacheCanvas组件内部用universal-env的isNode判断运行环境见 cache-canvas/src/index.tsx在 SSR 阶段不会执行浏览器相关的 Canvas 绘制与缓存读取逻辑从而保证同构渲染不报错、不闪烁这一点在后面的源码分析中会展开。3. 页面中直接使用 CacheCanvas注册插件后CacheCanvas会作为 ice.js 运行时的顶层导出出现页面代码可以直接导入import { CacheCanvas } from ice;三、CacheCanvas 组件核心 API 与使用范式CacheCanvas是插件的价值核心其完整实现位于 packages/cache-canvas/src/index.tsx。我们先看它对外暴露的 Props 与 Ref 接口见 index.tsxProps类型默认值说明idstring必填Canvas 元素的 DOM id既是组件渲染canvas的标识也是生成缓存 keycache-canvas-${id}的依据bizIDstring业务标识写入 KV 存储时用于业务隔离避免不同业务间缓存串扰init() Promiseany必填Canvas 初始化/绘制函数必须返回 PromisePromise resolve 后组件才认为渲染完成useCacheBooleantrue是否启用缓存命中逻辑设为false时跳过缓存直接渲染真实 CanvasgetSnapshot() String无自定义快照获取函数默认使用canvas.toDataURL()fallbackReactElement无兜底 UI在既无缓存快照又尚未完成绘制的阶段展示style/classNameHTMLAttributes无透传给 Canvas / 快照图片的样式与类名通过ref暴露的方法RefCacheCanvasRef 方法说明cacheCanvasToStorage()手动将当前 Canvas 渲染结果以 base64 快照写入缓存存储组件内部的工作流程从 组件实现 可以还原出它的完整运行逻辑初始化状态useState(!useCache)决定初始是否直接渲染真实 Canvas。开启缓存默认时renderedCanvas初始为false此时组件不展示真实canvas而是先尝试用存储中的 base64 快照渲染一个img占位index.tsx。异步初始化useEffect中调用你传入的init()只有当返回的 Promise resolve 之后renderedCanvas才会被置为trueindex.tsx真实 Canvas 随即显示并接管画面——这期间用户看到的一直是缓存快照实现无感秒开。兜底降级fallback只在服务端渲染阶段或本地确实没有缓存快照时渲染index.tsx保证最坏情况下也有内容可看。手动/自动缓存调用 ref 上的cacheCanvasToStorage()可将当前帧写入存储index.tsx默认通过canvas.toDataURL()取整帧 base64也可用getSnapshot自定义快照内容。值得一提的是组件内联注入了一段 IIFE 脚本index.tsx用于在客户端异步探测 App 容器桥window.__megability_bridge__的userKVStorage.getItem能力一旦可用就用异步方式拉取缓存快照并替换占位图——这是为了适配小程序/混合 App 容器场景而设计的降级链路。四、缓存存取机制Storage 的多层降级策略快照的存取不直接操作localStorage而是封装在 packages/cache-canvas/src/storage.tsx 的Storage对象中采用**容器 KV 存储优先、localStorage 兜底、内存兜底**的三层策略第一层App 容器 KV 存储userKVStorage。通过window.__megability_bridge__.syncCall(ability, available, { ability: userKVStorage, ... })探测能力是否可用storage.tsx。写入时特意用asyncCall而非syncCall因为Canvas 的 base64 可能非常大同步调用会阻塞线程该问题正是 cache-canvas 0.0.13 的修复点读取时则优先走同步调用获取结果。第二层Web localStorage。容器桥不可用时回退到标准的window.localStorage.setItem/getItemstorage.tsx。第三层内存对象缓存。SSR/无 window 环境下getItem最终回退到模块级cache对象保证读取行为在服务端也不会抛错storage.tsx。setItem全程以 Promise 包裹写入失败会reject并console.error不会影响页面主流程getItem则对异常做了兜底返回空串。这套降级策略让同一套组件代码可以同时跑在 Web、SSR 与混合 App 容器中也解释了为什么示例项目 cavans-project 会同时开启 SSR。五、完整实战示例cavans-project仓库中的 examples/cavans-project 是一个端到端可运行的演示工程它的首页 src/pages/home.tsx 完整展示了CacheCanvas的典型用法import { definePageConfig, CacheCanvas } from ice; import { useRef } from react; export type RefCacheCanvas { cacheCanvasToStorage: () void; }; const GAME_CANVAS_ID canvas-id; export default function Home() { const childRef useRefRefCacheCanvas(); const initFunc () { return new Promise((resolve) { const canvas: HTMLCanvasElement | null document.getElementById(GAME_CANVAS_ID) as HTMLCanvasElement; if (canvas typeof canvas.getContext function) { let ctx: CanvasRenderingContext2D | null canvas.getContext(2d); ctx?.fillRect(25, 25, 100, 100); ctx?.clearRect(45, 45, 60, 60); ctx?.strokeRect(50, 50, 50, 50); } setTimeout(() { console.log(canvas paint ready!); resolve(true); }, 10000); }); }; return ( h2Home Page/h2 CacheCanvas bizID{test} ref{childRef} id{GAME_CANVAS_ID} init{initFunc} fallback{() divfallback/div} / button onClick{() { console.log(active cache!); childRef.current?.cacheCanvasToStorage(); }}cache canvas/button / ); }这个示例浓缩了三个关键实践init模拟昂贵的首帧绘制initFunc在 2D 上下文中绘制三个矩形并用setTimeout模拟 10 秒的初始化耗时。在这 10 秒内页面展示的是缓存快照或 fallback10 秒后真实 Canvas 接管用户几乎无感知。手动触发缓存点击cache canvas按钮调用childRef.current?.cacheCanvasToStorage()把当前帧 base64 写入存储下次进入页面时useCache默认开启即可直接命中缓存直出。页面级配置definePageConfig声明页面标题与 meta属于 ice.js 页面的常规配置与 Canvas 缓存能力互不干扰说明插件是可插拔的。示例页面通过 ref 类型RefCacheCanvas与组件暴露的 RefCacheCanvas 接口 严格对齐保证了 TypeScript 类型安全。六、版本演进解读从支持 2D 缓存到修复 sourceMap 发布packages/plugin-cavans/CHANGELOG.md 完整记录了插件的三个发布版本结合ice/cache-canvas的 CHANGELOG 可以还原出整条能力演进线0.0.3 —— 能力起点支持 2D Canvas 缓存018238f9: feat: support cache of 2d cavans支持 2D Canvas 的缓存依赖更新ice/cache-canvas0.0.9、ice/runtime1.2.6这是插件的首发功能版本。对应的ice/cache-canvas0.0.9同样以支持 2D Canvas 缓存为特性见 cache-canvas CHANGELOG同时将ice/runtime纳入依赖意味着该版本插件与 ice.js 运行时绑定负责在运行时导出缓存能力。0.0.4 —— 结构收敛移除 runtimef923c586: chore: remove runtime移除 runtime 依赖依赖更新ice/cache-canvas0.0.12这一版把ice/runtime从依赖中移除插件职责进一步收敛为纯导出形态——这也与当前 src/index.ts 中只调用generator.addExport的极简实现相互印证。同一时期ice/cache-canvas0.0.12完成了两项关键增强CHANGELOGb588f0a4: fix: native back修复原生返回场景下的缓存问题4d5112bf: feat: add storage for canvas为 Canvas 新增存储能力即 storage.tsx 中的 KV/localStorage 降级存取链。0.0.5 —— 发布修复sourceMap 与生产文件对齐b8b1d5e4: fix: sourceMap url in prod files but not publish with sourceMap file修复生产文件中引用 sourceMap url、但发布包未包含 sourceMap 文件的问题依赖更新ice/cache-canvas0.0.13这是当前仓库中的最新版本与 package.json 的version: 0.0.5一致。它修复了一个典型的 npm 发布问题构建产物中残留.map引用但发布包未携带 sourceMap 文件。可以印证的是插件 package.json 的files字段明确写入了!esm/**/*.map——即发布时主动排除所有 sourceMap 文件与本次修复的意图完全对齐。同期ice/cache-canvas0.0.13还修复了两个重要问题CHANGELOG1e4b20af: fix: The base64 of canvans may be too large, and the syncCall will block the threadCanvas base64 过大时同步调用阻塞线程改用异步调用——对应 storage.tsx 中asyncCall写入的实现a04cc002: fix: fix style not match when hydrate修复水合阶段样式不匹配问题——对应 index.tsx 中渲染阶段对style的差异化处理未渲染完成时display: none渲染完成后再应用完整样式。版本间的依赖演进关系插件版本关键变更依赖的 cache-canvas0.0.3feat: 支持 2D Canvas 缓存ice/cache-canvas0.0.9、ice/runtime1.2.60.0.4chore: 移除 runtimeice/cache-canvas0.0.120.0.5fix: sourceMap 发布问题ice/cache-canvas0.0.13三条版本记录共同勾勒出该插件的成熟轨迹从能力从零到一0.0.3到职责收敛、存储能力下沉0.0.4再到发布质量与容器适配打磨0.0.5。对于需要跟进该插件行为的开发者这份 CHANGELOG 配合ice/cache-canvas的 CHANGELOG 可以准确判断升级影响面。七、总结ice/plugin-canvas是 ice.js 插件体系中一个小而美的典型插件本体只有十几行通过generator.addExport把CacheCanvas注入运行时真正的复杂度被合理地沉降到ice/cache-canvas组件中由异步初始化 快照占位 多层存储降级共同支撑起 Canvas 页面的秒开体验。它的版本演进CHANGELOG也展示了 ice.js 生态对插件工程质量的一贯要求。如果你正在用 ice.js 开发 Canvas 类应用游戏、可视化大屏、图形编辑器建议按以下路径实践先在 cavans-project 示例 中跑通缓存直出 手动缓存的完整闭环再对照 CacheCanvas 源码 与 Storage 实现 理解其 SSR 与容器桥的兼容细节最后把init替换为你自己的引擎初始化逻辑如示例 README 中提到的 eva.js 封装场景即可获得开箱即用的 Canvas 渲染缓存能力。【免费下载链接】ice ice.js: The Progressive App Framework Based On React基于 React 的渐进式应用框架项目地址: https://gitcode.com/gh_mirrors/ice1/ice创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考