CN113595885A - 图片发送方法及装置、电子设备、存储介质 - Google Patents

Abstract

本申请提供一种图片发送方法及装置、电子设备、存储介质。图片发送方法包括：确定至少一张待发送图片；至少一张待发送图片包括动态图片和/或静态图片；基于至少一张待发送图片的二进制流以及预先设定的压缩要求，生成与至少一张待发送图片相对应的至少一张目标图片；将至少一张目标图片发送至接收端。本申请能够减小通讯过程中图片消息的内存占用，提升应用程序稳定性。

Description

图片发送方法及装置、电子设备、存储介质

技术领域

本申请涉及图像处理领域，具体而言，涉及一种图片发送方法及装置、电子设备、非暂态电子设备可读存储介质。

背景技术

在社交/即时通讯软件中，图片消息出现的频率非常高，例如，微信已成为人们日常生活中常用的通讯软件，人们可以通过微信进行的文字/图片发送。一般而言，用微信发送图片时，需要先在从相册对应的存储空间中找到待发送的图片，并将该图片的二进制流信息存储到内存中，然后基于该二进制流信息对图片进行原图重绘，再对重绘后的原图进行图片编辑处理，包括尺寸等比例缩小处理、减色处理等，处理后的图片即可发送给接收方，但这种处理方式增加了图片处理的时间，还会占用额外的内存去存储图片的二进制流信息，导致内存占用和CPU消耗过大，出现APP卡顿、崩溃的情况。

发明内容

本申请实施例的目的在于提供一种图片发送方法，用以减小通讯过程中图片消息的内存占用，提升应用程序稳定性。

本申请实施例第一方面提供了一种图片发送方法，方法包括：

确定至少一张待发送图片；至少一张待发送图片包括动态图片和/或静态图片；

基于至少一张待发送图片的二进制流以及预先设定的压缩要求，生成与至少一张待发送图片相对应的至少一张目标图片；

将至少一张目标图片发送至接收端。

在一实施例中，待发送图片为静态图片时，压缩要求包括尺寸裁剪、比例压缩、减色处理中的一种或多种。

在一实施例中，当待发送图片为动态图片时，动态图片的压缩要求包括逐帧压缩；

逐帧压缩包括：对动态图片中的每一帧进行尺寸裁剪、比例压缩、减色处理中的一种或多种。

在一实施例中，当待发送图片为动态图片时，动态图片的压缩要求包括抽帧压缩；

抽帧压缩包括：去除动态图片中的第一部分帧；

第一部分帧中的每一帧均在第一剩余部分帧中存在相似帧。

在一实施例中，在去除动态图片中的第一部分帧之后，方法还包括：

对第一剩余部分帧进行尺寸裁剪、比例压缩、减色处理中的一种或多种。

在一实施例中，当待发送图片为动态图片时，动态图片的压缩要求包括选帧压缩；

选帧压缩包括：选取动态图片中的第二部分帧，并对第二部分帧进行减色处理；

第二部分帧中的每一帧均在第二剩余部分帧中存在相似帧。

在对第二部分帧进行减色处理之后，方法还包括：

对减色处理之后的第二部分帧以及第二剩余部分帧进行尺寸裁剪、比例压缩中的一种或多种。

本申请实施例第二方面提供一种图片发送装置，包括：

确定模块，用于确定至少一张待发送图片；至少一张待发送图片包括动态图片和/或静态图片；

生成模块，用于基于至少一张待发送图片的二进制流以及预先设定的压缩要求，生成与至少一张待发送图片相对应的至少一张目标图片；

发送模块，用于将至少一张目标图片发送至接收端。

本申请实施例第三方面提供一种电子设备，电子设备包括：

存储器，用以存储计算机程序；

处理器，用以执行本申请实施例第一方面及其任一项实施例的图片发送方法。

本申请实施例第四方面提供一种非暂态电子设备可读存储介质，包括：程序，当其藉由电子设备运行时，使得电子设备执行上述的图片发送方法。

