打造高性能 iOS 图片浏览器 (支持视频)

所以，笔者花了挺多时间重做图片浏览器，从功能、技术细节、代码架构都做了大量改进和优化，尽可能保证代码质量、提高可维护性和拓展性。

YBImageBrowser 2.x 版本已更新，如果项目中的图片浏览器过于蹩脚，替换掉它吧。笔者会抽时间维护和升级，打造开源第一是追求也是激励。

一、组件的视图层次

考虑到屏幕旋转的适配，笔者使用 UIViewController 作为图片浏览器的主体类，同时也方便做自定义的转场效果。内容的载体是 UICollectionView ，可以避免手动实现复用机制，并且可以优雅的管理布局。UICollectionViewCell 作为主要显示内容的载体，组件实现了两个，一个支持图像，一个支持视频。

除此之外，组件有两个概念，一个是 工具 栏 (ToolBar) ，一个是弹出视图 (SheetView)。"TooBar" 视图层级是在内容载体 UICollectionView 之上的，组件中默认实现了一个显示页码的 "TooBar"；"SheetView" 是需要的时候添加到 UIViewController 上，它的层级可以理解为组件内部最高。至于它们如何架构和自定义后文会阐述。

二、面向协议的设计模式

显示内容的载体目前有图像和视频，笔者先是考虑过写一个 UICollectionViewCell 的基类，利用多态来做子类的自定义，然而这样会带来问题：一是若组件使用者想要拓展内容载体但却不便于继承这个基类；二是继承本身带来的问题，虽然子类之间不直接接触，但是它们有同一个父类，若想组件和这些子类之间不直接耦合，必然要频繁的对这个基类做更改，牵一发而动全身，并且对于方法重载来说，不好准确的限定是否必须重载，是否需要调用父类方法。

继承往往是灾难的开端，所以，多态的解决方案被淘汰。

换个思路来思考，组件主体对内容载体也就是 UICollectionViewCell 的关系应该是无耦合的，就像上面多态的思路，组件只关心这个基类，而不直接和子类交互。我们无非是想遵守 依赖倒置原则 ，既然想到这个设计原则，很容易想到 面向协议的设计模式 。

所以，笔者在组件中创建了数个协议：

YBImageBrowserCellDataProtocol.hYBImageBrowserCellProtocol.hYBImageBrowserToolBarProtocol.hYBImageBrowserSheetViewProtocol.h

正如你所见，对于 "ToolBar" 和 "SheetView" 都有独自的协议。组件主体和这些视图都与协议耦合而不依赖对方，笔者可以优雅的移除或者添加视图元素，使用者也可以轻松的实现这些协议来自定义界面。

“我不关心你是不是鸭子，只要你会‘嘎嘎’叫并且有两只脚我把你当做鸭子”。

三、迪米特设计原则

在组件设计中，应该尽量遵循迪米特原则，在 OC 编程中会存在一个问题，属性和方法没有 protect，写在 .h 中的是公开的，写在 .m 中是私有的，所以对于某个对象来说，其子类和其它类的访问权限可以说是一样的。

解决这个问题的方案有几种，最简单的是将两个类的实现写在同一个文件，但是很多时候不希望这么做；笔者之前的版本中使用过 objc_msgSend 直接发送消息，也使用过 KVC 直接访问实例变量，虽然从效率的角度来看无伤大雅，使用 Runtime 甚至更快，但是代码却有些晦涩。

最终笔者选择了一种比较优雅的方式，使用独立文件的延展 (Extension) 来做“知识”隔离控制：

文件：YBImageBrowser+Internal.h@interface YBImageBrowser ()@property (nonatomic, strong) YBImageBrowserView *browserView;@end

YBImageBrowser+Internal.h 延展虽然是一个独立的文件，但是仍然是 YBImageBrowser 类的一部分，里面的方法和属性都是在编译期决议的，所以延展里面的属性是会自动生成实例变量的。这不同于分类 (Category) ，分类是运行期动态注入类中，所以只能添加方法而不能添加实例变量。

