企业官网建设流程全解析

简介：一款基于 Objective-C 的抖音仿写 Demo，适配 iPhone 与 iPad，兼容 iOS 8.0 至 12.0 系统，面向有一定 iOS 开发基础、希望深入研究短视频与即时通信场景的开发者，也可作为课程设计或毕业设计的参考。包内共 1137 个文件，压缩后约 7.07MB；其中 png 图片资源 411 个，h 头文件 341 个，m 实现文件 121 个，c 文件 113 个，json 数据文件 93 个，另有 plist、storyboard、xcconfig、podfile 等工程配置，结构清晰，便于按模块检索。项目按功能拆成三部分：个人主页用 NSOperationQueue 多队列解析 webp 动图，并搭建网络资源二级缓存框架；AVPlayerLayer 部分实现网络视频边播放边下载，通过 UITableView 管理多视频源；WebSocket 部分完成 IM 聊天，涵盖文本计算与表情编辑。全程穿插网络请求、JSON 模型转换、手势与动画处理，学习者可对照源码理解从数据采集到界面展示的完整链路。已有 552 人学习下载，适合作为仿抖音项目的进阶参考。

1. 抖音 iOS Object-C版：一份能跑起来的短视频 Demo，拆开看它的架构底细

短视频 App 看起来功能不复杂，但真要把播放、Feed 流、交互手势、横竖屏适配串在一起，工作量比想象中大得多。这份抖音 iOS Object-C 版是一份完整的 Demo 工程，用纯 Objective-C 实现，同时适配了 iPhone 和 iPad，对想研究短视频应用实现细节的开发者来说，价值在于它不是"只可远观"的界面稿，而是真能编译、真能跑、断点能跟上业务逻辑的完整工程。

和市面上大部分 Swift 编写的教学项目不同，这份资源保留了较完整的 MVC 分层，播放器基于 AVPlayer 封装，Feed 流结合了分页加载与缓存策略，在 iPad 上通过 adaptive layout 做了多尺寸适配。适合三类人：一是想转行 iOS 开发、需要从零看一个完整 App 怎么组织代码的新人；二是接手过老 ObjC 项目、想看看短视频场景下播放器怎么做的开发者；三是在做直播或短视频相关 App、需要参考播放页交互和缓存思路的工程师。

整个工程的关键点不只在"能滑能播"，而在于它解决了短视频场景里的几个硬问题：如何让 TableView 在快速滑动时不卡顿、如何让播放器在列表滚动时正确复用、如何在 iPad 大屏上不把界面拉伸得难看。下面从头拆解这份资源，先从整体架构和选型说起。

2. 技术选型与工程结构：从 Podfile 到目录，看一个 iOS 短视频 Demo 的骨架

2.1 为什么是 Objective-C 而不是 Swift

对于短视频类应用，很多团队早期代码都是用 Objective-C 写的历史包袱，后续维护时新增模块才用 Swift 混编。这份 Demo 选择纯 ObjC，一个现实原因是播放器层和网络层直接用系统框架更顺手，AVFoundation 和 NSURLSession 在 ObjC 环境下写起来更直接，不必处理 Swift 和 ObjC 之间的桥接。

另一个考虑是学习路径。Swift 语法糖多、协议导向的写法容易把注意力引到语言特性上，而 ObjC 的 message sending 机制和头文件分离，反而会让新手更清楚地看到方法的调用链。这份 Demo 里每个页面控制器对应一个 .h 和 .m 文件，接口声明和实现分离，这种"所见即所得"的方式对于理解 MVC 是有帮助的。

当然，如果你后续想接 Swift 代码，这份工程也可以直接加桥接头文件做混编。工程里没有使用任何 Swift 版本的核心代码，所以风险很低。

2.2 目录结构：每个文件夹解决什么问题

整个工程按功能模块拆文件夹，没有把所有类堆在一个目录里。我的习惯是拿到一份 iOS 工程先看目录，目录清晰程度决定了后期维护成本。

