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倍多，但是还是可以接受的