企业官网建设流程全解析

简介：面向 iOS 开发者的仿抖音 Objective-C 工程，适配 iPhone/iPad 与 iOS 8.0 至 12.0，适合学习短视频 App 架构、视频播放与即时通讯的开发者。压缩包共 1137 个文件、约 7.07MB，以 png 切图、.h/.m/.c 源码和 json 配置为主，并含工程配置与说明文档，目录便于按模块浏览。已有 553 人学习。工程含个人主页、视频播放与 IM 聊天三部分，覆盖 NSOperationQueue 解析 WebP 动图及二级缓存、AVPlayerLayer 边播边下与 UITableView 多视频源控制、WebSocket 即时聊天及文本计算和表情编辑。网络请求、JSON 模型转换、手势与动画处理也贯穿各模块，便于对照源码理解仿抖音核心功能的实现。

1. 拿到一份 iOS Objective-C 短视频 Demo：先判断它值不值得跑

短视频 Feed 流看起来就是一条视频加几个按钮，真到自己从零搭，播放器、复用、手势、旋转这几件事叠在一起，两天时间就没了。这份 iOS Objective-C 版短视频 Demo 把整条链路走通了一遍：竖滑切换、播放器复用、点赞评论浮层、本地 mock 数据，并且把 iPhone 和 iPad 两个形态都做了适配。它适合两类人，一类是想快速看清短视频 App 骨架的 iOS 新手，一类是接了个类似需求、需要一份能跑起来对照的熟手。选 Objective-C 而不是 Swift，意味着往老项目里搬代码的成本低很多，MRC 遗留的写法也不用改。工程能不能编译、播放器池怎么设计、iPad 上哪几块最容易出问题，下面按顺序拆。

2. 拆工程结构：播放器、Feed 流、数据层各自站在哪一格

拿到一份不熟悉的 iOS 源码，我的习惯是先看目录分组和 target 设置，再看 ViewController 有多少行。目录分组能看出作者对模块边界的理解，ViewController 的行数能看出他是真拆了还是只做了个样子。这份 Demo 在这两点上做得还算规整，属于能直接拿去改而不是只能看的那类。

2.1 目录分层与 MVC 的真实落点

工程按功能分模块，而不是按文件类型堆在一起：

VideoFeedDemo/ ├── App/ AppDelegate、全局配置、路由入口 ├── Modules/ │ ├── Feed/ Feed 列表控制器、cell、滑动手势 │ ├── Player/ 播放器封装、复用池、预加载器 │ ├── Comment/ 评论面板与输入框 │ └── Profile/ 个人主页 ├── Core/ │ ├── Network/ 请求封装、接口定义 │ ├── Model/ VideoItem、CommentItem 等数据模型 │ └── Cache/ 内存缓存与磁盘缓存 ├── Resources/ 图片、色值、字体配置 └── Supporting Files/ Info.plist、启动图

这套分层里最值得看的是Modules/Player，它被单独拎出来成为一层，而不是散落在 Feed 的 cell 里。这样做的好处是，播放器不用跟着 cell 复用的生命周期被随机创建和销毁，整个 App 只会存在固定数量的 AVPlayer 实例，内存占用和音频焦点都可控。

MVC 的落点也比较干净：Controller 只做编排和状态同步，View 只管布局与手势识别，Model 是纯数据结构不带行为。它的缺点是没有独立的 ViewModel，业务状态（当前播放索引、静音开关、是否在下拉刷新）都挂在 Feed 控制器上，读起来会有点挤。想改成 MVVM 的话，这块可以作为一个后续动作。

2.2 播放器封装被放在哪一层

播放相关的类一共三个，职责切得很清楚：

FeedVideoView只做一件事，把 layer 铺到正确的位置。它不负责创建播放器，也不管什么时候播。VideoPlayerPool是纯粹的实例池，输入一个 AVPlayerItem，输出一个可用的 AVPlayer，回收时断开 item 引用。FeedPlaybackCoordinator是这层的大脑，它监听列表滚动，算出当前停留的索引，然后通知池子取一个播放器、通知 view 挂 layer。

