分享开发直播系统遇到的问题及解决方案(uniapp)

1. 项目背景与技术选型

近期启动了一个基于 UniApp 的直播系统开发项目。在明确需求后，迅速完成了技术栈选型并投入开发。整体架构旨在实现一套代码多端运行（H5、微信小程序、APP），涵盖首页、直播列表、个人中心等核心模块。

• 前端框架：UniApp
• 后端管理：FastAdmin
• 即时通讯(聊天服务)：Workerman
• 目标平台：H5、微信小程序、原生 APP

2. 核心挑战与解决方案

虽然整体功能开发进展顺利，但在直播间页面的多端适配过程中遇到了三个关键技术瓶颈。以下是具体问题及最终的解决策略：

问题一：H5 端播放卡顿

• 现象描述：
  在 H5 端调试时，进入直播间页面加载极慢，体验严重卡顿。
• 原因分析：
  经排查，问题源于引用的第三方库 [hls.min.js]。该文件通过外网 CDN 引入，受网络波动影响较大，导致资源加载阻塞。
• ? 解决方案：
  本地化部署。将 [hls.min.js] 下载至项目本地目录，改为本地引用。此举显著提升了加载速度，彻底解决了卡顿问题。

  注：H5 端采用 m3u8 (HLS) 格式流，小程序端采用 rtmp 格式流。

问题二：APP 端页面层级错乱

• 现象描述：
  H5 和小程序端运行正常，但打包至 APP 端时，直播间页面布局完全错乱，视频组件覆盖异常。
• 原因分析：
  查阅文档后发现，这是由原生 APP 中视频组件的层级（Z-Index）导致的。试图在单一的 [.vue] 文件中通过条件编译兼容所有端（H5/小程序/APP）的方案，在处理复杂视频层级时存在天然局限。即便借助 AI 辅助调试三天，仍无法完美解决。
• ? 解决方案：
  拆分代码策略。放弃“一套代码通吃”的执念，改为维护两套直播间代码：
  1. [.vue] 文件：专用于 H5 和微信小程序。
  2. [.nvue]) 文件：专用于原生 APP（利用其原生渲染优势解决层级问题）。

问题三：APP 端推流功能实现困难

• 现象描述：
  由于 H5 限制及微信小程序政策调整（不再开放主播推流权限），推流功能仅在 APP 端有实际需求。在完成 [nvue]) 页面基础功能后，尝试利用 AI 生成推流逻辑，耗时两天仍未成功，且导致代码逻辑混乱。
• 原因分析：
  直播推流涉及底层摄像头权限、编码参数及推流协议，逻辑复杂度较高。完全依赖 AI 生成复杂业务逻辑容易导致代码结构不可控，维护成本激增。
• ? 解决方案：
  模块化隔离开发。
  1. 单独开发一个仅包含推流功能的独立页面，确保核心逻辑纯净可用。
  2. 验证成功后，再将该功能模块移植整合到主直播间页面中。

     经验总结：对于高复杂度的底层功能，AI 可作为辅助参考，但核心逻辑仍需人工把控，避免过度依赖导致代码失控。

3. 总结

本次开发经历表明，在跨端直播场景下，"因地制宜"比“强行统一”更有效。针对视频播放和推流等特殊场景，灵活采用 [.vue] 与 [.nvue] 分离的策略，以及模块化开发思路，是保障项目稳定落地的关键。

本项目前端代码已正式开源，旨在为开发者提供一套可参考的直播系统实现方案。欢迎各位同仁查阅源码、交流技术或将其作为二次开发的基础。

DCloud 插件市场**
便于直接在 HBuilderX 中导入使用：
点击查看插件详情 https://ext.dcloud.net.cn/plugin?id=26606

Gitee 代码仓库**
获取完整源代码及提交历史：
访问仓库地址 https://gitee.com/mldxmy/simplelive