那么，在需要调用这些方法的类中导入 YBImageBrowser+Internal.h 就能访问了。

四、当多线程遇上复用机制

多线程和复用机制看似互不相干，却会碰撞出意外的 BUG。

举个例子，一个 Cell 中的 UIImageView 在异步线程发起一个下载图片的网络请求，UITableView 在这期间滑动，触发了复用机制，该 Cell 的数据源更换，它的 UIImageView 又发起了另外的一个下载图片请求，当第一次网络请求成功返回图片的时候，已经不是这个 Cell 的 UIImageView 期望的图片了。

因为复用机制的问题，视图不能作为可信的异步回调接收者，但是数据却可以：

id tmpData = self.data
networkAsync^{    if (tmpData == self.data) {
        update UI.
    }
}

在 UITableView 滑动的时候，会不断的为 Cell 更新数据源 data，所以 cell.data 表示的就是 Cell 当前的数据状态，创建一个临时变量让 Block 持有它，这个临时变量就是异步网络请求所对应的数据。

这应该是最简单的处理方案。SDWebImage 是为 UIImageView 动态关联一个请求标识来判定最新的网络请求 URL，YYWebImage 是为 UIImageView 计数，异步回调回来，通过闭包持有的计数变量和 UIImageView 的计数变量比较来判定。

但是组件中并没有使用这种方法，而是使用了观察者 设计模式 来巧妙解决，后文会讲解。

五、异步任务的重复请求

对于图片浏览器每一个图像，都有一个数据模型 data，当异步操作回调过后，虽然可以通过对比 cell.data 和 block 持有的 data 来判断是否需要进行 UI 刷新，但是却不能解决另外一些问题：

1、当 Cell 进入复用池的时候，是否需要放弃它发起的未完成的异步操作？

当然，并不是所有异步任务都是可以中断的，发起的异步操作消耗了一定资源，笔者认为不应该放弃掉，而是将结果存储在异步回调 Block 持有的 data 中，至于 UI 刷新与否按照之前说的方法判断。

那么就带来了另外一个问题：

2、当来回滑动 ScrollView，如何避免 Cell 反复发起异步请求？

这种情况经常出现，如果脱离业务来思考，对于同一个异步请求多次调用，应该使用一个数组来将所有发起请求的 Block 回调存储起来，并且若正在异步请求要及时返回，当异步请求完成，遍历数组中的回调 Block 分别调用。

实际上关于网络的框架都有类似的处理，比如 SDWebImage，它通过 URL 来判断是否是重复的请求。

落地到图片浏览器中，若想判断某个异步请求是否是同一个，通过请求参数来判断有些复杂，最直接的方法就是把异步请求都写在 data 中，比如图片压缩异步请求，对于同一个 data 就很好判断是否正在压缩，只需要一个 BOOL 值。

在图片浏览器的功能设计中，笔者加入了预加载的功能，也就是说，data 中的这些异步操作并不都是在显示界面的时候由 cell 来调用，而是在创建 data 的时候就会调用。

比如在创建网络图片 data 的时候，就要发起异步请求下载图片，而当图片浏览器展示当前 data 对应的 cell 的时候，异步请求还未完成，cell 又调用 data 发起了相同的异步请求。这时候在异步请求中就要用一个指针存储这个 cell 发起异步请求的回调 Block，在异步请求成功的时候调用这个 Block，这带来了潜在的循环引用问题，并且代码观感非常差。

并且实际情况比这个更为复杂，在笔者的图片浏览器中，一个 data 需要进行的异步请求可能有好几个，比如异步查询缓存、异步解压、异步下载、异步压缩、异步裁剪，若统统使用这种方式处理，将会是代码维护的灾难。

六、巧用观察者设计模式

问题的本质就是，data 中的异步任务结果要在 cell 需要的时候通知它，而在 cell 不需要的时候默默执行。

