Symbian提供了CMdaImageDescToBitmapUtility和CMdaImageFileToBitmapUtility来专门处理读取GIF,PNG,JPG这样的压缩图片。不过，它们都是基于Symbian主线程下的活动对象，而且整个OpenL,ConvertL两个过程是异步执行的。也就是说，你是不可能在一次函数的执行，就完成整个的装载和转换。

  它的做法是利用CallBack回调函数。首先你执行一次OpenL打开，等它活动对象跑了几圈后，打开完毕就马上执行一次MMdaImageUtilObserver::MiuoOpenComplete函数。然后你才可以执行ConvertL进行转换，然后又等活动对象再跑几圈，然后它再执行另一个回调MiuoConvertComplete函数。通过他们的参数，你就能知道是否打开和转换成功。

  不过，还是有几点要说明的。

  第一就是关于CMdaImageDescToBitmapUtility的。它的OpenL参数是一个Descriptor。但是，请注意了，这个Descriptor在MiuoConvertComplete执行前，就必须保持。所以，你千万不能直接使用TPtrC8(aBuf,aBufSize)这样传送给OpenL,一旦这样执行，它就会在MiuoOpenComplete给你一个(-5)NotSuppoted的错误提示。 同样的情况也适合于CMdaAudioPlayerUtility的NewDesPlayerReadOnlyL。

  第二，关于CFbsBitmap直接访问其数据缓冲的办法.如果是1.0的SDK,那么需要使用TBitmapUtil::Begin函数来锁定内存,然后才能操作其缓冲区.操作完成后,需要使用TBitmapUtil:End来释放锁存.如果是2.0的SDK,那么可以直接使用LockHeap和UnlockHeap函数。如果要同时锁存两个或者两个以上得BITMAP的时候，那么第二个以后的TBitmapUtil都应该使用包含TBitmapUtil引用参数的构造函数。否则第二次锁存Begin函数的时候，就会出现死循环。

  第三，CFbsBitmap内存中，每行之间的数据并非是连续的。每行的缓冲的字节数，都应该是word(4字节)的倍数。这一点和DX类式，和Bmp文件也类似。如果你的CFbsBitmap是奇数宽度，而颜色是12位色，那么每行象素数据之后，还应该有个一个16位的空白单元。