Acrobat DC Pro 下载和序列号及安装激活图文教程

一、安装包下载

Adobe Acrobat DC Pro (Perpetual) – 永久版本

http://trials3.adobe.com/AdobeProducts/APRO/Solstice_Acrobat2015/win32/Acrobat_2015_Web_WWMUI.exe

Adobe Acrobat DC Pro (Subscription) – 连续版本

http://trials3.adobe.com/AdobeProducts/APRO/15/win32/Acrobat_DC_Web_WWMUI.exe

永久版本,只能获得补丁,不能获取功能更新。(以下安装以“永久版本”为例,本人亲测可以脱机激活)

连续版本,也就是订阅版,可以获得功能更新。(“连续版本”能否脱机激活,没有测试,请诸位自测。)

二、断网安装

1、注意整个安装和激活的过程中一定要断网,禁用网卡或拔掉网线。

2、由于目前还没有发布针对Adobe Acrobat DC的专用注册机,所以仍用适用Acrobat XI的Adobe Acrobat XI的专用注册机(xf-aarpxi.exe)算安装序列号。(不建议用Adobe破解补丁!)

以下为通用序列号:1118-1583-7979-9484-4887-4319输入的序列号要记住,因为后面脱机激活还要用到。

3、如果需要,可以选择“自定义”安装,“自定义安装”时组件和安装路径都可以更改。注意安装过程中不要运行Office程序

三、脱机激活

1、安装完毕首次运行软件,提醒你需要使用Adobe ID登录才能激活本软件。当然不能这么联网激活,我们要做的是脱机激活。

所以要点击“连接Internet时是否出现问题?”

2、点击“脱机激活”,并接着点击“生成请求代码”。


3、脱机激活的窗口不要关闭,再去运行Adobe CC2014的算号器(xf-adobecc2014.exe)计算响应代码。

(1)Serial 里输入之前安装时用的序列号;

(2)Request里输入脱机激活窗口里的“请求代码”;

(3)点击GENERATE就会在Activation里生成“响应代码”,复制到脱机激活窗口的响应代码区;

(4)点击“激活”并确认看到“脱机激活完成”的窗口。

四、屏蔽联网验证

脱机激活后在hosts文件里添加

127.0.0.1 lmlicenses.wip4.adobe.com

127.0.0.1 lm.licenses.adobe.com

127.0.0.1 3dns-2.adobe.com

127.0.0.1 3dns-3.adobe.com

127.0.0.1 activate.adobe.com

127.0.0.1 activate-sea.adobe.com

127.0.0.1 activate-sjc0.adobe.com

127.0.0.1 adobe-dns.adobe.com

127.0.0.1 adobe-dns-2.adobe.com

127.0.0.1 adobe-dns-3.adobe.com

127.0.0.1 ereg.adobe.com

127.0.0.1 hl2rcv.adobe.com

127.0.0.1 practivate.adobe.com

127.0.0.1 wip3.adobe.com

127.0.0.1 activate.wip3.adobe.com

127.0.0.1 ereg.wip3.adobe.com

127.0.0.1 wwis-dubc1-vip60.adobe.com

以上工作完成后,这时才可以联网。

五、后续完善工作

1、运行软件后,依次点选以下菜单栏

编辑——首选项——文档,“最近使用列表中的最大文档数量”设置为0

编辑——首选项——一般,取消勾选“启动Adobe Acrobat DC时向我显示消息”

编辑——首选项——更新程序,取消勾选“自动安装更新”

Adobe Acrabat的离线更新补丁下载网页:http://www.adobe.com/support/downloads/product.jsp?product=1&platform=Windows

 

2、如果系统中有防火墙的话,使用过程中会发现弹出一些程序的联网请求,分别是

C:\Program Files\Adobe\Acrobat 2015\Acrobat\AcroCEF\AcroCEF.exe(可能是连接Microsoft SharePoint帐户的进程)

C:\Program Files\Common Files\Adobe\OOBE\PDApp\P7\adobe_licutil.exe(这个就是联网验证序列号的程序,肯定要防火墙拦截)

C:\Program Files\Common Files\Adobe\ARM\1.0\AdobeARM.exe(这个是检查更新的程序)

3、清理开机启动项:

去注册表HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run下删除

Acrobat Assistant 8.0

AdobeAAMUpdater-1.0

4、“服务”里停止Adobe Acrobat Update Service,并将其启动类型设置为“手动”

5、去除右键菜单里Adobe PDF相关项目:

去”C:\Program Files\Adobe\Acrobat 2015\Acrobat Elements\ContextMenuShim.dll”目录下运行以下内容批处理反注册ContextMenuShim.dll(32位系统)或ContextMenuShim64.dll(64位系统)

regsvr32 /u ContextMenuShim.dll

regsvr32 /u ContextMenuShim64.dll

注意:以后每次更新补丁后,3、4、5三项仍会恢复原状,需要再去修改一番。

移动端图片格式使用

图片通常是移动端流量耗费最多的部分,并且占据着重要的视觉空间。合理的图片格式选用和优化可以为你节省带宽、提升视觉效果。在这篇文章里我会分析一下目前主流和新兴的几种图片格式的特点、性能分析、参数调优,以及相关开源库的选择。

