本文重要记录一个bug大年夜发明、定位到延期解决的过程。文末添加了已踩过的坑
近期在做“发送原图”功能的时刻,碰到一个bug:在Android、Windows、Mac 客户端发送原图,iOS客户端接收,保存原图后,原图物理尺寸不变,存储空间变小,对应的location等Exif信息损掉。与此同时,iOS客户端之间互发原图没有问题。针对这个问题,做了以下测试调研,现记录下来:
微信中发送原图样式
一. 起首介绍一下发送一张原图的流程:
- 比如 Android 端发送一张原图,先上传到 IM 的办事器,上传成功后再发送消息体;(上传成功后,办事器会分派三个url分别对应缩略图、大年夜图、原图)
- 接收方接收到消息体,下载缩略图;
- 点击缩略图,下载大年夜图;
- 再点击“查看原图”按钮,下载原图;
- 下载成功后,长按图片,保存原图。
二. 问题定位是在最后一步,保存图片的部分:
- 下载的图片大年夜小与办事器存储大年夜小是完全一致的,保存之后大年夜小就产生了变更(今朝是“jpg”格局变小,“png”格局图片变大年夜);
- 下载的方法分别测验测验了 AFNetwoking 下载、SDWebImage 的通俗下载和高等下载方法(因为产品需求请求显示下载原图进度)
- 结论下载的图片大年夜小与办事器存储大年夜小是完全一致的是因为在 SDWebImage 高等下载办法的 completionBlock 中有已下载的 bit 值
- 测验测验了能找到的各类保存图片的方法,均不可
弥补测试:安卓端拍摄一张图片(大年夜小为5M),发送给 iOS 客户端(下载大年夜小为5M),保存(大年夜小为3M),再将该保存的图片发给安卓客户端(保存后为3M),安卓客户端再发送给iOS 客户端(保存后大年夜小为3M)。结论:钙揭捉?缩只会进行一次
保存图片后,图片的Exif信息损掉,然则Exif信息的大年夜小远小于文件损掉的大年夜小。图片物理尺寸没有产生变更
三. 竞品的该功能近况:
- Android、Windows、Mac发送原图,iOS客户端接收
- 腾讯系(QQ、WeChat)各端发送接收原图都没有问题
- 钉钉 的图片变小,Exif 信息损掉
- BearyChat 发送原图的图片变小,Exif 信息损掉
- Slack 只支撑发送图片,没有发送原图功能
验证测试:将安卓端产生的图片(包含拍┞氛“jpg”和屏幕截图“png”)大年夜浏览器下载到电脑,大年夜小不变,将该图片文件拖到项目中,履行保存图片的办法,大年夜小也产生了变更。
四. 基于现有情况的分析
- iOS 体系在保存图片的时刻,会对图片进行编解码操作,可能在位图长进行优化
- 一张图片的存储大年夜小的计算方法:程度像素垂直像素1色诟谇或3基色*色彩深度bit数 = MB数,可能是不合体系的基数不合导致
- 如不雅要解决这个问题,要先研究一下图片编解码这些很底层的器械,今朝来看,性价比很低
- 如不雅您之前踩过类似的坑并找到有效的解决办法,便利的话,劳烦请私信告诉
SDWebImage-NSData+ImageContentType.m 已更新,刚开端碰到这个问题的时刻提了个issue,还让我供给对应url。。
五. 弥补点干货
1. 关于iOS11新增的“.heic”格局图片
什么是“.heic”格局图片?
之前叫“live”图片,打开下图红框中的按钮即可打开该模式,拍┞氛后会朝长进步拍┞氛前后大年夜概两秒的一个片段,与“Gif”图不合的是,该格局还包含了声音(今朝只有)
什么样的手机才能拍出“.heic”格局图片?
只有在 iOS11体系下且CPU为A10及其以上(最低也得是iPhone 7),其他情况下拍出来的都是通俗“live”图,即在须要转换格局的时刻会主动转换为“.jpg/.jpeg”格局
若何断定一张图片是否是“.heic”格局?
- + (SDImageFormat)sd_imageFormatForImageData:(nullable NSData *)data {
- if (!data) {
- return SDImageFormatUndefined;
- }
- // File signatures table: http://www.garykessler.net/library/file_sigs.html
推荐阅读
11月悉尼的春天溘然变得阴冷潮湿,和第一天抵达时刻的风和日丽大年夜相径庭,海风推动着飘忽的乌云,有点片子《魔戒》里阴郁军团压境的味道。因为早上不当心睡过了头,我只能在冷雨中边赶>>>详细阅读
本文标题:iOS开发关于“发送原图”功能问题的记录
地址:http://www.17bianji.com/lsqh/38516.html
1/2 1