Twitter对于有内嵌ICC profile PNG文件的处理乱象

最近换了新手机。前日在Twitter发手机截图的时候,一眼就注意到颜色不对(饱和度过低)。颜色不对的原因很显然:内嵌的色彩空间ICC profile没有正确处理。最近几年的手机基本都是广色域(Display P3为多),对于截图比较常见的处理方式是自动在截图的图片里加一个Display P3的ICC。iOS已经是这样很久,我之前的OnePlus手机并没有这么处理(而且我之前的手机截图直接就是JPEG,所以也不会有本文所述的问题),换了这个新手机才第一次在安卓端遇到。

对于使用非标准/默认sRGB的图片的处理方式大概有两种,一种是保留ICC,一种是转换为sRGB。前者最优但是向后兼容性有限,后者兼容性强。但是错误的方式是不转换(即保持像素点的原始RGB值)但是却丢掉ICC。这个具体的前文已经说过了就不赘述。显然,Twitter这里就犯了这样的错误。

但是这里有两点很难理解:第一,我用iPad上传截图从没遇到过这样的问题。前面已经说过iOS的截图也是用了Display P3的ICC。第二,我感觉Twitter的Media Team不应该这么菜。

推特的图片处理概述

既然说到2,那就得从当年Twitter对于图片上传处理的改版说起。推特原来是对于上传一切图片都二压的。从2019年12月起,改成了JPEG不二压(除非超大,见下述)。元数据自然是strip的,但是ICC profile保留。这里可以参见当年Media Team的dev发的推(注:此人已经跳槽到Meta。否则这次的问题还想at他反馈下呢)。PNG的话,则是一般都二压,除非:1) 转出来的JPEG比PNG还大、2) 图片特别小、3) 是palette(即所谓PNG8)、4) 有透明度等特殊情况。

这里有个日本网友总结的:

这个改动是非常好的,尤其是会对ICC进行保留这点。所以我想当然地认为,如果你上传PNG且被二压了,那么至少ICC是会保留的。结果居然不会?!

测试

OK,那为什么iPad就可以?这时候我脑子里大概已经确定了推特给了iOS特殊待遇,毕竟这种事情已经屡见不鲜了。不过到底是如何给的特殊待遇?我们得详细测试下。那么启动一个小号,开始大量上传测试。用Photshop制作一个Adobe RGB的PNG上传,丢失ICC,符合预测。用web上传一张iPad截图,咦,颜色怎么是正常的?看来特殊待遇不是在app端?那让我们把图片剪裁一下,再上传——咦,怎么又丢失ICC了?!难道我动到了什么元数据?不服,我用Exiftool把原始文件的metadata一字不漏的复制过来:

exiftool -TagsFromFile input.png "-all:all>all:all" output.png

怎么还是丢失?到这里我已经开始抓头发了。

不要急,让我们仔细对比一下两张图片的所有的技术细节区别——唔,看起来iPad的截图还挺可怕的,是用了16bit/ch(一般是8),而且有alpha通道[*]。转成8bit/ch的再上传,果然ICC又丢失了!难道是Twitter对于8bit和16bit的处理不同?那我们自己造一张16bit的图总可以了吧!咦,怎么还是丢失了,这……

[*] PNG支持alpha通道(约等于透明度)。但是注意,许多软件,例如Photoshop,在保存的时候,如果检测到你的alpha channel是全1(即全opaque,没有任何像素有任何透明度)的时候,会自动删除alpha通道。可以使用magick的

magick convert input.png -alpha on output.png

来强行开启alpha通道。

我反复地把不同图片的内容进行复制粘贴、缩小放大来上传,结果就是有时候行有时候不行。在我已经开始怀疑推特使用了什么heuristics来分析图片内容、又或者有奇怪的cache的时候,突然想到:咦,同样一张图8bit会丢失16bit不会,但是我自己制作的比较小的16bit却又不会,难道……和文件大小有关?想到上面规则里有的“JPEG不能超过5MB否则二压”,我于是制作了2张 PNG + display P3的图,一张小于5M 一张大于5M,然后上传……

