内容简介：[iOS 开发] 图文快照分享的实现
前言：『图文快照』是指将一组图片和文字，进行排版组合，最终生成一张长图片。长图片（长微博）最早是在微博中出现的，后来在一些应用中（简书、小红书、百度地图）也看到了分享 长图片 的功能，另外还有些专门制作长图片的工具，比如锤子便签、Zine。
目录
0.背景介绍
1. 需求分析
2. 实现思路
3. 实现过程
4. 单元测试
5. 几个问题
6. 参考资料
0.背景介绍
任何有实际意义的创新都不是凭空想象出来的（这不废话么~）。长图片在微博中出现的起因是当时微博中文字长度不得超过140字，所以当文字比较多时就可以转为图片来发布。 微博作为碎片化时代的代表，本身带有“快餐化”、“碎片化”的标签，长图片的出现，在一定程度上与短微博形成了互补，现在我们经常可以看到一条这样的微博：一段短文描述 + 链接 + 一张内容详尽的长图片。而且，以图片代替文字在某种程度上可以躲过“河蟹”。
![[iOS 开发] 图文快照分享的实现](https://img0.tuicool.com/EZFBBv3.png!web)
所以，长图片给我们带来的好处显而易见——快好省，可以让用户用最少的代价，更快地，看到更多的内容。
1. 需求分析
需求：点击分享菜单中的“朋友圈快照”按钮，将要分享的社区图文帖转成长图片（图片中的内容从上到下，依次为品牌 logo、用户信息、文字、图片、点赞、二维码信息），然后分享到朋友圈。
以前分享到朋友圈的是这条帖子的链接，用户看到的只是一个标题和 icon，需要点击跳转再加载网页才能看到内容，而现在采用长图的方式，可以让用户更直观、更快地看到分享的内容，更利于传播。
技术分析：这个需求的核心是图片，所以我们在生成图片时需要重点考虑的有两点：
-
尽量缩短用户在分享长图片时的等待时长
-
尽量保证图片质量和体积大小的平衡，也就是既要好看又不能太大
![[iOS 开发] 图文快照分享的实现](https://img1.tuicool.com/2ERZBjb.png!web)
生成并分享图文快照的过程
2. 实现思路
首先我们要考虑的是，如何把数据变成图片？
我们平时在开发过程中都是通过创建 view 来实现视觉效果的，所以我们可以从 UIView 入手—— UIView->UIImage 。我们可以通过 UILayer 的 -renderInContext : 方法将 UIView 在 context 上进行图像内容渲染，然后再通过 UIGraphicsGetImageFromCurrentImageContext() 获取图片。
讨论：当然你也许会说，为什么不用 drawViewHierarchyInRect:afterScreenUpdates: 方法来生成图片，它比 -renderInContext: 方法效率要高啊，实际上drawViewHierarchyInRect:afterScreenUpdates: 不支持不可见的 view，也就是说，对于没有显示在屏幕上的 view，调用这个方法不起作用。
核心部分弄清楚之后，其他的就简单了，大概梳理一下，生成图文快照的主要流程如下图所示：
![[iOS 开发] 图文快照分享的实现](https://img0.tuicool.com/iMz2UnY.png!web)
实现流程
3. 实现过程
具体的代码见 ShannonChenCHN/SCSnapshotManager，这里我们只讨论实现过程。
3.1 需要考虑的问题
-
功能拆分
-
二维码生成
-
图片下载
-
UIView -> UIImage
-
解耦：要根据不同数据生成不同样式的快照，怎么实现？
3.2 一图胜千言
![[iOS 开发] 图文快照分享的实现](https://img2.tuicool.com/fYBnieJ.png!web)
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 只需要遵守
|
| 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），太长的图片就裁剪掉一部分。
-
长图最大宽度和分辨率：为什么是 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 。
6.参考资料
以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网
猜你喜欢:
- [iOS 开发] 图文快照分享的实现
- Mysql可重复读（2） —— 快照真的就是快照吗
- 移动端页面分享快照生成总结
- LVM、物理卷、逻辑卷、卷组、快照
- KVM 虚拟化技术（八） 之快照
- Mysql可重复读（1） —— 快照何时创建
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
