混合移动App开发：瑜伽应用视频播放器章节功能与媒体存储方案咨询

针对主流Hybrid开发技术栈，有成熟的组件可以快速实现该效果，不需要从零开发：

• 若采用React Native技术栈：以react-native-video作为核心播放内核，配合react-native-video-controls扩展组件，直接传入提前配置好的章节数据（包含每个章节的起始时间戳、章节缩略图资源），组件原生支持在进度条对应位置渲染图片标记，点击标记可直接跳转到对应章节播放，也可以自定义扩展交互效果。
• 若采用Flutter技术栈：基于官方video_player播放内核，配合chewie组件的自定义控制层插槽，在进度条上层叠加自定义的章节标记组件，按照章节时间占比将缩略图定位到进度条对应位置即可。
• 若采用UniApp类跨端技术栈：基于原生video组件的cover-view自定义能力，在进度条上层叠加章节图片标记，适配多端的成本最低。
  小优化建议：章节缩略图可以在视频转码阶段同步生成，单张大小控制在10KB以内，单独作为静态资源加载，不要嵌入视频文件内，加载速度更快

将视频等大体积媒体资源存入NoSQL数据库、甚至转Base64存储绝对不是更优选择，弊端远大于收益：

• Base64编码会让资源体积直接膨胀33%，100MB的视频转码后会变成133MB，不仅额外占用更多存储空间，移动端加载时的解码耗时也会大幅提升，弱网环境下卡顿概率明显升高。
• NoSQL数据库的设计定位是半结构化数据的高性能查询，并非大体积二进制资源的存储，大部分主流NoSQL数据库单条数据都有大小限制，比如MongoDB单文档BSON上限为16MB，稍长的瑜伽视频根本无法存入，即使用GridFS这类扩展方案，读写性能、CDN适配能力也远不如专门的存储服务。
• 后续运维成本极高：数据库的带宽成本比对象存储高数个量级，大量用户并发拉取视频时，很容易打满数据库带宽直接导致服务宕机，后续资源扩容、迁移的难度也大很多。

推荐方案：视频、缩略图等媒体资源直接存在对象存储服务中，NoSQL数据库仅存储视频的访问地址、时长、章节配置等元数据即可，不管是加载速度、成本、扩展性都有明显优势。

内容的提问来源于stack exchange，提问作者n00b90