几种图片格式的简介

首先谈一下大家耳熟能详的几种老牌的图片格式吧:

JPEG 是目前最常见的图片格式,它诞生于 1992 年,是一个很古老的格式。它只支持有损压缩,其压缩算法可以精确控制压缩比,以图像质量换得存储空间。由于它太过常见,以至于许多移动设备的 CPU 都支持针对它的硬编码与硬解码。

PNG 诞生在 1995 年,比 JPEG 晚几年。它本身的设计目的是替代 GIF 格式,所以它与 GIF 有更多相似的地方。PNG 只支持无损压缩,所以它的压缩比是有上限的。相对于 JPEG 和 GIF 来说,它最大的优势在于支持完整的透明通道。

GIF 诞生于 1987 年,随着初代互联网流行开来。它有很多缺点,比如通常情况下只支持 256 种颜色、透明通道只有 1 bit、文件压缩比不高。它唯一的优势就是支持多帧动画,凭借这个特性,它得以从 Windows 1.0 时代流行至今,而且仍然大受欢迎。

在上面这些图片格式诞生后,也有不少公司或团体尝试对他们进行改进,或者创造其他更加优秀的图片格式,比如 JPEG 小组的 JPEG 2000、微软的 JPEG-XR、Google 的 WebP、个人开发者发布的 BPG、FLIF 等。它们相对于老牌的那几个图片格式来说有了很大的进步,但出于各种各样的原因,只有少数几个格式能够流行开来。下面三种就是目前实力比较强的新兴格式了:

APNG 是 Mozilla 在 2008 年发布的一种图片格式,旨在替换掉画质低劣的 GIF 动画。它实际上只是相当于 PNG 格式的一个扩展,所以 Mozilla 一直想把它合并到 PNG 标准里面去。然而 PNG 开发组并没有接受 APNG 这个扩展,而是一直在推进它自己的 MNG 动图格式。MNG 格式过于复杂以至于并没有什么系统或浏览器支持,而 APNG 格式由于简单容易实现,目前已经渐渐流行开来。Mozilla 自己的 Firefox 首先支持了 APNG,随后苹果的 Safari 也开始有了支持, Chrome 目前也已经尝试开始支持 ,可以说未来前景很好。

WebP 是 Google 在 2010 年发布的图片格式,希望以更高的压缩比替代 JPEG。它用 VP8 视频帧内编码作为其算法基础,取得了不错的压缩效果。它支持有损和无损压缩、支持完整的透明通道、也支持多帧动画,并且没有版权问题,是一种非常理想的图片格式。借由 Google 在网络世界的影响力,WebP 在几年的时间内已经得到了广泛的应用。看看你手机里的 App:微博、微信、QQ、淘宝、网易新闻等等,每个 App 里都有 WebP 的身影。Facebook 则更进一步,用 WebP 来显示聊天界面的贴纸动画。

BPG 是著名程序员 Fabrice Bellard 在去年 (2014年) 发布的一款超高压缩比的图片格式。这个程序员有些人可能感觉面生,但说起他的作品 FFmpeg、QEMU 大家想必是都知道的。BPG 使用 HEVC (即 H.265) 帧内编码作为其算法基础,就这点而言,它毋庸置疑是当下最为先进的图片压缩格式。相对于 JP2、JPEG-XR、WebP 来说,同等体积下 BPG 能提供更高的图像质量。另外,得益于它本身基于视频编码算法的特性,它能以非常小的文件体积保存多帧动画。 Fabrice Bellard 聪明的地方在于,他知道自己一个人无法得到各大浏览器厂商的支持,所以他还特地开发了 Javascript 版的解码器,任何浏览器只要加载了这个 76KB 大小的 JS 文件,就可以直接显示 BPG 格式的图片了。目前阻碍它流行的原因就是 HEVC 的版权问题和它较长的编码解码时间。尽管这个图片格式才刚刚发布一年,但已经有不少厂子开始试用了,比如阿里腾讯

移动端图片类型的支持情况

目前主流的移动端对图片格式的支持情况如何呢?我们分别来看一下 Android 和 iOS 目前的图片编解码架构吧:

mobile_image_arch

Android 的图片编码解码是由 Skia 图形库负责的,Skia 通过挂接第三方开源库实现了常见的图片格式的编解码支持。目前来说,Android 原生支持的格式只有 JPEG、PNG、GIF、BMP 和 WebP (Android 4.0 加入),在上层能直接调用的编码方式也只有 JPEG、PNG、WebP 这三种。目前来说 Android 还不支持直接的动图编解码。

iOS 底层是用 ImageIO.framework 实现的图片编解码。目前 iOS 原生支持的格式有:JPEG、JPEG2000、PNG、GIF、BMP、ICO、TIFF、PICT,自 iOS 8.0 起,ImageIO 又加入了 APNG、SVG、RAW 格式的支持。在上层,开发者可以直接调用 ImageIO 对上面这些图片格式进行编码和解码。对于动图来说,开发者可以解码动画 GIF 和 APNG、可以编码动画 GIF。

