androidinbitmap

Ⅰ 怎么给bitmap赋值 android

Bitmap是Android系统中的图像处理的最重要的类之一。用它可以获取图像文件信息，对图像进行旋转，剪切，放大，缩小等操作。

Bitmap代表一张位图，使我们在开发中常用的资源，下面就对Bitmap进行简单的介绍。

Bitmap的获取方法：

1、使用BitmapDrawable

BitmapDrawable里封装的图片就是一个Bitmap对象，我们要把Bitmap包装成BitmapDrawable对象，可以调用BitmapDrawable的构造方法：

BItmapDrawbale drawable = new BItmapDrawable(bitmap);

如果要获取BitmapDrawable所包装的Bitmap对象，则可调用BitmapDrawable的getBitmap()方法：

Bitmap bitmap = drawbale.getBitmap();

2、Bitmap提供了一些静态方法来创建Bitmap对象（仅列举几个）：

createBitmap(Bitmap source,int x,int y,int width,int height)：从原位图source的指定坐标(x,y)开始，从中挖取宽width，高heigtht的一块出来，创建新的Bitmap对象。

createScaledBitmap(Bitmap source,int width,ing height,boolean fliter)：对源位图进行缩放，缩放称宽width，高heigth的新位图。

createBitmap(int width,int height,Bitmap.Config config)：创建一个宽width，高height的可变的新位图。

createBitmap(Bitmap source, int x,int y,int width,int height ,Matrix m,boolean fliter)：从源位图source的指定坐标(x,y)开始，挖取宽width，高height的一块来，创建新的Bitmap对象，并按照Matrix指定的规则进行变换。

3、通过对资源文件的解析获取Bitmap对象

在这里就要用到BitmapFactory这个工具类，提供的方法如下：

decodeByteArray(byte[] data, int offset,int length)：从指定字节数组的offset位置开始，将长度为length的字节数据解析成Bitmap对象。

decodeFIle(String pathName)：从pathName指定的文件中解析、创建Bitmap对象。

decodeFileDescriptor(FileDescriptor fd)：用于从FileDescriptor对应的文件中解析、创建Bitmap对象。

decodeResource(Resource res,int id)：用于根据给定的资源ID从指定的资源文件中解析、创建Bitmap对象。

decodeStream(InputStream is)：用于从指定输入流中介解析、创建Bitmap对象。

但是，在系统不断的解析、创建Bitmap的过程中，可能会由于内存小或其他原因，导致程序运行时发生OutOfMemory错误。

为此，Android为Bitmap提供了内存回收方法：

void recycle()：强制回收Bitmap对象。

还有用于判断Bitmap 对象是否被回收的方法：

boolean isRecycle();

如果Android应用需要访问系统相册，都需要借助BitmapFactory解析、创建Bitmap对象。

4 从安卓无忧中看bitmap的几种例子，下面是加载bitmap的例子，可以看里面的源码：

如果您对答案满意，请您关注一下名字中微博。

Ⅱ android开发bitmap需要释放吗

不需要的，android 虚拟机有自动回收机制。

Ⅲ Android帧动画/AnimationDrawable导致的OOM/ANR的解决方案

如果有播放超多帧动画的需求，直接点击 FrameAnimation 在github查看，基本能满足你的所有需求，就不用往下看了，基本能满足 99.99% 人的需求。

       当在应用中需要使用帧动画的时候，最先想到的就是Android提供的AnimationDrawable了，但是如果帧动画中如果包含上百帧图片，此时再用AnimationDrawable就不是那么理想了。AnimationDrawable使用一个Drawable数组来存储每一帧的图像，会直接把全部图片加载进内存。随着帧数量的增多，就算性能再强劲的机器也会卡顿、OOM。

    最近的项目中需要用到大量的帧动画（各种闪瞎24K钛合金狗眼的礼物效果，多的高达200帧），既然AnimationDrawable不行，就想到了两种解决方法。

   因为是直播的项目，包含人脸贴图等都是用opengl绘制的，如果用OpenGL绘制一层Texture直接推流还省事。只在主播端处理就行了，但是IOS那边都弄得差不多了，直接原生的不用处理也不会有什么异常什么的。。很尴尬。

    好吧，第一个不行那就想到Android自带的surfaceView啦。我首先用不同的手机测试了下应用从本地decode一个bitmap的时间（png格式，414*736，大小在30-100k之间），因为帧动画的每帧不会太大，在性能好点的设备上基本保持在10-30ms之间（不推流基本上推流状态下10ms左右，推流状态下20左右），在性能稍差的设备中基本上也不会超过50ms，所以说是没什么大问题的。

