1106 字
6 分钟
实习第一天：uni-app 学习笔记
面向实际业务的 uni-app 技术准备与性能优化考量
本次结合业务线技术栈（Vue 与 uni-app），整理对跨端框架的设计概念（如 nvue、nts、webview、weex），逻辑层与渲染层分离模型的理解，以及在遇到如大量视频与长列表等性能敏感场景下的解决方案调研。
开发侧的核心技术抓手
面对一套包含多端特性的新框架，首先应该建立快速交付抓手，不需要初期通读所有 API，优先把以下核心概念闭环：
- 项目结构：约定目录与文件构建原则及生命周期。
- 页面与组件：如何划分边界并组织基础的交互响应。
- 数据绑定：状态流转以及数据渲染双向机制。
- 事件处理：触控与端能力的 API 调用。
- 路由与跳转：App/页面级路由栈和跳转机制。
- 生命周期：不同端下的页面与组件初始化释放时机。
- 条件编译：多平台架构中最关键的跨端差异填平语法。
场景难点与技术预研
当前负责的业务存在大量较重的流媒体播放和列表交互需求，主要存在两个渲染及加载难点：
- 视频资源过大、不能强依赖一次性全量加载并造成网络与设备负担；
- 长列表的内存泄漏风险和前端 DOM（如小程序节点）上限的性能阻塞。
经过技术调研，制定初步技术解法如下：
视频方面：性能优化方案
针对网课视频时长大（半小时至数小时）的特点，不能采用全量下载。经过调研，制定了分阶段的优化方案。
1. 核心技术原理
- HTTP Range Requests (范围请求)：这是“边下边播”和“拖拽进度”的基石。播放器通过
Range: bytes=start-end请求头，只请求视频的特定片段，而非下载整个文件。 - H.264 编码：兼容性最好的视频编码格式，确保在各种设备上利用硬件解码，省电且流畅。
2. 实施路线图
第一阶段：短期快速优化（前端主导）
- 启用 Range 请求：
- 确认 OSS 或后端接口支持
Range请求头（返回 206 状态码）。主流 OSS（阿里云、腾讯云）默认支持。 - 前端
<video>组件直接使用链接，会自动发送 Range 请求。
- 确认 OSS 或后端接口支持
- 智能预加载：
- 列表页：静默预加载下一节课的元数据（时长、大小）或首个分片（前 1-2MB），利用
uni.downloadFile或 XHR。 - 详情页：
onLoad时立即请求视频地址并初始化播放器，设置preload="auto"。
- 列表页：静默预加载下一节课的元数据（时长、大小）或首个分片（前 1-2MB），利用
- 体验优化：
- 利用
initial-time实现断点续播。 - 监控下载速率，若持续低于码率则提示用户切换清晰度（如果有多清晰度源）。
- 利用
第二阶段：长期架构升级（服务端主导）
- HLS 流媒体：
- 将原始 MP4 转码为 HLS (.m3u8 + .ts) 格式。
- 切片：将大文件切成小的
.ts文件，秒开速度更快。 - 多码率适配：生成不同清晰度（1080p, 720p, 480p）的流，播放器根据网络状况提醒用户切换,如果开了自动则自动切换（Adaptive Bitrate Streaming）。
- CDN 加速：配合 CDN 分发切片文件，降低延迟。
3. 决策建议
- 立即行动：检查现有视频文件是否为 H.264 编码的 MP4。
- 如果是：直接上 Range 请求 + 预加载方案。
- 如果不是：优先转码为 H.264。
- 后续规划：随着用户量增长，搭建服务端转码服务，向 HLS 方案迁移。
列表方面：虚拟列表 vs 懒加载
- 懒加载（Lazy Loading）
- 本质：数据层按需加载（例如先加载前 20 条，滚动到底再加载下 20 条）；
- 问题：虽然减少了初始请求，但最终仍可能渲染大量 DOM 元素，导致页面卡顿。
- 虚拟列表（Virtual List）
- 本质：渲染层优化的进阶方案，只渲染可视区域内的少量 DOM 元素；
- 核心：通过占位容器模拟总高度，滚动时回收离开可视区域的 DOM，用它们渲染新进入可视区域的数据；
- 关键技术点：
- 计算每个项目高度（固定或动态）；
- 根据滚动位置计算显示范围（startIndex、endIndex）；
- 使用偏移（例如 transform: translateY(…)）来模拟正确位置。
实习第一天：uni-app 学习笔记
https://blog.moxiaoshuai.fun/2025-12-实习第一天uni-app学习笔记/ 部分信息可能已经过时