本申请上述实施例提供的技术方案，本申请根据待发送图片的预设压缩要求，通过在一个内存中对待发送图片完成相应的图片处理，得到目标图片，再发送至接收端，无需占用额外的内存，从而减小通讯过程中图片消息的内存占用，提升应用程序稳定性。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请一实施例示出的电子设备的结构示意图；

图2为本申请一实施例示出的图片发送方法的流程示意图；

图3为本申请一实施例示出的图片裁剪方法的示意图；

图4为本申请一实施例示出的图片分片局部加载的示意图；

图5为本申请一实施例示出的图片传输方法的流程示意图；

图6为本申请一实施例示出的图片发送装置的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

请参照图1，其为本申请一实施例提供的电子设备100的结构示意图。该电子设备100包括：一个或多个处理器120、一个或多个存储处理器120可执行指令的存储器104。其中，处理器120被配置为执行本申请下述实施例提供的图片发送方法。

处理器120可以是网关，也可以为智能终端，或者是包含中央处理单元(CPU)、图像处理单元(GPU)或者具有数据处理能力和/或指令执行能力的其它形式的处理单元的设备，可以对电子设备100中的其它组件的数据进行处理，还可以控制电子设备100中的其它组件以执行期望的功能。

存储器104可以包括一个或多个计算机程序产品，计算机程序产品可以包括各种形式的非暂态电子设备可读存储介质，例如易失性存储器和/或非易失性存储器。易失性存储器例如可以包括随机存取存储器(RAM)和/或高速缓冲存储器(cache)等。非易失性存储器例如可以包括只读存储器(ROM)、硬盘、闪存等。在计算机可读存储介质上可以存储一个或多个计算机程序指令，处理器120可以运行程序指令，以实现下文的移动终端视图处理方法。在计算机可读存储介质中还可以存储各种应用程序和各种数据，例如应用程序使用和/或产生的各种数据等。

在一实施例中，图1所示电子设备100还可以包括输入装置106、输出装置108以及数据采集装置110，这些组件通过总线***112和/或其它形式的连接机构(未示出)互连。应当注意，图1所示的电子设备100的组件和结构只是示例性的，而非限制性的，根据需要，电子设备100也可以具有其他组件和结构。

输入装置106可以是用户用来输入指令的装置，并且可以包括键盘、鼠标、麦克风和触摸屏等中的一个或多个。输出装置108可以向外部(例如，用户)输出各种信息(例如，图像或声音)，并且可以包括显示器、扬声器等中的一个或多个。数据采集装置110可以采集对象的图像，并且将所采集的图像存储在存储器104中以供其它组件使用。示例性地，该数据采集装置110可以为摄像头。

在一实施例中，用于实现本申请实施例的图片发送方法的示例电子设备100中的各器件可以集成设置，也可以分散设置，诸如将处理器120、存储器104、输入装置106和输出装置108集成设置于一体，而将数据采集装置110分离设置。

在一实施例中，用于实现本申请实施例的图片发送方法的示例电子设备100可以被实现为诸如智能手机、平板电脑、笔记本电脑、个人数字助理(personal digitalassistant，PDA)等具有无线通信能力的移动终端。

请参照图2，其为本申请一实施例示出的图片发送方法的流程示意图。该方法包括如下步骤：

步骤210：确定至少一张待发送图片；至少一张待发送图片包括动态图片和/或静态图片。

本申请中图片发送方法的执行主体为移动终端的发送端。从发送端本地图片数据库获取并确定用户选择的一张待发送图片。待发送图片的形式包括动态图片和静态图片，图片的格式包括多种常规格式，例如GIF格式、PNG格式、JPG格式等等，对此不做赘述。

步骤220：基于至少一张待发送图片的二进制流以及预先设定的压缩要求，生成与至少一张待发送图片相对应的至少一张目标图片。