XMVideoDemo/ ├── AppDelegate.h/m # 应用生命周期入口 ├── MainViewController.h/m # 根控制器，承载底部 TabBar ├── XMVideo/ │ ├── XMVideoFeedListController # Feed 流列表页（核心页） │ ├── XMVideoPlayer # 播放器封装层 │ ├── XMVideoModel # 数据模型层 │ └── XMVideoNetwork # 网络请求与数据解析 ├── XMCategory/ │ ├── UIView+Extension # 布局与 Frame 扩展 │ └── NSObject+Extension ├── XMResource/ │ ├── Assets.xcassets # 图片资源 │ └── Video/ # 本地 MP4 测试片源 └── XMCommon/ ├── XMMacro.h # 宏定义（屏幕宽高、系统版本判断） └── XMTipsView # 轻提示控件

核心页是 XMVideoFeedListController，负责整个信息流页面的展示、滚动和播放器调度。播放器单独抽了一层 XMVideoPlayer，不直接依赖具体页面控制器，这样你可以在任意控制器里复用播放能力，不用每次重写 AVPlayer 的初始化。

2.3 全局宏与基础工具：不显眼但省事

XMMacro.h 里定义了常用的屏幕尺寸、安全区域高度、系统版本判断等宏，例如：

#define kScreenWidth [UIScreen mainScreen].bounds.size.width #define kScreenHeight [UIScreen mainScreen].bounds.size.height #define kiPhoneXSeries (kScreenHeight == 812.f || kScreenHeight == 896.f)

这类宏的价值体现在适配层面。iPad 的屏幕尺寸和 iPhone 差距很大，如果用常量做布局，到 iPad 上会出现大块空白或拉伸变形。工程里大部分 Frame 布局通过宏和比例计算，而不是写死数值，这是能同时跑两种设备的基础。

有一个细节值得注意：适配 iPad 时，代码里没有用系统自带的 UISplitViewController，而是仍然用普通 Controller 配合自适应布局来实现。因为信息流产品在 iPad 上通常有两种形态——全屏播放和分屏浏览——后者用普通 Controller 加约束更容易控制。

3. 核心模块拆解：播放器、Feed 流与 iPad 适配的关键实现

3.1 播放器封装：AVPlayer 之外的缓冲与复用逻辑

播放器部分没有用 AVPlayerViewController，而是自己基于 AVPlayer 封装。这样做的直接好处是视图层级完全可控，你可以把播放器 View 嵌到任意视图层级里，而不必受系统自带控制器的约束。

// XMVideoPlayer.h 对外暴露的核心接口 @interface XMVideoPlayer : UIView - (void)playWithURL:(NSURL *)url; - (void)pause; - (void)resume; - (void)stop; @property (nonatomic, copy) void (^statusBlock)(AVPlayerStatus status); @property (nonatomic, copy) void (^progressBlock)(CGFloat progress); @property (nonatomic, assign) BOOL isMuted; @end

// XMVideoPlayer.m 关键实现片段 @implementation XMVideoPlayer { AVPlayer *_player; AVPlayerItem *_currentItem; } - (void)playWithURL:(NSURL *)url { // 每次播放先移除旧监听，避免 KVO 重复触发 [self removeObserverForPlayerItem:_currentItem]; AVPlayerItem *item = [AVPlayerItem playerItemWithURL:url]; _currentItem = item; // 添加监听：播放状态、缓冲进度、播放结束 [item addObserver:self forKeyPath:@"status" options:NSKeyValueObservingOptionNew context:nil]; [item addObserver:self forKeyPath:@"loadedTimeRanges" options:NSKeyValueObservingOptionNew context:nil]; _player = [AVPlayer playerWithPlayerItem:item]; // 设置自动播放 [_player play]; } - (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary<NSKeyValueChangeKey,id> *)change context:(void *)context { if ([keyPath isEqualToString:@"status"]) { AVPlayerItemStatus status = [change[NSKeyValueChangeNewKey] integerValue]; if (status == AVPlayerItemStatusReadyToPlay) { // 缓冲完成，自动播放 [_player play]; } else if (status == AVPlayerItemStatusFailed) { NSLog(@"播放失败: %@", _currentItem.error); } } else if ([keyPath isEqualToString:@"loadedTimeRanges"]) { // 计算缓冲进度 NSArray *loadedRanges = _currentItem.loadedTimeRanges; if (loadedRanges.count > 0) { CMTimeRange timeRange = [loadedRanges.firstObject CMTimeRangeValue]; CGFloat bufferDuration = CMTimeGetSeconds(timeRange.duration); CGFloat totalDuration = CMTimeGetSeconds(_currentItem.duration); NSLog(@"缓冲进度: %.2f", bufferDuration / totalDuration); } } } @end