真相大白。I’m speechless.

……但是还没完。我们把这两张图下下来对比一下。记得要下载原图,也就是

咦,似乎还有点奇怪?两张图的技术参数是完全一样的,都是85% quality的4:2:0的JPEG,符合上面二压的说法。但是两者其实都没有保留Display P3的ICC:正确的那张图,是正确转换到了sRGB,而且加了sRGB的ICC:

错误的那张则是和原来一样,是直接丢掉了原来的ICC,也没有内嵌新的ICC。

赶紧掏出iPad确认了下,果然是不一样的——用iPad上传,是保留了原始的ICC而非转换:

果然,iPad客户端还是有特殊待遇的。那么我们再多试几次,发现如下现象:

如果用iPad客户端上传,所有的PNG二压都会保留ICC——即使是小于5MB的。而且也不限于iPad截图,我把我自己造的AdobeRGB的图、以及Android截图用iPad上传,全都是正常保留ICC:

与之相反,Android就惨咯:用Android上传任意PNG都会丢失ICC,哪怕是在web端可以正确处理的>5MB的图:

那么如果上传会被二压的超大的JPEG,会怎么样呢?我以为会和PNG一样,结果还稍有不同:

iPad – 保留ICC; Android – 保留ICC; Web – 转换ICC为sRGB

区别在于,Android这次正常了。

总结一下:

InputiPad appAndroid appWeb
PNG, <5MBKeep ICCLose ICCLose ICC
PNG, >5MBKeep ICCLose ICCConvert ICC to sRGB
Large JPEGKeep ICCKeep ICCConvert ICC to sRGB
How ICC is processed when Twitter recompress the image

使用Twitter内置的裁剪功能的结果

另外一个有趣之处是使用Twitter内置的crop功能时的结果。我分别拿各种组合试了下,不赘述直接贴结果:

iPad:如果原图是sRGB或者无ICC,会产生一个无ICC的图片;如果原图是非sRGB(Display P3、Adobe RGB),会一律转换为Display P3(含ICC)

Android:保留原图ICC。注意这里profile并不是直接copy,而是会用一套谷歌的equivalent的ICC,比如如果原图是苹果的Display P3:

会变成谷歌的:

如果原图是Adobe RGB:

同样会变成谷歌家的:

但是颜色都是一样的/对的。

另外一个小插曲:

用 Android Twitter打开修图时,会看到在filter等功能时图片的预览明显颜色是错误的(丢失ICC)(左),但是在crop的页面却正确(右):

如果试图打开那张10M的iPad截图,就更草了,filter直接无法处理(应该是凡是用了iPad这个color profile的都会有问题:我把这图用PS改小了点照样不行)(左),但是同样,crop是工作的(右):

估计是调用了不同的系统接口吧。

Web的话,则是无脑(无论图片大小、格式)调用上面提到过的PNG>5MB时的编码器,产出(正确转换的)sRGB的图(含ICC)。

总结如下:

InputiPad appAndroid appWeb
sRGB or no ICCNo ICCsRGB ICCsRGB ICC
Other ICCsConvert to Display P3Use Google equivalent ICCConvert to sRGB

结语

从上面的一些现象可以大概猜到,很多东西应该也不是Twitter自己写的,而是调用了系统的图形接口,所以这个问题也不能完全甩锅给Twitter;但是至少我们知道,如果他们用心,至少完全是可以做到正确转换/保留ICC的,所以在安卓端上传PNG会完全丢失ICC的问题还是要推特背锅。

