请选择 进入手机版 | 继续访问电脑版

网络科技

    今日:0| 主题:284363
收藏本版
互联网、科技极客的综合动态。

[其他] 网易云信 IM 推送保障及网络优化实践

[复制链接]
时鐘轻摇寂寞 发表于 2016-10-9 19:14:55
504 26
本文根据网易云信Android端高级技术架构师 周江华在 MDCC 2016 移动开发者大会 上的演讲整理而成,PPT 下载地址: https://github.com/MDCC2016/Android-Session-Slides 。
     

网易云信 IM 推送保障及网络优化实践

网易云信 IM 推送保障及网络优化实践-1-网络科技-推送,进程,可以,一个,消息
      网易云信Android端高级技术架构师 周江华   大家好,我是来自网易云信的周江华,从 2009年毕业至今,我一直在从事 IM 客户端的研发工作,最早是 Windows 客户端开发,直至 2011 年开始转向移动端,先是 iOS,到 2012 年开始进行 Android 端的开发,从 2014 年到现在,一直负责云信 Android SDK 的开发工作。今天,我想和大家分享的是云信在保障 IM 推送和移动网络优化方面的一些实践经验。
  对于移动 App 来说,除了简单的工具类 App 外,IM 功能可谓非常重要,它能够创建起人与人之间的连接。社交类产品中,用户与用户之间的沟通可以产生出更好的用户粘性。电商类产品,用户与商家的连接能极大的促进沟通效率,降低沟通成本。教育类产品,学生与老师的连接让在线教育犹如课堂。医疗类 App,医生与患者的沟通让医生把脉更加准确。
  IM 应用如此之广泛,那么,IM 是什么,有些什么要求呢?IM 由两个字组成:Instant,Messaging。即时性要求有新消息时能够立即收到,如果程序在后台,则要能立即收到推送通知。而通信则要求稳定可靠,系统不宕机,程序不崩溃,安全,传递消息时不会被拦截监听,消息不丢,顺序不乱,不重复,如果包含音视频聊天,则要求延迟低,流畅不卡顿。这两点说起来容易,但是,要真正做出一套稳定可靠的商用级IM系统,挑战非常之多。下面,我会挑选影响 IM 即时性和消息稳定性最核心的两个问题,来看看都有哪些障碍,以及云信是如何去实践克服这些障碍的。
  首先第一个问题是消息推送,在 iOS 端有 APNS 做推送,相当稳定。Android 本身也有 GCM 可以用,但是在国内,我们有一个叫作“墙”的东西,直接就把 GCM 等 Google 服务全部挡在外面了,导致国内根本无法运用。对于 IM,当 App 退到后台,是必须还能够收到新消息提醒的,没有 GCM,怎么办?唯一能做的,就是后台运行了。Android 从设计上,就是支持真后台运行的,后台运行的特性也是 Android 现在能如此成功的原因之一。但另一面,Android 长久以来一直摆脱不了的卡顿、耗电等坏名声,后台运行也拖不了干系。因此,系统对于后台运行也不会放任自流。App 想要在后台运行,需要面对不少的障碍。
  第一个障碍是 Android 的 Low Memory Killer 机制。手机的内存毕竟是有限的,当后台运行的进程越来越多,内存剩余量也就随之减少。当有一个新的 App 想要启动,如果此时内存不够了,LMK 机制就会启动,从正在运行的进程中挑选一个清理掉,释放出空间,然后新的 App 就可以云信了。这个挑选过程显然不会随机拼人品,LMK 有两个尺度去评判。一个是进程优先级,优先级越低,被清理的可能性越大,另一个是内存占用,占的内存越多,被清理的权重自然也越大。
  因为 LMK 机制的存在,虽然 App 允许在后台运行,但同样也面临随时被清理的风险。因此,我们需要在被清理后及时的重新启动。常规的,有 4 种方式能够做到:
  
       
  • sticky service,就是在 Service 的 onStartCommand 中返回 sticky flag,这样当 service 被 kill 掉后,系统会将它加入重启的 pending 列表,在后面合适的时机再把 service 重启;   
  • alarm,闹钟,有循环闹钟和一次性闹钟两种,在闹钟触发后启动对应的组件;   
  • 在 Manifest 文件中静态注册的 Receiver,通过监听各种系统事件,比如开机、网络变化、mount/unmounts 等。在这些事件发生时启动组件,因为这种方式会造成在这些事件发生时系统容易卡顿,在7.0里面,Android增加了限制;   
  • JobScheduler,这是在 5.0 里面新增的,允许 App 在特定事件发生时做一些动作,比如充电、切换到 Wi-Fi 等。  
     

