求解自定义相机短时间拍多张照片导致OOM如何解决

Question

oombitmapcamera相机

Answer 1

我做过的是操作Camera类的
mCamera.setPreviewCallback方法的
Camera.PreviewCallback回调接口的
onPreviewFrame方法
其中有个参数是byte[] data，就是每帧图像的byte数组，对其进行旋转如果知道设置过每帧动画的数据类型，例如设置了
parameters.setPreviewFormat(ImageFormat.YV12);//Camera.Parameters parameters
因为下面的旋转算法是对yv12，如果是图像是nv21算法有些类似，但需要修改下（原因是图像数据排列方式不同）。你可以百度一下
下面贴一下yv12的旋转算法（逆时针旋转90度）/**
 * 旋转数据
 * 
 * @param dst
 *            目标数据
 * @param src
 *            源数据
 * @param srcWidth
 *            源数据宽
 * @param height
 *            源数据高
 */
private void YV12RotateNegative90(byte[] dst, byte[] src, int srcWidth,
int height)
{
int t = 0;
int i, j; int wh = srcWidth * height; for (i = srcWidth - 1; i >= 0; i--)
{
for (j = height - 1; j >= 0; j--)
{
dst[t++] = src[j * srcWidth + i];
}
} for (i = srcWidth / 2 - 1; i >= 0; i--)
{
for (j = height / 2 - 1; j >= 0; j--)
{
dst[t++] = src[wh + j * srcWidth / 2 + i];
}
} for (i = srcWidth / 2 - 1; i >= 0; i--)
{
for (j = height / 2 - 1; j >= 0; j--)
{
dst[t++] = src[wh * 5 / 4 + j * srcWidth / 2 + i];
}
}
}

Answer 2

能否求告知一下如何知道图片是yv21还是nv21，还有我旋转的角度不是固定的，这个算法是否有出处，希望大神再指点详细些

Answer 3

android预览的效果默认支持为NV21和yv12，具体的你可以下面方法试着查看真机支持的格式
如果支持的话可以用parameters.setPreviewFormat(ImageFormat.YV12);之类的设置格式了。List<Integer> pvFmts = parameters.getSupportedPreviewFormats();//Camera.Parameters parameters
if (pvFmts == null || !pvFmts.contains(ImageFormat.NV21))//例如
{
Log.v(TAG, "手机不支持ImageFormat.NV21");
}
关于nv21
http://blog.csdn.net/vblittleboy/article/details/10945143
参考过的一篇，了解uv的排列旋转的思路大概是：
先对Y进行排列，再对UV进行排列，不同的编码格式的差异在于UV。
我项目中用的是YV12的转换算法。排列是U在前V在后，而I420是V在前U在后，所占位子一样。
NV21除了Y是一样的，UV是排列在一起的。就这么多资料了。靠你自己了

Answer 4

你的OOM是不是出现在Byte[]里面，你有没有试过新开一个线程就new 一个Byte[]，或者用更大的数组来存储，然后把这些数组存到一个指定的地方，处理完最近一张照片的同时异步处理这些照片，同时处理的话等待时间太长了，而且容易出错。

Answer 5

不可能是byte数组OOM的，因为android给bitmap分配的空间是8MB左右，一张清晰的照片基本应该是2M甚至更大，所以同时decode的时候会造成内存溢出，目前估计办法只能用算法甚至往JNI方面靠拢了

Answer 6

http://blog.csdn.net/taotao110120119/article/details/7450561这边文章里面我觉得对你可能是有用的，而且做法比较简单，你内存泄露其实主要就是没能够及时的释放内存导致的，那为什么没能够释放内存呢？这边文章里面有提到。

Answer 7

我之前做相关项目的时候，也是出现OOM，后来解决了。个人觉得你的问题跟我的有点类似，你自己也觉得是同时decode的时候造成的OOM吧，所以，我才说用一个数组来存一张照片，然后后面按照你的思路走，不过，这样的话，貌似有点奢侈，多了应该也会OOM，汗，这个问题还真不好解决。
加油吧，你行的！要是解决了，给个解决的思路或方案。呵呵。

Answer 8

因为目前在实习让做自定义相机项目，这个问题卡了两天了，有推荐直接对byte[]数组进行操作的，这个目前来说如果有算法应该是最佳的感觉，算法也肯定是有的，就是不知道去哪找，有点心烦

Answer 9