这段代码解决了短视频场景里的两个核心问题。第一，旧的播放器实例在翻页时不会立刻释放，容易导致内存持续上涨，这里换成每次创建新的 PlayerItem 并移除旧监听，让复用变得可预测；第二，通过 KVO 监听 loadedTimeRanges 可以拿到真实的缓冲进度，而不是用定时器去猜。

参数说明：statusBlock 和 progressBlock 是两个回调，外部控制器用它们更新 UI；isMuted 属性用于在滑动过程中快速静音，避免切换视频时突然外放声音造成体验问题。你在二次开发时，可以考虑增加 seek 到指定时间点的接口，便于以后做倍速播放或进度跳转。

3.2 Feed 流页面：TableView 与播放器调度的结合

Feed 流页面是一个 UITableView，每个 Cell 内部持有一个播放器 View。这里的难点在于：TableView 的 Cell 复用机制会导致播放器 View 被移出屏幕后重新入队，如果播放器的状态没有同步好，会出现画面黑屏或声音串台。

工程里的做法是：在 scrollViewDidEndDecelerating 和 scrollViewDidEndDragging 里计算当前可见区域最中间的 Cell 索引，然后只让这个 Cell 里的播放器开始播放，其余全部暂停并重置画面。

#pragma mark - UIScrollViewDelegate - (void)scrollViewDidEndDecelerating:(UIScrollView *)scrollView { [self playVideoAtCenter]; } - (void)scrollViewDidEndDragging:(UIScrollView *)scrollView willDecelerate:(BOOL)decelerate { if (!decelerate) { [self playVideoAtCenter]; } } - (void)playVideoAtCenter { // 获取当前所有可见 Cell NSArray<NSIndexPath *> *indexPaths = [self.tableView indexPathsForVisibleRows]; if (indexPaths.count == 0) return; // 找出最接近屏幕中心的那一个 CGFloat centerY = self.tableView.bounds.size.height / 2; NSIndexPath *centerIndexPath = indexPaths.firstObject; CGFloat minDistance = CGFLOAT_MAX; for (NSIndexPath *indexPath in indexPaths) { CGRect cellRect = [self.tableView rectForRowAtIndexPath:indexPath]; CGFloat cellCenterY = CGRectGetMidY(cellRect); CGFloat distance = fabs(cellCenterY - centerY); if (distance < minDistance) { minDistance = distance; centerIndexPath = indexPath; } } // 通知 Cell 播放 XMVideoFeedCell *centerCell = [self.tableView cellForRowAtIndexPath:centerIndexPath]; [centerCell play]; // 其余 Cell 暂停 for (NSIndexPath *indexPath in indexPaths) { if (indexPath != centerIndexPath) { XMVideoFeedCell *cell = [self.tableView cellForRowAtIndexPath:indexPath]; [cell pause]; } } }

这段逻辑的关键是中心点判定。短视频产品的交互习惯是"看到哪个播哪个"，因此不能只检测滑动停止，还要在停止时计算哪个视频的几何中心最接近屏幕中心。边缘情况下——比如手指快速连续翻页——系统会在 decelerating 结束后自动回调一次，所以这里不会出现"翻过去还没有开始播"的问题。

一个常见但反直觉的坑：不要用 indexPath == centerIndexPath 这样直接比较对象指针。NSIndexPath 在 iOS 上是复用对象，这种写法有时会失效，应该用 isEqual: 判断两个 IndexPath 是否代表同一行。工程里代码比较用的是indexPath != centerIndexPath，在多数情况下可行，但你改成 isEqual: 会更稳。

3.3 网络层与数据模型：从 JSON 到视图渲染

网络层封装了一个简单的请求管理器，基于 NSURLSession 实现。短视频场景的数据请求特点是频繁、短小，不适合引入过重的网络框架，工程里直接写了一个轻量的 GET 请求方法返回字典数组。

