Facebook移动端照片 预览 背后的技术

当在Facebook移动端上浏览某个人的用户资料或页面时，首先看到的往往是图片。这些图片是构成Facebook体验不可缺少的一部分，但有时候，图片的下载与展示非常慢，在低速或移动网络中尤其如此。而在像印度这样的发展中国家市场上，许多Facebook新用户主要是使用2G网络。近日，Facebook工程师BrianKCabral和EdwardKandrot撰文描述了Facebook解决这一问题的过程。

封面照片是屏幕上最显眼的部分，但它也是加载最慢的部分之一。这主要有两个原因：一是封面照片的大小常常达到100KB，而2G连接的传输速度可能只有32KB/秒；二是应用程序需要发送两个网络请求才能显示封面照片。它首先向GraphQL服务器发送请求，获得照片URL，然后发送第二个网络请求，使用该URL从CDN获取照片。第二个网络请求的延迟相当长，比第一个长许多。

为了解决上述问题，他们希望能够由原照片生成一张200字节大小的效果图，然后将其作为GraphQL响应的一部分在第一次请求应答中直接返回，这样可以省掉第二次请求，极大地缩短用户资料和页首的显示延迟。当然，他们最终还是要从CDN下载完整照片并进行展示，但这可以在后台进行。至此，问题变成如何将照片压缩成200字节。

他们希望照片的效果图有一种磨砂玻璃的效果。这既有趣，又能与原始照片保持一致。磨砂玻璃效果采用高斯滤波器比较容易实现，而且图片越模糊，分辨率就越低，图片的尺寸就越小。不过，为了提供良好的用户体验，分辨率也不能太低。通过多次尝试，他们得出，42x42的图片可以达到他们想要的效果，而分辨率再高一些并不会带来更好的效果。但是，即使只显示图片的DC分量，每个像素仍然需要3个字节，那么42x42x3就是5292字节，远远超出200字节的目标。

他们开始评估标准的压缩技术，试图找出一种最好的方法，将数据压缩至200字节。遗憾的是，只是对图片进行熵编码（比如zlib）的话，只能将图片压缩一半，仍然太大。他们还评估了其它若干非标准技术，但最终，他们决定试一下JPEG图像编码。遗憾的是，JPEG头本身就有几百个字节的大小。不过，去掉JPEG头，编码的数据有效负荷接近200字节。

于是，他们开始探索，JPEG图片是否有可能使用一个固定的头，那样就可以将其存储在客户端，而不需要传输。JPEG头包含多个表。在Q值一定的情况下，量化表是不变的。通过试验，他们发现，Q20生成的图片可以满足他们的要求。虽然他们的图片不是固定尺寸，但基本上都限制在42x42以下。他们还仔细查看了JPEG头中的其它内容，发现只有Huffman表会随着图片的不同发生变化。Q值、图片数据及图片尺寸决定着Huffman表中的频率值，每一项变化都会导致不同的压缩比和有效负荷字节数。他们在一组图片上进行了试验，并最终找出了一个可以作为标准的Huffman表。

虽然他们处理了大量的图片，但总有一些该方案不适用的情况。为此，他们增加了一个版本号。如果发现任何极端情况，或者未来发现了更好的Huffman表，那么他们就可以更新相关图片的版本号，并将新表发送给客户端。最终的格式包含一个字节的版本号、一个字节的宽度、一个字节的高度和大约200字节的有效负荷。服务器只将这一格式作为GraphQL响应的一部分发送，然后由客户端将JPEG体附加到预定义的JPEG头上，生成一个普通的JPEG图片。经过标准的JPEG解码后，客户端可以运行预定的高斯模糊，并拉伸其尺寸以适应窗口大小。

最终，他们获得一种可以满足需求的格式。在网速缓慢的情况下，这帮助他们将用户资料和页面加载时间缩短了30%。而在网速非常快的情况下，这可以确保用户立即看到封面照片预览，提升了整体体验。