这里有个反直觉的点：很多 Demo 会把 AVPlayer 直接作为FeedVideoView的强属性，滚动时新建、离开时销毁。这种写法在十几条数据上不会出问题，一上到几百条的无限流就会开始掉帧，因为 AVPlayer 的初始化和 layer 重建都不便宜。把播放器抽成池子，本质上是把「每条内容一个播放器」变成「固定几个播放器轮流用」，这是短视频类应用的标准做法。

2.3 数据层：本地 mock 与网络请求的切换开关

Demo 默认走本地数据，方便在没有后端的情况下直接跑。切换点在一个编译开关上，而不是散落在各个调用处：

// Core/Network/FeedService.h @protocol FeedService <NSObject> - (void)fetchFeedWithPage:(NSInteger)page pageSize:(NSInteger)pageSize completion:(void (^)(NSArray<VideoItem *> *items, NSError *error))completion; @end // Core/Network/FeedServiceFactory.m static BOOL const kUseMockData = YES; // 接真接口时改成 NO + (id<FeedService>)service { return kUseMockData ? [MockFeedService new] : [RemoteFeedService new]; }

page从 0 开始计数，pageSize建议跟预加载窗口对齐，默认给 10。这个数字不是随便定的：池子上限 3，预加载窗口是「当前 + 前后各一」，一页 10 条足够覆盖两屏的滑动距离，再大就是浪费请求。

接口协议化而不是直接写具体实现，好处是接后端时只换一个类，Feed 控制器一行都不用改。VideoItem这个模型里最少要有四个字段：videoURL、coverURL、authorName、likeCount，其中videoURL建议在 Demo 阶段用本地 bundle 里的文件路径，避免网络不稳定干扰播放链路的调试。

需要注意一点，MockFeedService回数据的时候不要在同一个 runloop 里同步回调，否则 Feed 控制器的下拉刷新逻辑会表现得很怪。加个dispatch_after延迟 150 毫秒模拟网络，能提前把很多并发时序问题暴露出来。

3. 播放链路落地：AVPlayer 复用池、预加载与三个监听的正确挂法

播放这块是整份 Demo 里最值得抠的部分。iOS 上做短视频，80% 的“玄学”问题都出在三个地方：播放器实例创建太多、KVO 观察者没配对移除、起播时机抢在了 readyToPlay 之前。下面按顺序给出可抄的实现，代码不依赖任何三方库。

3.1 为什么这套 Demo 不直接上 AVPlayerViewController

AVPlayerViewController自带一套播放控件和全屏转场动画，接第三方内容时省事，但短视频场景下它的封装反而成了阻碍。四个具体原因：一是它自带控制条，单击暂停、双击点赞这类手势要跟它抢事件；二是全屏进出走的是系统转场，跟竖滑的交互逻辑冲突；三是它内嵌在 cell 里时，退出复用的时机很难控制，容易在滚动过程中出现黑屏闪烁；四是它的播放速率、静音、循环这些参数要通过player属性和entersFullScreenWhenPlaybackBegins间接绕，调起来不直接。

所以 Demo 用的是AVPlayerLayer+ 自定义 UIView 的组合。layer 挂载的时机由FeedVideoView的layoutSubviews控制，videoGravity单独设，整个画面尺寸、圆角、遮罩都由自己掌。代价是要自己处理旋转时的 frame 更新和后台的前台切换，这两点在 4.2 和 4.3 里会细说。

3.2 播放器池的最小实现

// Modules/Player/VideoPlayerPool.h @interface VideoPlayerPool : NSObject @property (nonatomic, assign) NSInteger maxPoolSize; // 默认 3 - (AVPlayer *)playerForItem:(AVPlayerItem *)item; - (void)recyclePlayer:(AVPlayer *)player; - (void)purgeAll; @end // Modules/Player/VideoPlayerPool.m @implementation VideoPlayerPool { NSMutableArray<AVPlayer *> *_idlePlayers; } - (instancetype)init { if (self = [super init]) { _idlePlayers = [NSMutableArray array]; _maxPoolSize = 3; } return self; } - (AVPlayer *)playerForItem:(AVPlayerItem *)item { AVPlayer *player = [_idlePlayers lastObject]; if (player) { [_idlePlayers removeLastObject]; [player replaceCurrentItemWithPlayerItem:item]; // 复用实例，只换 item } else { player = [AVPlayer playerWithPlayerItem:item]; player.muted = YES; // 首屏默认静音 player.actionAtItemEnd = AVPlayerActionAtItemEndPause; player.automaticallyWaitsToMinimizeStalling = NO; // 短内容不等收敛缓冲 } return player; } - (void)recyclePlayer:(AVPlayer *)player { if (!player) return; [player pause]; [player replaceCurrentItemWithPlayerItem:nil]; // 断开对 item 的强持有 if (_idlePlayers.count < self.maxPoolSize) { [_idlePlayers addObject:player]; } } - (void)purgeAll { [_idlePlayers removeAllObjects]; } @end

