前言：『图文快照』是指将一组图片和文字，进行排版组合，最终生成一张长图片。长图片（长微博）最早是在微博中出现的，后来在其他一些应用中（简书、小红书、百度地图）也看到了分享长图片的功能，另外还有些专门制作长图片的工具，比如锤子便签、Zine。
目录
0.背景介绍
1. 需求分析
2. 实现思路
3. 实现过程
4. 单元测试
5. 几个问题
6. 参考资料
0.背景介绍
任何有实际意义的创新都不是凭空想象出来的（这不废话么~）。长图片在微博中出现的起因是当时微博中文字长度不得超过140字，所以当文字比较多时就可以转为图片来发布。 微博作为碎片化时代的代表，本身带有“快餐化”、“碎片化”的标签，长图片的出现，在一定程度上与短微博形成了互补，现在我们经常可以看到一条这样的微博：一段短文描述 + 链接 + 一张内容详尽的长图片。而且，以图片代替文字在某种程度上可以躲过“河蟹”。
所以，长图片给我们带来的好处显而易见——快好省，可以让用户用最少的代价，更快地，看到更多的内容。
1. 需求分析
需求：点击分享菜单中的“朋友圈快照”按钮，将要分享的社区图文帖转成长图片（图片中的内容从上到下，依次为品牌 logo、用户信息、文字、图片、点赞、二维码信息），然后分享到朋友圈。
以前分享到朋友圈的是这条帖子的链接，用户看到的只是一个标题和 icon，需要点击跳转再加载网页才能看到内容，而现在采用长图的方式，可以让用户更直观、更快地看到分享的内容，更利于传播。
技术分析：这个需求的核心是图片，所以我们在生成图片时需要重点考虑的有两点：
- 尽量缩短用户在分享长图片时的等待时长
- 尽量保证图片质量和体积大小的平衡，也就是既要好看又不能太大
2. 实现思路
首先我们要考虑的是，如何把数据变成图片？
我们平时在开发过程中都是通过创建 view 来实现视觉效果的，所以我们可以从 UIView 入手——UIView->UIImage。我们可以通过 UILayer 的 -renderInContext: 方法将 UIView 在 context 上进行图像内容渲染，然后再通过 UIGraphicsGetImageFromCurrentImageContext() 获取图片。
讨论：当然你也许会说，为什么不用
drawViewHierarchyInRect:afterScreenUpdates:方法来生成图片，它比-renderInContext:方法效率要高啊，实际上drawViewHierarchyInRect:afterScreenUpdates:不支持不可见的 view，也就是说，对于没有显示在屏幕上的 view，调用这个方法不起作用。
核心部分弄清楚之后，其他的就简单了，大概梳理一下，生成图文快照的主要流程如下图所示：
3. 实现过程
具体的代码见 ShannonChenCHN/SCSnapshotManager，这里我们只讨论实现过程。
3.1 需要考虑的问题
- 功能拆分
- 二维码生成
- 图片下载
- UIView -> UIImage
- 解耦：要根据不同数据生成不同样式的快照，怎么实现？
3.2 一图胜千言
结合上面的示例图，一张快照的生成需要经历下面几个步骤：
-
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 只需要遵守 <SCSnapshotProvider> 协议，并实现其中的方法即可：① 转换 Model，② 拼装图片下载 URL，以提供给 SCSnapshotImageDownloader 下载，③ 拿下载好的图片来创建 view，④ 其他强业务逻辑，比如埋点 |
SCQRCodeGenerator |
二维码生成器，根据一个字符串生成一张二维码图片 |
SCSnapshotImageDownloader |
图片下载器，因为要下载的是多张图片，而且还要考虑到分组展示的情况，所以这里我们将要下载的图片 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），太长的图片就裁剪掉一部分。长图最大宽度和分辨率：为什么是 640px，而不是750px ？这里还用考虑 @2x 和 @3x 的问题吗？
综合考虑图片展示效果和图片体积大小，640px 的宽度已经足够了。因为不论是iPhone 5 还是 iPhone 6Plus 生成的图片，都是640 px 宽度的，而且不需要在屏幕上展示，所以用于生成快照的 view 的图片素材不管是 @2x，还是 @3x，都是一样的大小。
- 单张图片的宽高比限制：宽高比小于 1/2 就只显示中间部分，有两种方案可选：① 每张图片下载完成后，如果太高就裁剪中间的部分；② 在 view 中渲染时，只“显示”中间的 1/2 部分。应该选哪一种呢？
从效率和性能上看，显然选第二种更好，因为绘制是比较耗性能的。 评测结果证明也是如此。
- 减少下载时长：① 提前下载，点击菜单时就开始下载；② 用小图片行不行，会影响显示效果吗
- 二维码技术：参考 kingsic/SGQRCode 和 iOS 7 Core Image QR Code generation too blur。
- 图片 resizing 技术：参考 Image Resizing Techniques。