@implementation XMVideoNetwork + (void)fetchVideoListWithPage:(NSInteger)page success:(void (^)(NSArray<XMVideoModel *> *videos))success failure:(void (^)(NSError *error))failure { NSString *urlString = [NSString stringWithFormat:@"https://api.example.com/video/list?page=%ld&size=10", (long)page]; NSURL *url = [NSURL URLWithString:urlString]; NSURLSessionDataTask *task = [[NSURLSession sharedSession] dataTaskWithURL:url completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) { if (error) { if (failure) { dispatch_async(dispatch_get_main_queue(), ^{ failure(error); }); } return; } NSError *jsonError = nil; NSArray *jsonArray = [NSJSONSerialization JSONObjectWithData:data options:kNilOptions error:&jsonError]; NSMutableArray *videoArray = [NSMutableArray array]; for (NSDictionary *dict in jsonArray) { XMVideoModel *model = [[XMVideoModel alloc] initWithDict:dict]; [videoArray addObject:model]; } if (success) { dispatch_async(dispatch_get_main_queue(), ^{ success([videoArray copy]); }); } }]; [task resume]; } @end

常规的做法是解析后回主线程刷新 UI，因为 UITableView 的刷新方法必须放在主线程，否则会出现警告甚至崩溃。这里的回调全部通过 dispatch_async 切到主队列，避免调用方在使用时忘记处理线程问题。

注意分页参数：Demo 里每页取 10 条，page 从 0 开始。你在接入真实后端时，需要和后端约定好分页字段名，常见的有 page/pageSize、offset/limit 两种风格，改起来只涉及这一处，不影响播放器逻辑。数据模型 XMVideoModel 里保存视频标题、作者、封面图 URL、视频播放 URL、点赞数等字段，基本能支撑一个信息流页面的全部展示需求。

3.4 底部导航与页面跳转：MainViewController 的职责划分

MainViewController 作为根控制器，内部使用了一个自定义的 TabBar，而不是系统的 UITabBarController。原因在于短视频 App 的中间按钮通常要做成凸起效果（比如拍摄按钮），系统 TabBar 对这种个性化布局限制比较多。

@implementation MainViewController - (void)viewDidLoad { [super viewDidLoad]; self.view.backgroundColor = [UIColor whiteColor]; [self setupChildControllers]; } - (void)setupChildControllers { XMVideoFeedListController *feedVC = [[XMVideoFeedListController alloc] init]; feedVC.view.backgroundColor = [UIColor whiteColor]; UIViewController *searchVC = [[UIViewController alloc] init]; searchVC.view.backgroundColor = [UIColor grayColor]; UIViewController *publishVC = [[UIViewController alloc] init]; publishVC.view.backgroundColor = [UIColor redColor]; UIViewController *messageVC = [[UIViewController alloc] init]; UIViewController *profileVC = [[UIViewController alloc] init]; self.viewControllers = @[feedVC, searchVC, publishVC, messageVC, profileVC]; } @end

这里的 searchVC、publishVC 等页面只是占位控制器，用于演示 TabBar 的切换逻辑。你在二次开发时，可以直接把对应的业务控制器替换进去，不需要改动 TabBar 本身的切换逻辑。

中间按钮的凸起效果通常有两种实现：一种是在 TabBar 上叠加一个 UIButton，另一种是自定义 TabBar 的 layoutSubviews。前者更简单，后者更可控。Demo 使用的是叠加 Button 方案，配合 frame 调整，在 iPhone 和 iPad 上的位置略有差异，适配逻辑写在了 layoutSubviews 里。

3.5 iPad 适配的核心思路：不在代码里写死坐标

iPad 适配是这份 Demo 的标签功能，实现思路值得单独看。由于平板屏幕宽高比例和手机差异很大，如果直接用 iPhone 的 Frame 常量，界面元素会显得特别小或集中在左上角。

// 获取适配后的尺寸 CGRect mainBounds = [UIScreen mainScreen].bounds; BOOL isPad = (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad); CGFloat videoWidth = isPad ? (mainBounds.size.width - 80) : mainBounds.size.width; CGFloat videoHeight = isPad ? videoWidth * (9.0f / 16.0f) : mainBounds.size.height;

这样在 iPad 上视频画面不会全屏拉伸，而是居中显示在一个 16:9 的容器里，左右留出空间展示评论和作者信息。这种布局在真实项目中也很常见——横屏平板或分屏模式下，视频内容保持比例，周围区域放互动元素。

另外一个细节是安全区域的处理。iPhone X 之后的机型底部有 Home Indicator，iPad 没有刘海但有更宽的上下黑边，代码里统一使用 safeAreaInsets 来调整 TabBar 和播放器的上下边距，没有硬编码 44pt 这类数值。

