iOS开发之——浅谈网络图片处理机制

做iOS开发的对网络图片一定不会陌生，因为在日常开发中我们难免需要下载网络图片并及时显示出来， 而这个看似简单的逻辑其实蕴含着许多难点，为了直接“跨越”这些难点， 通常我们会直接使用SDWebImage第三方框架来进行“傻瓜式”处理。今天我们就来谈谈这个“简单逻辑”到底有哪些难点， SDWebImage又是如何处理这个逻辑的。

本文案例

为了更有针对性进行分析， 在前文我先抛出一个案例，给出一个具体的需求，这个需求一句话概括就是——每个cell上都有一张网络图片的TableView，具体如下图所示。图左侧的tableView正在下载网络图片，因此先用占位图片（一拳超人）顶替着，右侧的tableView则已完成下载，因此直接显示网络图片。

网络图片的技术难点

要实现上述案例中的需求并不难，但要体验良好并且高性能地实现这个需求，则要克服一些难点，其中包括：

1.网络图片下载的延时性带来的UI卡顿问题

• 假设下载是直接在主线程中进行的， 那么在下载过程中，势必会因为网络的延时作用带来UI卡顿问题，因此网络图片的下载必须放在子线程中进行。等网络图片下载成功了，再回到主线程中刷新界面， 显示图片。

2.多线程的管理问题

• 假设一个图片对应一个URL，每使用一个URL来下载图片都需要开启一个子线程，此时如何合理地管理这些线程也是一个问题，例如可以同时开启多少个子线程， 子线程的缓存如何处理，线程的销毁问题等等。

3.网络图片的缓存问题

• 网络图片下载下来后，必须缓存在本地。而且为了保证下次开启App时再次“丝滑”加载这些图片，图片还需要保存到本地沙盒中。

多图下载的解决方案

说完难点，接下来说说解决方案，具体的思路如下图所示：

为什么要这么做

一句话概括，全是为了用户体验！！！（你做iOS开发，你不注重用户体验，你还能注重什么？）。 那么按照上述流程图实现图片下载和缓存，在用户体验上，具体表现为什么？

1. 子线程在后台下载图片，令UI体验依旧如飘柔般丝滑
2. 省流量呀亲，一次下载，造福后代。
3. 二次加载图片速度更快，图片都保存到本地了，加载速度肯定快过第一次不止一百倍。

代码实现

上述流程图，通过代码具体实现起来，如下所示：

1.初始化缓存池和队列

2.UITableViewDataSource代理方法中显示Cell

3.核心方法（即流程图中的执行过程）

写在文末的话

以上就是网络图片的一个基本处理机制，其实为了更好地突出主题，笔者并没有把最完整的思路贴出来，也就是说，以上的处理流程其实还有很多值得优化的小地方（至少三个）。