网易云信 IM 推送保障及网络优化实践

网易云信 IM 推送保障及网络优化实践-2-网络科技-推送,进程,可以,一个,消息
    虽说无论怎么做,App 终究免不了一死,但通过对照 LMK 的评判准则,我们还是可以降低 App 被清理的概率的。第一个就是降低进程的内存占用。如果采用单进程的模式,由于进程中包含了 UI、Webview、各种图片缓存等内容,内存必然会居高不下,降不下来。IM 软件一般都会采用双进程甚至多进程的策略,将 push 进程独立出来,在 push 进程里只处理网络连接和 push 业务,不参与任何其他业务逻辑,更不包含任何 UI。
     

网易云信 IM 推送保障及网络优化实践

网易云信 IM 推送保障及网络优化实践-3-网络科技-推送,进程,可以,一个,消息
      

网易云信 IM 推送保障及网络优化实践

网易云信 IM 推送保障及网络优化实践-4-网络科技-推送,进程,可以,一个,消息
    我们来看一下云信 Demo 的进程内存占用情况。上面一个是主进程,看第四列 PSS 的数据,内存占用是 50M 左右,下面一个是 push 进程,内存占用只有 10M 左右。当处于后台时,push 进程被清理概率比 UI 主进程低很多。
     

网易云信 IM 推送保障及网络优化实践

网易云信 IM 推送保障及网络优化实践-5-网络科技-推送,进程,可以,一个,消息
    降低被清理概率的第二个手段是提升进程优先级。我们先看这个例子,这是绿色守护的一个截图,我们评价其他 App 的行为,也不打广告,所以这里对 icon 和名字做了模糊处理。看最上面,这一组是“暂不自动休眠”,因为这里列出的两个 App 的状态都是工作中,对应的进程优先级是“可视进程”。但这两个 App 并没有提供桌面小部门在运行,也没有指示前台服务的常驻通知栏提醒,事实上,它们就只是在后台运而已。通常进程退到后台后,其进程优先级类型就变成了较低的后台进程,而不是这样的“可视进程”,它们是通过什么方法来提升优先级,降低被清理概率的呢?
     

网易云信 IM 推送保障及网络优化实践

网易云信 IM 推送保障及网络优化实践-6-网络科技-推送,进程,可以,一个,消息
    Android 在设计前台服务上有一个漏洞,通过两个服务配合,我们就能创建一个隐形的前台服务。这里有两个已经启动的 service: A 和 B。先在 A 中调用 startForeground,提供一个 NOTIFY_ID, 然后 A 就变成前台服务了,同时有了一个 ID 为 NOTIFY_ID 的常驻通知栏提醒,然后我们在 B 中也调用 startForeground,提供相同的 NOTIFY_ID, B 也变成了前台服务,因为两个通知 ID 相同,因此这一次就不会创建新的通知栏提醒了。然后再在 A 中调用 stopForeground,A 的前台属性被取消,同时,常驻通知栏提醒也会被移除,但是,service B 并不会受到任何影响,还是前台服务,这是再把 A 停掉,进程就只剩下前台服务 B 了,进程也变成了前台进程,但用户不会有任何感知。
  正常来说,做了上面三步之后,我们的进程就能够比较稳定地在后台运行了。但是后来发现,在有些情况下,我们的推送进程却永远起不来。跟踪之后发现,除了系统能够杀掉后台运行的进程外,用户也一样是可以杀死进程的。用户杀掉进程的方式有两种,一种是在最近任务列表中将 App 划掉,这种方式和系统杀掉进程效果相同。另外一种就是通过这里的 force stop,这种方式比系统清理更加彻底。不但 App 正在运行的进程会被清理,App 当前在重启列表中的待重启服务,注册的各种闹钟、事件监听组件等都会被移除,除非用户在主动点击或者系统重启等外力,App 没法再自己重新爬起来了。
  我们后来还发现,在有些国内的像 MIUI 一类的 ROM 上,用户从最近任务列表中将 App 移除,效果竟然也是 force stop。正常来说,如果是用户主动操作,我们 App 本身也不应该再重启了。但有些时候这个并不是用户本意。况且,对于 IM 软件来说,消息提送是一定要得到保障的,否则不明正确的吃瓜群众们会觉得是我们软件不行,连消息推送都做不好。因此,这时候还是应该想办法继续维持后台运行。那么,又有哪些办法呢?
     

