Ⅰ android性能优化（八）--Android图片内存优化
2个基本原则
既然需要的内存公式已得到，那优化就显而易见了，无非就是减小的这三个参数的值，具体的策略如下：
这里我们将图片分为2种情况来探讨：
图片占用的内存 大小为：
为什么mipmap不在这种情况的考虑范围之内呢？
因为mipmap是Android系统为了避免Launcher Icon变形而添加的资源目录，也就是说，mipmap中的图片不会被缩放。所以Google也不推荐将除Launcher Icon之外的图片放在mipmap目录中。
本地图片通常都是通过Android提供的BitmapFactory来加载的, 这里看几个常用的API：
图片的优化可通过Options参数来实现(Options的介绍可参考 从fresco 看图片优化 ：
inPreferredConfig的取值为Bitmap.Config类型(这里只考虑以下几种情况)，它是一个枚举类型，用来设置每个像素需要的字节数：
1.jpeg和gif
2.webp
3.png8, png24, png32
网络图片通常我们都是使用开源库进行加载, 所以不需要拿到Bitmap再进行缩放或裁剪。
这时可让后台实现网络图片的裁剪，即：根据图片的请求参数返回合适的尺寸，最大也只需要控件的大小即可。
再大也没意义，不仅浪费流量，还占用内存。
如果你的APP中有很多图片，那么可对图片的宽高根据设备的内存情况进行适当的缩小：
尽量为所有分辨率创建资源 资源匹配分辨率 = 减少不必要的缩放，从而提高UI绘制效率
对于一个多图片的APP来说，图片所占内存的优化是一项必不可少的工作。
总的来说，其优化也就是通过 缩放 和指定 Bitmap.Config的值 来实现的，只是不同位置，不同格式的图片有所差异而已。
https://juejin.im/post/5af84f4b51882542714fdaa9?utm_medium=an&utm_source=weixinqun
Ⅱ Android 图片加载（一）高效加载Bitmap 基础篇
由于Bitmap的特殊性以及Android对单个应用所规定的最大内存限制，我们在同时加载大量Bitmap时很容易发生内存溢出，即我们通常所说的OutOfMemoryError（OOM），因此高效加载Bitmap就成为了每个Android开发者的必备技能。
在学习如何高效地加载Bitmap之前，首先介绍一下如何加载一个Bitmap。我们都知道，Bitmap在Android中通常指的是一张图片，那么如何将JPG、PNG等格式的图片转换成Bitmap对象呢？BitmapFactory类给我们提供了一些方法：
接下来开始介绍如何高效地加载Bitmap，其实核心思想很简单： 就是采用BitmapFactory.Options参数来调整图片尺寸来适配控件的大小。
假如我们显示图片的控件ImageView宽高为100×100像素，而图片的尺寸为1024×1024像素，这个时候如果将整个图片加载进来并显示到控件上，自然是很占用内存资源的。这个时候可以通过BitmapFactory.Options按一定的采样率加载缩小后的图片，再将缩小后的图片显示到ImageView中，这样就能减小内存占用从而在一定程度上避免OOM的发生。
通过BitmapFactory.Options来缩放图片，主要是使用它的inSampleSize参数，也就是前面提到的采样率。当采样率inSampleSize为1时，采样后的图片大小为原图大小；当采样率inSampleSize>1，比如为2时，采样后的图片宽高都为原图的1/2，即像素降为原图的1/4，占用的内存大小也就是原图的1/4；比较特殊的是，当采样率inSampleSize<1时，系统会自动将该值当做1来处理。 因此可以得出一个结论：采样率inSampleSize必须是大于1的整数图片才会有缩小的效果，并且采样率同时作用于宽高，也就是说采样后的图片会缩小到原图的1/(inSampleSize^2)。比如inSampleSize=4，那么缩放比例为1/16。
我们现在知道了，通过采样率可以提高图片的加载效率，那么如何才能计算出最合适的采样率？我们可以按照如下流程：
接下来以decodeFile方法为例实现图片的缩放，其他三个方法处理方式类似。
下一篇： Android 图片加载（二）图片加载框架Glide 入门篇
《Android开发艺术探索》
Ⅲ Android图片加载及虚化效果
[TOC]
使用如下方式加载图片
会导致OOM，android对于直接通过资源id载入的资源需做cache，下次再需要此资源的时候直接从cache中得到。但这样做也造成了用过的资源都会在内存中，这样的设计不是很适合使用了很多大图片资源的应用，这样累积下来应用的内存峰值是很高的。
当使用诸如
imageView.setBackgroundResource
imageView.setImageResource
BitmapFactory.decodeResource
这样的方法来设置一张大图片时，在完成decode后，最终都是通过java层的createBitmap来完成的，需要消耗更多内存。因此，改用先通过BitmapFactory.decodeStream方法，创建出一个bitmap，再将其设为ImageView的 source，decodeStream最大的秘密在于其直接调用JNI>>nativeDecodeAsset()来完成decode，无需再使用java层的createBitmap，从而节省了java层的空间。如果在读取时加上图片的Config参数，可以有效减少加载的内存，从而有效阻止抛OOM异常。
实际使用中，可以针对bitmap做如下操作
RenderScript是Google在API11中引入的类，可看作业android内置的图片处理框架（区别于Glide等图片处理框架，RenderScript注重于图片的处理而不是加载）。RenderScript实际操作基于RenderScript Intrinsics，一些可以帮助RenderScript快速实现各种图片处理的操作类。该类包含诸多操作功能，比如利用ScriptIntrinsicBlur，就可以简单高效地实现高斯模糊效果，可通过参数radius设置虚化的程度。
1920*1080的原始图片未经压缩读取时间可能会超过1s，使用该图片作为背景图片加载时会有明显的卡顿。此时就需要设置BitmapFactory.Options实现对待加载图片的压缩。可参照 https://blog.csdn.net/u012124438/article/details/66087785 逐步优化Bitmap加载。对于加载图片较多较频繁的功能，建议使用第三方的图片加载框架，如Glide或者Picasso。
需要注意的是，此处doBlur有两个重载，可根据需要设置图片的缩放比例.这种方式和前文通过BitmapFactory.Options设置Bitmap取样格式的效果是一致的，都是为了减小Bitmap加载的资源消耗，提高加载效率。
Ⅳ android 加载大量图片速度慢是什么原因，是访问sd卡慢，还是使用bitmap的时候慢
android 加载大量图片速度慢原因一般是访问sd卡慢，SD卡读取速度较慢造成的加载文件速度慢。
加载，汉语词语，字面意思是增加装载量。现多用于计算机相关领域，表示启动程序时文件或信息的载入。
位图文件(Bitmap)，扩展名可以是.bmp或者.dib。位图是Windows标准格式图形文件，它将图像定义为由点(像素)组成，每个点可以由多种色彩表示，包括2、4、8、16、24和32位色彩。例如，一幅1024×768分辨率的32位真彩图片，其所占存储字节数为:1024×768×32/8=3072KB
位图文件图像效果好，但是非压缩格式的，需要占用较大存储空间，不利于在网络上传送。jpg格式则恰好弥补了位图文件这个缺点。