笔者最终决定采用观察者模式，考虑到业务的特殊性，对于同一个 data，基本上异步操作是串联的，也就是说，不会在下载的同时异步压缩，不会在异步查询缓存的时候下载。所以，基本上同一时刻，data 的状态是唯一的，如此，对于组件中的 YBImageBrowseCellData ，定制了一系列的状态：

typedef NS_ENUM(NSInteger, YBImageBrowseCellDataState) {
    YBImageBrowseCellDataStateInvalid,
    YBImageBrowseCellDataStateImageReady,
    ...
    YBImageBrowseCellDataStateIsDownloading,
    YBImageBrowseCellDataStateDownloadProcess,
    YBImageBrowseCellDataStateDownloadSuccess,
    YBImageBrowseCellDataStateDownloadFailed,
};

在异步请求的过程中，更新这些状态。

而对于 cell，只需要在赋值 data 的时候观察这个 state，在进入复用池等情况移除就行了。state 改变的时候，就做一些 UI 操作，比如 YBImageBrowseCellDataStateDownloadProcess 更新下载进度条，在 YBImageBrowseCellDataStateDownloadFailed 显示下载失败文案。

这是观察者模式比较好的实践，但有一点需要注意，若有某些异步任务不是串联的，需要设置另外一个 state 枚举。

七、屏幕旋转的处理

有两个概念，一个是设备的方向通过 UIDeviceOrientationDidChangeNotification 添加通知，一个是状态栏的方向通过 UIApplicationDidChangeStatusBarOrientationNotification 添加通知。

通常情况下，状态栏的方向可以确定当前控制器的布局方向，所以通过监听状态栏的方向更新子视图的布局。

组件采用 UIViewController 作为主体，通过重写如下方法自定义旋转方向：

- (BOOL)shouldAutorotate {    return YES;
}
- (UIInterfaceOrientationMask)supportedInterfaceOrientations {    return self.supportedOrientations;
}

但其实当前控制器实际允许旋转的方向受很多因素控制。一是 general -> deployment info -> Device Orientation 中勾选的设备支持的旋转方向，它的优先级是最高的；二是在 AppDelegate 中实现的 代理方法 -application:supportedInterfaceOrientationsForWindow: ，它的优先级次之；三是若当前控制器是栈内的，它的旋转方向由 UINavagationController 重载的 -shouldAutorotate 和 -supportedInterfaceOrientations 方法控制，若存在 UITabBarController ，它将控制它管理的那些控制器的旋转方向。

所以，实际上组件内部可以说无法准确的获取到 YBImageBrowser 这个控制器实际支持的方向，这些逻辑需要开发者自行去解决。

TODO

关于自定义转场，需要设置如下代码：

self.transitioningDelegate = ...;self.modalPresentationStyle = UIModalPresentationCustom;

UIModalPresentationCustom 模式下，才能做到完美的出场和入场动效，但是有个非常蛋疼的地方，若在该模式下，图片浏览器旋转的时候，它的 presentingViewController 会跟着旋转，不管 presentingViewController 是否支持这个方向。然后在图片浏览器 dismiss 的时候， presentingViewController 方向并不会恢复。

这个问题笔者未找到完美的解决方案，看了一下“微博”的图片浏览器貌似也是类似的实现方式，在横屏的时候出场是立即触发的，猜测可能是此刻将屏幕旋转回来。

所以，尝试了一下，若当前图片浏览器的方向和 presentingViewController 起始的方向不同，将取消手势交互动效，直接 dimiss 转场，并且在转场的同时强制旋转屏幕。

然而预期的效果和“微博”并不一样，强制转场有一定的延时。若读者朋友有解决方案还望指点一下，目前就采用这个处理方案，作为一个待完成的优化吧。

八、三方图片处理框架的选择

上一个版本是使用 SDWebImage + FLAnimatedImage 来处理的，但是感觉使用体验不太好，在创建本地图片的时候需要用户判断当前图片是不是 gif，所以后来笔者选择了功能更强、代码质量很高的 YYImage 做为 GIF 的处理框架，它还支持 APNG、WebP 等格式，使用也很简单，完全兼容 UIImage。YYImage 原理可看笔者的一篇博客： YYImage 源码剖析：图片处理技巧 。