两个平台在导入第三方编解码库时,都多少对他们进行了一些修改,比如 Android 对 libjpeg 等进行的调整以更好的控制内存,iOS 对 libpng 进行了修改以支持 APNG,并增加了多线程编解码的特性。除此之外,iOS 专门针对 JPEG 的编解码开发了 AppleJPEG.framework,实现了性能更高的硬编码和硬解码,只有当硬编码解码失败时,libjpeg 才会被用到。

静态图片的编码与解码

由于我目前主要是做 iOS 开发,所以下面的性能评测都是基于 iPhone 的,主要测试代码可以在这里看到测试素材很少,只有两个:

dribbble512_pngcrushlena512_weibo

第一张是Dribbble 的 Logo,包含 Alpha 通道,用于测试简单的、图形类的图像。
第二张经典的 Lena 图,用于测试照片类的、具有丰富细节的图像。
每个图像都有 64×64、128×128、256×256、512×512 四种分辨率。
测试素材过少可能导致某些测试不够准确,但作为参考大致是没问题的。

JPEG

目前比较知名的 JPEG 库有以下三个:

    libjpeg开发时间最早,使用最广泛的 JPEG 库。由于 JPEG 标准过于复杂和模糊,并没有其他人去实现,所以这个库是 JPEG 的事实标准。

    libjpeg-turbo一个致力于提升编解码速度的 JPEG 库。它基于 libjpeg 进行了改造,用 SIMD 指令集 (MMX、SSE2、NEON) 重写了部分代码,官网称相对于 libjpeg 有 24 倍的性能提升。

    MozJPEG 一个致力于提升压缩比的 JPEG 库。它是 Mozilla 在 2014 年发布的基于 libjpeg-turbo 进行改造的库,相对于 libjpeg 有 5% ~ 15%  的压缩比提升,但相应的其编码速度也慢了很多。

除了上面这三个库,苹果自己也开发了一个 AppleJPEG,但并没有开源。其调用了芯片提供的 DSP 硬编码和硬解码的功能。虽然它不如上面这三个库功能完善,但其性能非常高。在我的测试中,其编解码速度通常是 libjpeg-turbo 的 1~2 倍。可惜的是,目前开发者并不能直接访问这个库。

下面是 ImageIO (AppleJPEG/libpng) 在 iPhone 6 上的编解码性能:

jpeg_bench_dribbble jpeg_bench_lena

可以看到,JPEG 编码中 quality 越小,图片体积就越小,质量越也差,编码时间也越短。解码时间并没有很大的差距,可能是其大部分时间消耗在了函数调用、硬件调用上。苹果在自己的相册 Demo 中提供的 quality 的默认值是 0.9,在这个值附近,图像质量和体积、编码解码时间之间都能取得不错的平衡。

PNG

相对于 JPEG 来说,PNG 标准更为清晰和简单,因此有很多公司或个人都有自己的 PNG 编码解码实现。但目前使用最广的还是 PNG 官方发布的 libpng 库。iOS 和 Android 底层都是调用这个库实现的 PNG 编解码。

下面是 PNG 在 iPhone 6 上的编解码性能:

jpeg_png_bench

可以看到,在编解码图形类型(颜色少、细节少)的图片时,PNG 和 JPEG 差距并不大;但是对于照片类型(颜色和细节丰富)的图片来说,PNG 在文件体积、编解码速度上都差 JPEG 不少了。

和 JPEG 不同,PNG 是无损压缩,其并不能提供压缩比的选项,其压缩比是有上限的。目前网上有很多针对 PNG 进行优化的工具和服务,旨在提升 PNG 的压缩比。下面是常见的几个 PNG 压缩工具的性能对比:

png_tools_bench

pngcrush 是 Xcode 自带的 PNG 压缩工具,相对于设计师用 Photoshop 生成的图片来说,它能取得不错的压缩效果。ImageOptim 则更进一步,对每张图用多种缩算法进行比对,选择压缩比更高的结果,进一步缩小了文件体积。TinyPNG.com 相对于其他工具来说,压缩比高得不像话。它启用了类似 GIF 那样的颜色索引表对 PNG 进行压缩,所以会导致颜色丰富的图片丢失掉一部分细节。如果使用 TinyPNG 的话,最好在压缩完成后让设计师看一下颜色效果是否可以接受。

WebP

WebP 标准是 Google 定制的,迄今为止也只有 Google 发布的 libwebp 实现了该的编解码 。 所以这个库也是该格式的事实标准。

WebP 编码主要有几个参数:

    lossless: YES:有损编码 NO:无损编码。WebP 主要优势在于有损编码,其无损编码的性能和压缩比表现一般。

    quality: [0~100] 图像质量,0表示最差质量,文件体积最小,细节损失严重,100表示最高图像质量,文件体积较大。该参数只针对有损压缩有明显效果。Google 官方的建议是 75,腾讯在对 WebP 评测给出的建议也是 75。在这个值附近,WebP 能在压缩比、图像质量上取得较好的平衡。

    method: [0~6] 压缩比,0表示快速压缩,耗时短,压缩质量一般,6表示极限压缩,耗时长,压缩质量好。该参数也只针对有损压缩有明显效果。调节该参数最高能带来 20% ~ 40% 的更高压缩比,但相应的编码时间会增加 520 倍。Google 推荐的值是 4

