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

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

原文

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

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

• 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），太长的图片就裁剪掉一部分。

• 长图最大宽度和分辨率：为什么是 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.参考资料

• How to convert a UIview to a image

• iOS单元测试-百度Hi iOS团队

• 使用模板快速编写测试用例

• 二维码的生成细节和原理

• kingsic/SGQRCode

• iOS 7 Core Image QR Code generation too blur

• Image Resizing Techniques

以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

• [iOS 开发] 图文快照分享的实现
• Mysql可重复读（2） —— 快照真的就是快照吗
• 移动端页面分享快照生成总结
• LVM、物理卷、逻辑卷、卷组、快照
• KVM 虚拟化技术（八） 之快照
• Mysql可重复读（1） —— 快照何时创建

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。