网易云信 IM 推送保障及网络优化实践

网易云信 IM 推送保障及网络优化实践-7-网络科技-推送,进程,可以,一个,消息
    第一个是通过两次 fork 加上 exec 的方式。两个 fork 后,第一次 fork 的进程退出,第二次 fork 出来的进程就会被 init 进程领养。用户此时再 force stop,因为这个进程父进程是 init,而不是 Zygote,因此不会被清理。由于这个进程还是从 Android 进程 fork 出来的,带有 Android 运行时环境以及父进程的资源,所以内存会比较大。这里可以再通过 exec 命令,打开一个纯 Linux 的可执行文件,开启一个 daemon 进程,其内存占用大概只有100K+,对用户也就完全无感了。利用这个后台进程,可以定时地将 push 进程拉起来。此种方式只在 5.0 以下的系统中有效,在 4.4 及以上系统中,SELinux 特性是强制开启的,exec 没有权限执行,同时在 5.0 之后,ActivityManager 在做 force stop 以及移除任务时,只要是具有相同的 uid 的进程,就会全部清理掉,不再漏掉没有虚拟机环境的进程。
  最后一个后台保活的手段是一个大杀器,也是带有强烈的中国特色。因为前面所列的所有保活手段都不是那么保险,因此想出来这么一个互相保活的方式。当一个 App 进程起来后,它就去扫描已安装的应用列表,看看有没有自己的兄弟姐妹。比如说同一个长的 App,或者是集成了同一个 SDK 的 App,如果有,就把这些 App 都拉起来。这也就是现在比较出名的“全家桶”方案。虽说这种方法确实能够带来较高的后台存活率,特别是那些大厂和应用广泛的 SDK,但是这种方式对于用户的伤害也非常大,如果有后台推送的必要性,且不会对用户体验造成太大伤害时,此方式还可以使用,但如果只是为了推广告,则会对用户造成伤害,反过来,也可能会导致用户直接卸载 App。
  现在,因为“全家桶”实在是太令人讨厌,现在各种手机管理软件都会对这种唤醒方式做限制,特别是在 Root 过的机器上,可以做到完全切断这些唤醒路径。同时,很多 ROM 也会自带管理软件,限制后台运行和后台唤醒,以便给设备换取更长的续航。在目前国内的 Android 生态环境中,无论采用什么方式,想要一直在后台运行时越来越难了,我们需要重新想另外的办法来保障消息推送。另一方面,我们作为开发者,也有义务为用户提供更好体验的软件,而不是无休止的在后台浪费用户的资源。
  其实,对于 IM 来说,及时的消息推送和较低的电量消耗也并非不可兼得。在传统上,每个 IM 客户端都会各自维护一条与服务器的长连接,自己的消息和信令都在这条长连接上传递,每个 App 也独自去心跳,断线重连等事情。这种模式比较简单,不同的 App 也是完全隔离的,不会互相影响。但它的缺点也非常明显,首先是做了很多重复的事情,造成了流量和电量的无谓消耗,第二是要保证所有的进程都能在后台运行很难。优化的方向也就非常明显了,那就是共享连接,现在绝大部分推送 SDK 也是这么做的。
  从这些 App 里选出一个当前正在运行的,或者是被杀概率最低的 App 作为总代理,只由这个代理和服务器建立连接,一个手机上的所有其他 App 都通过这个代理中转与服务器通信。但是,IM有一个很基本的要求在这种模式下无法得到满足:安全。所有 App 的消息都经过代理中转,代理到服务器的连接是加密、安全的,但到了代理这里,消息都被解开了,因此代理理论上可以看到其他所有 App 的来往消息。因此,这种共享长连接的方式并不适用于 IM。
     

网易云信 IM 推送保障及网络优化实践

网易云信 IM 推送保障及网络优化实践-8-网络科技-推送,进程,可以,一个,消息
       长连接+推送    虽然共享长连接方式不合适,但仍然给我们提供了一个优化的思路。在此基础上,我们想到了另外一个可以脱敏共享连接的方式:安全长连接加推送连接模式。每个 App 在使用和真正传递数据时,仍然独立使用自己的安全长连接。而当 App 退到后台一段时间之后,则断开长连接,然后每个 App 开启一个推送代理,并选择其中一个和云信的推送服务器建立连接,之后当 App 有新消息时,就通过这个推送连接传递。 App 可以自己控制发出的推送消息的安全级别,可以是包含说话人和消息内容,可以只包含说话人,或者只是一条简单的有新消息到达的提醒文案。推送到达后,如果是代理 App 自己的消息,直接传递给代理 App 即可。如果是其他 App 消息,前面说到过,直接唤醒可能会失败,而且会导致无谓的电量消耗,所以这里并不直接将提醒传递给目标 App ,而是由带来发出一条通知栏提醒。等用户去点击通知栏提醒后,才会把目标 App 唤醒。
     