对于编码无损图片来说,quality=0, method=0~3 是相对来说比较合适的参数,能够节省编码时间,同时也有不错的压缩比。无损编码图片,quality=75, method=2~4 是比较合适的参数,能在编码时间、图片质量、文件体积之间有着不错的平衡。

WebP 解码有三个参数:

    use_threads: 是否启用 pthread 多线程解码。该参数只对宽度大于 512 的有损图片起作用。开启后内部会用多线程解码,CPU 占用会更高,解码时间平均能缩短 10%~20%。

    bypass_filtering: 是否禁用滤波。该参数只对有损图片起作用,开启后大约能缩短 5%~10% 的解码时间,但会造成一些颜色过渡平滑的区域产生色带(banding)。

    no_fancy_upsampling: 是否禁用上采样。该参数只对有损图片起作用。在我的测试中,开启该参数后,解码时间反而会增加 525%,同时会造成一些图像细节的丢失,线条边缘会增加杂色,显得不自然。

通常情况下,这三个参数都设为 NO 即可,如果要追求更高的解码速度,则可以尝试开启 use_threads 和 bypass_filtering 这两个参数。而 no_fancy_upsampling 在任何情况下都没必要开启。

由于 WebP 测试数据较多,这里只贴一下 512x512 大小的一部分测试结果,感兴趣的可以看文章结尾处的 Excel 附件。

webp_bench

对于简单的图形类型的图像(比如 App 内的各种 UI 素材),WebP 无损压缩的文件体积和解码速度某些情况下已经比 PNG 还要理想了,如果你想要对 App 安装包体积进行优化,可以尝试一下 WebP。

对于复杂的图像(比如照片)来说,WebP 无损编码表现并不好,但有损编码表现却非常棒。相近质量的图片解码速度 WebP 相距 JPEG 也已经相差不大了,而文件压缩比却能提升不少。

BPG

BPG 是目前已知最优秀的有损压缩格式了,它能在相同质量下比 JPEG 减少 50% 的体积。下面是经典的 Lena 图的对比,你也可以在这里看到大量其他图片的 BPG、JPEG、JPEG2000、JPEG-XR、WebP 压缩效果的在线对比,效果非常明显。

bpg_demo

BPG 目前只有作者发布的 libbpg 可用。但作者基于 libbpg 编译出了一个 Javascript 解码器,很大的扩展了可用范围。bpg 可以以无损和有损压缩两种方式进行编码,有损压缩时可以用 quality 参数控制压缩比,可选范围为 0~51,数值越大压缩比越高。通常来说,25 附近是一个不错的选择,BPG 官方工具默认值是 28。

libbpg 目前并没有针对 ARM NEON 做优化,所以其在移动端的性能表现一般。下面是 iPhone 6 上的性能测试:

bpg_bench

由于 bpg 编码时间太长,我并没有将数据放到表格里。可以看到相同质量下,BPG 的解码速度还是差 JPEG 太多,大约慢了 35 倍。目前来说,BPG 适用于那些对流量非常敏感,但对解码时间不敏感的地方。从网上的新闻来看,手机淘宝和手机QQ都已经有所尝试,但不清楚他们是否对 BPG 解码进行了优化。

动态图片的编码与解码

动图在网络上非常受欢迎,它近似视频,但通常实现简单、文件体积小,应用范围非常广泛。动图的始祖是 GIF,它自 Windows 1.0 时代就在互联网上流行开来,直到今天仍然难以被其他格式取代。尽管它非常古老,但其所用的原理和今天几种新兴格式几乎一样。

下面是一张 GIF 格式的 QQ 大表情:

bench_gif_demo

这张表情由 6 幅静态图构成,每幅图片有一定的存活时间,连贯播放就形成了动画:

bench_gif_demo1

这几张图中,大部分内容是相近的,为了压缩文件体积,通常动图格式都支持一些特殊的方式对相似图片进行裁剪,只保留前后帧不同的部分:

bench_gif_demo2

在解码动图时,解码器通常采用所谓“画布模式”进行渲染。想象一下:播放的区域是一张画布,第一帧播放前先把画布清空,然后完整的绘制上第一帧图;播放第二帧时,不再清空画布,而是只把和第一帧不同的区域覆盖到画布上,就像油画的创作那样。

像这样的第一帧就被称为关键帧(即 I 帧,帧内编码帧),而后续的那些通过补偿计算得到的帧被称为预测编码帧(P帧)。一个压缩的比较好的动图内,通常只有少量的关键帧,而其余都是预测编码帧;一个较差的压缩工具制作的动图内,则基本都是关键帧。不同的动图压缩工具通常能得到不同的结果。

除此之外,动图格式通常有更为详细的参数控制每一帧的绘制过程,下面是 GIF/APNG/WebP 通用的几个参数:

