器的结构图；
[0039]图5是本发明实施例中的一种富文本动态消息发布系统的示意图。
【具体实施方式】
[0040]为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。
[0041]图1是本发明实施例中的一种富文本动态消息发布方法的流程图。如图1所示，所述方法包括:
[0042]步骤S110，将待发布的动态消息中的各多媒体附件分别打包上传到服务器。
[0043]步骤S120，接收每个多媒体附件上传成功时，服务器返回的回包，该回包中包含上传成功的该多媒体附件的服务器地址。
[0044]在本发明的实施例中，服务器收到客户端通过当前客户端应用上传的多媒体附件后，存储附件，并根据存储位置生成各附件的服务器地址。回包包括上传附件的信息，比如该附件对应的服务器地址。还可以包括附件的大小、附件的缩略图地址等。客户端将每次一上传成功后服务器返回的回包保存起来。
[0045]步骤S130，将所述待发布的动态消息中的各多媒体附件的回包中的信息打包到最后一个包中上传到服务器，使得服务器根据该最后一个包中的信息生成一条富文本动态消息并发布。
[0046]本步骤中，如果所述待发布的动态消息还包括文本信息以及一些发布动态消息需要的其他信息，则将文本信息、各多媒体附件的回包中的信息以及一些发布动态消息需要的其他信息打包成最后一个包上传到服务器。
[0047]在本步骤中，客户端在附件都上传成功后，在给服务器发送一个最终创建动态的信令(即这里所述的最后一个包)，这个信令里面包括所有附件的回包信息，还有用户发布的文字信息、以及动态需要的一些其他信息等。这样，服务器就可以把每一条富文本动态和相应的富文本附件对应上，以创建该条富文本动态消息。即服务器端可以根据最后一个包中的各回包信息找到对应的富文本附件，进而结合文字、所找到的附件以及一些其他信息生成富文本动态消息。
[0048]图1所示的方法中采取了将富文本动态消息中的每个附件分别上传的策略，这样能有效的将原本需要将几个附件合并在一起的较大包拆开，每个附件单独成为一个包上传，等每个附件上传成功后，再将文本信息(如果有的话)、所有的附件的服务器地址和一些其他信息(如果有的话)合成最后一个包上传到服务器。这样每个包都比原来的一个大包小了很多，每个包的上传成功率也会相应增加，尤其是在弱网条件下。
[0049]在本发明的一个实施例中，步骤S130中发送的最后一个包还包括该待发布的动态消息的唯一标识，以使所述服务器根据该唯一标识确定该动态消息是否已经生成并发布过，服务器接收到最后一个包时缓存该唯一标识，当由于网络故障或延时等原因，可能会导致重复发送最后一个包到服务器，服务器通过该唯一标识可以确认该条富文本动态消息是否已经生成过，从而不会重复生成该富文本动态消息。该唯一标识具体可以根据用户ID及时间戳生成。
[0050]在本实施例中，最后一个包的内容还包括:动态消息附件类型，例如类型为文本、图片、视频和/或音频等、各附件对应的回包内容，若发布的状态信息还包括文本信息，则最好一个包中还包括该文本信息。各个回包中信息包括对应附件类型、附件的服务器地址、较小尺寸缩略图UR1、较大尺寸缩略图URI等信息，若附件为视频或音频时，还可以包括音视频文件的长度等信息。服务器接收到最后一个包后，根据最后一个包中的信息，生成动态信息并发布。
[0051]在上面的方案中，由于将整条富文本动态进行按附件多次上传，减少了一次上传的包的大小，所以每一次上传的成功率也就提高了。遇到多媒体文件个数很多(比如用户分享了很多张图片)的时候，也不会出现由于多媒体文件过多导致最终包过大而上传失败的问题。此外，由于每个附件单独打包上传，相对于现有技术中将需要上传的图片、音视频等富文本附件按照一定压缩比例转换成二进制码，然后跟文本动态按照一定协议拼成一个包上传的方式，降低了富文本附件的失真率，提高了上传附件的清晰度和附件的展示效果。
[0052]但是在实际情况中，在某个时间段，由于网络不好导致某个附件上传失败，其他附件即使都上传成功，整条动态也将发布失败。因此，本发明的发明人在上述方案的基础上，引入了如下重发机制以提高发布动态的成功率:
[0053]对于每一个附件，如果上传失败，就再重发预设次数，如三次。也就是说，只有四次上传，每一次都失败的时候，才判定整条动态发送失败。为了节省流量，如果有附件上传四次都失败，其他图片也停止上传，整个动态才会被判定发布失败。为了保证每一个附件的上传的成功率，采用队列机制。每个附件上传失败后，如果在重发次数之内，那么重新上传的时候，就把这个待重新上传的附件放在附件上传队列的队尾。这样可以使得每个附件的每一次上传，都有一定的时间间隔，在信号不稳定的情况下，能最大程度的保证发布的成功率。这样，由于某一个图片发布失败而导致整个动态发布失败的问题，就可以得到解决。
[0054]但是，在实际情况中，如果是在地铁里发布这条富文本动态消息，可能经过某一站的时候手机没有信号，如果某个附件总共4次的上传，都赶在手机没信号的这一刻上传，4次重发机会很快就会用完，达不到提高发布成功率的效果。针对这种情况，本申请中还采用了如果当前环境无法检测到网络，附件就不进行上传的策略。但是，这种解决方案，也只针对无网的情况才能有效。还有一种情况是弱网。弱网的情况是，手机有时候能检测到网络，但是时断时续。或者打个比方，当前这个手机能连上自家的wifi路由器，但是这个无线路由器并没有连接到外网。这一时刻，我们也是能检测到wifi网络信号存在的，但是却无法真正连接到网络。数据包也就发不出去。
[0055]针对上述比较复杂的情况，本申请中提出了延时重发方案。也就是，当同时上传多个附件的时候，对附件进行分组，每3个附件为一组进行发送，其他的待发送的附件处于等待状态。如果其中一组附件上传成功，才在等待队列中取出下一组待发送的附件进行上传。如果之前上传的附件中，有一个附件已经上传失败达到一定次数(小于等于重发预设次数，例如两次)，整体网络情况就被定义为弱网。弱网环境下，我们对每一条动态消息，都设置动态发布非超时时间段(可以为30分钟，即以开始向服务器上传该动态消息的内容起始的30分钟时间段是该动态消息的动态发布非超时时间段)。每一个附件的每一次重发，我们都设置了一定的间隔时间。间隔时间内，如果收到了系统网络连接成功的通知，就立刻进行发送。如果间隔时间内没有网络连接成功通知(针对于上面所说的，能连接到路由器，但是连不到外网的情况)，到达了间隔时间，就重新发送。每一次发送数据包之前，都判断一下当前网络状况，如果连不上网，就不进行发送。直到有了连网成功通知，而且在动态发布非超时时间段内(离开始上传不超过30分钟)，