㈠ 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格式则恰好弥补了位图文件这个缺点。
㈡ 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 图片加载（一）高效加载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 ImageView加载超长图片解决方案
在平时开发过程中，我们偶尔会发现有些较长的图片在Imageview内加载显示白屏，也没啥明显的报错，而且在不同性能的手机上有不同的效果。有的可以加载，有的不行。其实这个原因是由于GPU渲染限制导致的白屏问题。性能较差的手机上GPU的渲染限制较大，容易出现白屏的问题。针对这样的问题有以下几个解决方案，看个人的使用场景进行取舍
1、关闭硬件加速
在manifest文件里面设置 hardwareAcceleration = “false”可以关闭了硬件加速
这样是可以加载长图了，但是APP变卡了，体验非常不好，看个人取舍。
这也是最简单的方案
2、裁剪拼接显示（分割显示）
每次显示在imageView中的图不是原图的bitmap，通过一个方法
Bitmap.createBitmap(bitmap,x,y,width,height)创建一个bitmap，长宽符合屏幕要求，这样就不会超过像素限制。实际操作以后发现，的确可以显示大图，但是效果也不好，拖动的时候帧数比较低，比上一条的那种好点，但是没有达到最好的要求（就是像快图浏览里面那样的），即便手机自带的相册app也比这个流畅一些。
这个方案推荐一个比较好的库：
https://github.com/davemorrissey/subsampling-scale-image-view
使用注意点：不要设置全局的matrix canvas.concat（）
改写后：
3、取GPU支持最大的高度将图片进行缩放加载
由于是GPU加载限制导致的问题，我们可以找到GPU加载的阈值，然后通过阈值来计算出一个合理的尺寸
附几个方法：
㈤ 在android开发中加载的图片太大，有好几十兆，应该怎么办
如果图片太大会造成OOM内存溢出的错误，需要用Bitmap的压缩机制。
解决方案:
1.使用BitmapFactory.decodeStream替代createBitmap方法
原因是该方法直读取图片字节，调用JNI>>nativeDecodeAsset()来完成decode，无需再使用java层的createBitmap。
2.使用压缩读取技术
BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeFile(imageSdUri, options);
final int height = options.outHeight;
final int width = options.outWidth;
options.inSampleSize = 1;
int w = 320;
int h = 480;
h = w*height/width;//计算出宽高等比率
int a = options.outWidth/ w;
int b = options.outHeight / h;
options.inSampleSize = Math.max(a, b);
options.inJustDecodeBounds = false;
Bitmap bitmap = BitmapFactory.decodeFile(imageSdUri, options);
3.及时释放Bitamp
Bitmap对象在不使用时,我们应该先调用recycle()释放内存，然后才它设置为null.虽然recycle()从源码上看，调用它应该能立即释放Bitmap的主要内存，但是测试结果显示它并没能立即释放内存。但是我它应该还是能大大的加速Bitmap的主要内存的释放。
㈥ android怎么设置应用启动时加载图片
我觉得这主要是你测试手机的问题 还是你是用模拟器做的测试？ 最好用手机测试 还有 这种问题解决只能是你不要把很多东西都写到oncreate里面 也不要布局的太复杂 android应用需要适配那么多的机型 而且大多都是低配机 如果你的oncreate方法处理时间过长的话 肯定是会有这种现象的
㈦ Android软件开发,对于地图软件,是怎么加载图片的呢
先说当前大家常用的地图，比如网络，高德这些，他们是怎么做的。
底层实现不是纯java的，而是使用了类似opengl的技术，比如可能是osg这样的开源图像处理系统，也就是说是c/c++来做的底层，java的存在只是作为外部调用的接口。这也是为什么在做网络高德的二次开发时，你除了使用对方的jar包外，还有一些so库。至于他们使用的view已经不那么重要了，反正要底层实现，用surfaceview就可以了。
这些地图的矢量地图是由矢量数据符号化以后绘制出来的，而不是由我们在pc端浏览的地图那样的瓦片来绘制的，这一点，你在接触天地图的apk以后，会有明显的感觉。当然卫星地图还是来自瓦片数据。三维地图则是加载相应的三维数据了，因为opengl本来就是三维领域的王者。
然后说一下纯java开发地图应用的模式——我们以前就是用这个的。
这类地图是使用瓦片的，一张张的图片拼接起来的，所使用的控件就是surfaceView或者GLSurfaceView，这一类的开源项目也有很多，比如decarta，所使用的方式就是用以LRU方式缓存图片，然后绘制在surfaceView上。至于题主所担心的OOM的问题，我只能说要看目标设备和代码的优化情况了。