这里不得不顺便提一个很让人frustrated的问题:对于这种大型服务,通常完全没有任何顺畅反馈的通道。比如Twitter的客服,基本只会处理账号和内容相关的问题,凡是任何技术问题,反馈就如同对牛弹琴。Twitter另有面向dev的渠道,但是严格只回答和API相关的问题——如果只是“使用”上的技术问题,他们是不管的。如果没有在Twitter上班的朋友,几乎没有任何办法传达到相关人士耳中。之前有人劝我,别白费功夫了,他们不care;但是我想反馈也不是单纯为了帮他们改善产品,而是这种问题切实地影响到了我个人的用户体验。(耸肩)

ReplayGain在UPnP media server中的应用和补遗

UPnP media server是个挺有用的东西。在PC端配合一个功能非常全面的foobar2000插件——foo_upnp,安卓端配合foobar2000 Mobile或是BubbleUPnP,即可轻松实现包括但不限:用手机播放电脑里的媒体库,用手机当电脑的音响用(呃延迟没测过,估计只够听歌),用手机控制电脑播放器,以及前面的全部反过来控制等功能。当然,最理想的情况是把media server设在诸如NAS之类的设备上,但是就我个人来说,最常用的应用场景是躺在床上耳机插手机听电脑的媒体库/播放列表。

既然前一段时间折腾了那么就RG,这也得用上不是。让我们先仔细研究一下foobar2000那边的server的profile设置。

qq%e5%9b%be%e7%89%8720170220192532

另外为了便于测试,将Basic Settings里设成始终使用默认profile和关闭增加兼容性的额外流:

qq%e6%88%aa%e5%9b%be20170220193855

可以看到大抵来说,有这么几种streaming的方案:源文件直出,转码为MP3,解码为WAV。

直出最好理解,就是在http上host对应的文件而已。直出可以保有原始文件的所有metatag,自然也就包括RG信息;这样,在移动端使用支持RG的客户端时(这里就是foobar2000 mobile了),就会读取到信息进行响度调整。

但是直出的局限性非常大。foobar2000 mobile支持的格式非常有限。TAK这种就不用说了,自然也不支持任何音频文件+cue的类型。不过倒也不会播不了,只是sever会自动无条件帮你转成WAV。最吊诡的是,像FLAC这种明明是支持的格式(即,你把歌曲拷贝到手机里是能放的),有时候会在foobar2k mobile那边出现播放列表里完全看不到的现象(不能稳定重现。与之相对,第三方的BubbleUPnP则很稳定不会有这个问题)。

既然直出这条路不行,那就只能转码或者解码了。介于局域网带宽对于音频来说完全不是问题,自然选择音质更好的WAV,也避免了二次压缩的问题。不过,转码/解码之后有一个问题,就是RG信息完全丢失。哪怕是转码成MP3也是一样。还好,在下面那个Audio processing里,和Converter(转码器)一样,可以设置转码/解码时的处理。注意这里既然叫processing那自然是硬编码进去,而不是靠RG信息。所以foobar2000 mobile端会识别成无RG信息,调整那边相应的RG设置时要注意(我则是完全关闭)。

哦从图中可以看到,你可以设置规则对不同文件类型设置不同的转码规则(例如有些转,有些直出等等)。但是没啥卵用,因为你一旦开启了processing,所有的都会被强制转一遍mp3/WAV,所以还是死了这条心。

这里又是和上一篇文章中提到的普通用电脑回放时一样,面对一个抉择:是选择全部降低到和RG目标响度一样的响度(即:较低的响度),还是全部增益到和“新歌”一致的一个比较高的响度。这里还是选择了前者,因为毕竟那样对音质的保存是最完整的,而且主要用耳机听歌的话也不用担心有输出不足的问题。具体来说,就是在Processing里开启apply RG,同时对无RG信息的歌曲(主要是响度大的新歌)加个-9.5 dB的pre-amp。如果还不放心可以再加个Advanced limiter(虽然99%的情况根本不会有任何区别),但是介于Advanced limiter目前有个会把1缩成0.9999的bug,还是别了罢。

