妈的什么时候能显示16g tlc 三爽U 阴阳尿屏电池冬天尿崩的粉木耳6s在线啊！ 
原帖由 @532 于 2016-1-22 17:08 发表
原帖由 @elia 于 2016-1-22 17:25 发表
微信的人本来就用苹果，不然为什么苹果的朋友圈比安卓的清楚？
原帖由 @一个大叫驴 于 2016-1-22 17:46 发表
他妈逼的意思是猴机上传图片会压缩的事情近期不会修复了？
原帖由 colaaz 于 2016-1-22 18:40 发表
posted by wap, platform: iPhone
下次谁跟你说果机不压缩图片的，请帮我大力呼他一脸。
原帖由 @一个大叫驴 于 2016-1-22 18:50 发表
你们狗机传个500*500px的头像会模糊么？问一下
原帖由 约翰法雷尔 于 2016-1-22 19:16 发表
posted by wap, platform: iPhone
前面一楼一楼酸过来真好玩
表示手上有ipad专发带图的朋友圈 原帖由 红叶 于 2016-1-22 17:59 发表
posted by wap, platform: Android
猴机都是小米之流 修复个毛啊
原帖由 一个大叫驴 于 2016-1-22 17:46 发表
他妈逼的意思是猴机上传图片会压缩的事情近期不会修复了？
原帖由 @yaoyuef 于 2016-1-22 18:55 发表
微信从诞生开始就是果粉队……
这奖品挺正常啊，并且通常刻了名字不好转手
原帖由 meidle 于 2016-1-22 23:21 发表
posted by wap, platform: VIVO
他怎么知道谁得安慰奖谁抽到其他奖项，怎么提前刻字？
原帖由 @para 于 2016-1-22 22:52 发表
说了一百遍了，都会压缩只不过是调用系统自己的压缩处理，偏偏ios的压缩比Android压缩的效果好一点而已。
原帖由 @pacman 于 2016-1-22 22:53 发表
我还以为电脑都换mac了。。。
原帖由 一个大叫驴 于 2016-1-23 00:21 发表
posted by wap, platform: Meizu Pro 5
同样一个头像，一张图，就微信压缩成马赛克，不说别家，QQ都很清楚的
原帖由 @para 于 2016-1-22 22:52 发表
说了一百遍了，都会压缩只不过是调用系统自己的压缩处理，偏偏ios的压缩比Android压缩的效果好一点而已。
原帖由 @zo 于 2016-1-24 03:08 发表
并不是。
ios发出来300kb的图，猴机发出来只有80kb
可想画质差别有多大。
原帖由 para 于 2016-1-22 10:52 PM 发表
说了一百遍了，都会压缩只不过是调用系统自己的压缩处理，偏偏ios的压缩比Android压缩的效果好一点而已。
原帖由 @para 于 2016-1-22 22:52 发表
说了一百遍了，都会压缩只不过是调用系统自己的压缩处理，偏偏ios的压缩比Android压缩的效果好一点而已。
原帖由 阳光运动帅 于 2016-1-24 23:11 发表
posted by wap, platform: iPhone
放屁
原帖由 @para 于 2016-1-25 00:01 发表
为什么微信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。
http://files.jb51.net/file_images/article/201408/201408291059166.jpg
这段解释乍看起来没有任何问题，libjpeg的代码也经受了十多年的考验，健壮而高效。但很多人忽略了这一点，那就是，这段解释是十多年前写的，对于当时的计算设备来说，空间和时间的消耗可能是显著的，但到今天，这似乎不应再是问题，相反，我们应该更多的考虑图片的品质(越来越好的显示技术)和图片的大小(越来越依赖于云服务)。
谷歌的Skia项目工程师们最终没有设置这个参数，optimize_coding在Skia中默认的等于了FALSE，这就意味着更差的图片质量和更大的图片文件，而压缩图片过程中所耗费的时间和空间其实反而是可以忽略不计的。那么，这个参数的影响究竟会有多大呢?
经我们实测，使用相同的原始图片，分别设置optimize_coding=TRUE和FALSE进行压缩，想达到接近的图片质量(用Photoshop放大到像素级逐块对比)，FALSE时的图片大小大约是TRUE时的510倍。换句话说，如果我们想在FALSE和TRUE时压缩成相同大小的JPEG图片，FALSE的品质将大大逊色于TRUE的(虽然品质很难量化，但我们不妨说成是差510 ...
原帖由 @para 于 2016-1-24 04:01 发表
为什么微信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。
http://files.jb51.net/file_images/article/201408/201408291059166.jpg
这段解释乍看起来没有任何问题，libjpeg的代码也经受了十多年的考验，健壮而高效。但很多人忽略了这一点，那就是，这段解释是十多年前写的，对于当时的计算设备来说，空间和时间的消耗可能是显著的，但到今天，这似乎不应再是问题，相反，我们应该更多的考虑图片的品质(越来越好的显示技术)和图片的大小(越来越依赖于云服务)。
谷歌的Skia项目工程师们最终没有设置这个参数，optimize_coding在Skia中默认的等于了FALSE，这就意味着更差的图片质量和更大的图片文件，而压缩图片过程中所耗费的时间和空间其实反而是可以忽略不计的。那么，这个参数的影响究竟会有多大呢?
经我们实测，使用相同的原始图片，分别设置optimize_coding=TRUE和FALSE进行压缩，想达到接近的图片质量(用Photoshop放大到像素级逐块对比)，FALSE时的图片大小大约是TRUE时的510倍。换句话说，如果我们想在FALSE和TRUE时压缩成相同大小的JPEG图片，FALSE的品质将大大逊色于TRUE的(虽然品质很难量化，但我们不妨说成是差510 ...
原帖由 @para 于 2016-1-25 00:01 发表
为什么微信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。
http://files.jb51.net/file_images/article/201408/201408291059166.jpg
这段解释乍看起来没有任何问题，libjpeg的代码也经受了十多年的考验，健壮而高效。但很多人忽略了这一点，那就是，这段解释是十多年前写的，对于当时的计算设备来说，空间和时间的消耗可能是显著的，但到今天，这似乎不应再是问题，相反，我们应该更多的考虑图片的品质(越来越好的显示技术)和图片的大小(越来越依赖于云服务)。
谷歌的Skia项目工程师们最终没有设置这个参数，optimize_coding在Skia中默认的等于了FALSE，这就意味着更差的图片质量和更大的图片文件，而压缩图片过程中所耗费的时间和空间其实反而是可以忽略不计的。那么，这个参数的影响究竟会有多大呢?
经我们实测，使用相同的原始图片，分别设置optimize_coding=TRUE和FALSE进行压缩，想达到接近的图片质量(用Photoshop放大到像素级逐块对比)，FALSE时的图片大小大约是TRUE时的510倍。换句话说，如果我们想在FALSE和TRUE时压缩成相同大小的JPEG图片，FALSE的品质将大大逊色于TRUE的(虽然品质很难量化，但我们不妨说成是差510 ...
原帖由 jun4rui 于 2016-1-25 09:51 发表
posted by wap, platform: 小米 NOTE
假的啦，微信自带浏览器连CSS3动画效果都会给你忽略掉很多，别的浏览器平滑的动画效果在微信浏览器里面压根就没有直接跳过去了！
而且这小组粗心到连开发文档的demo页面都有很 ...
原帖由 阳光运动帅 于 2016-1-25 10:16 发表
posted by wap, platform: iPhone
别自己骗自己了。这种肉眼就能一眼发现的严重Bug你和我说谷歌几年了都没修复？
既然谷歌没修复，又知道问题所在，微信几年了，也没像你文章中说的自己修复？
这明显就是一个人为的 ...
原帖由 @para 于 2016-1-24 14:35 发表
人家懒得做吧,有种你们别用^,等心情好了再改.
原帖由 para 于 2016-1-25 12:01 AM 发表
为什么微信android图片质量会比iphone的差？
我们团队最初也纠结过这个问题，费了半天劲、绕了好大圈，直到最后才发现，原来这是谷歌犯得一个“小”错误，而且一直错到了今天。
为什么微信android图片质量会 ...
原帖由 solbadguy 于 2016-1-25 13:37 发表
老文了，而且“这样在我们的产品中，就做到了仅仅用1/5的图片大小，就能让用户得到不逊色甚至更优的图片品质”，趴在地上仔细想想，有这技术JPEG标准早被推翻了，你觉得可能吗？
原帖由 @para 于 2016-1-25 17:43 发表
https://github.com/bither/bither ... ob/master/REASON.md
原文可能翻译有问题吧,说是facebook和twitter的Android端图片比ios差
原帖由 @jun4rui 于 2016-1-25 10:54 发表
这种大公司的牛逼产品真的操蛋极了！
而且微信妈比自带浏览器还没办法清理缓存的，而且缓存非常厉害，经常页面改了很久还不刷新，只能把自家公众号取消关注，再重新关注，这样才能看到页面刷新。
好吧，你缓存牛逼要是真可以让页面加载速度提升也就罢了，问题是加载速度几乎是主流业内最慢的，你这牛逼的缓存干嘛去了？！！！
好吧，你这狗日的浏览器烂连HTML5+CSS3的支持都不完整也就算了，你这iOS版的自带浏览器内核和Android还不同，一段在主流Chrome、Android浏览器跑得OK的代码，在iOS上跑解释结果和别的浏览器不一样，没办法调试搞得工程师累得死才发现这个问题，只能针对iOS版机型单独的适配。
还有最令人发指的不支持put/patch/delete等请求，这些都是HTTP标准的好吗？我当年知道后简直想捶地板了！
这里还有别人整理的51条腾讯内核浏览器问题汇总，比较大的包括：Android下特有的15条单列算1条，不支持Blur滤镜，不支持ShadowBlur效果，完全不会清理Cookie且不能大于4k，canvas有限制，webgl不完善，不支持web audio api，svg有问题，flexbox正在开发，不支持wss和webrtc，播放音效的话BGM会暂停，多音频会卡住甚至无法播放，一些常用库会非常卡
不过人家号称是独立开发的浏览器内核，所以这个不行、那个不行你们就忍忍吧，这个我们是独立开发的内核哦哈哈哈哈（妈比你给我滚！）
就这烂货，还专门上过新闻说Chrome再现安全漏洞，腾讯X5浏览器内核彰显优势，什么互联网急速上网体验，提供云服务优化引擎之类的，完全就他妈的是个烂货！烂货！烂货！！！
原帖由 jun4rui 于 2016-1-26 14:04 发表
posted by wap, platform: Chrome
说的是libjpeg因为代码太古老了，以前的机器内存和CPU都不咋地，所以默认参数很保守，而谷歌负责做图片压缩处理的Skia封装了libjpeg的方法但是没有给出设置参数的方法，导致只能用默 ...
原帖由 @para 于 2016-1-25 20:28 发表
我的意思就是微信团队懒的搞,用默认的,偏偏默认ios比android做得好一点呗...
其实也很奇怪,这么个免费app,大家也不捧一个跟它占有率旗鼓相当的出来,非得拼命用它,那人家当仁不让就是垄断之后爱做不做不用就滚呗...
原帖由 @jun4rui 于 2016-1-25 10:54 发表
这种大公司的牛逼产品真的操蛋极了！
而且微信妈比自带浏览器还没办法清理缓存的，而且缓存非常厉害，经常页面改了很久还不刷新，只能把自家公众号取消关注，再重新关注，这样才能看到页面刷新。
好吧，你缓存牛逼要是真可以让页面加载速度提升也就罢了，问题是加载速度几乎是主流业内最慢的，你这牛逼的缓存干嘛去了？！！！
好吧，你这狗日的浏览器烂连HTML5+CSS3的支持都不完整也就算了，你这iOS版的自带浏览器内核和Android还不同，一段在主流Chrome、Android浏览器跑得OK的代码，在iOS上跑解释结果和别的浏览器不一样，没办法调试搞得工程师累得死才发现这个问题，只能针对iOS版机型单独的适配。
还有最令人发指的不支持put/patch/delete等请求，这些都是HTTP标准的好吗？我当年知道后简直想捶地板了！
这里还有别人整理的51条腾讯内核浏览器问题汇总，比较大的包括：Android下特有的15条单列算1条，不支持Blur滤镜，不支持ShadowBlur效果，完全不会清理Cookie且不能大于4k，canvas有限制，webgl不完善，不支持web audio api，svg有问题，flexbox正在开发，不支持wss和webrtc，播放音效的话BGM会暂停，多音频会卡住甚至无法播放，一些常用库会非常卡
不过人家号称是独立开发的浏览器内核，所以这个不行、那个不行你们就忍忍吧，这个我们是独立开发的内核哦哈哈哈哈（妈比你给我滚！）
就这烂货，还专门上过新闻说Chrome再现安全漏洞，腾讯X5浏览器内核彰显优势，什么互联网急速上网体验，提供云服务优化引擎之类的，完全就他妈的是个烂货！烂货！烂货！！！
原帖由 jun4rui 于 2016-1-25 10:54 发表
posted by wap, platform: Chrome
这种大公司的牛逼产品真的操蛋极了！
而且微信妈比自带浏览器还没办法清理缓存的，而且缓存非常厉害，经常页面改了很久还不刷新，只能把自家公众号取消关注，再重新关注，这样才 ...
原帖由 @VEVAN 于 2016-1-27 17:44 发表
然而微信本地调试工具还是chrome套个壳=___=|||
原帖由 jun4rui 于 2016-1-28 13:45 发表
posted by wap, platform: Chrome
是的，因为是Chrome的壳所以和iOS的webkit还有些不兼容的坑
原帖由 @VEVAN 于 2016-1-27 18:01 发表
最大的坑是该死的效率，css3动画能给你卡成PPT
原帖由 jun4rui 于 2016-1-28 19:26 发表
posted by wap, platform: 小米 NOTE
微信自带浏览器跑HTML5test才407分，满分550分。手机上Android自带的WebKit框架都有502分，chrome都有510多。
而且就算支持的项目这货也老出妖蛾子，在移动端要适配这么个货色 ...
| 欢迎光临 TGFC Lifestyle (http://bbs.tgfcer.com/) | Powered by Discuz! 6.0.0 |