Disposal Method (清除方式) 
   Do Not Dispose:把当前帧增量绘制到画布上,不清空画布。
   Restore to Background:绘制当前帧之前,先把画布清空为默认背景色。
   Restore to Previous:绘制下一帧前,把先把画布恢复为当前帧的前一帧

Blend Mode (混合模式) 
   Blend None: 绘制时,全部通道(包含Alpha通道)都会覆盖到画布,相当于绘制前先清空画布的指定区域。
   Blend over:绘制时,Alpha 通道会被合成到画布,即通常情况下两张图片重叠的效果。

上面这些技术,就是常见动图格式的基础了,下面分别介绍一下不同动图格式的特点。

GIF

GIF 缺陷非常明显:它通常只支持 256 色索引颜色,这导致它只能通过抖动、差值等方式模拟较多丰富的颜色;它的 Alpha 通道只有 1 bit,这意味着一个像素只能是完全透明或者完全不透明。

gif_apng_demo

上面这是腾讯博客里的一张演示图,可以看到 GIF 由于 Alpha 通道的问题,产生了严重的“毛边”现象。目前通常的解决方案是在图片的边缘加一圈白边,以减轻这种视觉效果:

gif_wrong_demo

可以仔细观察一下 QQ、微信等 App 里面的动画表情,几乎每个表情都被一圈白边所环绕,不得不说是一种很无奈的解决方案。

GIF 的制作工具有很多,但效果好、压缩比高的工具非常少。对于已经制作好的 GIF 来说,用 imagemagick 处理一下可以把文件体积压缩不少。如果需要将视频转为 GIF,Cinemagraph Pro 是个不错的傻瓜化工具。这里有一篇文章介绍如何用 ffmpeg 压缩 GIF,虽然参数调节有点麻烦,但效果非常理想。

下面是没有经过优化的 GIF 和经过 ffmpeg 优化编码的 GIF,可以看到差距非常大。

bbb-trans bbb-nodither

APNG

APNG 目前并没有被 PNG 官方所接受,所以 libpng 并不能直接解码 APNG。但由于 APNG 只是基于 PNG 的一个简单扩展,所以在已经支持 PNG 的平台上,可以很轻松的用少量代码实现 APNG 的编解码。Chromium 为了支持 APNG 播放,只增加了不到 600 行代码我自己也用大概 500 行 C 代码实现了一个简单的 APNG 编解码工具。另外,在支持 canvas 的浏览器上,可以用 apng-canvas 直接显示 APNG 动画。APNG 压缩最好的工具目前是 apngasm,大部分图形化工具比如腾讯的 iSparta 都是基于这个工具开发的。

就目前而言, APNG 是 GIF 最好的替代了:实现简单,可用范围广,压缩比不错,显示效果好。

WebP

WebP 在 2010 年 发布时并没有支持动图。2012 年 libwebp v0.2 的时候,Google 才开始尝试支持动画,但其实现有很多问题,性能也非常差,以至于 Chrome 团队一直都没有接受。直到 2013 年,libwebp v0.4 时,动画格式才稳定下来才被 Chrome 所接受。

WebP 动图实际上是把多个单帧 WebP 数据简单打包到一个文件内,而并不是由单帧 WebP 扩展而来,以至于动图格式并不能向上兼容静态图。如果要支持动图,首先在编译 libwebp 时需要加上 demux 模块,解码 WebP 时需要先用 WebPDemuxer 尝试拆包,之后再把拆出来的单帧用 WebPDecode 解码。为了方便编译,我写了个脚本用于打包 iOS 的静态库,加入了 mux 和 demux 模块。

Google 提供了两个简单的命令行工具用于制作动图:gif2webp 能把 GIF 转换为 WebP, webpmux 能把多个 WebP 图片打包为动态图,并且有着很多参数可以调节。这两个工具对相近帧的压缩并不太理想,以至于有的情况下压缩比还不如 APNG,但除此以外也没有其他什么更好的工具可以用了。

BPG

BPG 本身是基于 HEVC (H.265) 视频编码的,其最开始设计时就考虑到了动图的实现。由于它充分利用了 HEVC 的高压缩比和视频编码的特性,其动图压缩比远超其他格式。这里这里有几张 BPG 动图示例,可以看到相同质量下 BPG 动图只有 APNG/WebP/GIF 几十分之一的大小。

我在这里写了个简单的利用 libbpg 解码动图的方法,如有需要可以参考下。

动图性能对比

我把下面这张 GIF 分别转为 WebP、APNG、BPG 动图,并在 iPhone 6 上对其所有帧进行解码。

gif_ermilio

评测结果如下:

anim_bench

APNG 在文件体积上比 GIF 略有优势,解码时间相差不多。WebP 在体积和解码时间上都具有较大的优势。BPG 在体积上优势最大,但解码时间也最长。这么看来,APNG 和 WebP 都是不错的选择,而 BPG 还有待性能优化。

