Auto-Novel项目移动端滚动体验优化实践

Auto-Novel项目移动端滚动体验优化实践

auto-novel 轻小说机翻网站，支持网络小说/文库小说/本地小说 项目地址: https://gitcode.com/gh_mirrors/au/auto-novel

移动端视口高度问题的背景

在Web开发中，移动设备浏览器的视口高度处理一直是个棘手的问题。特别是在使用100vh单位时，由于移动设备浏览器地址栏的动态显示/隐藏特性，会导致实际可视区域高度计算不准确。这个问题在Auto-Novel项目中表现得尤为明显，影响了移动端用户的阅读体验。

问题现象分析

在Auto-Novel项目中，当用户在iPhone或iPad等移动设备上浏览时，页面滚动会出现以下问题：

1. 需要滑动到页面最底部才能收起地址栏
2. 需要再次滑动到页面顶部才能显示地址栏
3. 页面滚动不够流畅，有时需要多次操作才能到达目标位置

这些问题主要源于项目使用了Naive UI框架的NLayout组件，该组件默认使用内部实现的滚动条而非浏览器原生滚动条。这种设计虽然在某些场景下提供了更一致的UI体验，但在移动端却带来了交互上的不便。

技术原因探究

问题的核心在于视口高度单位的应用。项目中使用了height: 100vh的样式定义，这在移动端存在以下缺陷：

1. 100vh在移动端会包含可能隐藏的地址栏区域，导致实际可视区域计算不准确
2. 当地址栏显示/隐藏时，100vh不会自动调整，造成布局错位
3. 内部滚动条实现与浏览器原生滚动行为存在差异

解决方案演进

项目维护者经过多次尝试，最终确定了以下优化路径：

第一阶段：放弃固定Header方案

最初考虑放弃网站的固定Header，让其与页面内容一起滚动。这种方案虽然简单，但会牺牲部分桌面端的用户体验。

第二阶段：采用动态视口单位

考虑到现代浏览器对dvh(dynamic viewport height)单位的支持，项目尝试使用100dvh替代100vh。这个单位能够自动适应移动端地址栏的显示状态，提供更准确的高度计算。

最终方案：回归原生滚动条

经过权衡，项目最终选择回归浏览器原生滚动条实现。这种方案具有以下优势：

1. 完美适配各种移动设备的不同交互模式
2. 无需处理复杂的视口高度计算问题
3. 提供与操作系统一致的滚动体验
4. 减少自定义滚动条带来的性能开销

实现细节

在ReaderLayout组件中，关键的修改包括：

1. 移除了自定义滚动条的配置
2. 简化了高度计算逻辑
3. 确保布局容器能够正确响应视口变化

这些改动显著提升了移动端的滚动体验，同时保持了桌面端的良好表现。

经验总结

通过Auto-Novel项目的这次优化实践，我们可以得出以下Web开发经验：

1. 在移动优先的设计中，应优先考虑使用浏览器原生滚动机制
2. 对于视口高度计算，dvh单位比传统的vh更适合移动场景
3. UI框架提供的增强功能需要权衡其在不同平台的适应性
4. 移动端和桌面端的交互模式差异需要在设计初期就充分考虑

这次优化不仅解决了具体的技术问题，也为类似项目的移动端适配提供了有价值的参考。

auto-novel 轻小说机翻网站，支持网络小说/文库小说/本地小说 项目地址: https://gitcode.com/gh_mirrors/au/auto-novel