网易云信 IM 推送保障及网络优化实践

网易云信 IM 推送保障及网络优化实践-9-网络科技-推送,进程,可以,一个,消息
       系统推送    现在国内的ROM中,华为和小米的系统本来是带有推送系统,且开放给了第三方 App 的。在这两个系统上,使用系统的推送通道明显会更加稳定,也更加节省资源。因此在MIUI上,从长连接到推送通道的切换流程仍然和前面的一样,只是不再使用自己的推送连接,而是将消息转发到MIUI的推送服务器,然后转给MIUI系统的推送代理,然后传递给云信的 App 。华为的推送系统流程也是一样。不过现在华为和MIUI在推送实现上有一些区别,例如MIUI的通知栏提醒是在自己的推送代理里完成的,而华为却是将提醒通知交给 App 自己去完成的,另外,他们的通知栏提醒的管理接口也有很多区别。在 App 没有被禁用的情况下,两者都可以收到推送,而如果 App 已经被禁用了,MIUI的通知栏提醒方式还可以将推送送达,而其他的推送方式则不能送达了。
  以上就是在保障消息推送方面我们所能够做的所有事情了。如果以后有更多的系统开放自己的推送系统,我们也可以选择逐步接入,以提高推送到达即时性,减少资源消耗。不过相应的,我们也要承受不断加入各种系统的推送SDK,增大发布包体积的缺点。期望Android拥有统一推送平台的那一天早点到来吧。
  相对于PC的网络环境,我总结的手机网络有三个特点:
  
       
  • 第一个是 ,尤其是2G,3G网络,慢的令人发指。当我们收发图片视频这类比较大的文件时,就会看到蛋疼的菊花一圈一圈不停的转。   
  • 第二个是 ,手机跟着人不停的移动,网络也不停的在切换,从 Wi-Fi 到移动网络,从一个基站到另一个基站,从有信号到没信号,都可能导致网络中断。有些制式的网络,接打电话也会导致数据网络断开。另外,移动基站还有 NAT 超时,到一个连接上长时间空闲后,基站就会默默的将连接断开,没有任何通知。   
  • 第三个是 ,这个就不用多说,看中国移动每天净赚一个亿就知道了。  
  在云信整个通信系统中,我们有三种类型的连接:TCP,UDP,HTTP。虽说这三个并不是同一层的协议,不过毕竟都在我们的应用的更下层,因此这么划分也无妨。3种类型的协议对应了不同的业务应用。TCP主要是用户长连接,也就是普通IM消息和信令的传输,UDP用于传输实时音视频数据流,而HTTP则主要用在音频,图片等文件的上传下载上。对于不同的业务,我们的优化的关注点会有一些不相同。
  长连接是云信所有业务的基础,使用量也是最大的,因此优化也是从基础开始。 在这里我们举两个例子。
     

网易云信 IM 推送保障及网络优化实践

网易云信 IM 推送保障及网络优化实践-10-网络科技-推送,进程,可以,一个,消息
    第一个是协议的选择。前面说,长连接的使用量是最大,选择一个合适的协议至关重要。如果是刚开始接触IM开发,一般会选择一些开源的协议,比如XMPP,SIP等。这是XMPP协议的一个请求样例,可以看到是一段XML格式的文本数据。这是基于SIP的SIMPLE协议的一个请求样例,可以看到是一段类似HTTP协议的文本数据。这些协议的优势在于开源,有成熟的解决方案可以使用,扩展性好,甚至还可以和其他系统互联互通,协议的可读性也非常好。但是在普遍比较臃肿,冗余字段很多,在昂贵的移动网络里面用起来会让人觉肉疼。云信采用的是私有的二进制协议,这是一个请求的数据样例,这里是把二进制数据转为了16进制显示出来,每个字节这里显示为两个字符。可以看到二进制协议的特点在于完全失去了可读性,但是,却带来极高的表达效率,相对于文本协议,可以节省非常多的数据流量。
     

网易云信 IM 推送保障及网络优化实践

