如何在BREW中使用Gzip压缩减少应用程序包的大小？
目前在无线增值业务中,涉及图像、声音和数据处理的应用占很大比例,但由于掌上系统的存储能力和处理能力受到很大限制,因此目前BREW应用的大小一般都要求比较校如果图像在整个应用中占很大比例,那么减小图像的存储空间就成为非常迫切的要求。本文从一个开发者的角度阐述了一种解决存储空间限制的方法，使用Gzip压缩工具结合BREW IUnzipAStrem接口可以将资源的大小减小到原来的1/3左右。
大多数BREW开发者都回为手机的存储空间问题而苦恼吧，做个简单的小游戏，图片资源也要占个几十上百KB，有人试图用PNG图片来替代BMP图片，但在实际操作的时候会遇到不少的问题，一些底端的设备根本不支持PNG图片，即使支持在使用的时候也经常会遇到一些莫名其妙的问题。大家仔细看看BREW SDK的API文档，不难发现其中有一个IUnzipAStream接口，高通给出的描述如下：IUnzipAStream接口用于扩展IAStream接口，允许将压缩的IAStream解压并以流的方式读龋（此接口只能解压缩使用GZip算法压缩的数据）。
我的解决方案大致如下：
1. 使用Gzip压缩工具（Linux下使用GZip，Windows下使用7-Zip）压缩BMP图片、声音、数据等资源； 2. 把压缩后的文件作为资源加入到.bar文件中； 3. 在应用程序中使用IUnzipAStream接口来解压相应的数据。 注：PNG图片不能用GZip算法压缩，因为PNG图片本身已经进行了压缩处理，再用GZip算法压缩不会减少，在一些情况下甚至会变大。了解了大体步骤之后我们来简单了解一下GZip算法。GZIP最早由Jean-loup Gailly和Mark Adler创建，用于UNIX系统的文件压缩。我们在Linux中经常会用到后缀为.gz的文件，它们就是GZIP格式的。现今已经成为Internet上使用非常普遍的一种数据压缩格式，或者说一种文件格式。HTTP协议上的GZIP编码是一种用来改进WEB应用程序性能的技术。大流量的WEB站点常常使用GZIP压缩技术来让用户感受更快的速度。
GZIP文件由1到多个“块”组成，实际上通常只有1块。每个块包含头、数据和尾三部分。块的概貌如下：| ID1 | ID2 | CM | FLG | MTIME | XFL | OS | 额外的头字段 | 压缩数据 | CRC232 |ISIZE
这里强调一下和我们应用有关的块的最后一个字段ISIZE，共4个字节，存储了未压缩前数据的长度，这在解压程序中很重要。
应用程序中如何解压缩呢？我们看看下面一段解压的代码。
static uint32 UnZip(theApp *pi,int16 picId,byte **ppBuffer) { uint32size,len,ret; void*pSource; //存放压缩图片的源数据 IMemAStream*memStream; IUnzipAStream*unzipStream; byte*pSourceBuff; //存放压缩图片的有效数据 byte*tempBuff; //存放解压图片的数据 AEEImageInfo info;
ISHELL_CreateInstance(pi->m_App.m_pIShell,AEECLSID_MEMASTREAM,(void **)&memStream); ISHELL_CreateInstance(pi->m_App.m_pIShell,AEECLSID_UNZIPSTREAM,(void **)&unzipStream);
//载入压缩图片的源数据 pSource = ISHELL_LoadResDataEx(pi->m_App.m_pIShell,RES_FILE,picId,RESTYPE_IMAGE,NULL,&size); size = size-*((byte*)pSource); //计算压缩图片有效数据的长度 pSourceBuff = (byte*)MALLOC(size); MEMCPY(pSourceBuff,(byte*)pSource+*((byte *)pSource),size); //从源数据中拷贝出有效数据 ISHELL_FreeResData(pi->m_App.m_pIShell,pSource); //释放载入的源数据 //把内存流和压缩图片相关联 IMEMASTREAM_Set(memStream,pSourceBuff,size,0,FALSE); //把IUNZIPASTREAM对象设置为从内存流中读取数据 IUNZIPASTREAM_SetStream(unzipStream,(IAStream *)memStream); //计算解压后图片的大小 len = (*(pSourceBuff+size-4)) +(*(pSourceBuff+size-3)<<8) +(*(pSourceBuff+size-2)<<16) +(*(pSourceBuff+size-1)<<24); tempBuff = (byte *)MALLOC(len); //读取解压图片的数据流到tempBuff中 ret = IUNZIPASTREAM_Read(unzipStream,tempBuff,len); if (ret>0) { //如果没读完就继续读 while (ret<len) { ret += IUNZIPASTREAM_Read(unzipStream,(byte*)tempBuff+ret,len-ret); } IMEMASTREAM_Release(memStream); //释放内存流 memStream = NULL; IUNZIPASTREAM_Release(unzipStream); //释放解压流 unzipStream = NULL; //图片转换为位图放在内存中 *ppBuffer = CONVERTBMP(tempBuff,&info,FALSE); FREE(tempBuff);
return len; } else if(ret == AEE_STREAM_WOULDBLOCK||ret == 0) { IMEMASTREAM_Release(memStream); memStream = NULL; IUNZIPASTREAM_Release(unzipStream); unzipStream = NULL;
if (tempBuff) { FREE(tempBuff); } return 0; } IMEMASTREAM_Release(memStream); memStream = NULL; IUNZIPASTREAM_Release(unzipStream); unzipStream = NULL;
return 0; }
仔细分析这段代码，大概分为如下几步：
1. 用工厂方法产生内存流的指针memStream 和解压流的指针unzipStream； 2. 从资源文件中读取需要解压图片的数据，存放在pSource中； 3. 将有效的压缩图片数据拷贝到pSourceBuff中，并释放pSource; 4. 把内存流memStream和存放压缩图片数据的缓存相关联； 5. 把解压流和内存流相关联，从内存流memStream中读取压缩图片数据； 6. 根据压缩图片数据的最后4个字节计算出解压后图片的大小，并申请内存空间； 7. 从解压流unzipStream中读取解压后的数据存放到tempBuff中； 8. 释放内存流和解压流，用CONVERTBMP宏把解压后的图片数据转换为本地格式存放到ppBuff中； 9. 释放存放解压图片的内存；
细心一点可能会发现两个问题：
1. 为什么存放压缩图片数据的缓存pSourceBuff没有释放？ 2. 存放本地格式位图的缓存ppBuffer事先并没有申请内存空间 其实当pSourceBuff和内存流memStream关联之后，当调用IMEMASTREAM_Release释放内存流时就会自动释放和流关联的数据缓冲区，不需要手动释放。而CONVERTBMP宏也会自动申请大小适合的内存空间。同样声音和数据的解压函数和上面的函数大体相同，只是省去用CONVERTBMP宏进行转换的步骤。
这种方法对图片的压缩效果非常明显，可以达到PNG图片的压缩效果，对数据文件的压缩效果也比较明显，对声音文件的压缩效果可能要差一些。总体来说，这种方法可以大幅度减少应用程序的大小，而不影响质量，是为存储空间苦恼的开发者的一个不错的选择。