最后做一个小广告:如果你是 iOS 平台的开发者,可以试试我开发的 YYWebImage,它支持 APNG、WebP、GIF 动图的异步加载与播放、编码与解码,支持渐进式图像加载,可以替代 SDWebImage、PINRemoteImage、FLAnimatedImage 等开源库。

WebP 探寻之路

不管是 PC 还是移动端,图片一直是流量大头,以苹果公司 Retina 产品为代表的高 PPI 屏对图片的质量提出了更高的要求,如何保证在图片的精细度不降低的前提下缩小图片体积,成为了一个有价值且值得探索的事情。

但如今对于 JPEG、PNG 和 GIF 这些图片格式的优化几乎已经达到了极致, 若想改变现状开辟新局面,便要有釜底抽薪的胆量和气魄,而 Google 给了我们一个新选择:WebP

对 WebP 的研究缘起于手机 QQ 原创表情商城,由于表情包体积较大,在 2G/3G 的网络环境下加载较慢。同事小贝恰好因为 2013 Google I/O Event 了解到了 WebP,于是我们便一起开始了没羞没躁的技术预研,期待在原创表情图片的质量与体积之间寻找最美的平衡。

2

今年 WebP 图片格式得到越来越多的关注,很多团队也开始布道,前阵子的前端圈“走进腾讯互娱前端技术专场”也有相关专题。借此热潮,在这里把上一年的探索过程以及今年 WebP 新的发展一同分享出来,同时也期待更多的人将其应用于实际业务中。

什么是 WebP?

WebP(发音 weppy,项目主页),是一种支持有损压缩和无损压缩的图片文件格式,派生自图像编码格式 VP8。根据 Google 的测试,无损压缩后的 WebP 比 PNG 文件少了 45% 的文件大小,即使这些 PNG 文件经过其他压缩工具压缩之后,WebP 还是可以减少 28% 的文件大小。

2010 年发布的 WebP 已经不算是新鲜事物了,在 Google 的明星产品如 Youtube、Gmail、Google Play 中都可以看到 WebP 的身影,而 Chrome 网上商店甚至已完全使用了 WebP。国外公司如 Facebook、ebay 和国内公司如腾讯、淘宝、美团等也早已尝鲜。目前 WebP 也在我厂很多的项目中得到应用,如腾讯新闻客户端、腾讯网、QQ空间等,同时也有一些针对 WebP 的图片格式转换工具,如 智图iSparta 等。

1

(Google 已和正在部署的 WebP 的产品)

可喜的是,直到今年,Google 对 WebP 依旧投入了持续的热情,2014 年的 Google I/O Event 中也出现了两个介绍 WebP 应用的视频。WebP 已大量应用于全球流量消耗最多的 Google 产品中,你还有理由拒绝它吗?

未标题-1

WebP 的优势

上面只是简单介绍了这种图片格式的背景和应用,不过 “talk is cheap”,这种格式优势在哪里?除了压缩效果极好,图片质量能否得到保障?这需要更理性客观的数据:

这里列举一个简单的测试:对比 PNG 原图、PNG 无损压缩、PNG 转 WebP(无损)、PNG 转 WebP(有损)的压缩效果。更多测试查看这里(请用 Chrome 浏览器打开)

Image2

可以得出结论:
  • PNG 转 WebP 的压缩率要高于 PNG 原图压缩率,同样支持有损与无损压缩
  • 转换后的 WebP 体积大幅减少,图片质量也得到保障(同时肉眼几乎无法看出差异)
  • 转换后的 WebP 支持 Alpha 透明和 24-bit 颜色数,不存在 PNG8 色彩不够丰富和在浏览器中可能会出现毛边的问题
 

WebP 的优势体现在它具有更优的图像数据压缩算法,能带来更小的图片体积,而且拥有肉眼识别无差异的图像质量;同时具备了无损和有损的压缩模式、Alpha 透明以及动画的特性,在 JPEG 和 PNG 上的转化效果都非常优秀、稳定和统一。

科技博客 Gig‍‍‍aOM 曾报道:YouTube 的视频略缩图采用 WebP 格式后,网页加载速度提升了 10%;谷歌的 Chrome 网上应用商店采用 WebP 格式图片后,每天可以节省几 TB 的带宽,页面平均加载时间大约减少 1/3;Google+ 移动应用采用 WebP 图片格式后,每天节省了 50TB 数据存储空间。

兼容性与可用性

现在问题来了:WebP 的支持度和兼容性如何?

根据对目前国内浏览器占比与 WebP 的兼容性分析,大约有 50% 以上的国内用户可以直接体验到 WebP,如果你的网站以图片为主,或者你的产品基于 Chromium 内核,建议体验尝试。假如你打算在 App 中使用 WebP,除了 Android4.0 以上提供的原生支持外,其他版本以及 iOS 都可以直接使用官方提供的解析库(AndroidiOS )。

为了验证 WebP 图片格式的业务可行性,我们从流畅度、解码耗时、CPU 使用、内存占用几个维度进行的分析,在开发同学们的帮助下得到了非常宝贵的测试数据:

测试一:AndroidQQ 下 PNG 和 WebP 各指标对比。
测试环境:AndroidQQ、Galaxy Nexus、Android4.2.2 系统
测试对象:WebP、PNG

