- 相册存在架构问题，相册与业务代码耦合、没有分层设计、牵一发动全身，作为一个相对独立的模块，不利于整体迁移和维护。
- 存在业务逻辑问题，随着业务不断发展，散落的逻辑补丁没有收口导致维护成本高。
- 存在用户体验问题，如对iOS14以上部分权限授权的引导做的不够，在相册场景里面无法实时刷新，UI不适配不统一如对刘海屏、灵动岛的适配和相册不同tab之间的列表间距不一致问题等。
同时，对相册的重点诉求如下：
- 需要增加相册外露能力，相册外露能力的底层链路应和相册本体保持复用。
- 将当前的相册模块化，使用模块接入的形式调用，不直接依赖拍立淘的业务代码；理想情况能够剥离成独立的SDK。
- 能够提供给业务方使用，包括拍立淘、扫一扫等
- 相册视觉焕新，包括增加统一的图片背景，整体色调更换等。
根据相册的功能，现在先把相册框架自顶向下拆解：
接口层：相册的对外接口（适配层、API）
视图定制层：相册的展示链路（MVVM架构）
逻辑管理层：
- 相册的读取链路（包括读取 Asset 和获取源文件）
- 相册的变更链路（观察者模式）
- 相册的体验优化（预加载、缓存回收）
根据上述的分层思想，依次自底向上设计与实现
▐ 读取链路
在制作相册管理中，读取图片是重要的一个环节。设计一个相册读取管理器，主要功能：
- 通过 API 获取系统/用户相簿
- 查询相簿内容
- 相簿模型转换
- 读取多媒体元素
▐ 变更链路
相册变更链路是因业务场景而产生的诉求，主要解决的问题是：用户停留在相册页面时候，如果系统相册发生变更（如截屏、录屏、切后台时候进行相册操作），需要刷新页面。
这里有个优化点，系统相册提供的获取相册变更数据的能力，类似于游标增量读取。即给定一个游标，API查询基于这个游标之后的变更。那么在相册场景中，这个游标就是 PHFetchResult，具体来说，就是读取管理器获取相簿数据之后拿到的。
读取管理器对「游标」和「观察者」能力的补充，示例代码如下：
- (NSArray <PhotoGroupModel *> *)fetchAssetGroup { //... //读取相簿数据 `-_fetchSystemAssetGroup` //保存游标 self.lastResult = assetGroups.lastObject.fetchResult; //开启观察者 [self startObserver]; //... } - (void)startObserver { [self.observer initCursor:self.lastResult]; [self.observer startObserver]; } - (void)stopObserver { [self.observer stopObserver]; }
观察者的注册和反注册如下：
- (void)startObserver { //抛到指定线程处理 dispatch_async(self.observerQueue, ^{ //防止重复注册 if(!self.isObserving) { //前后台切换，使用的全量更新 [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(resumeForeground) name:UIApplicationWillEnterForegroundNotification object:nil]; self.isObserving = YES; //注册观察者 [[PHPhotoLibrary sharedPhotoLibrary] registerChangeObserver:self]; } });} - (void)stopObserver { //抛到指定线程处理 dispatch_async(self.observerQueue, ^{ //防止重复反注册 if(self.isObserving) { self.isObserving = NO; [[NSNotificationCenter defaultCenter] removeObserver:self]; //反注册观察者 [[PHPhotoLibrary sharedPhotoLibrary] unregisterChangeObserver:self]; } });}
简单的来说，观察者注册后，有回调- (void)photoLibraryDidChange:(PHChange *)changeInstance;后就更新数据，通知页面刷新就可以了。但这里会遇到衍生问题：
- iOS14 部分相册权限时，回调的数据有不同。解法：针对 iOS14 有限选择照片的判断及通知
- 变更回调会发生多次，如果不进行过滤，会造成无效读取/刷新。解法：只有RIC - removedIndexes，insertedIndexes，changedIndexes才进行回调
因此，观察者的实现的流程如下：
关于相册变更后更精准的刷新：
在 Apple Doc 中提供了一种更为精确的配合CollectionView的刷新方式：根据PHFetchResultChangeDetails 里面的增删改Set，直接进行BatchUpdates，因为我们相册的 View 和 ViewModel 和原始数据不相同，因此没有采用。感兴趣的可以看下列官方示例代码：
Apple Doc地址 ： https://developer.apple.com/documentation/photokit/phfetchresultchangedetails?language=objc
@property (nonatomic, strong) UICollectionView* collectionView;// ...PHFetchResultChangeDetails* fetchResultChangeDetails;NSIndexSet* deletedCollectionIndicesBeforeChanges;NSIndexSet* insertedCollectionIndicesAfterDeletions;NSArray* deletedPhotoPathsBeforeChanges;NSArray* insertedPhotoPathsAfterDeletions; //精准增删改：[self.collectionView performBatchUpdates:^{ if (deletedCollectionIndicesBeforeChanges.count > 0) { [self.collectionView deleteSections:deletedCollectionIndicesBeforeChanges]; } if (insertedCollectionIndicesAfterDeletions.count > 0) { [self.collectionView insertSections:insertedCollectionIndicesAfterDeletions]; } if (deletedPhotoPathsBeforeChanges.count > 0) { [self.collectionView deleteItemsAtIndexPaths:deletedPhotoPathsBeforeChanges]; } if (insertedPhotoPathsAfterDeletions) { [self.collectionView insertItemsAtIndexPaths:insertedPhotoPathsAfterDeletions]; }} completion:nil]; [fetchResultChangeDetails.changedIndexes enumerateIndexesUsingBlock:^(NSUInteger index, BOOL* stop) { NSIndexPath* indexPath = [NSIndexPath indexPathWithItem:index inSection:0]; UICollectionViewCell* changedCell = [self.collectionView cellForItemAtIndexPath:indexPath]; if (changedCell) { // ... Configure changedCell here ... } // Set *stop = YES to stop iteration early.}];
关于相册变更后更精准的刷新：在 Apple Doc 中提供了一种更为精确的配合CollectionView的刷新方式：根据PHFetchResultChangeDetails 里面的增删改Set，直接进行BatchUpdates，因为我们相册的 View 和 ViewModel 和原始数据不相同，因此没有采用。感兴趣的
可以看下列官方示例代码：
▐ 体验优化
预加载及时机：按中端机来说，平均读取10000张预估需要1s，按照这种时长，预加载是必要的。但是，预加载和隐私合规是需要权衡的。具体展开会在文章后面「实现细节-相册隐私合规」中阐述。这里主要引出需要做预加载这个动作。
思路是提供一个单例，在合适的时机，可以操作读取管理器进行读取并保存。视图层在即将展示时候，判断读取管理器是否有缓存数据，并且已经完成读取。则直接使用缓存数据。也因为增加了这个逻辑，需要有读取完成的回调，防止视图层判断到正在读取时，没有时机响应数据回调。
▐ 展示链路
展示链路上，就是根据视觉需要各显神通了。考虑到保持底层逻辑复用，对相册做了MVVM架构，保持了Model、ViewModel、View不变的情况下，支持了相册外露能力和相册本体两个ViewController。
▐ 对外接口
为了让相册模块独立，但又需要业务方修改，增加了适配层。我们的适配层提供了如下的能力可以作为参考：
对外API方面，我们进行了可扩展的封装：
可扩展性体现在：
- 回调参数使用字典，可以灵活扩展，通过Key获取。
- 创建相册通过配置相关能力，方便业务方增加需求。
/* * imagePickerFinishOpenBlock 用户选择相册的图片或视频后的回调 * @params mediaInfo 参数说明 * key: ImagePickerInfoKeyMetaInfo vaule: 系统返回的metaInfo (NSDictionary *) * key: ImagePickerInfoKeyImage value:图片对象（UIImage *_Nullable） * key: ImagePickerInfoKeyAvAsset value: 视频的avAsset（AVAsset *_Nullable） * key: ImagePickerInfoKeyError value:错误信息 (Error *_Nullable) */typedef void (^imagePickerFinishOpenBlock)(NSDictionary *mediaInfo, NSDictionary *paramURLArgs); typedef void (^imagePickerCancelBlock)(void); extern const NSString *ImagePickerInfoKeyImage;extern const NSString *ImagePickerInfoKeyAvAsset;extern const NSString *ImagePickerInfoKeyMetaInfo;extern const NSString *ImagePickerInfoKeyError; #pragma mark - 业务能力/* * 打开相册，选择相片之后回调，此时使用默认的photoConfig配置 * @param getImageBlock 获取到图片/视频后的回调 * @param cancelBlock 用户取消block，相册dismiss前调用 */- (void)openImagePickerViewController:(imagePickerFinishOpenBlock)getImageBlock cancelBlock:(imagePickerCancelBlock)cancelBlock; /* * 打开相册，选择相片之后回调 * @param config 用户自定义相册相关的配置 * @param getImageBlock 获取到图片/视频后的回调 * @param cancelBlock 用户取消block，相册dismiss前调用 */- (void)openImagePickerViewControllerWithConfig:(PhotoConfig *)photoConfig finishBlock:(imagePickerFinishOpenBlock)getImageBlock cancelBlock:(imagePickerCancelBlock)cancelBlock; /* * 若用户未授予权限，则主动申请相册权限，并打开相册，选择相片之后回调 * @param photoConfig 用户自定义相册相关的配置 * @param getImageBlock 获取到图片/视频后的回调 * @param cancelBlock 用户取消block，相册dismiss前调用 */- (void)requestAuthAndOpenImagePickerViewControllerWithConfig:(PhotoConfig *)photoConfig finishBlock:(imagePickerFinishOpenBlock)getImageBlock cancelBlock:(imagePickerCancelBlock)cancelBlock; /* * 关闭相册页 */- (void)dismissImagePickerAnimated:(BOOL)flag completion:(void (^)(void))completion;
针对第一个问题，需要做好权限判断，在最合适的时机申请权限，在所有读取相册的时候都进行权限判断。
针对第二个问题，我们发现除了很明显的读取系统相册之外，注册相册变更获取事件也会让APP隐私报告中留下记录。解决方案是在合适的时机注册相册变更获取。
▐ 关于“有限权限访问那些事
iOS14 新增了“Limited Photo Library Access” 模式，在授权弹窗中增加了 Select Photo 选项。用户可以在 App 请求调用相册时选择部分照片让 App 读取。从 App 的视角来看，你的相册里就只有这几张照片，App 无法得知其它照片的存在。
这对于开发者来说，有几个场景可以优化：
一是注册相册变更，详见「设计与实现-相册的变更链路」中，观察者对 iOS14 有限选择照片的判断及通知的处理
二是当判断到有限权限的时候，告知用户，并对用户引导开启更多照片权限。
▐ 多线程问题
在实际的操作中，由于很多业务场景都进行了Photos库的操作，会遇到如下问题：
子线程如果在做耗时读取操作，并且如果多个子线程同时操作，这时候产生os_unfair_lock_lock。此时，如果主线程对PHPhotoLibrary进行任何操作，大概率造成ANR。
解决方案是：
- 首先我们自己的业务，对相册的读取操作，都放到一个指定的线程。
- 其次，进行子线程加载时，如果主线程有访问PHPhotoLibrary的地方，进行阻塞loading加载。