相关技术中，图片的上传、存储和读取显示，需要转成二进制流并保存在移动终端的内存或计算机内存中，并在内存中进行原图的重绘，从而会导致内存的占用率较高的问题；且目标图片是通过对重绘的原图进行压缩得到的，增加了额外的处理流程。而本申请中是直接基于待发送图片的二进制流和压缩要求，绘制出目标图片，不用原图重绘、也不用占用过多内存，更不用额外增加处理流程，释放了内存，简化了处理流程，提升了图片传输的效率。

根据二进制流和预先设定的压缩要求，生成待发送图片的缩略图。包括：获取待发送图片的尺寸信息；根据预设尺寸阈值和尺寸信息，确定待发送图片的压缩比例；根据压缩比例，绘制缩略图。

也就是说，在本申请中，是直接基于二进制流和压缩要求，绘制缩略图的，而不是绘制原图，再进行压缩，从而减少了处理流程，节省了内存，对此不做赘述。

在一实施例中，待发送图片为静态图片时，压缩要求包括尺寸裁剪、比例压缩、减色处理中的一种或多种。

针对图片比例压缩而言，现有技术一般通过设置阈值过滤占用空间较大的图片，来限制可选图片大小，避免内存占用过高，但此方法忽略了本身空间占用符合阈值，对于尺寸非常大的图片，例如，对于一张大小为34K、尺寸为1920*1080的内容单一的图片，如果该图片为SRGB格式，每个像素点的颜色由red(红色)，green(绿色)，blue(蓝色)，alpha(透明度)这4个bytes(字节)来决定，则该图片占用的内存为1920*1080*4＝8294400bytes＝7.9M，这依然会造成内存占用过高。

在上述步骤中，使用底层ImageIO(image Input/Out，读取与写入图片数据的基本方法)将待发送图片重绘，将尺寸和大小做压缩，可以避免现有技术方案只限制大小，因尺寸过大导致高内存占用的问题，也能有效避免常规压缩方案图片解码时造成的内存峰值过大问题。

具体步骤如下：

(1)读取图片资源路径创建CGImageSource对象，方式如下：let imageSource＝CGImageSourceCreateWithURL(url,nil)；

(2)设置缩略图宽高尺寸，方式如下：let option＝kCGImageSourceThumbnailMaxPixelSize＝1920；

(3)生成缩略图，方式如下：let thumbnail＝CGImageSourceCreateThumbnailAtIndex(imageSource,0,option)。

在一实施例中，可以利用ImageIO将待上传图片的尺寸压缩至小于1920*1080，待上传图片的大小压缩至小于20M。

例如，当一张待发送图片为人物图像时，图片尺寸很大，但是人物在图片中所占的比例很小，这使得人物在整张图像中就显得很小。按照上述图片比例压缩步骤，将整幅图片重绘，然后对尺寸和大小进行等比例缩小，避免占用内存。

针对图片尺寸裁剪而言，现有技术中在iOS端常规图片压缩方式UIGraphicsBeginImageContextWithOptions、UIGraphicsImageRenderer，压缩过程是将原图解码，再渲染为压缩后的图片，而原图片的解码则会造成内存峰值过高，同样会引起卡顿、崩溃问题。

如图3所示，本实施例中，使用底层ImageIO裁剪需要显示的图片到合适的尺寸。在当前多图消息九宫格中UIImageView(图3中的矩形框1)尺寸是w*h＝100*100，对于一张尺寸为W*H＝1080*1920(图3中的矩形框2)的图片以scaleAspectFill方式放置到UIImageView(图3中的矩形框1)上，不需要显示全部，裁剪成尺寸为w*h＝100*100(图3中的矩形框3)，内存占用为100*100*4＝40000bytes＝39K，内存占用将大幅减少。其中，裁剪区域(x,y)计算方式：x＝(W-w)/2；y＝(H-h)/2。

例如，当一张待发送图片为人物图像时，为了凸显出人物，采用图3所示的图片尺寸裁剪的步骤，把人物从图片中裁剪出来，这样图片上的人物就显得很大了，也不会占用过多的内存。

