[iOS 开发] 图文快照分享的实现

栏目: IOS · 发布时间: 7年前

内容简介：[iOS 开发] 图文快照分享的实现

原文

前言：『图文快照』是指将一组图片和文字，进行排版组合，最终生成一张长图片。长图片（长微博）最早是在微博中出现的，后来在一些应用中（简书、小红书、百度地图）也看到了分享长图片的功能，另外还有些专门制作长图片的工具，比如锤子便签、Zine。

0.背景介绍

1. 需求分析

2. 实现思路

3. 实现过程

4. 单元测试

5. 几个问题

6. 参考资料

0.背景介绍

任何有实际意义的创新都不是凭空想象出来的（这不废话么~）。长图片在微博中出现的起因是当时微博中文字长度不得超过140字，所以当文字比较多时就可以转为图片来发布。微博作为碎片化时代的代表，本身带有“快餐化”、“碎片化”的标签，长图片的出现，在一定程度上与短微博形成了互补，现在我们经常可以看到一条这样的微博：一段短文描述 + 链接 + 一张内容详尽的长图片。而且，以图片代替文字在某种程度上可以躲过“河蟹”。

[iOS 开发] 图文快照分享的实现

所以，长图片给我们带来的好处显而易见——快好省，可以让用户用最少的代价，更快地，看到更多的内容。

1. 需求分析

需求：点击分享菜单中的“朋友圈快照”按钮，将要分享的社区图文帖转成长图片（图片中的内容从上到下，依次为品牌 logo、用户信息、文字、图片、点赞、二维码信息），然后分享到朋友圈。

以前分享到朋友圈的是这条帖子的链接，用户看到的只是一个标题和 icon，需要点击跳转再加载网页才能看到内容，而现在采用长图的方式，可以让用户更直观、更快地看到分享的内容，更利于传播。

技术分析：这个需求的核心是图片，所以我们在生成图片时需要重点考虑的有两点：

尽量缩短用户在分享长图片时的等待时长
尽量保证图片质量和体积大小的平衡，也就是既要好看又不能太大

生成并分享图文快照的过程

2. 实现思路

首先我们要考虑的是，如何把数据变成图片？

我们平时在开发过程中都是通过创建 view 来实现视觉效果的，所以我们可以从 UIView 入手—— UIView->UIImage 。我们可以通过 UILayer 的 -renderInContext : 方法将 UIView 在 context 上进行图像内容渲染，然后再通过 UIGraphicsGetImageFromCurrentImageContext() 获取图片。

讨论：当然你也许会说，为什么不用 drawViewHierarchyInRect:afterScreenUpdates: 方法来生成图片，它比 -renderInContext: 方法效率要高啊，实际上drawViewHierarchyInRect:afterScreenUpdates: 不支持不可见的 view，也就是说，对于没有显示在屏幕上的 view，调用这个方法不起作用。

核心部分弄清楚之后，其他的就简单了，大概梳理一下，生成图文快照的主要流程如下图所示：

[iOS 开发] 图文快照分享的实现

实现流程

3. 实现过程

具体的代码见 ShannonChenCHN/SCSnapshotManager，这里我们只讨论实现过程。

3.1 需要考虑的问题

功能拆分

二维码生成
图片下载
UIView -> UIImage

解耦：要根据不同数据生成不同样式的快照，怎么实现？

3.2 一图胜千言

SCSnapshotManager 的实现原理

结合上面的示例图，一张快照的生成需要经历下面几个步骤：

SCSnapshotManager 拿到传进来的 model
SCSnapshotManager 根据 model 的类型创建 model 对应的 provider 对象
provider 对象会通过 SCSnapshotModelTransformer 来转换生成快照的 content（其实也是一个 model，只不过是为了统一）
SCSnapshotManager 从 provider 对象那里获取到要分享的 URL，并调用 SCQRCodeGenerator 生成二维码图片，拿到二维码图片后，再回传给 content
provider 对象把下载的图片的 URL 整理好，交给SCSnapshotManager， SCSnapshotManager再通过 SCSnapshotImageDownloader 进行下载，下载完成后再将图片回传给 provider 对象
provider 对象拿到下载好的图片后，创建相应的 view
SCSnapshotManager 把 provider 对象提供的 view 交给 SCSnapshotGenerator 转成一个压缩过的 UIImage 对象
SCSnapshotManager 拿到最终的 UIImage 对象，就可以干自己想干的事了——分享或者保存到相册

3.3 Architecture

类名	功能
SCSnapshotManager	负责主线逻辑，串联各子逻辑（从生成二维码到分享快照），这里面的逻辑一般不怎么变动的
SCSnapshotProviderProtocol	所有 Provider 类需要遵循的协议，不论是要生成什么样的快照，主流程是不会有什么变化的，变化的是 Provider，不同的需求（数据、逻辑、展示）对应不同的 Provider，所以在 Example 中，商户快照对应有一个 SCSnapshotMerchantProvider，图文帖快照对应也有一个 SCSnapshotPostProvider，每个具体的 provider 只需要遵守协议，并实现其中的方法即可：① 转换 Model，② 拼装图片下载 URL，以提供给 SCSnapshotImageDownloader 下载，③ 拿下载好的图片来创建 view，④ 其他强业务逻辑，比如埋点
SCQRCodeGenerator	二维码生成器，根据一个字符串生成一张二维码图片
二维码生成器，根据一个字符串生成一张二维码图片	图片下载器，因为要下载的是多张图片，而且还要考虑到分组展示的情况，所以这里我们将要下载的图片 URLs 包装成二维数组传入，下载完成后，得到一个装有图片的二维数组
SCSnapshotGenerator	将 view 转成 image

4. 单元测试

4.1 单元测试的目的

模拟大多数的真实情况，更方便地测试各种边界条件和异常情况

保证在加入新功能或修改旧功能时，不影响原有功能

检验程序的设计合理性，是否遵循功能单一原则，是否低耦合

4.2 怎么测

Mock 数据，测试基本流程
Mock 数据，测试单个模块的功能
Mock 数据，测试各种极端情况，比如 image 为空

具体测试内容见 ExampleProject 。

5. 几个问题

图片压缩策略：是分别把各单张图片压缩好，还是最后对整张长图进行压缩呢？

从评测结果中的内存峰值和压缩时间来看，显然后者更好。
图片压缩方式：

采用 JPG 呢，还是 PNG？如果是 JPG 的话，压缩比为多少最合适？是不是想压到多大就能压到多大？压了之后清晰度怎么保障？

采用的是 JPG 的格式，因为 JPG 的格式可以设置压缩比。综合压缩后的体积和展示效果来看，压缩到压缩比为 0.8 就差不多了。值得注意的是，并不是压缩比越小，压缩后的图片体积就越小，实际上，当压缩到一定程度后，就会到一个极限，不能再小了。
微信说限制为 10M 是指什么格式下呢？

从微信中导出的图片格式来看，应该是 JPG 的。
如何保证所有图片都能压缩到10M 以下？

从图片尺寸大小入手，限制每单张图片的宽高比（我们这里取1/2），太长的图片就裁剪掉一部分。