【开源】Cocos 高性能虚拟列表 SKILL(带演示工程)

地址:https://github.com/VaJoy/cocos-virtual-list (支持的话欢迎点 star :star:

SKILL 使用方式

./skills 文件夹放到你的项目根目录下,然后直接向 Agent 提出疑问或需求:

  • “基于 cocos-virtual-list,总结下实现一个高性能虚拟列表需要留意哪些点?”
  • “基于 cocos-virtual-list,修改 assets/virtual-list(替换为你的虚拟列表文件夹路径)的虚拟列表,让它支持不等高 item 的模式。”
  • “修改 assets/virtual-list(替换为你的虚拟列表文件夹路径)的虚拟列表,让它支持分层渲染。”

保守起见,建议以「基于 cocos-virtual-list」开头,确保 agent 命中该 SKILL。

演示工程(基于 3.8.6)

./skills/examples/cocos-3.8.6-project-demo 是基于此 SKILL 创建的虚拟列表工程,运行时会生成 10 万条数据,但能确保在虚拟列表中顺畅滚动展示。

在「打开摄像头都会卡 10 秒」的低端红米手机上的演示:

性能/交互保障:

  • 支持垂直和水平滚动模式(可根据 vertical 参数修改模式)。
  • 像素对齐 —— 定位走 Math.round,规避子像素采样导致 item 纹理发虚/闪烁的问题(可通过 pixelAlign 参数关闭此功能)。
  • 只生成容器视口可见的 item + 前后缓冲的 item(默认单侧缓存 2 个,可通过 buffer 参数修改)。
  • item 走对象池复用。
  • 高速滚动降低刷新率——飞速≈20fps、快速≈30fps、慢速≈60fps(可通过 throttle 参数关闭此功能)。
  • 自动统计最近几帧的耗时,识别为低性能时自动降级刷新率到 30fps(可通过 autoDowngrade 参数关闭此功能)。
  • 支持内置 item 点击事件。

:bulb: 如果有功能扩展需要,可以基于此 SKILL 对其进行二次改造。
:bulb: 想尝试 Agent 的可以来 workbuddy 薅羊毛, 新用户送 2600 积分,每天签到又送 100 积分,搭配 ds v4 flash 可以用很久。


其它分享

4赞

你在skills里塞了个cocos的demo。是不是故意坑我的硬盘容量啊。 :rofl:

很小的,没几个文件,像 library 这些又没上传。

按理说,直接把demo给AI,让他把虚拟列表抽出来用到我的项目里就行吧,真的要skills吗

不太一样,这个 SKILL 目标是实现一个【高性能】的虚拟列表,是基于 Cocos 3.8.6 源码 RAG + 多篇技术文章的蒸馏(台上一个普通 SKILL,台下起码花掉了我几千万 token),常规不依赖 SKILL 的 AI 无法了解这些技能点。

如果你的需求是“我看到了一个第三方的虚拟列表(或其它组件),想直接用”,那确实不需要任何 SKILL,直接让 AI Agent 抽出来即可。

虽然但是 先赞一个。

可能我现在会倾向认为虚拟列表技术已经被在LLM的参数中了 所以。。

好吧,但是同样的skill,给不同的模型,生成的虚拟列表应该还是会有不一样的地方吧

谢谢,我个人的经验是:

  • LLM 的预训练对 Cocos 的了解并不够多,因为 Cocos 还不够主流,例如你让 LLM 生成 Cocos 使用的着色器,八成是无法直接使用的;
  • LLM 对虚拟列表的常规认知和实现技术是没问题的,但它缺乏一些可以提升性能的“旁门左道”和基于 Cocos 的优化实现。

未来兴许 LLM 足够聪明到不需要任何的 SKILL,但目前还是不行的。

不要选太差的模型,一般都没啥问题(大不了返工小几次)

一般的模型搭配好的工具 > 顶级的模型但不搭配工具

例如这是我私下开发 Cocos 项目时会使用的系列 SKILL,不需要搭配很贵的顶级模型也能实现高精度的开发、减少大模型幻觉:

1赞

这种虚拟列表测试应该是在item里塞入文本、图片、富文本吧,用图片穿插在文本中间用来打断合批,这样来测才是正常的吧,毕竟游戏开发时会经常这样用

那需要做分层或者动态合批等手段了

都虚拟列表的 还考虑啥合皮

,,,是滴,,,

额,直接把引擎代码拖到工作目录就行了,理解代码没有幻觉

star and fork

star not fork

处理此问题的分层渲染能力在 SKILL 里有的,有需要让它扩展即可。

因为觉得除非断批问题很严重才建议实现分层渲染方案(毕竟 hack 性能开销不小,特别是 3.8.6 没有 Sorting2D 接口),所以演示工程没实现此能力。

有工具直接命中,减少检索源码的过程,又快又准又省 token

有些东西也不在引擎源码里(例如与编辑器强相关的,或者一些技巧)

都在源码里,编辑器相关的也在,毕竟UI会被加载到引擎的不是吗?省token没必要,弄不准确还得不断返工更浪费token

好的,感觉扩展下很有必要 :rofl:,,,我去试试