对上述人物图像也可以进行减色处理。图片是由多个像素点组成的，图片中人物背景为蓝天，但是蓝天的颜色也会存在不同程度的差异，比如深蓝色、浅蓝色、灰蓝色再过渡到白色，这几种颜色代表了九个不同的像素点，可以将这九个颜色接近的像素点全部统一成一种颜色的像素点，例如全部统一成白色像素点，就相当于把原本分类更细的深蓝色、浅蓝色、灰蓝色减色成一种颜色，这样图片的表征信息就少了，内存占用自然也就减少了。

当待发送的静态图片处理完成后，可以进行分片局部加载，如图4所示，可以使用CATiledLayer将一张尺寸为W*H＝1080*1920的大图(图4中的矩形框4)分成多个小图连续加载，例如从第1个分片区域(图4中的1区域)加载到第N个分片区域(图4中的N区域)，CATiledLayer将使用渲染更快的GPU(Graphics Processing Unit，图形处理器)进行渲染。在进行分片局部加载时，每一个分片区域的分片宽度等于图片宽度，分片高度等于预设分片字节大小/(4*分片宽度)。例如，取第1个分片区域为例，预设分片字节大小为2M，图片宽度为W，则分片宽度也为W，分片高度H＝(2*1024*1024)/(4*W)。CATiledLayer可以根据是否显示在屏幕区域内来自动计算分块显示区域并决定加载顺序。

若静态图片尺寸大于显示视图，可以通过ImageIO裁剪待显示的静态图片。例如，在一个多图消息九宫格中，显示视图尺寸为w*h＝100*100，对于一张尺寸为W*H＝1080*1920的图片，可以将该图片裁剪为w*h＝100*100的尺寸，以scale Aspect Fill方式放置到显示视图上，不需要显示全部，裁剪后的图片内存占用为100*100*4＝40000bytes＝39K，可以大幅减少内存占用。在一实施例中，裁剪图片时可以优先保留图片的中心区域，裁剪四周区域。

在一实施例中，当待发送图片为动态图片时，动态图片的压缩要求包括逐帧压缩；

逐帧压缩包括：对动态图片中的每一帧进行尺寸裁剪、比例压缩、减色处理中的一种或多种。

在进行动态图片GIF处理时，可以将动态图片的每一帧作为静态图片来处理。对于每一帧的尺寸裁剪、比例压缩与上述对静态图片的尺寸裁剪、比例压缩的处理方式一样，其中，GIF动态图片做减色处理具体包括如下步骤：

(1)读取压缩图片的文件信息；

(2)根据文件信息，获取压缩图片的全局调色盘长度；

(3)将全局条色盘长度减小至预设长度，预设长度大于2。

在一实施例中，预设长度的取值范围可以为30至128。

在上述步骤中，文件信息包括调色盘信息。每一帧的延迟时间信息、背景色信息以及是否循环播放等。全局调色盘是指整个GIF图片所有帧的调色盘，即GIF图片所有帧的颜色均包含在该全局调色盘中。全局调色盘的长度即GIF图片所有帧包含的颜色总数。可以通过合并RGB值较接近的颜色来减小全局条色盘长度。

在一实施例中，当待发送图片为动态图片时，动态图片的压缩要求包括抽帧压缩。

对待发送动态图片逐帧进行压缩处理，包括：判断待发送图片的帧数是否超过预设帧数阈值；若待发送图片的帧数超过预设帧数阈值，则根据预设帧数阈值，对待发送图片进行抽帧。

在上述步骤中，可以根据待发送图片的文件信息，获取待发送图片的总帧数，然后根据待发送图片的总帧数确定抽帧间隔，总帧数越多，对应的抽帧间隔也越大，例如，总帧数小于或等于8帧，抽帧间隔为1帧，总帧数大于8帧，小于或等于20帧，抽帧间隔为2帧，总帧数大于20帧，小于或等于30帧，抽帧间隔为3帧，总帧数大于30帧，小于或等于40帧，抽帧间隔为4帧，总帧数大于40帧，抽帧间隔为5帧。根据抽帧间隔，重新计算每一帧的延迟时间，生成新的GIF动态图片。

