手机客户端网络加速技术方案实现思考 — 数据压缩技术-出家如初,成佛有余

作为对前段时间手机客户端网络加速技术方案实现思考的思考延续，继续考虑一下手机客户端网络通信性能优化。

1、手机客户端实现的制约因素

对于基于互联网应用的手机客户端开发而言，在设计与服务器端通信协议设计时候，不可避免要考虑目前手机终端特点、运营商业务、服务器端实现的各种限制，包括：

功能型手机(Feature Phone) vs. 智能手机：目前功能性手机仍然占据较大的市场，基本上大部分的Java手机均支持HTTP方式进行通信的（MIDP 1.0），但支持SOCKET通信方式的Java手机较少(MIDP 2.0)。
手机CPU频率及处理性能：相对于PC CPU的处理性能而言，目前手机CPU频率相对还是较低、处理性能也相对还弱，尚不适合完成较为复杂的计算处理，同时也不适合多线程、多进程的并发处理。
手机RAM、ROM、Flash内存：目前RAM、ROM、Flash还是相对较小，因此尚不适合进行较为消耗内存的计算处理，同时也不适合较大的应用数据存储。
运营商网络带宽：在2G时代带宽仍然是客户端应用最大的约束因素之一，按照中国运营商们的一贯作风，可以预见短期内即使在3G时代带宽问题也不会达到运营商们所宣传的高速率的美好前景。
流量资费：各运营商还是上网资费相对较贵
运营商网络限制：例如cmnet、cmwap的防火墙限制（诸如同时并发的请求数限制、socket、http代理等）、移动白名单、LBS等等
服务器端高并发处理：在大用户量、高并发的情况下，服务器端如果处理速度较慢，也会导致与客户端交互过程的缓慢
协议解析的方便性、可扩展性、性能
其他因素：诸如签名、电池待机时间、用户交互体验等其他因素

2、http+xml方案缺点

基于以上一些因素考虑，尤其考虑到协议定义清晰易懂、协议扩展方便、服务器及客户端协议解析的方便性以及cmwap、cmnet网络环境下处理一致性、手机终端支持等因素的考虑，采用了http+xml数据报文方式来定义通信协议（关于采用http+xml作为协议实现与采用socket+自定义字节报文方式实现的优缺点在后续专门讨论）。

但采用http+xml报文的方案存在如下的一些弱点：

1、xml报文的解析速度较慢，对手机CPU、内存的占用相对较高

2、对服务器端而言，xml报文方式相对来说解析速度也较慢，导致交互过程较慢，对服务器端处理性能要求也较高，尤其是在大用户量情况下

3、xml报文冗余信息较多，传输数据量较大，从而导致更高的流量费用

对于1、2来说，目前只能在协议设计、程序实现上进一步优化，很难立竿见影，但对于3，可以在传输中采用数据压缩的方式来降低客户端与服务器端传输的数据量（尽管会加重客户端及服务器端的处理负担，但考虑到流量的降低可以有效提高与客户端的交互速度及降低流量费用，还是值得的一试的）。

3、数据压缩方案

目前可供选择的对xml数据压缩的方案包括：

Gzip（Deflate）
wbXML
wbXML+ Gzip
ASN.1
ASN.1 + Gzip
XML Information Set
XML-binary Optimized Packages（XOP）
XMill 、Fast Web Services、XML Binary Infoset (XBIS)、bzip压缩等方案

在考察选择以上这些压缩方案是，可以按照如下一些标准来度量方案的优劣：

标准1: 压缩率较高

标准2：压缩、解压缩速度较快

标准3：协议易懂，较为容易理解和实现

标准4：相对成熟的第三方的API及开发包支持

标准5：实际应用需求

当然这些标准并不能帮助回答哪一个最优选择，选择的关键还是在于“那一种方案更为适合我的应用需要”。

按照以上标准，从日常的开发应用而言，gzip、wbXML、wbXML+ Gzip 这三种方案是较为合适的选择。

Gzip（Deflate）：服务器端可以直接通过配置apache、tomcat等来实现对gzip、deflate的支持（用压缩工具来提高web应用程序效率），java、python对gzip也有较好的库支持。在客户端symbian、windows mobile、j2me等都提供了对gzip的支持

wbXML ：在服务器端可以参考funambol、kXML的实现，在客户端可参考kXML、libwbxml项目的实现

关于各种压缩方式压缩比率的比较，可以参考A Comparison of Compression Techniques for XML-based Security Policies in Mobile Computing Environments