引用:

原帖由 meidle 于 2016-1-22 23:21 发表
posted by wap, platform: VIVO
他怎么知道谁得安慰奖谁抽到其他奖项，怎么提前刻字？

这个是微信老传统阳光普照奖人手一个的。不过确实没刻字，方便送人或买卖。

posted by wap, platform: Meizu Pro 5

引用:

原帖由 @para  于 2016-1-22 22:52 发表
说了一百遍了，都会压缩只不过是调用系统自己的压缩处理，偏偏ios的压缩比Android压缩的效果好一点而已。

同样一个头像，一张图，就微信压缩成马赛克，不说别家，QQ都很清楚的

posted by wap, platform: iPhone

引用:

原帖由 @pacman  于 2016-1-22 22:53 发表
我还以为电脑都换mac了。。。

微信前几年已经人手一台macbook发过了

posted by wap, platform: Galaxy Note III
好一点喷了      假如狗机是屎  猴机的微信视频连天天吃屎的屎壳郎拉的屎上面的细菌拉的屎都不如

posted by wap, platform: iPhone
上原麻衣什么鬼？上原亚衣吧

就不能在设置里加个压缩程度的选项嘛

压缩这事之前用Z1和狗6对比过，同一张照片分别发了以后用同一个机子再下下来，文件大小和实机效果基本一致。

引用:

原帖由 一个大叫驴 于 2016-1-23 00:21 发表
posted by wap, platform: Meizu Pro 5
同样一个头像，一张图，就微信压缩成马赛克，不说别家，QQ都很清楚的

可惜QQ和微信联系不大。

posted by wap, platform: Chrome
对于微信团队来说，iphone不是工作必须的吗？再抠门的搞移动互联网的公司也得给员工发iphone用来开发测试吧。

posted by wap, platform: VIVO

引用:

原帖由 @para  于 2016-1-22 22:52 发表
说了一百遍了，都会压缩只不过是调用系统自己的压缩处理，偏偏ios的压缩比Android压缩的效果好一点而已。

并不是。
ios发出来300kb的图，猴机发出来只有80kb
可想画质差别有多大。

posted by wap, platform: iPhone
iphone盒子真结实，罗那么多层……

posted by wap, platform: iPhone

引用:

原帖由 @zo  于 2016-1-24 03:08 发表
并不是。
ios发出来300kb的图，猴机发出来只有80kb
可想画质差别有多大。

悲剧了

引用:

原帖由 para 于 2016-1-22 10:52 PM 发表


说了一百遍了，都会压缩只不过是调用系统自己的压缩处理，偏偏ios的压缩比Android压缩的效果好一点而已。

怎么解释一样的图片QQ发出来比较清晰？QQ用自己的压缩？

posted by wap, platform: iPhone

引用:

原帖由 @para  于 2016-1-22 22:52 发表
说了一百遍了，都会压缩只不过是调用系统自己的压缩处理，偏偏ios的压缩比Android压缩的效果好一点而已。

放屁

引用:

原帖由 阳光运动帅 于 2016-1-24 23:11 发表
posted by wap, platform: iPhone
放屁

为什么微信android图片质量会比iphone的差？

我们团队最初也纠结过这个问题，费了半天劲、绕了好大圈，直到最后才发现，原来这是谷歌犯得一个“小”错误，而且一直错到了今天。
为什么微信android图片质量会比iphone的差？

谷歌的错就在于：libjpeg。

libjpeg是广泛使用的开源JPEG图像库(参考 http://en.wikipedia.org/wiki/Libjpeg )，安卓也依赖libjpeg来压缩图片。通过查看源码，我们会发现安卓并不是直接封装的libjpeg，而是基于了另一个叫Skia的开源项目(http://en.wikipedia.org/wiki/Skia_Graphics_Engine)来作为的图像处理引擎。Skia是谷歌自己维护着的一个大而全的引擎，各种图像处理功能均在其中予以实现，并且广泛的应用于谷歌自己和其它公司的产品中(如：Chrome、Firefox、Android等)。Skia对libjpeg进行了良好的封装，基于这个引擎可以很方便为操作系统、浏览器等开发图像处理功能。

libjpeg在压缩图像时，有一个参数叫optimize_coding，关于这个参数，libjpeg.doc有如下解释：

为什么微信android图片质量会比iphone的差？

这段话大概的意思就是如果设置optimize_coding为TRUE，将会使得压缩图像过程中基于图像数据计算哈弗曼表(关于图片压缩中的哈弗曼表，请自行查阅相关资料)，由于这个计算会显著消耗空间和时间，默认值被设置为FALSE。



这段解释乍看起来没有任何问题，libjpeg的代码也经受了十多年的考验，健壮而高效。但很多人忽略了这一点，那就是，这段解释是十多年前写的，对于当时的计算设备来说，空间和时间的消耗可能是显著的，但到今天，这似乎不应再是问题，相反，我们应该更多的考虑图片的品质(越来越好的显示技术)和图片的大小(越来越依赖于云服务)。

谷歌的Skia项目工程师们最终没有设置这个参数，optimize_coding在Skia中默认的等于了FALSE，这就意味着更差的图片质量和更大的图片文件，而压缩图片过程中所耗费的时间和空间其实反而是可以忽略不计的。那么，这个参数的影响究竟会有多大呢?

经我们实测，使用相同的原始图片，分别设置optimize_coding=TRUE和FALSE进行压缩，想达到接近的图片质量(用Photoshop放大到像素级逐块对比)，FALSE时的图片大小大约是TRUE时的5-10倍。换句话说，如果我们想在FALSE和TRUE时压缩成相同大小的JPEG图片，FALSE的品质将大大逊色于TRUE的(虽然品质很难量化，但我们不妨说成是差5-10倍)。

我们又对Android和iOS进行了对比(均使用标准的JPEG压缩方法)，两个系统都没有提供设置optimize_coding的接口(通过阅读源码，我们已经知道Android是FALSE，iOS不详)，当压缩相同的原始图片时，结果也是一样，iOS完胜。想要品质接近，文件大小就会差出5-10倍，而如果要压缩出相同大小的文件，Android的压缩品质简直就是惨不忍睹。

结果说明，苹果很清楚optimize_coding参数和哈弗曼表的意义，这里需要特别指出，苹果使用的哈弗曼表算法与libjpeg(及我们后来自行采用的libjpeg-turbo)不同，像素级可以看出区别，苹果似乎基于libjpeg又进行了进一步的优化，压缩出来的图片细节上更柔和、更平滑。

以上试验，我们尝试过多个原图、多种压缩比例，试验结果均类似，如有兴趣，您不妨也自行进行尝试。

最终我们决定，不再使用安卓系统原生的JPEG压缩方法，而是基于libjpeg-turbo自行编译了一版native的安卓库，专门用来压缩图片，这样在我们的产品中，就做到了仅仅用1/5的图片大小，就能让用户得到不逊色甚至更优的图片品质，对于我们团队来说，费了半天劲、绕了好大圈是非常值得的。(使用libjpeg-turbo还有性能上的好处，这里就不再赘述了)