逻辑说明：池子只持有 AVPlayer 实例，不持有 item。replaceCurrentItemWithPlayerItem:nil这一句是必须的，它会把播放器对旧 item 的强引用断掉，旧 item 才能在合适的时机释放。省掉这一句，表面上看不出问题，跑久了内存曲线会一路向上。

参数说明：maxPoolSize取 3，对应「当前播放 + 上一条 + 下一条」的滑动窗口。这个值跟pageSize无关，改大只会增加内存驻留，不会提升流畅度。automaticallyWaitsToMinimizeStalling设NO是为了压掉首帧延迟，短视频大多是十几秒的内容，等缓冲收敛的收益远低于它带来的等待感，代价是弱网下中途可能停顿，需要靠预加载兜住。actionAtItemEnd设Pause而不是None，避免播完自动回退到第一帧造成视觉跳动。

3.3 预加载与 KVO 参数怎么调

预加载的核心是提前把下一条的 asset 元信息解析出来，等用户滑过去时 item 能更快进入 readyToPlay：

// Modules/Player/VideoPreloader.m - (void)preloadItemAtIndex:(NSInteger)index { if (index < 0 || index >= self.items.count) return; NSURL *url = self.items[index].videoURL; AVURLAsset *asset = [AVURLAsset URLAssetWithURL:url options:@{ AVURLAssetPreferPreciseDurationAndTimingKey: @NO }]; NSArray<NSString *> *keys = @[@"playable", @"tracks"]; [asset loadValuesAsynchronouslyForKeys:keys completionHandler:^{ dispatch_async(dispatch_get_main_queue(), ^{ for (NSString *key in keys) { NSError *error = nil; AVKeyValueStatus status = [asset statusOfValueForKey:key error:&error]; if (status == AVKeyValueStatusFailed) { NSLog(@"[preload] key=%@ error=%@", key, error); } } }); }]; } - (void)preloadAroundIndex:(NSInteger)index { [self preloadItemAtIndex:index + 1]; [self preloadItemAtIndex:index - 1]; }

参数说明：AVURLAssetPreferPreciseDurationAndTimingKey设NO换取更快的元信息解析，短视频的时间轴不需要精确到帧，精确解析反而拖慢起播。preloadAroundIndex只预取前后各一条，再多就是从磁盘读到内存的搬运工，收益递减得很明显。

KVO 这块必须配一个固定的 context 指针，否则父类的 KVO 回调会混进来，排查起来很麻烦：