抽帧压缩包括：去除动态图片中的第一部分帧；第一部分帧中的每一帧均在第一剩余部分帧中存在相似帧。

例如，从一张总帧数为20帧的GIF动态图片中，抽取10帧图片信息，这10帧则称为第一部分帧，剩下的10帧称为第一剩余部分帧。使第一部分帧中的每一帧均在第一部分剩余帧中存在相似帧。例如，第1帧与第2帧存在相同或相似的图片帧信息(如两帧图片中的背景颜色均相同或图片中的人物动作均相似)，则可以将第2帧抽取掉，仅保留第1帧，同上，第3帧和第4帧存在相同或相似的图片帧，则可以将第3帧保留，第4帧抽取掉，如此类推下去，以抽帧间隔为1帧进行抽帧，由此抽取10帧无关紧要的图片帧，只要剩下的10帧图片能够连续起来，成为一个GIF动态图片，即可生成新的GIF动态图片。对GIF动态图片的抽帧处理即可认为是对图片的压缩处理。

在一实施例中，在去除动态图片中的第一部分帧之后，方法还包括：

对第一剩余部分帧进行尺寸裁剪、比例压缩、减色处理中的一种或多种。

去除了第一部分帧(前述举例中的10帧)后，保留第一剩余部分帧(剩余10帧)，生成了新的GIF动态图片，可以对新的GIF动态图片再进行对透明度和公共区域的优化压缩。把新的GIF动态图片中的每一帧当做一副静态图片来处理，对第一剩余部分帧的图片处理方式包括尺寸裁剪、比例压缩和减色处理，处理方式与前述对静态图片的处理方式一致，在此不再赘述。对抽帧后的GIF动态图片进行逐帧比例压缩处理，则图片的尺寸将被压缩的更小。

在一实施例中，当待发送图片为动态图片时，动态图片的压缩要求包括选帧压缩；

选帧压缩包括：选取动态图片中的第二部分帧，并对第二部分帧进行减色处理；第二部分帧中的每一帧均在第二剩余部分帧中存在相似帧。

例如，一张总帧数为20帧的GIF动态图片，需要选取这20帧中需要保留的图片帧，即第二部分帧，然后去除掉不需要的图片帧，即为第二剩余部分帧。例如，GIF动态图片的20帧图片中有些背景并没有发生变化，这些未发生变化的背景对应的图像帧就是不需要的图片帧(即第二剩余部分帧)，可以选取剔除，也就是说选取的这20帧中第二部分帧，与剔除的图片帧即第二剩余部分帧存在相似的背景信息或相似的图片帧。选帧的具体方法如下：

将GIF动态图片的二进制流想象成一个表格，图片的尺寸对应表格的横坐标和纵坐标，每个表格代表该图片的像素点，每个像素点对应一个RGB值。例如GIF动态图片为人物时，背景为一组白墙，白墙像素点对应的RGB值为0，人物黑色头发像素点对应的RGB值为255，根据背景白墙的像素点对应的RGB值和人物黑色头发像素点对应的RGB值，可以把背景和人物目标标记出来，进行保留，介于0-255之间的剩余像素点对应的信息就成为了不需要的图像帧，可以选取剔除，因此，只留下有用的图片帧作为新的GIF动态图片。

对原GIF动态图片做选帧处理，对保留的图片帧进行减色处理，保留的图片帧每一帧的尺寸大小都是一致的，从而合并成为新的GIF动态图片，因此，新的GIF动态图片不存在帧忽大忽小的问题。本实施例中，对第二部分帧进行减色处理的方式与上述逐帧压缩减色处理的方式一致，在此不再赘述。

在对第二部分帧进行减色处理之后，方法还包括：

对减色处理之后的第二部分帧以及第二剩余部分帧进行尺寸裁剪、比例压缩中的一种或多种。

对减色处理后的第二部分帧进行合并，以及第二剩余部分帧进行合并，成为新的GIF动态图片，对新合并的GIF动态图片再进行尺寸裁剪和比例压缩后，整体图片的尺寸减小，但不会存在帧忽大忽小的问题。