当然这种选择下就会有一个问题,那就是和我手机里那些已经转换好的、响度和新歌一个水平的音频文件有冲突。而且因为两者都是无RG信息,也无法靠调整手机端的RG设置中pre-amp来弥补。不过还好我一般其他场合听歌是用Google Music而不是foobar2000 mobile,以后就用fb2k mobile专门听媒体库就是。

多说一句,客户端那边选用foobar2000 mobile而不是BubbleUPnP的原因倒不是fb2k mobile支持RG(毕竟在我的最终配置下也用不到),主要还是foobar2000 mobile支持手机端的last.fm统计插件,虽然BubbleUPnP的界面大概好一万倍(电脑的foobar我觉得还行了,手机那个真的是丑的惨绝人寰)。另外,BubbleUPnP有个很烦的地方就是每次我修改服务器端(我电脑)的UPnP设置那边就必须会自动切断连接,也就是退出所有的远程playlist啥的,我还得重新选,在测试的时候尤其烦。而foobar2000 mobile则是另外一个极端……不但不会断,他还会缓存一部分媒体的地址(其实就是个URL,可以在电脑端或手机端的console里看到),也就是说我切换了设置之后有时候得在那边强制退出一次来让他刷新URL(服务器端这边即使你修改了设置,老设置的URL实际上还是并没有禁用的,依然有效)和播放列表。

screenshot_20170220-193326
客户端(foobar2000 mobile)读取流媒体的log范例

UPnP媒体库播放的响度规格化这事儿到此也就告一段落了。不过,我又回头去想在移动设备播放歌曲的workflow能否有可优化的地方。

如前文所述,我目前在移动设备采用的是“新歌不变,老歌先RG再+9.5dB”的方案,原因是因为这样兼容性最好,对没有RG支持的播放器也能完美播放,而且不会有输出太低的问题(我手机插车上听,即使在这种设置下都几乎要开到最大音量才行了,如果全部都低9.5dB那可调整的余地就太小了)。当然最大的问题就是+9.5dB导致的超过full scale引起的削波问题。

解决方案上次也说过,就是在转换时再用DSP加一层Advanced limiter,把超出的部分动态调整到1以下。不过由于犹豫会对音乐的完美呈现造成影响(毕竟还是部分压缩了动态范围)我之前一直没用。不过最近遇到这么一首歌,一下子就听出削波的问题了(下载链接):

废话一下,歌曲是菊池桃子的「卒業 -GRADUATION-」,个人的五星歌曲。算是无数好听的叫“卒业”的歌曲之一(其他的还有尾崎豊的,斉藤由貴等等)。菊池桃子天使般的声线在这歌里得到完美的体现。咳跑题了。

这歌的问题在于动态范围极大,在我的传统转换设置下,自然会溢出full scale很多,事实上,其peak达到了1.40(+2.93 dBFS)之高。从1:00左右开始,就会疯狂爆音,用手机+耳机听时最明显。因此,Advanced limiter就是非常必要的了。我对比了下开启Advanced limiter的版本和原版,完全听不出区别(毕竟音量大于1的部分只是极小的spike,频段可能更不是人耳敏感的部分),可见这个limiter的效果比起一般的动态压缩要好得多,也解除了我之前的一大顾虑。

不过在研究过程中我发现一个有趣的事实:AAC(m4a)这个格式居然可以保存大于1的数值!也就是说,我上面发这个+过9.5dB的音频文件,其实并没有损失任何信息或者削波——超过FS的1.4的peak也完整地记录在了音频中。这说明了什么呢?如果你的播放流程在输送到DAC之前有足够的衰减处理(例如软件中的波形层面的音量降低,但包含音响上的Analog的音量旋钮),又或者你的DAC/Analog设备足够专业,留有headroom支持超过1的波形,其实并不会产生削波/爆音。对应到电脑,foobar2000里的volume就是个不错的例子(但是别忘了上文提到的Win7的自带的limiter适用过早的bug,所以避免);对应手机端,根据我的观察,至少安卓系统的音量是不行的(不过安卓的音频处理一直都臭名昭著):如果仅仅靠调整系统的媒体音量,该爆音的还是爆(不清楚安卓的系统音量具体原理是数字上衰减波形还是模拟级)。不过,foobar2000 mobile中有个单独的volume设置,通过那个,或者里面带的RG设置的pre-amp,可以做到同响度情况下(即先用foobar2000 mobile的音量降低几个dB,再在系统音量里稍微开大一点达到同样响度)完美无爆音播放上面那个m4a文件。