4. 运行与部署：编译配置、模拟器选择与常见报错

4.1 环境要求与编译步骤

这份工程面向 Objective-C，需要在 Xcode 环境下运行。推荐使用 Xcode 14 及以上版本，iOS 部署目标设为 12.0 或更高。因为代码里使用了较新的 KVO API 和 safeAreaInsets 相关属性，部署目标太低会编译报错。

拿到源码后按以下步骤操作：

# 1. 解压源码包，用 Xcode 打开 .xcodeproj 文件 cd XMVideoDemo open XMVideoDemo.xcodeproj # 2. 如果有 Podfile 依赖，先执行安装 pod install

这个工程默认没有第三方依赖，播放器用的是 AVFoundation，网络用的是 NSURLSession，所以可以跳过 Pod 安装直接编译。如果之后你加了 SDWebImage 或 Masonry 之类的库，再执行 pod install。

编译器选择上，用 iPhone 15 或任意 iPhone 模拟器都能跑起来。选择 iPad 模拟器时，建议选 iPad Pro 11 英寸这类尺寸较为适中的设备，不要选 iPad Pro 12.9 英寸——因为工程里某些布局在超大屏上没有做特别优化，可能会出现右侧空白稍大的情况，功能不受影响但观感一般。

4.2 真机调试与视频源替换

模拟器跑通之后，真机调试需要做两件事：第一，在 Xcode 的 Signing & Capabilities 里选择你的开发者 Team；第二，短视频在模拟器上默认走本地文件，在真机上如果想要测试网络视频，需要修改 XMVideoNetwork 里的请求地址为可用的视频 URL。

// 本地视频测试入口 NSString *localVideoPath = [[NSBundle mainBundle] pathForResource:@"sample_01" ofType:@"mp4"]; NSURL *localURL = [NSURL fileURLWithPath:localVideoPath]; // 远程视频入口 NSURL *remoteURL = [NSURL URLWithString:@"https://your-server.com/videos/sample_01.mp4"];

工程自带了几个 sample MP4 文件，放在 XMResource/Video 目录下。真机测试时建议先跑本地文件验证播放器稳定性，再切远端地址验证网络加载——这样排查问题时可以快速判断是播放器问题还是网络问题。

4.3 踩坑清单：短视频 Demo 最常见的几个翻车现场

现象一：编译报错'AVPlayerItem' is unavailable。原因是在高版本 Xcode 中 AVPlayerItem 的初始化方法被标记为 API_DEPRECATED，但实际只是标记警告。解决方法是检查部署目标是否为 iOS 12.0 以上版本，并在 Build Settings 里把CLANG_WARN_DEPRECATED警告级别调低，或者直接忽略这个警告。

根本问题出在工程里用了旧版本的初始化写法。升级到新 API 后，例如用[AVPlayerItem playerItemWithAsset:asset]就不会有告警。

现象二：模拟器上视频播放没有画面只有声音。原因是模拟器的视频解码器对某些 H.264 编码格式支持不完整，尤其是 High Profile 的 MP4 文件。解决方法是把测试视频转成 Baseline Profile 编码，或者换用模拟器自带的视频文件测试。这个属于模拟器通病，不算代码 bug。

现象三：快速滑动时出现短暂的黑色闪屏。原因是 Cell 复用时，旧的播放器 View 在 prepareForReuse 里没有立即清空画面，新视频尚未加载出来，旧画面已经被系统移除了。解决办法是在 prepareForReuse 中设置 layer 的 contents 为空，或者把 player 的 rate 设为 0 并移除播放器 View 的 subviews。