static void *kPlayerItemStatusContext = &kPlayerItemStatusContext; - (void)attachObserverToItem:(AVPlayerItem *)item { [item addObserver:self forKeyPath:@"status" options:NSKeyValueObservingOptionNew context:kPlayerItemStatusContext]; [item addObserver:self forKeyPath:@"playbackLikelyToKeepUp" options:NSKeyValueObservingOptionNew context:kPlayerItemStatusContext]; [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(itemDidPlayToEnd:) name:AVPlayerItemDidPlayToEndTimeNotification object:item]; // object 必须指定 item } - (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary<NSKeyValueChangeKey, id> *)change context:(void *)context { if (context != kPlayerItemStatusContext) { [super observeValueForKeyPath:keyPath ofObject:object change:change context:context]; return; } AVPlayerItem *item = (AVPlayerItem *)object; if ([keyPath isEqualToString:@"status"]) { if (item.status == AVPlayerItemStatusReadyToPlay) { [self playIfStillVisible]; } else if (item.status == AVPlayerItemStatusFailed) { NSLog(@"[player] item failed: %@", item.error); } } else if ([keyPath isEqualToString:@"playbackLikelyToKeepUp"]) { NSLog(@"[player] keepUp=%d", item.playbackLikelyToKeepUp); } }

AVPlayerItemDidPlayToEndTimeNotification的 object 参数传 item 而不是 nil，这条最容易被忽略。传 nil 意味着所有 item 的播放结束都往这个 selector 上回调，池子一复用就会串台：A 视频播完把 B 视频的进度重置了。移除观察者时同样要指定 object，并且必须发生在 item 释放之前，顺序反了就等着收EXC_BAD_ACCESS。这类崩溃没有符号信息，调起来是最花时间的。

4. iPhone 与 iPad 双端适配：Size Class 判定、安全区与分屏行为

iPad 适配最常犯的错误，用UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad一刀切。这个判断在 iPad 全屏时是对的，一进分屏就失效了——App 可能被压到 320pt 宽度，这时候还按双栏排就会挤成一团。

4.1 从单列到双栏：布局判定的切入点

正确做法是看 trait collection 的 horizontal size class，跟着它动态变：

- (void)traitCollectionDidChange:(UITraitCollection *)previousTraitCollection { [super traitCollectionDidChange:previousTraitCollection]; if (self.traitCollection.horizontalSizeClass != previousTraitCollection.horizontalSizeClass) { [self applyLayoutForSizeClass:self.traitCollection.horizontalSizeClass]; [self.feedLayout invalidateLayout]; // 尺寸变了必须让布局失效 } } - (void)applyLayoutForSizeClass:(UIUserInterfaceSizeClass)sizeClass { if (sizeClass == UIUserInterfaceSizeClassRegular) { self.feedLayout.itemSize = CGSizeMake(self.view.bounds.size.width * 0.6, self.view.bounds.size.height); self.commentPanel.hidden = NO; } else { self.feedLayout.itemSize = self.view.bounds.size; self.commentPanel.hidden = YES; } }

三种典型形态下的参数对照：

注意horizontalSizeClass在 iPad 分屏到 1/3 宽度时会变成 compact，这时要退回单列全宽。这套逻辑不要写在viewDidLoad里，写在traitCollectionDidChange:和viewWillLayoutSubviews两处，前者管形态切换，后者管首次布局。

4.2 视频画布比例、安全区与旋转

短视频素材绝大多数是 9:16 竖版。在 iPhone 上直接铺满还能看，铺到 iPad 上就有问题了：横向空间富余，纵向被拉，videoGravity一旦设成ResizeAspectFill，上下能裁掉三分之一画面。

Demo 的处理方式是按 9:16 定容器宽度，而不是定满屏：

- (void)layoutSubviews { [super layoutSubviews]; CGFloat maxW = CGRectGetWidth(self.bounds); CGFloat maxH = CGRectGetHeight(self.bounds); CGFloat targetW = MIN(maxW, maxH * 9.0 / 16.0); // 按 9:16 反推宽度 self.playerLayer.frame = CGRectMake((maxW - targetW) / 2.0, 0, targetW, maxH); self.playerLayer.videoGravity = AVLayerVideoGravityResizeAspect; }

ResizeAspect而不是ResizeAspectFill，是因为短视频本来就有上下黑边的可能，宁可留边也不裁内容；如果要做到满屏沉浸，就得在 cell 上叠一层渐变压暗，把边角藏进视觉里。

安全区这块，iPhone 的刘海和 iPad 的圆角屏safeAreaInsets数值不一样，评论输入框的底部约束必须挂在safeAreaLayoutGuide上，不能写死bottom = -20。写死的结果是在 iPad 横屏时输入框被圆角切掉一半，或者在带 Home 指示条的机型上被挡住。

旋转的处理放在viewWillTransitionToSize:withTransitionCoordinator:里，先暂停再改布局，转完再恢复：

- (void)viewWillTransitionToSize:(CGSize)size withTransitionCoordinator:(id<UIViewControllerTransitionCoordinator>)coordinator { [self.coordinator pauseCurrentPlayer]; [super viewWillTransitionToSize:size withTransitionCoordinator:coordinator]; [coordinator animateAlongsideTransition:^(id<UIViewControllerTransitionCoordinatorContext> ctx) { [self.feedLayout invalidateLayout]; } completion:^(id<UIViewControllerTransitionCoordinatorContext> ctx) { [self.coordinator resumeCurrentPlayerIfVisible]; }]; }

不暂停也能转，但转场过程中 layer 会被拉伸成一次可感知的形变，观感很差。

4.3 分屏与画中画场景下的播放器行为

iPad 分屏和侧拉会让 App 在没有收到applicationDidEnterBackground的情况下丢失焦点，这时候如果还在播，音频会和另一侧的 App 打架。Demo 的做法是在viewWillDisappear里统一停播，回来时由 coordinator 根据当前索引重新取播放器，而不是简单地resume。

音频会话也要配，否则静音开关和别的 App 的音乐都会受影响：

- (void)configureAudioSession { AVAudioSession *session = [AVAudioSession sharedInstance]; NSError *error = nil; [session setCategory:AVAudioSessionCategoryPlayback withOptions:AVAudioSessionCategoryOptionMixWithOthers error:&error]; [session setActive:YES error:&error]; if (error) NSLog(@"[audio] session error: %@", error); }

AVAudioSessionCategoryOptionMixWithOthers是关键选项，加上它之后你的视频播放不会把用户正在听的音乐掐掉。如果产品要求跟随静音键，category 换成AVAudioSessionCategoryAmbient，setActive就可以省了。

后台进前台这块，applicationDidEnterBackground里要做两件事：暂停当前播放器，调用purgeAll把池子清空。不清的话，后台驻留期间那几个 AVPlayer 还攥着解码器资源，被系统回收时可能连带 App 一起杀。

5. 编译和运行避坑：五条能省两天时间的排查记录

这份 Demo 我从克隆到跑通花了小半天，中间踩的坑基本都集中在这五条上。每条按现象、原因、解决的顺序写，照着排查能省不少时间。

5.1 链接阶段报 Undefined symbols，或高版本 Xcode 编译报错

现象：pod install之后在真机上编译，链接阶段报Undefined symbols for architecture arm64，模拟器上却是好的。或者换到较新的 Xcode 之后，某些三方库直接编译不过。

原因有两个方向。一是 Excluded Architectures 里残留了以前为模拟器加的arm64排除项，Debug 和 Release 的配置不一致，切到真机 Release 时就缺符号。二是 Pods 工程里的ONLY_ACTIVE_ARCH设置跟主工程没对齐，Debug 下只编当前架构，Release 下却要求全架构。

解决：打开 Build Settings，检查 Excluded Architectures 的 Debug 和 Release 三项是否为空；Pods 工程里 Debug 的ONLY_ACTIVE_ARCH设YES、Release 设NO，跟主工程保持一致。改完还不行就走一遍pod deintegrate再pod install，比手动翻配置快。

5.2 模拟器上视频黑屏，有声音没画面

现象：cell 正常出来，播放器状态能走到 readyToPlay，日志也有，但画面全黑。

原因：素材编码是 HEVC（H.265），在部分模拟器环境里没有可用的硬解路径，走软解又会被优化掉；另外模拟器对 Rec.2020 这类色彩空间支持不全，解码成功但渲染出来是黑的。

解决：素材统一转成 H.264 的 main profile，容器用 mp4。转换用系统自带的命令行工具就行，不要在这上面折腾。真机验证是最快的排除方式，模拟器能跑通不代表真机没问题，反过来也一样。

5.3 滑动十几条之后崩溃，堆栈指向 KVO 回调

现象：列表往下滑十来条，App 崩在observeValueForKeyPath:ofObject:change:context:里，堆栈里全是系统帧，看不出业务代码。

原因：replaceCurrentItemWithPlayerItem:之后旧 item 被释放，但观察者还挂在上面；再叠加通知中心用了object:nil，回调会串到已经复用的播放器上。这类崩溃在 Debug 下有时不出现，Release 下必现。

解决：把所有 KVO 的 add/remove 收进一个PlayerItemObserver小类，item 被替换前先removeObserver，再换；通知中心一律指定object:item，移除时同样指定。检查一遍dealloc里有没有漏掉的移除，漏一处就够了。

5.4 首帧黑屏几百毫秒，或者点了不自动播

现象：滑到某一条，声音立刻就出来了，画面要等半秒才亮；或者日志里明明调了[player play]，画面不动。

原因：play调用的时机早于 item 的status变成 readyToPlay；再加上automaticallyWaitsToMinimizeStalling默认为YES，play之后播放器还在等缓冲区收敛，表现就是“调了没反应”。

解决：把play挂在status == AVPlayerItemStatusReadyToPlay的回调里，并且加一次「此时这一条是否还在可见索引上」的校验，避免用户已经滑走了才起播。短视频把automaticallyWaitsToMinimizeStalling设NO，配合 3.3 的预加载，首帧延迟能压到可接受范围。

5.5 iPad 旋转或分屏之后，cell 高度错乱、画面变形

现象：iPad 上横竖屏切一次，部分 cell 的高度还停留在旧值，视频被横向拉伸。

原因：布局用了estimatedItemSize并缓存了计算过的 itemSize，旋转后没有让布局失效；或者playerLayer的 frame 只在init里设了一次，layoutSubviews里没更新。

解决：viewWillTransitionToSize:里调invalidateLayout，prepare里按collectionView.bounds重算 itemSize，不要跨 trait 缓存尺寸。playerLayer.frame的赋值统一放到layoutSubviews，让 UIKit 自己驱动。

6. 二次开发进阶：给复用池加缓存开关，再用 Instruments 验一次

跑通之后如果要往产品方向走，第一件该做的事是给播放链路加一层可控的磁盘缓存开关，而不是急着堆功能。原因很简单，短视频的实际体验瓶颈不在 UI，在「滑过去能不能立刻看到画面」。

做法是在VideoPlayerPool外面套一层资源定位器，预加载阶段先查缓存，命中就直接给本地文件 URL，没命中再走网络并且把结果落到磁盘。下面这段是开关部分的骨架：

// Core/Cache/VideoResourceLocator.m - (NSURL *)resolvedURLForItem:(VideoItem *)item useCache:(BOOL)useCache { if (!useCache) return item.videoURL; NSString *key = [self cacheKeyForURL:item.videoURL]; NSURL *local = [self.diskCache fileURLForKey:key]; if (local && [[NSFileManager defaultManager] fileExistsAtPath:local.path]) { return local; // 命中缓存，直接本地起播 } [self.diskCache fetchAndStoreURL:item.videoURL forKey:key]; // 异步落盘 return item.videoURL; }

useCache建议做成一个运行时可切的开关，而不是编译期常量。调试阶段关掉它，能快速区分「是缓存坏了」还是「是播放器坏了」，这个区分能力在排障时价值很高。磁盘缓存的容量上限建议设 200MB 左右，超过就按 LRU 淘汰，短视频单个文件小，200MB 能装几十条，够覆盖一次会话。

验证池子有没有真的复用，别靠肉眼看内存曲线，用 Instruments 的 Allocations 抓两个指标：AVPlayer 的实例数在滑动过程中应该稳定在 3 以内，AVPlayerItem的实例数应该跟滑动过的条数接近但能被回收掉。如果 AVPlayer 实例数随着滑动一路往上涨，说明回收路径没走到，八成是recyclePlayer:在某个分支里被跳过了。再挂一个 Time Profiler，看layoutSubviews里的耗时，iPad 上超过 2ms 就要留意，通常是 layer frame 计算里带了不必要的转换。

有个小技巧：在recyclePlayer:里打一行带自增计数的日志，跑一轮五十条的滑动，看「取」和「还」的次数是否配平。不平就是有路径漏了归还，这个检查我每次改播放相关代码都会加一遍，比事后翻崩溃日志省事得多。

从那以后我每次改播放链路，都会先把池子的进出日志打开跑一轮，配平了再谈性能。这套流程看着笨，但它把「玄学卡顿」变成了一个能对账的数字。希望帮到你。

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