前言主进程骨架搭完以后我没有马上去写复杂交互而是先给自己定了一个最小目标先做出一个真的像桌宠的窗口再把模型画进去。因为如果窗口本身还是普通软件窗口后面再怎么调模型视觉感觉都不对。桌宠最先要成立的其实是“它像一个悬浮在桌面的角色”而不是“它能播放模型”。总体过程第一步我先把窗口做成桌宠外壳这一层我放在了 src/main/windows/model-ui.js。我当时的思路很简单窗口参数先一步到位把桌宠该有的气质先定出来。核心参数就是这些transparent: true, frame: false, resizable: false,这样一来窗口就不再像普通软件而是变成了一个透明悬浮层。做到这里我才第一次真正感觉“桌宠外壳”出来了。但是与此同时问题明显出现了。在调试时由于代码可能出现错误resizable: false,很容易导致窗口的报错看不了(因为悬浮窗初始化很小并且我无法拉动边界放大与此同时如果背景是透明的甚至很难定位到窗口的问题毕竟Electron的错误需要在窗口查看。第二步故意让页面结构很简单主窗口加载的是 src/renderer/pages/index.html。我没有在这里堆 DOM而是刻意只保留了一个核心区域canvas idcanvas/canvas原因很简单主窗口的主角不是网页布局而是模型本身。页面只是承载的画布仅此而已。我当时就是想先把角色画出来所以页面只保留最必要的承载层其他交互后面再补。第三步用 Pixi.js 渲染既然页面里只留了 canvas那下一步自然就是找一个足够轻、又适合 2D 模型渲染的引擎。我最后选的是 Pixi.js。它在这个项目里承担的角色很明确- 创建渲染上下文- 管理舞台- 管理精灵和模型对象- 后面给 Live2D 和 Spine 提供共同的绘制基础我当时很喜欢这个方案因为 Electron 负责窗口Pixi 负责画面职责特别清楚。为什么我没有把模型格式写死因为我查找了现有的相似产品stream 的Live2DviewerEX的创意工坊我发现了除了live2d外还有spine的支持并且深入了解后发现spine体系散乱市面上版本层次不齐统一极度困难。所以我意识到如果窗口层写死只支持某一种格式后面扩展就会很难受。我后来在渲染层专门做了一层判断读取文件夹的适合进行路由判断。如果是 .model3.json走 Live2D 管理器如果是 .skel 或 Spine JSON走 Spine 管理器这就意味着主窗口不是“某一种模型播放器”而是“一个通用模型舞台”。我现在回头看这一步非常值因为后面功能加多以后整个渲染结构依然没塌。我是怎么把“窗口”和“模型”接起来的我当时给自己梳的链路就是1. 主进程创建透明窗口2. 窗口加载 index.html3. 页面脚本初始化 Pixi 应用4. 从配置里读取模型路径5. 根据文件类型选择管理器6. 管理器把模型挂到 Pixi 舞台上只要这条链路通了这个项目第一阶段最关键的目标就算达成了角色能出现在桌面上。Live2D 这一层我做了什么Live2D 管理器这边我先做了 4 件最基本的事把模型加载出来根据窗口尺寸重新缩放把模型居中摆放给后面点击和视线控制预留接口也就是说我没有一开始就追求“它要会很多动作”而是先保证它能稳定显示、位置正常、尺寸正常。这是我做这个项目时一直在坚持的思路先做最小闭环再谈增强。但是由于有Spine的介入他和live2d虽然看起来大差不差但是一些细节截然不同例如两种模型对于中心点的位置判断不一样模型边界判定不同等。这些问题使得代码编写难度提高。这一阶段我最在意的不是酷炫而是稳定很多人第一次做桌宠会忍不住先追求动作很多效果很炫等但我在这一阶段其实反而更克制。因为只要窗口是对的模型能稳定加载缩放和位置正常后面所有交互才有继续叠上去的基础。本篇小结这一篇我做的事情本质上很简单先用 Electron 做出桌宠窗口的外壳再用 Pixi.js 把模型渲染能力塞进去最后用一层管理器把 Live2D 和 Spine 统一接到主窗口。做到这里这个项目才算真正从“想法”进入“能看见东西”的阶段。