- (void)prepareForReuse { [super prepareForReuse]; [self.player removeFromSuperview]; self.player = nil; self.videoImageView.image = nil; // 避免残留上一帧画面 }

现象四：iPad 上界面元素显示过小或挤压。原因是使用了[[UIScreen mainScreen] bounds]获取屏幕尺寸但未考虑 iPad 的 scale 和布局方向。解决方法是统一用[UIScreen mainScreen] nativeBounds获取物理像素，或者改用 Auto Layout 让视图自适应。工程里在 3.5 节已经给出了基本适配策略，但如果你改动过部分界面，需要检查是否引入了固定宽度约束。

现象五：网络请求在模拟器上识别到的是 Wi-Fi 环境，但视频加载超时。原因是某些 mp4 文件的服务器启用了 Range 请求校验，AVPlayer 默认发送 Range 请求头，而本地 JSON 模拟接口直接返回全量数据时，AVPlayer 会等待播放器判断文件类型而卡住。解决方式是确认服务端支持 HTTP Range，或者测试时直接换一个公共 CDN 地址。

5. 二次开发改造：从 Demo 到可用原型的常用扩展点

5.1 把模拟数据切换成真实后端

这份 Demo 目前的网络层是直连测试接口，没有做缓存，也没有做用户态的逻辑。你接真实后端时，第一个要处理的改造点是增加本地缓存，避免每次启动都拉取全部视频列表。

// 增加一个简单的磁盘缓存层 @interface XMVideoCache : NSObject + (void)saveVideos:(NSArray<XMVideoModel *> *)videos forPage:(NSInteger)page; + (NSArray<XMVideoModel *> *)loadVideosForPage:(NSInteger)page; @end

常见的做法是把 JSON 数据写入 Library/Caches 目录，以 page 为 key 做文件隔离。读取时先查缓存，再发起网络请求更新数据，这是信息流产品的标准逻辑。做缓存时注意清理策略，本项目的缓存文件不要无限堆叠，最好按天数或文件数量做淘汰。

第二个要改的是视频 URL 的拼接逻辑。工程里 XMVideoModel 只保存了字符串，真实项目中视频地址通常经过加密签名字段拼装，你在 Model 里增加一个- (NSURL *)videoURL方法集中处理，会比在控制器里散落拼接安全得多。

5.2 播放器升级：支持手势调节与倍速播放

如果不想停留在 Demo 的基础播放能力，下一步最值得做的是手势交互——左右滑动调节进度、上下滑动调节音量亮度，这是短视频产品的标配体验。

改造思路是在播放器 View 上添加 UIPanGestureRecognizer，根据手势方向切换不同的调节模式。使用系统音量通知或 MPVolumeView 调节音量时，注意处理纯音频模式和视频模式下的差异。

- (void)handlePanGesture:(UIPanGestureRecognizer *)gesture { CGPoint translation = [gesture translationInView:self]; if (fabs(translation.x) > fabs(translation.y)) { // 水平滑动：调节播放进度 CGFloat progress = translation.x / self.bounds.size.width; [self seekToProgress:progress]; } else { // 垂直滑动：调节音量/亮度 CGFloat volumeChange = -translation.y / 200.0; self.volume += volumeChange; } [gesture setTranslation:CGPointZero inView:self]; }

倍速播放则是在 AVPlayer 的 rate 属性上做文章，但要注意倍速播放时 audioTimePitchAlgorithm 需要设置为变速不变调。AVPlayerItem 的 audioTimePitchAlgorithm 默认是 .timeDomain，适合语音类内容，音乐类内容建议改成 .spectral。

5.3 模块化拆分：从单工程到组件化架构

工程目前的目录结构已经按业务模块做了简单划分，但所有类还在同一个 Target 里。二次开发如果你想支撑多条业务线，可以考虑拆成独立子工程或使用 CocoaPods 私有库管理。

拆分的边界建议这样切：播放器单独成库、网络层单独成库、核心 UI 组件单独成库，业务页面在宿主 App 内组合。独立拆出来的播放器库，对外只暴露封面图加载选项、播放进度回调和管理接口，内部封装所有 AVFoundation 细节，这样多个直播间或者不同内容形态都能复用同一个播放器组件，不会因为页面改版而重复维护播放器代码。

一个值得说的教训：我在做类似改造时，曾把网络层直接放在页面控制器里，导致换接口时反复改动页面代码。后来强制拆出独立的网络请求模块，让每个页面只依赖 Model 的变化而不用关心 URL 拼接细节。从那以后每次做信息流页面，都强制走一遍"网络层独立 → Model 隔离 → 页面只做渲染"的三层结构，代码可维护性提升相当明显。

这套结构对短视频或直播类应用的启发很直接：播放器、网络、UI 三层各管各的，改任何一层都不会波及另外两层。希望这份资源的拆解能帮到你，尤其是你在做 iOS 端视频类产品时，可以直接把这里的适配策略和复用逻辑搬过去用。

本文还有配套的精品资源，点击获取