网易云信 IM 推送保障及网络优化实践-11-网络科技-推送,进程,可以,一个,消息
    另一个例子是登录的优化。由于移动网络经常断开,所以登录常常是心跳之外交互最多的协议了。使用量越大,优化就越有意义。一般而言,登录会经过这么几步。
  第一步是LBS。这里的LBS不是经常说的基于地址位置的服务,在不同的厂商可能也有不同的叫法,反正作用都是获取服务器的IP地址。像云信这种需要提供全球服务的系统,在世界各地都要部署服务器,用户登录时,肯定要选择一台最优的服务器接入服务。通过lbs,客户端可以获取离自己最近,连通性最好的服务器连接机IP地址,服务器也可以据此做负载均衡。
  拿到服务器连接机IP后,客户端就去连接该服务器。
  连接成功,需要有一次握手。这个握手不是TCP的三次握手,而是为了建立安全连接,同服务器协商加密算法和加密密钥。
  然后就发送登录请求,这里会带上用户认证信息,本机设备信息等数据。
  登录成功之后,就是同步数据,包括离线消息,用户信息,群组信息等。一般而言,这里不会去做全量同步,而是采用基于时间戳的增量同步。
  在移动网络上,每一次交互都需要比较长的时间,同时,每一次网络请求电量消耗也是很大的。所以,优化的方向就是尽量减少交互次数,而方法则是合并请求,并行操作以及省略请求。
  LBS和连接这两个步骤是可以并行完成的。如果前面已经获取过LBS,这里可以有之前的缓存地址,如果没有,可以先连一个默认地址。
  其次是握手和登录也可以并行操作。在握手包中,就可以把加密后的登录包直接带上去了。如果是断线重连,我们还可以简化登录,直接带上上一次登录的会话ID,一来减少服务器鉴权压力,二则可以直接带回在断线期间是否有未读消息等数据,如果没有,则能直接将同步这一步省略掉。如果有,同步也可以只做部分同步,只去拉去离线消息即可。等到 App 切换到前台,才去同步其他的信息。
  通过这些优化,登录时间可以降为原来的1/2到1/3,登录的流量消耗也可以节省30%左右。
     

网易云信 IM 推送保障及网络优化实践

网易云信 IM 推送保障及网络优化实践-12-网络科技-推送,进程,可以,一个,消息
    实时音视频对实时性要求很高,但可以容忍一定的丢包,所以我们选择 UDP 私有协议来作为底层的传输协议。如果只是普通的IM消息,对网络情况其实不是太敏感,最多也就是慢一点,菊花转得久一点。但对于这种视频电话,如果网络差了,发生了经常性卡顿,或者是延迟很高,图像出现花屏,音视频不同步了,这个功能其实也就相当于废弃了。而且,音视频数据量本身也比较大,在弱网环境下发生问题的概率就更大了。
  UDP 协议是不可靠,为了提高弱网下的实时音视频的通话效果,需要使用相关方案来做 QoS 保障:主要包括了基于 UDP 协议的拥塞控制、前向纠错 FEC 技术及相关的重传技术。同时网络层需要能够实时的探测到网络状态,作为底层调整 QoS 策略的依据,同时需要回调上层,来动态调整音视频的码率,做到音视频码率自适应。通过上面的 QoS 保障,我们实际测试在 20% 的随机丢包弱网环境下,音视频通话还能够正常进行。
  第二是音频,我们的音频编解码主要以Opus为主,它具备高音质,高压缩率,高抗丢包等特性,非常适合移动网络。我们使用智能的jitterbuffer算法来平滑由于网络抖动引起的声音卡顿和延迟累计问题。配合PLC丢包补偿算法,来降低音频丢包后的爆音。同时,我们使用自研的高性能降噪算法,配合回声消除、自动增益和舒适噪音等音频处理算法来进一步保证音频部分的质量。
  对于视频,我们使用时域分层的H264视频编码器,来降低丢包对视频流畅性的影响,同时支持动态帧率和动态分辨率,方便上层根据业务需求进行切换。现在用户对于视频的清晰度要求越来越高,我们的实时通话系统当前能够支持720p。720p下纯软件编解码对CPU开销过大,因此在可以开启硬件编解码的机器上,对于需要720p清晰度的都尽量使用硬件编解码。
  由于音视频的网络优化如果全部细说,恐怕再加1个小时也讲不完,所以这里我只提了一些优化的方向供大家参考,就不一一展开了。
  下面再来看看对于HTTP的优化。图片语音是IM的必需元素,而且本身数据比较大。在弱网环境下,快速的上传下载,更少的等待时间可以带来更好的用户体验。
  断点续传可以减少因网络原因导致的重复传输,减少传输时间,节省流量。
  图片预加载技术可以根据不用网络情况,在收到消息后,就加载不同素质的预览图片,甚至直接将原图预加载,做到用户点开即看。
  上面两个是比较基础的优化措施,下面两个则比较高级一点。
     