既然不能完全加载到内存，想到的就是类似视频播放或者视频直播类似的思路。首先定义一个Bitmap的缓冲区，边绘制边加载。首先加载一定数量的帧到Bitmap缓冲区，加载完成后通知SurfaceView开始绘制。SurfaceView绘制一帧完成后通知Bitmap缓冲区加载下一帧，同时将绘制过的一帧的从Bitmap缓冲区移除。一帧绘制完成后，绘制线程根据设置的帧间隔休眠一段时间，休眠完成后开始从Bitmap缓冲区获取下一帧，依此类推，一直循环，直到播放完成或者手动停止。按照这种方式实现起来，发现oom卡顿什么的果然不存在了，内存的使用情况如图。

但是看着这个垃圾桶一个挨一个，这个内存回收情况完全不正常！GC太频繁了。想着应该是这里出现了问题。[图片上传失败...(image-96f387-1512626035688)]
频繁的添加移除bitmap，导致了不算太严重的内存抖动。之所以称之为不算太严重，因为大概400ms一次，一次gc花费2ms左右。不看内存，只看运行效果。真的感觉不出来。但是呢，这样显然也是不行滴。

最常见的解决方法就是对象的复用，创建各种pool。Android也提供了Bitmap的复用方式，在加载bitmap的时候传入一个inBitmap，那么加载的bitmap就会复用原bitmap的内存空间，所以理论上将要复用的bitmap和新加载的bitmap在颜色深度一样的情况下，复用的bitmap宽高要大于新加载的bitmap。50L的桶毕竟最多只能装50L的水。关于inBitmap更多资料可以参考 这里 ， 还有这里 。（请自备梯子）。 使用起来很简单，大概就是这样

然后实现思路就是在这里修改了，把将要删除的哪一帧留下来作为inBitmap。

Ⅳ android bitmap 使用时候注意什么

一、 问题的背景和意义
在Android移动应用开发中，对Bitmap的不小心处理，很容易引起程序内存空间耗尽而导致的程序崩溃问题。比如我们常遇到的问题：
java.lang.OutofMemoryError: bitmap size exceeds VM budget.
导致该问题的出现，一般由以下几方面原因导致：
引动设备一般存储空间非常有限。当然不同设备分配给应用的内存空间是不同的。但相对不但提高的设备分辨率而言，内存的分配仍然是相对紧张的。
Bitmap对象常常占用大量的内存空间，比如：对于2592*1936的设备，如果采用ARGB_8888的格式加载图像，内存占用将达到19MB空间。
在Anroid App中经常用到ListView，ViewPager等控件，这些控件常会包含较大数量的图片资源。
二、 问题及场景分析
1 高效地加载大图片。
BitmapFactory类提供了一些加载图片的方法：decodeByteArray(), decodeFile(), decodeResource(), 等等。
为了避免占用较大内存，经常使用BitmapFactory.Options 类，设置inJustDecodeBounds属性为true。
//
BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds =true;
BitmapFactory.decodeResource(getResources(), R.id.myimage, options);
为了避免java.lang.OutOfMemory 的异常，我们在真正decode图片之前检查它的尺寸，除非你确定这个数据源提供了准确无误的图片且不会导致占用过多的内存。
加载一个按比例缩小的版本到内存中。例如，如果把一个原图是1024*768 pixel的图片显示到ImageView为128*96 pixel的缩略图就没有必要把整张图片都加载到内存中。为了告诉解码器去加载一个较小的图片到内存，需要在你的BitmapFactory.Options 中设置 inSampleSize 为true 。例如, 一个分辨率为2048x1536 的图片，如果设置inSampleSize 为4，那么会产出一个大概为512x384的图片。加载这张小的图片仅仅使用大概0.75MB，如果是加载全图那么大概要花费12MB(假设bitmap的配置是ARGB_8888).
2 不要在主线程处理图片。

众所周知的问题，不再赘述。
注意两点：1. 为了保证使用的资源能被回收，建议使用WeakReference, 以应用内存内存紧张时，回收部分资源，保证程序进程不被杀死。
2. 避免异步任务的长时间耗时操作，在任务执行结束后，及时释放资源。
3 管理Bitmap内存。
在Android开发中，加载一个图片到界面很容易，但如果一次加载大量图片就复杂多了。在很多情况下（比如：ListView,GridView或ViewPager），能够滚动的组件需要加载的图片几乎是无限多的。
有些组件的child view在不显示时会回收，并循环使用，如果没有任何对bitmap的持久引用的话，垃圾回收器会释放你加载的bitmap。这没什么问题，但当这些图片再次显示的时候，要想避免重复处理这些图片，从而达到加载流畅的效果，就要使用内存缓存和本地缓存了，这些缓存可以让你快速加载处理过的图片。
3.1 内存缓存
内存缓存以牺牲内存的代价，带来快速的图片访问。LruCache类（API Level 4之前可以使用Support Library）非常适合图片缓存任务，在一个LinkedHashMap中保存着对Bitmap的强引用，当缓存数量超过容器容量时，删除最近最少使用的成员（LRU）。
注意：在过去，非常流行用SoftReference或WeakReference来实现图片的内存缓存，但现在不再推荐使用这个方法了。因为从Android 2.3 （API Level 9）之后，垃圾回收器会更积极的回收soft/weak的引用，这将导致使用soft/weak引用的缓存几乎没有缓存效果。顺带一提，在Android3.0（API Level 11）以前，bitmap是储存在native 内存中的，所以系统以不可预见的方式来释放bitmap，这可能会导致短时间超过内存限制从而造成崩溃。 收起