测试数据(部分):

开发测试数据3

测试结论:
  • 解码耗时:WebP 的解码时间是 PNG 格式的 4.4 倍(24.8ms)
  • 流畅程度:两种格式下,AIO 滑动流畅度无明显差异
  • CPU使用:两种格式下,连续发送 15 个表情,CPU 使用均在 10%—26% 之间波动,两者无明显差异
  • 内存占用:两者格式下,连续发送 15 个表情,PSS 内存占用跨度均为 11M,无明显差异
测试二:iPhoneQQ 下 PNG 和 WebP 各指标对比。
测试环境:iPhoneQQ、iPhone4、iOS5.1.1 系统
测试对象:WebP、PNG

测试数据(部分):

开发测试数据2

测试结论
  • 解码耗时:WebP 的解码时间是 PNG 的 5 倍 左右(64.1ms)
  • 流畅程度:WebP 的 FPS 平均值会比 PNG 的平均值要小,但是比较稳定,跨度不大,性能也相差不大
  • CPU使用:总体上看,PNG 格式的表情使用 CPU 波动比较大。从平均值来看 WebP 格式表情占用的 CPU 会比 PNG 表情的占用率大
  • 内存占用:WebP 格式表情,占用内存的跨度为 4M,波动比较明显。PNG 格式表情,占用内存的跨度为 5M,没有明显波动。停止发送表情后,40s 左右内存均有回降

可见除了 WebP 在解码时间与 PNG 有较明显差异(毫秒级别)之外,总体使用体验和 PNG 基本无差异。同时也需要明确,移动设备的发展迅猛,硬件升级快,上一年的表现也许在今年又有了明显的提升。所以,在 App 中使用 WebP 基本没有技术阻碍。

对原创表情商城的技术指导

在验证了业务可行性之后,WebP 又激发了我们对另外一些方向的思考:既然它表现如此优秀,能否进一步摸清其“秉性”,得到一些能在未来使用中遵循的指导方案?

于是,为了更深入了解 WebP 特性,我们针对原创表情项目 “不同的表情图片,如何获得 WebP 的最佳压缩效率” 问题继续展开探究,主要从图片规格、色彩数(颜色数量)、参数配置几个维度进行:

探索一:图片规格

通过阅读文献了解到 WebP 使用的是 Fancy 采样算法,既然是采样算法必然有采样区块,而 JPEG 的采样区块是 8*8,对于原始图片的长宽不是 8 的倍数,都需要先补成 8 的倍数,使其能一块块的处理,所以对于 8 的整数倍的图片,压缩会更高效。

那么 WebP 的采样区块会是多少?我们在其他因素保持不变的前提下改变图片规格,选取了 200*200 附近多个规格值,得到了一些数据。将数据可视化之后可以看到凡是以 16*16 倍数(160*160、176*176、192*192、256*256)为规格的图片,有损压缩的比例都明显大于以 4*4 或 8*8 的倍数为规格的图片。

图片

结论:原创表情可以考虑使用 “16n*16n” 的规格。目前原创表情选择的是 200*200 的规格大小,实际上选择 256*256 或者 192*192 能获得更高的 WebP 压缩效率,量级在千分之几。

探索二:色彩数

在 JPEG 和 PNG 格式的选择经验上可以知道,对于色彩复杂的图片,一般使用 JPEG 格式,而对于色彩单一的图片,使用 PNG 格式。可见色彩数会影响图片的压缩效果。于是我们通过 Photoshop 中的色阶分离功能调整表情图片的色彩数,在其他因素保持不变的前提下对比不同色彩数对于 WebP 有损无损压缩的影响。

QQ20141207-2@2x

可见,在色彩数相对较少的前提下,无损压缩的效果要优于有损压缩;而色彩数很多时,有损压缩效果要优于无损压缩,这个分界点在 256±100 之间。

结论:建议原创表情尽量控制颜色数在 256 色以内,采用无损压缩性价比最高。
  • 小于 256 色:以图标,图形,剪贴画为代表,最适合采用 WebP 无损压缩,精细度完美,体积大幅减少;
  • 大于 256 色:以多数表情图,广告图为代表,最适合采用 WebP 有损压缩,选择较高压缩比(建议压缩质量为 100% ~ 75%)
  • 远大于 256 色:以风景照,视频截图为代表,最适合采用 WebP 有损压缩,选择适中压缩比(建议压缩质量为 75% 以下)

 

探索三:色温、渐变与杂色、直线与直线、描边

未标题-3

随后又从色温、渐变与杂色、直线曲线、是否需要描边上进行了分析,最后的结论即:

  • 色温并不会影响表情图片的压缩效果,可大胆用色
  • 渐变与杂色理论上都是增加色彩数,它的压缩规律从符合第二条,但建议表情图片少用渐变杂色和不必要的线条
  • 直线与曲线理论上也是增加了色彩数(因为曲线边缘会存在渐变),建议如果表情中可以“直”的地方就不要“弯”
  • WebP 格式的图片不会存在毛边问题,所以不需要为表情图片添加描边

 