吐槽一下 SDWebImage 蹩脚的缓存设计

它的内存缓存就是一个 hash 容器，没有缓存策略，不及基于 LRU 淘汰算法的 YYMemeryCache。

SDWebImage 缓存策略中有一个逻辑，在磁盘缓存中查找到了缓存，会解压过后放入内存缓存，若这个图片是 GIF 的，它就会解压为第一帧图片，不能满足我们的需求。

从解压过后是否放入缓存说起：它是由 [SDImageCache sharedImageCache].config.shouldCacheImagesInMemory 决定的，所以一开始我想要在框架生命周期内禁止它。然而 shouldCacheImagesInMemory 同时决定了调用 -stroreImage:imageData:forKey:toDisk 的时候是否缓存到内存，所以这个属性是不能设置为 NO 的，否则内存缓存永远存不进去。

发现了么，死循环，要想 -stroreImage:imageData:forKey:toDisk 支持内存缓存，就要 shouldCacheImagesInMemory 为 YES，而它为 YES 就会错误的同步 GIF 的第一帧到内存缓存。

以 SD 的思路，最好的解决方案就是使用 SDWebImage 的 GIF 分类 + FLAnimatedImage 显示了，SD 解压的 GIF 图片类型可以由 FLAnimatedImageView 解析。这个设计让我有些无语，有种捆绑销售的感觉

在这个需求下，SD 的拓展性做得不太友好。

之所以选择 SDWebImage 是因为它的人气最高，并且长期有人维护，然而我又舍不得放弃强大的 YYImage，所以目前的处理方式就是放弃内存缓存，每次从磁盘查找，这个做法看似降低了查询性能，却又可以降低内存峰值。

然而笔者在 SD 添加缓存的源码中又看到了这样一个出其不意的判断：