不过这个用起来其实也有颇多不便:第一个不便是foobar2000 mobile的音量设置……他有bug。每次切歌,音量就会回归到0dB,即使界面里显示的还是你的设置。另外还是上面说的问题了,如果你降了几个dB,那输出不够这老问题又来了。所以,我最终还是经过权衡选择了转换时选择高响度水平+Advanced limiter的方案。当然还有第三个方案:转换时不加Advanced limiter(利用m4a的特性保留超过1的数值),但在播放时靠foobar2000 mobile自带的DSP即时加。这样可以最大限度保存动态范围,以后这些mp4拷贝到电脑上听时还可以还原。我现在还在想要不要全面转成这样——因为如果这么做,就表示了我就锁死只能用foobar2000 mobile当手机播放器了,这方面有点犹豫。

前面说了AAC(m4a)可以保存高于full scale的数值,那相对地WAV、FLAC和APE就不行了,如果你转换过程中增益到超过1,最终出来的文件会被削波到1。当然FLAC/APE之类的是为了完美呈现WAV而故意这么设置的吧,大概。MP3则比较奇怪,还是上面那个歌,转换之后会出来个peak为1.075的玩意…大概和MP3算法有关吧。另外每个的平均响度也会细微的差别,理论上来讲很自然AAC会高一些(毕竟没削波),虽然差别很小就是了。

qq%e6%88%aa%e5%9b%be20170221233307
利用RG扫描来查看peak和平均响度。因为Gain是负值,所以绝对值越大说明响度越大。音频全部通过原始wav文件+硬编码进(RG+增益9.5dB)的方式逐一生成

所以很显然地,如果你是转成了FLAC之类的已经会直接削波的格式,即使上面那个很复杂的操作也没法拯救你这音频了,怎么放都会爆音,万万要避免。

嗯,最后附一个几种流程的图示吧。三脚猫ps功夫不要笑话(点击大图)。

blog.png

上面的是最终响度=RG目标响度的workflow,优点是基本无损,缺点是输出比较低。目前我在电脑和UPnP媒体库输送到手机两种回放方式时使用。可以看到新歌直接降低-9.5dB(图里写成9了…),老歌直接RG,两者会获得一个相对一致的响度,同时不破坏老歌的动态范围。注意这里的-9.5dB和RG都是纯粹回放时加的,原始音频是不经过修改的。

下面的是方法2,即最终响度=新歌平均响度的workflow。我在转换歌曲到单独m4a文件时使用此方法。优点是兼容性强,和大多数市面上现成的歌曲文件响度一致;缺点自然是对于高动态的老歌峰值会溢出。为了防止削波,如果是即时回放或转换成支持超过FS的格式(AAC/m4a)时,可以通过再加个digital音量调整拯救(这种情况下就依然无损动态范围),或者如图所示干脆直接最后加个可选的Advance limiter进去(可以是转换时的硬编码,可以是回放的DSP)。对于不支持超过FS的音频格式,这大概是唯一可以接受的转换方案)。

安卓4.3之后的位置服务导致的电池问题

前一段AT&T终于推送了4.3,于是就升级了,而之前我还在用4.1——AT&T把4.2直接给跳过了。升级之后系统总体变化不大,但是反而出现一个非常烦人的问题,电池消耗特别快。经过在Xda、Android Central等著名安卓论坛的一番搜索,可以发现4.3之后出现battery drain问题是一个非常常见的现象。而且遇到问题的用户并不局限于HTC,包括nexus 4的官方系统在内都有很多人遇到了此问题。经过一番研究,可以发现罪魁祸首是位置服务。以下是整个问题的详细分析以及(暂时性地)解决方案。