在一实施例中，可以在对动态图片进行压缩减色处理之前进行抽帧，也可以在对动态图片进行压缩减色处理之后进行抽帧，若在压缩减色处理之后进行抽帧，则需要先获取压缩减色前的GIF文件信息，再进行抽帧。

需要说明的是，前述的多种压缩方式，可以单独使用，也可以相互结合使用，只要满足实际的需求即可，对此不做任何限定。

步骤230：将至少一张目标图片发送至接收端。

基于上述对静态图片或动态图片的处理方法，获得至少一张待发送的目标图片，将目标图片发送至接收端。

在一实施例中，在进行图片批量发送时，可以在自动释放池(Auto release pool)中进行压缩和发送操作，在每一次处理完图片压缩和发送操作后，自动释放池都会将任务中引用计数(retain Count)为0的对象逐一释放，及时释放无用内存，有效降低内存峰值。

在一实施例中，可以根据发送任务中图片的尺寸或体积，调整发送任务并发数量，防止过多图片同时解码，造成内存峰值过高，也可以避免逐个发送带来的耗时长，用户体验差的问题。

在一实施例中，发送任务并发数量可以为3个，若当前的发送任务中有大尺寸和/或大体积的图片超过预设比例，例如50％，则发送任务并发数量减小为1-2个，若当前的发送任务中均为小尺寸小体积的图片，则发送任务并发数量减小为4-5个。其中，大尺寸图片是指尺寸大于4096*1280的图片，大体积图片是指体积大于20M的图片，小尺寸图片是指尺寸小于540*3600的图片，小体积图片是指体积小于2M的图片。

在一实施例中，如图5所示，其为本申请一实施例的图片传输方法的流程示意图，该方法可由图1所示的电子设备100来执行，以实现减小通讯过程中图片消息的内存占用，在本实施例中电子设备100作为接收端。

该方法包括如下步骤：

步骤410：接收服务端发送的图片消息。

在上述步骤中，图片消息包括待发送图片在服务端的URL(uniform resourcelocator，统一资源定位***)地址，接收端可以根据URL地址下载对应的图片。

步骤420：判断图片消息是否为动态图片。

在上述步骤中，判断图片消息是否为动态图片，若图片消息为动态图片，则执行步骤430，若图片消息不是动态图片，则执行步骤460。

步骤430：判断图片消息的文件大小是否超过预设阈值。

在上述步骤中，判断图片消息的文件大小是否超过预设阈值，若图片消息的文件大小超过预设阈值，则执行步骤440，若图片消息的文件大小不超过预设阈值，则执行步骤450。图片消息的文件大小是指图片占用的内存的大小。

步骤440：对图片消息逐帧进行压缩处理并加载。

在上述步骤中，图片消息对应的GIF图片大小超过预设阈值，对GIF图片进行逐帧重绘压缩尺寸和大小，并做减色处理进一步压缩。

步骤450：直接加载图片消息。

在上述步骤中，直接加载图片消息对应的GIF图片进行显示。

步骤460：判断是否存在对应于图片消息的缩略图。

在上述步骤中，判断是否存在对应于图片消息的缩略图，若存在对应于图片消息的缩略图，则执行步骤470，若不存在对应于图片消息的缩略图，则执行步骤480。

步骤470：加载缩略图。

步骤480：对图片消息进行分片局部加载。

在上述步骤中，使用CATiledLayer将一张大图分成多个小图连续加载，CATiledLayer将使用渲染更快的GPU(Graphics Processing Unit，图形处理器)进行渲染。在进行分片局部加载时，每一个分片的分片宽度等于图片宽度，分片高度等于预设分片字节大小/(4*分片宽度)。例如，预设分片字节大小为2M，图片宽度为W，则分片宽度也为W，分片高度＝(2*1024*1024)/(4*W)。CATiledLayer可以根据是否显示在屏幕区域内来自动计算分块显示区域并决定加载顺序。

