Android将bitmap存入数据库记录

有一个场景是在用户发帖的时候，当用户没有发表而退出的时候，要存储一下草稿，这里就需要把上传的图片也存一下

之前想过直接存图片的地址，但是这样就存一个用户可能在下次编辑之前把图片删掉的情况，所以只能直接存图片了

这里是将bitmap转换为byte在base64成string存在sqlite数据库中

bitmap转为byte的时候是采用JPEG的格式转的

未存之前，程序的数据为92.00KB

1. 存一张

宽高：816 x 612

byte长度：393418

程序的数据大小变为：608.00KB，增长了516KB

2. 存九张

宽高：816 x 612    816 x 612   384 x 640     816 x 612     816 x 612 

byte长度：416099    395662    200186    438182    430468

数据大小变为：2.50MB，增长了近2.4MB，平均一张图也是近500KB的大小

这样看来这个方案还是可行的，限制一下图片的数量就行。

问题：

有一个问题就是，在不断存取草稿的过程中，图片转换的字节数居然会有轻微的变化，不懂。。。

问题2：

在读草稿，也就是从数据库取出字符串的数据，在转换为byte数组，再转换为bitmap，这个过程会卡顿，耗时较长，所以我验证了一下时间都花在哪儿了。

10张图

第一次：

读数据库耗时（从数据库load出数据到对象，orm的数据库框架）：696 ms

解析数据耗时（string到byte到bitmap）：1800 ms

string到byte的base64解码：1371 ms

byte到bitmap：422 ms

第二次：

读数据库耗时（从数据库load出数据到对象，orm的数据库框架）：211 ms

解析数据耗时（string到byte到bitmap）：1889 ms

第三次：

读数据库耗时（从数据库load出数据到对象，orm的数据库框架）：142ms

解析数据耗时（string到byte到bitmap）：1994 ms

可以看到，主要的时间花在了数据转换上面，而其中base64的解码占约80%的时间，所以这方面要重点优化一下。

byte转bitmap暂时不知道咋优化，因为用的是系统的方法，目前只能往子线程丢一下，不然会阻塞主线程。

PS：其实存的时候也花很多时间，只不过我放在了destroy里，activity结束后，它在后台执行，所以不影响主线程。

---1106---

对比测试了自己在java写的base64和java系统自带的base64

字节长度：879401

次数：10

系统encode：810 ms

系统decode：971 ms

java encode：4724 ms

java decode：3723 ms

可以看出，系统快了5倍左右，估计是用native跑的，看到还是直接调系统自带的吧

问题3：

反复几次，出现OOM，说明资源未及时释放

通过DDMS的heap监控中得知，每一次进入Heap Size都在涨，而Allocated也涨，但会随着退出而相应减少。当Heap Size接近64M的时候很危险，很容易OOM，这也说明我找个手机为APP分配的heap空间是64M.

所以，我需要在最后destory的时候，把里面的bitmap都给recycle了，虽然不能马上清理，但是把这些bitmap所占的空间标为了dead，下次需要空间的时候就可以再用了。

问题4：

反复N次存取草稿之后，图片的信息有丢失，后面会损失严重，（麻痹，有这样的SB用户肯定是做测试的）

原因猜测：我是用jpg压成byte的，jpg可能有损失。

换为PNG转换后，果然上面出现的每次byte都不一样的情况消失了，每次的byte长度都一样，说明真的没有损失信息。

鉴于这种情况的存在，还是用PNG存吧，虽然byte增加了1倍多，但是还是可以接受的

http://blog.csdn.net/archer_zoro/article/details/40823315