brew平台编解码问题，请提供思路，高手请进！

[jackyqjy]

如题，在brew平台上写MMS，遇到一个问题。brew平台对图片采用的是软解码方式，从内存使用情况看，及有可能是load整个图片进行解码，当图片尺寸较大或分辨率超高，耗费内存就相当大。导致系统内存严重不足，所以后果可想而知。
在MMS中，预览图片会有涉及图片编解码。对于主动新写一封MMS或者是修改草稿箱中的MMS，在用户插入图片的时候我们可以对大图片进行缩放，使其变小。但如果是用户收到一封彩信，其中包含大图片就不是那么容易处理了，因为图片数据源直接来自SMIL的数据包中。
问题是在遇到上面这种情况，能够采用什么有效的方法，使得用户操作时尽量避免对大图片的编解码，但是界面仍然要求友好！烦请各位brew的高手提供一下思路。这个问题困扰太久，实在是有些不爽阿。

[sunwhite]

如果你能确认BREW平台是用软解码方式处理图片，那的确没有太好办法，比如你使用IImage处理图片，那么在处理完毕没有释放IImage时都会占用大量的内存，这样的情况似乎不是你能控制的，只能建议你可以考虑在处理完图片后，就释放对象，但这时需要对已经解码的图片数据做一些处理，保证解码图片的数据可以继续使用。

[jackyqjy]

Thanks楼上的提醒，你提到的我已经注意到了，无奈夹在brew和第三方的中间地带，特别是编解码的地方没有办法主动去控制它，所以现在暂时的做法是先对图片进行resize，MMS中使用resize后的小图片。这种做法只能说只减少了错误发生的机率，但不能从根本上避免。期待网上brew的高手可以提供出更好的思路，谢谢！

[aetherstone]

BREW平台是用软解码方式处理图片 ? 这句话不完全,这依赖于解码的媒体格式和OEM层的配置.大部分情况应该是DSP解码的,如果你做动态应用,而OEM手机厂商碰巧属于少数软解码方式,唉,,那就...

[jackyqjy]

纠正下，不是brew平台采用图片软解码的方式。不好意思！

[babiq]

It depends on your image format.

[jackyqjy]

结贴！