网易云信 IM 推送保障及网络优化实践

网易云信 IM 推送保障及网络优化实践-13-网络科技-推送,进程,可以,一个,消息
      

网易云信 IM 推送保障及网络优化实践

网易云信 IM 推送保障及网络优化实践-14-网络科技-推送,进程,可以,一个,消息
    图片和语音这种文件我们并没有通过长连接收发,而是通过HTTP去做上传下载。传统上通过HTTP上传时,文件会分为一片一片,传完一片,收到回包,才会穿下一个分片,一直到最终传输完成。可以看到,服务器返回ack这段时间,上传通道其实是空闲的,如果把这段时间利用起来,可以节约不少上传时间。Pipeline就是为此而来。通过重叠利用http请求的响应等待时间,加快传输速度。使用pipeline,需要修改HttpClient,同时还需要服务器提供支持。视网络具体情况,使用pipeline后,一次上传可以减少20%至30%的时间。
     

网易云信 IM 推送保障及网络优化实践

网易云信 IM 推送保障及网络优化实践-15-网络科技-推送,进程,可以,一个,消息
    常规发送语音消息需要这几步,先录音,然后计算hash值,然后上传,上传完毕后,服务器计算一下校验和,通过后语音消息发送成功。在前面录制语音时,网络其实也是空闲的。把这段时间利用起来,则可以减少后面上传步骤的时间。优化后,流程就变成这样。在录制的过程中,每录完一段,就作为一个分片直接上传。直到最后录完,计算好hash,再把最后一个分片带上hash信息上传。这里除了客户端的改动,也是需要服务器支持。服务器在开始接收时,很多信息都不明确,需要开辟缓存来记录整次上传过程。对于比较差的网络,边录边传的效果会更好,毕竟纯语音的比特率并不高,基本都能做到录完就传完。
  以上就是我今天分享的全部内容。提升消息推送达到率和到达速度,优化网络利用效率,节省系统资源一直都是Android开发的核心和基础,新技术,新方法都在不停的涌现,也欢迎大家一起讨论,进步,谢谢大家。
  了解最新移动开发相关信息和技术,请关注mobilehub公众微信号(ID: mobilehub)。

     

网易云信 IM 推送保障及网络优化实践

网易云信 IM 推送保障及网络优化实践-16-网络科技-推送,进程,可以,一个,消息
王思源 发表于 2016-10-9 19:37:08
只吃楼主,撸过过经验,小伙伴们都惊呆了
回复 支持 反对

使用道具 举报

黄金单身小青年 发表于 2016-10-9 19:37:42
勿以坑小而不灌,勿以坑大而灌之。  
回复 支持 反对

使用道具 举报

Lonelyplanet 发表于 2016-10-9 19:38:39
吾生也有涯,而吃也无涯.
回复 支持 反对

使用道具 举报

mingjideyu 发表于 2016-10-9 20:15:25
是爷们的娘们的都帮顶!大力支持
回复 支持 反对

使用道具 举报

语蓉 发表于 2016-10-9 20:24:20
占位编辑
回复 支持 反对

使用道具 举报

小辉煌1 发表于 2016-10-9 20:24:30
OMG!介是啥东东!!!
回复 支持 反对

使用道具 举报

国豪 发表于 2016-10-9 21:00:06
你瞧你吧!看背影急煞千军万马,转过头吓退百万雄狮。
回复 支持 反对

使用道具 举报

lsh1812 发表于 2016-10-10 01:49:05
失而复得的东西。永远都是二手货。
回复 支持 反对

使用道具 举报

收起你那虚伪 发表于 2016-10-10 19:29:51
发发呆,回回帖,工作结束~
回复 支持 反对

使用道具 举报

我要投稿

推荐阅读


回页顶回复上一篇下一篇回列表
手机版/c.CoLaBug.com ( 粤ICP备05003221号 | 文网文[2010]257号 | 粤公网安备 44010402000842号 )

© 2001-2017 Comsenz Inc.

返回顶部 返回列表