在一实施例中，接收端在显示静态图片时，若静态图片尺寸大于显示视图，可以通过ImageIO裁剪待显示的静态图片。前文已经详细描述，在此不再赘述。

在一实施例中，接收端消息列表滚动时，停止GIF图片播放，可以有效减小CPU占用，提升页面流畅度，不在消息列表内的GIF图片，停止播放并释放内存，可以有效减小内存和CPU占用。

下述为本申请装置实施例，可以用于执行本申请图片发送方法的实施例。对于本申请装置实施例中未披露的细节，请参照本申请图片发送方法的实施例。

图6为本申请一实施例示出的图片发送装置的结构示意图。如图6所示，该装置包括：确定模块500、生成模块600和发送模块700。

确定模块500，用于确定至少一张待发送图片；至少一张待发送图片包括动态图片和/或静态图片；

生成模块600，用于基于至少一张待发送图片的二进制流以及预先设定的压缩要求，生成与至少一张待发送图片相对应的至少一张目标图片；

发送模块700，用于将至少一张目标图片发送至接收端。

上述装置中各个模块的功能和作用的实现过程具体详见上述图片发送方法的中对应步骤的实现过程，在此不再赘述。

在本申请所提供的几个实施例中，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的***来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

Claims (10)

1.一种图片发送方法，其特征在于，包括：

确定至少一张待发送图片；所述至少一张待发送图片包括动态图片和/或静态图片；

基于所述至少一张待发送图片的二进制流以及预先设定的压缩要求，生成与所述至少一张待发送图片相对应的至少一张目标图片；

将所述至少一张目标图片发送至接收端。

2.根据权利要求1所述的方法，其特征在于，所述待发送图片为静态图片时，所述压缩要求包括尺寸裁剪、比例压缩、减色处理中的一种或多种。

3.根据权利要求1所述的方法，其特征在于，当所述待发送图片为动态图片时，所述动态图片的压缩要求包括逐帧压缩；

所述逐帧压缩包括：对所述动态图片中的每一帧进行尺寸裁剪、比例压缩、减色处理中的一种或多种。

4.根据权利要求1所述的方法，其特征在于，当所述待发送图片为动态图片时，所述动态图片的压缩要求包括抽帧压缩；

所述抽帧压缩包括：去除所述动态图片中的第一部分帧；

所述第一部分帧中的每一帧均在第一剩余部分帧中存在相似帧。

5.根据权利要求4所述的方法，其特征在于，在去除所述动态图片中的第一部分帧之后，所述方法还包括：

对所述第一剩余部分帧进行尺寸裁剪、比例压缩、减色处理中的一种或多种。

6.根据权利要求1所述的方法，其特征在于，当所述待发送图片为动态图片时，所述动态图片的压缩要求包括选帧压缩；

所述选帧压缩包括：选取所述动态图片中的第二部分帧，并对所述第二部分帧进行减色处理；

所述第二部分帧中的每一帧均在第二剩余部分帧中存在相似帧。

7.根据权利要求6所述的方法，其特征在于，在对所述第二部分帧进行减色处理之后，所述方法还包括：

对减色处理之后的第二部分帧以及所述第二剩余部分帧进行尺寸裁剪、比例压缩中的一种或多种。

8.一种图片发送装置，其特征在于，包括：

确定模块，用于确定至少一张待发送图片；所述至少一张待发送图片包括动态图片和/或静态图片；

生成模块，用于基于所述至少一张待发送图片的二进制流以及预先设定的压缩要求，生成与所述至少一张待发送图片相对应的至少一张目标图片；

发送模块，用于将所述至少一张目标图片发送至接收端。

9.一种电子设备，其特征在于，所述电子设备包括：

存储器，用以存储计算机程序；

处理器，用以执行如权利要求1至7中任一项所述的图片发送方法。

10.一种非暂态电子设备可读存储介质，其特征在于，包括：程序，当其藉由电子设备运行时，使得所述电子设备执行权利要求1至7中任一项所述的图片发送方法。

Images