为例，详细介绍本发明。
[0044]第一终端的用户在微信的应用界面（即上述实施例中的第一界面）发起传输图片 的请求，在确定待传输图片之后，第一终端生成待传输图片的数据流，该数据流中包括待传 输图片的图片数据和待传输图片的预设传输数据容量。在启动图片传输之后，采用流式传 输方式将预设传输数据容量和图片数据依序上传给服务器，服务器在接收图片数据的过程 中实时向第一终端确认已接收到待传输图片中的数据容量，在已接收到的待传输图片中 的数据容量为预设传输长度时，认为待传输图片接收成功，向第一终端发送确认信号，确认 已接收到的待传输图片中的数据容量为预设传输长度，第一终端接收到确认信号，在微信 的上传图片的进度条中显示上传（或发送）成功。
[0045]在本发明的上述实施例中，在接收到服务器发送的确认信号之后，传输方法还可 以包括：将第j+1层图片编码数据至第N层图片编码数据逐层上传至服务器，其中，第j层 图片编码数据为接收到确认信号时发送的最后一层图片编码数据，l〈j〈N，j为自然数。
[0046] 具体地，在服务器已接收到的待传输图片的数据容量为预设传输数据容量时，确 认待传输图片上传成功，然后，继续上传图片数据中尚未上传至服务器的数据。也即，在确 认上传成功的情况下，转到后台继续发送待传输图片的图片数据中剩余的图片编码数据， 剩余图片编码数据即为尚未上传的数据。
[0047] 通过上述实施例，在上传预设传输数据容量之后即向用户通知已经上传成功，然 后继续将全部的待传输图片的图片数据上传成功，缩短了传图的时间，提高了传输图片的 成功率，这样，第一终端的用户体验到发图的时间缩小了，发图过程变快了，在解决上述技 术问题的同时提高了用户体验。
[0048] 在本发明的上述实施例中，生成待传输图片的数据流可以包括：使用第一终端的 网络状态确定传输因子，其中，第一终端为上传待传输图片的终端；将待传输图片的总数据 容量和传输因子之积作为预设传输数据容量；根据待传输图片的预设传输数据容量和待传 输图片的图片数据生成数据流。
[0049] 具体地，使用第一终端的网络状态确定传输因子可以包括：获取第一终端当前使 用的网络类型数据和网络信号强度；从数据表中读取网络类型和网络信号强度指向的传输 因子，其中，数据表为二维数据表，一个网络类型数据和一个网络信号强度确定一个传输因 子。
[0050] 在使用第一终端上传待传输图片时，最少传输预设传输数据容量，该预设传输数 据容量为最小传输数据容量（MTS，MinimalTransportSize)。MTS与待传输图片的图片 总数据容量（TS，TotalSize)的比值，称为传输因子Q。公式如下：Q=MTS/TS，或者写成： MTS=TSXQ。
[0051] 由于第一终端的数据传输速率与第一终端所处的网络环境相关，好坏网络的传输 速率可能相差上百倍，在待传输图片的总数据容量不变的前提下，第一终端的用户等待待 传输图片的传输的时间也将相差上百倍。为了适应不同的网络环境，在本发明的上述实施 例中可以通过第一终端所处的网络的网络状态确定传输因子，然后使用传输因子和图片总 数据容量确定待传输图片的MTS。
[0052] 可选地，网络状态可以使用两个维度的数据来确定网络的传输质量：网络类型数 据和网络信号强度。其中，网络类型数据可以包括：WiFi和4G、3G以及2G等网络类型的描 述数据；网络信号强度可以使用数据来确定（如80、90以及100)，可以使用文字描述来确 定网络信号强度（如：强、中、弱），根据网络类型数据和网络信号强度的不同组合，确定传 输因子。在上述实施例中还可以结合不同的应用程序对图片质量要求确定传输因子。
[0053] 具体地，可以通过查数据表得到传输因子，表1提供了一种可选的确定传输因子 的数据表。
[0054]表1
[0055]
[0056] 如表1所示，传输因子使用了字母代码A、B、C、D、E和F来表示，在使用字母代码 (如A、B、C、D、E和F)表示的情况下，可以通过数值表查表得到每个字母代码代表的传输因 子的值，如，A= 1. 0、B= 0? 9、C= 0? 8、D= 0? 7、E= 0? 6、F= 0? 5。
[0057] 在实际应用中还可以直接使用传输因子的值代替字母代码，如表2所示。
[0058] 表 2
[0059]
[0060] 通过本发明上述实施例中的传输因子确定方法，一个TS= 100KB的待传输图片， 在WiFi强信号网络中，MTS= 100*1. 0 = 100KB;而在2G中等信号网络下，MTS= 100*0. 7 =70KB，MTS减少了 30%，结合上述的图片的传输方法，可以减少30%的用户等待时间。 [0061] 上述实施例中的，预设传输数据容量MTS是待传输图片的最小应该传输的数据容 量，而不是最终传输的总数据容量，通过上述实施例，在服务器确认传输成功之后，在网络 不中断的条件下，第一终端还是可以将整个待传输图片的完整的图片数据完全发送至服务 器，以便第二终端获得更加清晰的待传输图片。
[0062] 在本发明的上述实施例中，在即时通讯应用程序的应用场景中，第一终端生成的 数据流中可以包括元数据，该元数据中可以包括：第一终端的第一标识、第二终端的第二标 识、待传输图片的总长度以及预设传输长度。其中，第一终端可以为上传（或接收）待传输 图片的终端，第二终端可以为下载（或接收）待传输图片的终端，在即时通讯应用程序为微 信的情况下，第一标识和第二标识可以分别为微信号。
[0063] 具体地，第一终端可以将第一标识、第二标识、预设传输数据容量、待传输图片的 总数据容量作为元数据放在数据流的最前面，将待传输图片的图片数据放在元数据的后 面。按照流式传输方式传输待传输图片时，先发送元数据，在发送完成元数据之后，再发送 图片数据。在这个过程中，由于元数据的数据容量很小，在待传输图片的传输过程中不会影 响传输速率。
[0064] 进一步地，在第一终端将元数据发送完成之后，发送图片数据，服务器接收图片数 据，并不断向第一终端确认已接收到的待传输图片的数据容量，同时对元数据进行解析，得 到第一终端的第一标识、第二终端的第二标识、待传输图片的总数据容量以及预设传输长 度。
[0065] 根据本发明的上述实施例，生成待传输图片的数据流可以包括：对所述待传输图 片进行渐进式图片编码得到N层图片编码数据；将N层图片编码数据作为待传输图片的图 片数据。
[0066] 通过上述实施例可以将待传输图片的格式转换为渐进式JPEG格式，得到格式为 渐进式JPEG格式的图片；将格式为渐进式JPEG格式的图片的图片数据作为待传输图片的 图片数据。通过上述的渐进式编码，可以得到N层图片编码数据，从第一层图片编码数据开 始叠加可以得到分辨率逐渐增高的图片，也即逐层叠加得到的图片可以从模糊到清晰。
[0067] 其中，JPEG图片压缩格式具有良好的压缩性能，JPEG格式有两种编码方式：基线 式（baseline)和渐进式（progressive)。基线式的编码方式是图片从上到下，从左到右地 进行处理和编码，如图3所示。渐进式编码方式是先全局后局部，先轮廓再细节的编码方 法，如图4所示。
[0068] 可选地，渐进式JPEG格式属于JPEG国际标准的一部分，在Android、iOS和 WindowsPhone三大移动操作系统自带的JPEG编解码库都直接支持，无需引入第三方编解 码库。
[0069]具体地，渐进式编码得到的文件数据容量（也可以称之为数据长度或数据大小） 比基线式编码略小一些，且具有更友好的图片展示过程，不会出现如图3所示的半张图片 情况。
[0070] 在本发明的上述实施例中，图片的传输方法中使用的可以是渐进式JPEG格式的 图片。
[0071] 进一步地，渐进式JPEG格式图片可以被用来有选择性地控制传输的数据量，提高 传输的成功率。在网络条件较差的情况下，可以丢弃图片的部分不重要细节，换取传图功能 的可用性。图5是接收到原图片一定比例数据的图片展示效果，图中分别示出了接收到原 始图片20%、60%、80%以及100%的数据容量的图片的展示效果。
[0072] 从图5中可知，接收到待传输图片的图片数据越多，待传输图片的展示越清晰。在 20%的时候，还看不清楚图片中的文字，到了 60%的时候，文字已清晰可见，再到80%以及 100%，图片细节更清楚，但如果没有多张图片仔细比较，已看不出图片差异。
[0073] 在该实施例中，在接收到用户的发送图片请求，并确认待传输图片之后，判断待传 输图片的格式是否为渐进式JPEG格式；在待传输图片的格式不为渐进式JPEG格式的情况 下，将待传输图片的格式转换为渐进式JPEG格式，得到渐进式JPEG格式的图片，并将渐进 式JPEG格式的图片的图片数据作为待传输图片的格式的图片数据，生成数据流；在待传输 图片的格式为渐进式JPEG格式的情况下，直接根据待传输图片的格式的图片数据生成数 据流。
[0074] 通过上述实施例，采用渐进式（progressive)JPEG格式的图片，对图片不是传统 的自上而下先左再右的编码过程，而是先轮廓后细节的编码过程，在接收到的图片数据的 数据量逐渐变大的过程中，待传输图片的展示从模糊逐渐清晰；并且在上述实施例中采用 了流式传输方式，图片数据按先主后次的顺序像水流一样在网络中传输，传输进行过程实 时处理响应：服务器实时向第一终端确认收到的待传输图片的数据容量，在接收到特定长 度之后确认发送成功，还可以通过第二终端，第二终端实时将收到的数据（即上述的预设 传输数据容量的数据）展示在第二界面上。整个图片的传输过程，无论是对于第一终端还 是对于第二终端，图片传输的时间都很短，对于使用第一终端和第二终端的用户来讲，需要 等待时间也会大大缩小。
[0075]需要进一步说明的是，在将预设传输数据容量和图片数据上传至服务器之后，传 输方法还可以包括：服务器实时记录已接收到待传输图片中的数据容量；在已接收到待传 输图片中的数据容量为预设传输数据容量时，生成确认信号和通知信号；将确认信号发送 至第一终端，其中，第一终端为上传待传输图片的终端；以及将通知信号发送至第二终端， 其中，通知信号用于通知第二终端接收待传输图片。
[0076] 可选地，在将通知信号发送至第二终端之后，传输方法还可以包括：在接收到第 二终端的查看待传输图片的信息之后，将已接收到待传输图片中的数据容量发送至第二终 端。
[0077] 根据上述实施例，在第一终端按照流式传输方式将预设传输数据容量和图片数据 上传至服务器，服务器首先接收到的是预设传输数据容量，在待传输图片的图片数据上传 至服务器的过程中，服务器实时记录已接收到待传输图片中的数据容量，并且实时比较已 接收到待传输图片中的数据容量与预设传输数据容量，在已接收到待传输图片中的数据容 量为预设传输数据容量时，生成确认信号和通知信号，然后将确认信号发送至上传待传输 图片的第一终端，并将通知信号发送至第二终端，通知第二终端接收待传输图片。
[0078] 具体地，在将通知信号发送至第二终端之后，传输方法还可以包括：在接收到第 二终端的查看待传输图片的信息之后，将已接收到待传输图片中的数据容量发送至第二终 端。
[0079] 下面结合图6详细介绍本发明。
[0080] 如图6所示，该方法可以通过如下步骤实现：
[0081] 步骤S601 :第一终端对待传输图片进行预处理得到渐进式JPEG格式的图片。
[0082] 其中，上述实施例中的预处理即为上述的格式转换的处理。
[0083] 具体地，可以在确认待传输图片之后，判断待传输图片的格式是否为渐进式JPEG 格式。如果是，则不对待传输图片进行格式处理；如果不是，则对待传输图片进行格式转换。
[0084] 进一步地，渐进式JPEG格式属于JPEG国际标准的一部分，在Android、iOS和 WindowsPhone三大移动操作系统自带的JPEG编解码库都直接支持，无需引入第三方编解 码库。
[0085] 步骤S602 :第一终端生成待传输图片的数据流。
[0086] 具体地，可以将第一终端101(如发送方终端）的第一标识（如WN，用户编码）、 第二终端103(如接收方终端）的第二标识、待传输图片的图片总数据容量，预设传输数据 容量（如MTS长度）等数据作为元数据组织在数据流的最前面，将渐进式JPEG格式的图片 的图片数据组织在元数据的后面。
[0087] 步骤S603 :第一终端向服务器发送数据流至服务器。
[0088] 具体地，上述步骤可以按照流式传输方式传输数据流，更具体地，先发送元数据， 然后发送图片数据。在服务器102接收图片数据的过程中，实时地向第一终端确认已接收 到的待传输图片的数据容量（如图片数据的长度），同时对元数据进行解析处理，得到第一 终端的第一标识、第二终端的第二标识，待传输图片的图片总数据容量，以及预设传输数据 容量（即上述实施例中的MTS长度）。
[0089] 步骤S604:服务器已接收到待传输图片中的数据容量为预设传输数据容量时，生 成确认信号和通知信号，将确认信号发送给第一终端，将通知信号发送给第二终端。
[0090] 具体地，当服务器收到的待传输图片中的数据容量为预设传输数据容量时，认为 待传输图片接收成功，向第一终端发送确认信号，确认已收到MTS数据容量；同时向第二终 端发送通知信号，通知第二终端（接收方）收到一张新图片（即上述实施例中的待传输图 片）。
[0091] 其中，服务器102可以通过设置在第二终端的消息通知中心1031传输通知信号。
[0092] 进一步地，第一终端接收到确认信号之后，可以向第一终端的第一界面上显示发 送成功的消息；第二终端收到通知信号之后，在第二终端的第二界面上显示有新图片的消 肩、。
[0093] 根据本发明的上述实施例，在第二终端接收到确认信号并向第一终端的第一界面 上显示发送成功的消息之后，转到后台继续发送待传输图片中的尚未上传至服务器的剩余 数据。
[0094] 通过上述实施例，缩短了图片传输的时间，提高了图片传输的成功率。并且第一终 端（即发送方终端）的用户也会体验到发图时间缩小了，发图过程变快了。
[0095] 需要进一步说明的是，如果发送方此时网络正常，图片数据将被全部发送完毕；如 果发送方此时网络不稳定导致无法发送更多数据，发送过程也属于成功结束。
[0096] 步骤S605 :第二终端在收到新图片的通知信号之后，向服务器发送查看该图片的 请求，服务器将已接收到待传输图片中的数据容量发送至第二终端。
[0097] 步骤S606 :第二终端的第二界面上展示该接收到的服务器已接收