- (void)storeImage:(nullable UIImage *)image
         imageData:(nullable NSData *)imageData
            forKey:(nullable NSString *)key
            toDisk:(BOOL)toDisk
        completion:(nullable SDWebImageNoParamsBlock)completionBlock {    if (!image || !key) {        if (completionBlock) {
            completionBlock();
        }        return;
    }
...

在 image 不存在的时候，居然直接返回，这不得不让组件在下载完成的时候同时传入 NSData 和 UIImage 对象，然后 SD 就会做磁盘和内存缓存。然而，组件内部暂时又不需要内存缓存。

SDWebImage 缓存方面的拓展性确实不能让人满意，也坚定了笔者替换掉它的想法，在后面的版本中，考虑的是用 YYWebImage 替换它，虽然 YYWebImage 很久不维护了，使用的时候需要做一些源代码调整，并且拓展下载之类的接口，但是能逃脱 SDWebImage 的魔爪这个成本还是可以接受的。

缓存共享问题

组件用到了缓存，而开发者自己的业务中同样用到了缓存，它们之间如何共享是一个问题，若是用的同一个缓存框架还好说，若不是就比较麻烦了。因为不同的图片处理框架对缓存的处理或多或少有些差别，很多时候通过上层的 API 做不到联合查找缓存，所以关于这个待优化的功能，笔者还需要考虑一些时间。

下载框架的替换问题

用 SDWebImage 或 YYWebImage 的开发者总是看不上另一个框架，这也是个恼人的问题，若笔者自己实现却又感觉成本太高，这个问题同样需要考量一下。

九、图片异步解码的思考

图片浏览器做了高清图的压缩和裁剪，所以只要组件使用者不去改变这个临界值，图片绘制不会消耗过多的 CPU 和 GPU 格外资源去处理高清图。

那么，绘制在屏幕上的图片不会很大且最多有两张，笔者早些时候也认为图片在主线程的解码压力不大，然而一条 issues 让我看到了图片浏览器主线程解码的性能瓶颈。

由于 iOS 设备的 CPU 是支持 JPEG 图片格式的硬解码的，所以当图片浏览器展示多张 JPEG 图片时，主线程看起来是可以轻松解决的。然而对于颜色和细节丰富的 PNG 图片来说，主线程解码的压力倍增，导致会产生交互卡顿的现象。而且经过一些测试，当图片分辨率比较高时，就算是 JPEG 格式的图片仍然会消耗比较长的时间来解码（比如相册图片通常都比较大）。

所以在新版的组件中，笔者默认开启了允许异步解码的选项。同时，为了减少用户查看图片的等待时间，组件做了预加载功能。

十、意外释放的危机处理

就比如 UIViewController，它并不是每次释放都会走 -viewWillAppear: 方法，可能内存强制清理或者闪退等导致意外释放。只要是释放，理论上就会走 -dealloc 方法，所以在这个方法中需要做一些危机处理。

在组件的设计中，应该尽量避免对外部业务的直接操作，但是有的时候又不可避免，比如图片浏览器要做这个效果：

- (void)dealloc {    // If the current instance is released (possibly uncontrollable release), we need to restore the changes to external business.
    [YBIBWebImageManager restoreOutsideConfiguration];    self.hiddenSourceObject = nil;
}

@property (nonatomic, class) YBImageBrowseFillType globalVerticalfillType;@property (nonatomic, assign) YBImageBrowseFillType verticalfillType;

CGRect startFrame = ...;CGFloat anchorX = point.x / startFrame.size.width,
anchorY = point.y / startFrame.size.height;self.mainContentView.layer.anchorPoint = CGPointMake(anchorX, anchorY);

BOOL can = ABS(currentPoint.x - startPoint.x) > triggerDistance && ABS(currentPoint.y - startPoint.y) < triggerDistance;

CGPoint velocityPoint = [panGesture velocityInView:...];BOOL can = ABS(velocityPoint.x) < 500;

- (NSArray
<uicollectionviewlayoutattributes nbsp="">
  *)layoutAttributesForElementsInRect:(CGRect)rect {    NSArray
 <uicollectionviewlayoutattributes nbsp="">
   *layoutAttsArray = [[NSArray alloc] initWithArray:[super layoutAttributesForElementsInRect:rect] copyItems:YES];    CGFloat halfWidth = self.collectionView.bounds.size.width / 2.0;    CGFloat centerX = self.collectionView.contentOffset.x + halfWidth;
    [layoutAttsArray enumerateObjectsUsingBlock:^(UICollectionViewLayoutAttributes * _Nonnull obj, NSUInteger idx, BOOL * _Nonnull stop) {
        obj.center = CGPointMake(obj.center.x + (obj.center.x - centerX) / halfWidth * self.distanceBetweenPages / 2, obj.center.y);
    }];    return layoutAttsArray;
}
 </uicollectionviewlayoutattributes>
</uicollectionviewlayoutattributes>

// Local imageYBImageBrowseCellData *data = [YBImageBrowseCellData new];
data.imageBlock = ^__kindof UIImage *{ return [YBImage imageNamed:...]; };

- (id
<ybimagebrowsercelldataprotocol>
 )dataAtIndex:(NSUInteger)index {    if (!self->_dataCache) {        self->_dataCache = [NSCache new];        self->_dataCache.countLimit = 6;
    }    if (self->_dataCache && [self->_dataCache objectForKey:@(index)]) {        return [self->_dataCache objectForKey:@(index)];
    } else {
        id
 <ybimagebrowsercelldataprotocol>
   data = [self.yb_dataSource yb_imageBrowserView:self dataForCellAtIndex:index];
        [self->_dataCache setObject:data forKey:@(index)];        return data;
    }
}
 </ybimagebrowsercelldataprotocol>
</ybimagebrowsercelldataprotocol>

作者：indulge_in

链接：https://www.jianshu.com/p/bffdb9f0036c