Ⅳ android怎么压缩一个bitmap占用空间大小

在Android应用里，最耗费内存的就是图片资源。而且在Android系统中，读取位图Bitmap时，分给虚拟机中的图片的堆栈大小只有8M，如果超出了，就会出现OutOfMemory异常。所以，对于图片的内存优化，是Android应用开发中比较重要的内容。 1) 要及时回收Bitmap的内存 Bitmap类有一个方法recycle()，从方法名可以看出意思是回收。这里就有疑问了，Android系统有自己的垃圾回收机制，可以不定期的回收掉不使用的内存空间，当然也包括Bitmap的空间。那为什么还需要这个方法呢? Bitmap类的构造方法都是私有的，所以开发者不能直接new出一个Bitmap对象，只能通过BitmapFactory类的各种静态方法来实例化一个Bitmap。仔细查看BitmapFactory的源代码可以看到，生成Bitmap对象最终都是通过JNI调用方式实现的。所以，加载Bitmap到内存里以后，是包含两部分内存区域的。简单的说，一部分是Java部分的，一部分是C部分的。这个Bitmap对象是由Java部分分配的，不用的时候系统就会自动回收了，但是那个对应的C可用的内存区域，虚拟机是不能直接回收的，这个只能调用底层的功能释放。所以需要调用recycle()方法来释放C部分的内存。从Bitmap类的源代码也可以看到，recycle()方法里也的确是调用了JNI方法了的。 那如果不调用recycle()，是否就一定存在内存泄露呢?也不是的。Android的每个应用都运行在独立的进程里，有着独立的内存，如果整个进程被应用本身或者系统杀死了，内存也就都被释放掉了，当然也包括C部分的内存。 Android对于进程的管理是非常复杂的。简单的说，Android系统的进程分为几个级别，系统会在内存不足的情况下杀死一些低优先级的进程，以提供给其它进程充足的内存空间。在实际项目开发过程中，有的开发者会在退出程序的时候使用Process.killProcess(Process.myPid())的方式将自己的进程杀死，但是有的应用仅仅会使用调用Activity.finish()方法的方式关闭掉所有的Activity。 经验分享： Android手机的用户，根据习惯不同，可能会有两种方式退出整个应用程序：一种是按Home键直接退到桌面;另一种是从应用程序的退出按钮或者按Back键退出程序。那么从系统的角度来说，这两种方式有什么区别呢?按Home键，应用程序并没有被关闭，而是成为了后台应用程序。按Back键，一般来说，应用程序关闭了，但是进程并没有被杀死，而是成为了空进程(程序本身对退出做了特殊处理的不考虑在内)。 Android系统已经做了大量进程管理的工作，这些已经可以满足用户的需求。个人建议，应用程序在退出应用的时候不需要手动杀死自己所在的进程。对于应用程序本身的进程管理，交给Android系统来处理就可以了。应用程序需要做的，是尽量做好程序本身的内存管理工作。 一般来说，如果能够获得Bitmap对象的引用，就需要及时的调用Bitmap的recycle()方法来释放Bitmap占用的内存空间，而不要等Android系统来进行释放。 下面是释放Bitmap的示例代码片段。 // 先判断是否已经回收 if(bitmap != null && !bitmap.isRecycled()){ // 回收并且置为null bitmap.recycle(); bitmap = null; } System.gc(); 从上面的代码可以看到，bitmap.recycle()方法用于回收该Bitmap所占用的内存，接着将bitmap置空，最后使用System.gc()调用一下系统的垃圾回收器进行回收，可以通知垃圾回收器尽快进行回收。这里需要注意的是，调用System.gc()并不能保证立即开始进行回收过程，而只是为了加快回收的到来。 如何调用recycle()方法进行回收已经了解了，那什么时候释放Bitmap的内存比较合适呢?一般来说，如果代码已经不再需要使用Bitmap对象了，就可以释放了。释放内存以后，就不能再使用该Bitmap对象了，如果再次使用，就会抛出异常。所以一定要保证不再使用的时候释放。比如，如果是在某个Activity中使用Bitmap，就可以在Activity的onStop()或者onDestroy()方法中进行回收。 2) 捕获异常 因为Bitmap是吃内存大户，为了避免应用在分配Bitmap内存的时候出现OutOfMemory异常以后Crash掉，需要特别注意实例化Bitmap部分的代码。通常，在实例化Bitmap的代码中，一定要对OutOfMemory异常进行捕获。 以下是代码示例。 Bitmap bitmap = null; try { // 实例化Bitmap bitmap = BitmapFactory.decodeFile(path); } catch (OutOfMemoryError e) { // } if (bitmap == null) { // 如果实例化失败 返回默认的Bitmap对象 return defaultBitmapMap; } 这里对初始化Bitmap对象过程中可能发生的OutOfMemory异常进行了捕获。如果发生了OutOfMemory异常，应用不会崩溃，而是得到了一个默认的Bitmap图。 经验分享： 很多开发者会习惯性的在代码中直接捕获Exception。但是对于OutOfMemoryError来说，这样做是捕获不到的。因为OutOfMemoryError是一种Error，而不是Exception。在此仅仅做一下提醒，避免写错代码而捕获不到OutOfMemoryError。 3) 缓存通用的Bitmap对象 有时候，可能需要在一个Activity里多次用到同一张图片。比如一个Activity会展示一些用户的头像列表，而如果用户没有设置头像的话，则会显示一个默认头像，而这个头像是位于应用程序本身的资源文件中的。 如果有类似上面的场景，就可以对同一Bitmap进行缓存。如果不进行缓存，尽管看到的是同一张图片文件，但是使用BitmapFactory类的方法来实例化出来的Bitmap，是不同的Bitmap对象。缓存可以避免新建多个Bitmap对象，避免内存的浪费。 经验分享： Web开发者对于缓存技术是很熟悉的。其实在Android应用开发过程中，也会经常使用缓存的技术。这里所说的缓存有两个级别，一个是硬盘缓存，一个是内存缓存。比如说，在开发网络应用过程中，可以将一些从网络上获取的数据保存到SD卡中，下次直接从SD卡读取，而不从网络中读取，从而节省网络流量。这种方式就是硬盘缓存。再比如，应用程序经常会使用同一对象，也可以放到内存中缓存起来，需要的时候直接从内存中读取。这种方式就是内存缓存。 4) 压缩图片 如果图片像素过大，使用BitmapFactory类的方法实例化Bitmap的过程中，需要大于8M的内存空间，就必定会发生OutOfMemory异常。这个时候该如何处理呢?如果有这种情况，则可以将图片缩小，以减少载入图片过程中的内存的使用，避免异常发生。 使用BitmapFactory.Options设置inSampleSize就可以缩小图片。属性值inSampleSize表示缩略图大小为原始图片大小的几分之一。即如果这个值为2，则取出的缩略图的宽和高都是原始图片的1/2，图片的大小就为原始大小的1/4。 如果知道图片的像素过大，就可以对其进行缩小。那么如何才知道图片过大呢? 使用BitmapFactory.Options设置inJustDecodeBounds为true后，再使用decodeFile()等方法，并不会真正的分配空间，即解码出来的Bitmap为null，但是可计算出原始图片的宽度和高度，即options.outWidth和options.outHeight。通过这两个值，就可以知道图片是否过大了。 BitmapFactory.Options opts = new BitmapFactory.Options(); // 设置inJustDecodeBounds为true opts.inJustDecodeBounds = true; // 使用decodeFile方法得到图片的宽和高 BitmapFactory.decodeFile(path, opts); // 打印出图片的宽和高 Log.d("example", opts.outWidth + "," + opts.outHeight); 在实际项目中，可以利用上面的代码，先获取图片真实的宽度和高度，然后判断是否需要跑缩小。如果不需要缩小，设置inSampleSize的值为1。如果需要缩小，则动态计算并设置inSampleSize的值，对图片进行缩小。需要注意的是，在下次使用BitmapFactory的decodeFile()等方法实例化Bitmap对象前，别忘记将opts.inJustDecodeBound设置回false。否则获取的bitmap对象还是null。 经验分享： 如果程序的图片的来源都是程序包中的资源，或者是自己服务器上的图片，图片的大小是开发者可以调整的，那么一般来说，就只需要注意使用的图片不要过大，并且注意代码的质量，及时回收Bitmap对象，就能避免OutOfMemory异常的发生。 如果程序的图片来自外界，这个时候就特别需要注意OutOfMemory的发生。一个是如果载入的图片比较大，就需要先缩小;另一个是一定要捕获异常，避免程序Crash。

Ⅵ bitmap璁剧疆锲剧墖澶у皬-Android鍐呭瓨浼桦寲浜旓细Bitmap浼桦寲