提前准备不等于已经展示，局部提速也不等于启动问题已经解决。 今天较完整的一条工作线是 MovieClaw 平台放映厅。海报墙已经能提供推荐，但图片一张张出现，连续换面也需要等待；手机布局、登录回跳和动效裁切又分别影响使用。于是这轮先调整图片请求，再把预加载从单张图片推进到整面队列。另一条工作线来自桌面应用的隔离验证。原生与 Rosetta 下的功能流程可以通过，但启动耗时仍明显不同，需要把应用本身的工作、系统首次执行成本和自动化工具延迟分开测量，不能因为窗口最后打开了就认为性能验收完成。两边都有已完成与进行中的部分。放映厅已经更新到 0.5.3，后续整面显示与默认开关调整仍在实施；桌面应用修复了重复初始化工作，但 Rosetta 整体启动慢尚未解决，也没有发布本轮测试包。海报按显示尺寸取图，把额外加载限制在后台海报墙慢不只是图片数量多。源码检查发现，页面统一使用较大的图片，首屏也全部采用懒加载；取得推荐前，还会等待片单与订阅同步。几个等待叠在一起，让用户先看到空白，再看到图片逐张出现。0.4.9 先按实际显示尺寸取图，减少不必要的下载量，首批 6 张优先显示，其余限量并发加载。换面时保留旧墙，预热新图片；悬停时提前取得详情海报。新增的“提前加载”默认开启，但节省流量模式会暂停额外预加载。当时首屏和换面检查均为 36 张全部加载成功，主程序与原有设置保持不变。这个结果证明样本加载完整，并不能保证首次访问无需下载，也不能保证任何网络条件下都能立即铺满。从下一面到三面队列，预加载不写展示历史0.5.0 把提前加载扩展为下一整面的片单与海报。当前面准备完成后，后台开始准备下一面，显示就绪提示后再供用户切换。实测 36 张海报全部加载，与上一面没有重复，220 项 Python 测试和 11 组前端测试通过。这里最重要的状态区分是：预加载不是展示。只有用户真正切换时才计入展示历史，并重新核对偏好，继续排除已看过的内容。否则后台多准备几面，就会提前消耗展示记录，用户实际没见过的影片也可能被错误排除。随后 0.5.2 将队列扩大为三面，队内也尽量避重。正式服务连续换三次，四面共 144 张海报没有重复。移动端同时修复海报区域被挤小、下载反复中断的问题，并检查页面显示。但用户晚些时候仍觉得加载在视觉上太慢，希望打开就看到完整一面。最新一轮准备改为图片就绪后整面一起显示，保留最多三面的预加载，连续换面优先用已准备内容。这项请求已经开始处理，截至整理时只有实施说明，尚无完成或上线结果；首次访问仍需下载图片，也没有承诺消除网络等待。动效、登录回跳与原生入口分别处理0.5.2 还补上未登录时进入主程序登录、随后返回插件的流程，并提供当前地址或自定义内外网地址的入口链接。生成可用链接解决的是访问路径，不代表主程序已经支持插件网页按钮。当天核对结果显示，MovieClaw 正式版 0.40.0 尚未提供这项原生入口能力，相关实现已经进入官方 main，但还没有正式发布。插件详情中的命令说明也不是可点击的网页入口，因此没有为此直接升级主程序。动效则经历了不同取舍。0.5.2 增强上下浮动和缩放后，用户指出海报裁切过多；0.5.3 改为固定放大 2%、上下各浮动 0.8%，取消动态放大，并确认动画运行。最后的要求又进一步明确：整张海报上下移动，不额外缩放、不改变比例；无缝模式跟随动效开关，全屏和无缝拼接默认关闭，海报墙名称与排序也要调整。这些属于正在实施的新一轮，不与已安装的 0.5.3 混写。动效“看得到”和海报“保持完整”是两个条件，需要一起验收。桌面启动提速，只报告已量到的改善一项桌面应用的隔离验证中，同一份 Universal 包已完成原生与 Rosetta 的备份、回读校验、报告生成、转码及重启恢复等功能检查，但 Rosetta 的首次启动和部分交互仍慢。功能通过不能替代性能结论。无界面的对照也观察到应用侧耗时，因此不能全部归因于桌面自动化。后续定位并消除了重复目录初始化 SQL，定向回归覆盖已有索引不做无效写入、缺失触发器修复、旧触发器升级与工作区恢复，完整性检查仍保留。控制对照的中位耗时从 8.71 秒降到 8.12 秒，约降低 6.75%；982 项测试通过、4 项跳过，原生和 Rosetta 桌面流程重新验收通过。但 Rosetta 再次启动从运行时开始到窗口可显示仍约 21.6 秒，整体启动慢没有解决。晚些时候继续拆分完整性检查、窗口创建和渲染耗时，观察到首次检查明显慢于重复检查，说明包含较多首次执行成本。当前仍保留每次启动的完整检查，没有用削弱校验和恢复保障换取数字改善。排查继续在隔离环境中进行，公开仓库未改动，未上传或提交审核；原生 Intel 与真实外部介质场景也不能由 Rosetta 测试替代。接下来沿着实际等待继续验收今天留下三点认识。后台准备与用户实际看到是不同状态，需要独立记账。图片完整加载、整面同时呈现和连续切换流畅也是不同目标，不能用一次加载成功概括全部体验。性能修复则要同时报告局部收益与剩余耗时，不能把一段初始化提速写成整个启动问题已经解决。放映厅下一步检查整面显示、三面预备、比例不变的浮动，以及默认开关和移动端行为；原生插件入口等待正式版本支持，不擅自升级。桌面应用继续定位串行等待，并在完整性检查和恢复能力保持不变的条件下重新测量与验收。隐私说明本文只整理当天有记录支持的技术进展，泛化私有开发内容，省略个人行程、观看偏好、账户信息、设备标识、服务器地址、私人链接和本地路径。不包含凭据、完整代码或原始日志，保留公开项目名、必要技术术语和测试数据。
2026-10-19｜自然语言编程日记
今天较完整的一条工作线是 MovieClaw 平台放映厅。海报墙已经能提供推荐，但图片一张张出现，连续换面也需要等待；手机布局、登录回跳和动效裁切又分别影响使用。于是这轮先调整图片请求，再把预加载从单张图片推进到整面队列。
另一条工作线来自桌面应用的隔离验证。原生与 Rosetta 下的功能流程可以通过，但启动耗时仍明显不同，需要把应用本身的工作、系统首次执行成本和自动化工具延迟分开测量，不能因为窗口最后打开了就认为性能验收完成。
两边都有已完成与进行中的部分。放映厅已经更新到 0.5.3，后续整面显示与默认开关调整仍在实施；桌面应用修复了重复初始化工作，但 Rosetta 整体启动慢尚未解决，也没有发布本轮测试包。
海报按显示尺寸取图，把额外加载限制在后台
海报墙慢不只是图片数量多。源码检查发现，页面统一使用较大的图片，首屏也全部采用懒加载；取得推荐前，还会等待片单与订阅同步。几个等待叠在一起，让用户先看到空白，再看到图片逐张出现。
0.4.9 先按实际显示尺寸取图，减少不必要的下载量，首批 6 张优先显示，其余限量并发加载。换面时保留旧墙，预热新图片；悬停时提前取得详情海报。新增的“提前加载”默认开启，但节省流量模式会暂停额外预加载。
当时首屏和换面检查均为 36 张全部加载成功，主程序与原有设置保持不变。这个结果证明样本加载完整，并不能保证首次访问无需下载，也不能保证任何网络条件下都能立即铺满。
从下一面到三面队列，预加载不写展示历史
0.5.0 把提前加载扩展为下一整面的片单与海报。当前面准备完成后，后台开始准备下一面，显示就绪提示后再供用户切换。实测 36 张海报全部加载，与上一面没有重复，220 项 Python 测试和 11 组前端测试通过。
这里最重要的状态区分是：预加载不是展示。只有用户真正切换时才计入展示历史，并重新核对偏好，继续排除已看过的内容。否则后台多准备几面，就会提前消耗展示记录，用户实际没见过的影片也可能被错误排除。
随后 0.5.2 将队列扩大为三面，队内也尽量避重。正式服务连续换三次，四面共 144 张海报没有重复。移动端同时修复海报区域被挤小、下载反复中断的问题，并检查页面显示。
但用户晚些时候仍觉得加载在视觉上太慢，希望打开就看到完整一面。最新一轮准备改为图片就绪后整面一起显示，保留最多三面的预加载，连续换面优先用已准备内容。这项请求已经开始处理，截至整理时只有实施说明，尚无完成或上线结果；首次访问仍需下载图片，也没有承诺消除网络等待。
动效、登录回跳与原生入口分别处理
0.5.2 还补上未登录时进入主程序登录、随后返回插件的流程，并提供当前地址或自定义内外网地址的入口链接。生成可用链接解决的是访问路径，不代表主程序已经支持插件网页按钮。
当天核对结果显示，MovieClaw 正式版 0.40.0 尚未提供这项原生入口能力，相关实现已经进入官方 main，但还没有正式发布。插件详情中的命令说明也不是可点击的网页入口，因此没有为此直接升级主程序。
动效则经历了不同取舍。0.5.2 增强上下浮动和缩放后，用户指出海报裁切过多；0.5.3 改为固定放大 2%、上下各浮动 0.8%，取消动态放大，并确认动画运行。
最后的要求又进一步明确：整张海报上下移动，不额外缩放、不改变比例；无缝模式跟随动效开关，全屏和无缝拼接默认关闭，海报墙名称与排序也要调整。这些属于正在实施的新一轮，不与已安装的 0.5.3 混写。动效“看得到”和海报“保持完整”是两个条件，需要一起验收。
桌面启动提速，只报告已量到的改善
一项桌面应用的隔离验证中，同一份 Universal 包已完成原生与 Rosetta 的备份、回读校验、报告生成、转码及重启恢复等功能检查，但 Rosetta 的首次启动和部分交互仍慢。功能通过不能替代性能结论。
无界面的对照也观察到应用侧耗时，因此不能全部归因于桌面自动化。后续定位并消除了重复目录初始化 SQL，定向回归覆盖已有索引不做无效写入、缺失触发器修复、旧触发器升级与工作区恢复，完整性检查仍保留。
控制对照的中位耗时从 8.71 秒降到 8.12 秒，约降低 6.75%；982 项测试通过、4 项跳过，原生和 Rosetta 桌面流程重新验收通过。但 Rosetta 再次启动从运行时开始到窗口可显示仍约 21.6 秒，整体启动慢没有解决。
晚些时候继续拆分完整性检查、窗口创建和渲染耗时，观察到首次检查明显慢于重复检查，说明包含较多首次执行成本。当前仍保留每次启动的完整检查，没有用削弱校验和恢复保障换取数字改善。排查继续在隔离环境中进行，公开仓库未改动，未上传或提交审核；原生 Intel 与真实外部介质场景也不能由 Rosetta 测试替代。
接下来沿着实际等待继续验收
今天留下三点认识。后台准备与用户实际看到是不同状态，需要独立记账。图片完整加载、整面同时呈现和连续切换流畅也是不同目标，不能用一次加载成功概括全部体验。性能修复则要同时报告局部收益与剩余耗时，不能把一段初始化提速写成整个启动问题已经解决。
放映厅下一步检查整面显示、三面预备、比例不变的浮动，以及默认开关和移动端行为；原生插件入口等待正式版本支持，不擅自升级。桌面应用继续定位串行等待，并在完整性检查和恢复能力保持不变的条件下重新测量与验收。
隐私说明
本文只整理当天有记录支持的技术进展，泛化私有开发内容，省略个人行程、观看偏好、账户信息、设备标识、服务器地址、私人链接和本地路径。不包含凭据、完整代码或原始日志，保留公开项目名、必要技术术语和测试数据。