问题原因:网络Location服务唤醒次数过多,导致电池高速消耗。

检测方式:检测wakelock次数,通过Wakelock Detector或BetterBatteryStats可以轻松实现。如果发现NLPwakelock以及NLPcollecterwakelock在唤醒次数以及时间中占了大量的比例(注意:基于Location服务的特性,其唤醒次数高于其他App是正常的。在BetterBatteryStats的统计中,NLPwakelock的比例小于2%可以视为正常。高于4%则可视为异常),那么可以确定你也遇到了此问题。

解决方案:修改位置服务的设置。位置服务有以下几个设置(本人使用英文系统,故只能提供英文关键词,中文类似):

  1. Wifi & Mobile network location
    位于Settings->Location下。关闭可以解决问题,但是之后你的所有应用程序都无法访问位置,严重影响体验,不建议。
  2. Let Google apps access your location
    同样位于位于Settings->Location下,等同于Google Settings->Location中的”Access location”。关闭可以解决问题,但是关闭后所有google服务无法获取位置,比如当你用Chrome访问google.com就会提示你无法获取位置,另外会导致Google now的大多数feature无法正常运作。影响体验,不建议。如果关闭它,NLPwakelock可以降低到一个几乎不唤醒系统的地步,如果你完全不需要google服务,那么可以关闭它来省电。
  3. Location Reporting & Location history
    此设置Google Settings->Location中的”Access location”账号名称下方。后者无影响,前者是真正的罪魁祸首。只要关闭它,NLPwakelock的唤醒比例(基于BetterBatteryStats的统计,下同)可以下降到一个非常合理的数值(5.x%–>1.x%),同时副作用很小(实话说我根本不知道关闭它有什么影响…)。

其他解决方案:Xda很多人汇报,通过删除系统组件Google Play Service以及Maps并手动重新安装,可以在不修改以上任何设置的情况下解决此问题。本人没有Root,无法测试。

底层原因猜想:虽然这是一个非常常见的安卓4.3之后的电量问题,但是并不是所有人都会遇到。而且上面那个“其他解决方案”也给人一种感觉,这个问题可能并不是4.3内在的一个固有bug。在这贴中你可以发现,此人遇到的nlpwakelock耗电问题是因为他的XPrivacy导致的。所以有一定的可能,导致nlpwakelock或者说google services中的location服务耗电的真实原因是某些其他程序不断地调用位置服务而造成。比如一个很可能的原因就是Maps。可惜我没有Root,无法查看log,所以没法确定。Root后的用户可以随便装一个log软件比如LogCat查看log看看到底是什么东西在不断地用location。

附录:电池软件比较

其实我最开始并不是先发现了电池耗电过快,而是发现系统自带的电量统计让我大跌眼镜——android system居然耗掉了90%的电量,直接导致很多程序的用电量小到根本看不见了,而在4.1的时候从来没出现过这样的情况。后来装了GSam Battery Monitor,显示的结果就好很多。另外为了监视wakelock次数,还装了BetterBatteryStats(BBS)和Wakelock Detector(WLD),这里一并比较一下这几款软件之间的区别。

首先,我们应该先搞清楚Wakelock和耗电的区别。Wakelock是指会唤醒设备,自然,设备被唤醒的次数越多,耗电也就越多。但是并不是一个唤醒次数最多的进程,就一定耗电最多——耗电和CPU time才是直接联系。CPU time越多,耗电越多。唤醒只是一个会导致CPU time增加,间接地导致耗电增加的玩意——当然,在待机的情况下,可能是主因。BBS和WLD实际上只能统计wakelock次数和时间,并不能统计真正的耗电;只有Gsam可以显示耗电比例。另外,不同APP对进程的分类也有一定的区别——这里主要体现在系统自带的Power和GSam的区别里。