探索四:压缩配置

为了得到无损压缩和有损压缩的最佳压缩配置,我们通过对 900 张表情图片进行不同压缩配置的测试(大部分表情图片的色彩数都在 256 色以上),得到下面的数据:

图片2

压缩参数说明:
  • -lossless:无损压缩
  • -q:压缩质量,值越大越图片质量越好
  • -m:压缩方式,值越大则图片质量越好,体积越小,但是耗时较长

可以发现,无损压缩表现很稳定,压缩质量越高,压缩效果也越好。而有损压缩在压缩质量设置为 75 以上之后,压缩效果反而减弱,甚至压缩后的图片体积会大于压缩前的体积。所以得出以下结论:

  • 选择无损压缩时,“-lossless -q 100” 是最佳方案
  • 选择有损压缩时,“-q 75”是最佳方案(图片质量与体积大小达到均衡)
  • 无论何种压缩参数,加上“-m 6”都能使得输出的 WebP 图片进一步减少体积,量级是1%~2%,但是会增加耗时

最终,得出了一个正反面案例,从技术角度分析不同的表情图标的优劣(强调一下是“技术角度”,这里列举的表情都很赞 ^_^)。

正反面

动态 WebP 初探

了解完静态 WebP,下面再了解一下动态 WebP(Animated WebP):2013 年 11 月 21 日,Animated WebP 终于取得进展,并在 Chrome32 Beta 中得到了支持。目前 Animated WebP 支持将 GIF 直接转换成 Animated WebP,或者将多张 WebP 图片组合成 Animated WebP。与传统的 GIF 图比较,Animated WebP 的优势在于:

  • 支持有损和无损压缩,并且可以合并有损和无损图片帧
  • 体积更小,GIF 转成有损 Animated WebP 后可以减小 64% 的体积,转成无损可以节省 19% 的体积
  • 颜色更丰富,支持 24-bit 的 RGB 颜色以及 8-bit 的 Alpha 透明通道(而 GIF 只支持 8-bit RGB 颜色以及 1-bit 的透明)
  • 添加了关键帧、metadata 等数据

假如你在使用 Chrome32 以上的浏览器,可以点这里体验

QQ截图20141212164455

但新兴的事物必然存在不足的地方,Animated WebP 存在的问题:
  • 消耗较多的 CPU 和解码时间(多 1.5~2.2 倍)
  • 和 GIF 相比起来支持度还不够,目前仍无法通用
  • 为了支持 Animated WebP,Chrome 的新内核 Blink 添加了近 1500 行的代码

根据自己实际的测试,发现 Animated WebP 的压缩效果较不稳定,在默认压缩配置下达不到 Google 官方提供的示例效果。但 Animated WebP 依然有很多值得期待的空间,值得继续关注。

综合技术方案

对于不同场景下 WebP 的使用,我们总结了一些解决方案,如下:

1、若使用场景是浏览器,可以:
  • JavaScript 能力检测,对支持 WebP 的用户输出 WebP 图片
  • 使用 WebP 支持插件:WebPJS
2、若使用场景是 App,可以:
  • Android 4.0 以下 WebP 解析库(链接
  • iOS WebP 解析库(链接
3、转换工具:

iSparta 是我们组针对 WebP 和 APNG 两种新型图片格式的转化而开发的一款桌面应用,直接图片批量转换为 WebP,同时提供多种参数配置,欢迎体验。

QQ截图20141215144504

参考文献

解决“数据错误,循环冗余检查”的问题

这种问题一般是某个文件或文件夹存储有下载技术的数据文件时,对磁盘产生了损坏。
此类文件无法删除。
解决方法是:
不用找问题病原文件。分下面2步操作即可:
1、右键问题磁盘-工具-磁盘碎片整理-这步不能解决问题,只是把磁盘数据整理的整齐些,提高下一步的速度和磁盘处理速度。
2、右键问题磁盘-工具-差错开始检查-两项都勾选。重启。doc模式自动检查。此类问题一般都可以修复。
开机会文件循环冗余问题解决,顽固文件可删。最重要的是文件夹切换速度加快了。

sublime,光标快速定位多行行头或行尾

经常用到sublime,我们都知道sublime支持多光标功能,就是按住ctrl键逐个点选,这样为我们提供了很大的方便。

QQ截图20170317143707

然而有时我们需要选择的点达几十条上百条时我们还是要点选太多了,也很麻烦。比如想在下面每行数据的前面或者后面添加内容的话,就要按住ctrl一个一个去点了,选好后再输入需要添加的内容。

QQ图片20170317143123

所以就有了一种新的方法可以快速定位纵多光标点。
1.选中所有需要光标点的内容  按下“Ctrl + Shift + L”,如下图,看到了没,每行的结尾都有了一个光标点,然后按住ctrl,同时按方向键移动光标到你所需要的位置。
1111

2.鼠标光标放在需要定位的起始位置,然后按住ctrl键,按住鼠标中键,记住是鼠标中键,一直往下拖,拖到你想要的位置就好了。

222