在每次使用完bitmap之后都有recycle和置为null，但是依旧存在OOM的问题，因为我是开线程来操作的，就可能是多条线程同时出现decode的情况，而且我查到一篇博文有说recycle不是立马回收，不知真假

Answer 10

在每次使用完bitmap之后都有recycle和置为null，但是依旧存在OOM的问题，因为我是开线程来操作的，就可能是多条线程同时出现decode的情况，而且我查到一篇博文有说recycle不是立马回收，不知真假
这个问题可能有几个原因：
1，你保存bitmap的方法有问题，如果你使用的是BitmaFactory.createBitmap这种方式，来生成图像，保存，那么，很有可能出现挂掉的情况，最好使用流操作；
2，你保存过程中，是否显示图像，如果显示，那么每次都把ImageView先设置为空，比如setImageResource(0)，然后在显示图像；
3，如果实线程冲突了，那么你记录个boolean变量，当线程执行时，变量为true，该线程执行完毕后，为false，先一个线程开启时 做个判断即可。

Answer 11

在每次使用完bitmap之后都有recycle和置为null，但是依旧存在OOM的问题，因为我是开线程来操作的，就可能是多条线程同时出现decode的情况，而且我查到一篇博文有说recycle不是立马回收，不知真假
这个问题可能有几个原因：
1，你保存bitmap的方法有问题，如果你使用的是BitmaFactory.createBitmap这种方式，来生成图像，保存，那么，很有可能出现挂掉的情况，最好使用流操作；
2，你保存过程中，是否显示图像，如果显示，那么每次都把ImageView先设置为空，比如setImageResource(0)，然后在显示图像；
3，如果实线程冲突了，那么你记录个boolean变量，当线程执行时，变量为true，该线程执行完毕后，为false，先一个线程开启时 做个判断即可。1.createBitmap是必须使用的吧，因为我要对图片做旋转剪裁还有缩放，就必须先从流里面加载一个图片，然后再将这个Bitamp作为source来create出最终的bitmap分享下我的解决方法便于往后需要的人参考：
1.在AndroidManifest中申请largeHeap=true，向系统申请应用所能拿到的最大空间，对于图片处理软件来说这个操作应该是利大于弊的
2.使用线程池进行操作，往高一点可以动态根据手机的不同内存来开启不同数量的线程
3.可以考虑往JNI方面走，但是不知道使用算法后图片处理效率是否会变慢，有试过使用算法合并两张图片，时间大概要十来秒，这方面之前还没深入研究过，所以还得尝试一下
希望有更好解决方法的朋友一起交流，这个应该是android系统经常会遇到的问题，帮助别人也是帮助自己，万分感谢！

Answer 12

在每次使用完bitmap之后都有recycle和置为null，但是依旧存在OOM的问题，因为我是开线程来操作的，就可能是多条线程同时出现decode的情况，而且我查到一篇博文有说recycle不是立马回收，不知真假
这个问题可能有几个原因：
1，你保存bitmap的方法有问题，如果你使用的是BitmaFactory.createBitmap这种方式，来生成图像，保存，那么，很有可能出现挂掉的情况，最好使用流操作；
2，你保存过程中，是否显示图像，如果显示，那么每次都把ImageView先设置为空，比如setImageResource(0)，然后在显示图像；
3，如果实线程冲突了，那么你记录个boolean变量，当线程执行时，变量为true，该线程执行完毕后，为false，先一个线程开启时 做个判断即可。1.createBitmap是必须使用的吧，因为我要对图片做旋转剪裁还有缩放，就必须先从流里面加载一个图片，然后再将这个Bitamp作为source来create出最终的bitmap分享下我的解决方法便于往后需要的人参考：
1.在AndroidManifest中申请largeHeap=true，向系统申请应用所能拿到的最大空间，对于图片处理软件来说这个操作应该是利大于弊的
2.使用线程池进行操作，往高一点可以动态根据手机的不同内存来开启不同数量的线程
3.可以考虑往JNI方面走，但是不知道使用算法后图片处理效率是否会变慢，有试过使用算法合并两张图片，时间大概要十来秒，这方面之前还没深入研究过，所以还得尝试一下
希望有更好解决方法的朋友一起交流，这个应该是android系统经常会遇到的问题，帮助别人也是帮助自己，万分感谢！
jni层可以 引用 CC写的图像合并算法，肯定不会那么慢你！我现在专业做jni+C图像处理的