让我们先对比下系统自带的Power和Gsam:

Screenshot_2013-10-20-17-56-49 Screenshot_2013-10-20-17-57-02 Screenshot_2013-10-20-17-57-12

可以明显感觉到,系统自带的这个一定有什么问题——屏幕耗电的5.4%他居然完全给忽略了,这明显不正常。但是我在网上看贴的时候发现别的人尤其是Nexus 4没有这个问题(其实我4.1的时候也没有这个问题),所以我强烈怀疑是HTC的定制ROM在4.3里把这玩意给搞糟了。另外可以看到两者对QQ的统计的差异——QQ在后者显示耗电7.8%,高于Google services,而前者却直接没有QQ(意味着小于1%)——从道理上可以看出前者更科学一点。我的猜测是QQ耗电里的Wakelock Detail中有个Alearmmanager被自带的算进Android System或者Google Services里去了。另外Kernel (Android OS)啊、HTC啊System UI等等在自带的里面被算进Android System里去了这点应该没有疑问。

那么既然我们觉得Gsam比较靠谱,就详细看看他的各项:

Screenshot_2013-10-20-17-57-19 Screenshot_2013-10-20-17-57-33 Screenshot_2013-10-20-17-57-54

分别是CPU Mnites,Held Awake、Number Times Waking Devices。可以看出,CPU Minites的分布和Power Used基本完全一致。至于Held Awake,在你非待机(操作手机时)全部算进了Kernel里,其他的才是真正意义上的待机唤醒——在接下来讲BBS和WLD时就知道,这两款是会把Kernel和其他的分开统计的。最后一个比较有意思,应该是GSam的独有功能,叫做“唤醒设备的次数”——注意这个并不等于“Wake Lock次数”。这个统计是BBS和WLD都不提供的,但是从直观上理解,是否这个数字应该比Wake Lock次数更有意义呢?另外,GSam也是提供Wake Lock次数统计的,只是要点开每个项目里面才有,并不提供对此排序。

那么接下来让我们看看专精WakeLock统计的BBS和WLD。

Screenshot_2013-10-20-17-58-02 Screenshot_2013-10-20-17-58-08 Screenshot_2013-10-20-17-58-14

注意,因为BBS是自己统计而不是调用系统数据,所以现在他的结果只能从Boot起开始算起而不是Last charged(因为我中间重启了一次手机),所以数字上和WLD和GSam的略有不同。第一幅图是总体统计wake time和sleep time。注意有个每小时耗电统计,非常实用。我现在是每小时不到2%(大部分时间待机),已经算是可以接受了。顺便一提,如果完全关闭Location改服务,可以达到0.x%/h的纯待机。第二张图是大家最关心的Partial Wakelock——前面提过了,Kernel的Wakelock因为我们不关心,被单独分到Kernel Wakelock里去了,这里就不截图了。这里可以看到,NLP相关的依然占有最高的WakeLock次数…不过两者相加也只有2%的比例,算是可以接受。WLD的CPU Wakelock其实和BBS的是一致的(注意Kernel的也是单独的一个分类,没在这里面;另外还有Screen wakelock啥的统计不过没啥用),只是他把所有的进程按照App分类了(点开App可以看到具体的Process),只能按照App排序而不能按照Process排序,两者算是各有利弊吧。顺便一提,BBS支持设定统计起点/终点,这点非常方便。别的几款软件就只能充电才能重置参考点了——当然别的我都用的免费版,BBS用的0元收费版囧。orz,今天才发现GSam也有参考点设置的功能!

Screenshot_2013-10-20-18-02-06 Screenshot_2013-10-20-18-02-14

最后来两张系统自带的的详情。这个里面的数字(CPU、 Awake time)倒是和GSam等同步了,但是你不到5分钟的CPU用了75%的电是闹哪样啦www