概述
Android 大图加载显示
文章目录
- Android 大图加载显示
- 通过本文你能学到什么?
- 一、ImagerView直接放置一张几十M的图片会崩溃吗?
- 二、如何保证加载大图不发生崩溃?
- 三、Glide设置显示大图是否会发生崩溃
- 四、大图缩放滑动如何实现
- 五、大图缩放和滑动框架的使用
- 六、最后总结一下最开始目录学习的内容:
- 共勉:自强不息,才是生活的样子。
通过本文你能学到什么?
1、普通设置方法设置大图片是否会导致界面崩溃,多大的图片才会导致崩溃
2、如何保证加载大图不发生崩溃
3、Glide设置显示大图是否会发生崩溃
4、大图缩放滑动如何实现
5、大图缩放和滑动框架的使用
这里有个测试上面几个问题的demo,效果图如下:
代码和apk资源:
https://download.csdn.net/download/wenzhi20102321/85079242
代码不多也不太难,又兴趣的可以自己运行调试下。
本文主要分析大图加载为啥会崩溃,其他的可以参考demo代码。
下面开始正文内容:
一、ImagerView直接放置一张几十M的图片会崩溃吗?
测试代码如下:
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_bitmap);
Log.d(TAG," onCreate");
ImageView image = findViewById(R.id.image);
image.setImageResource(R.mipmap.test);//22M的图片
Log.d(TAG," show bitmap end");
}
测试的Demo代码和测试的资源都在上面打包的资源里面。
测试效果如下:
在模拟器上Activity直接崩溃了
日志:
Process: com.liwenzhi.bitmapdemo, PID: 10090
java.lang.RuntimeException: Canvas: trying to draw too large(161566192bytes) bitmap.
at android.graphics.RecordingCanvas.throwIfCannotDraw(RecordingCanvas.java:280)
at android.graphics.BaseRecordingCanvas.drawBitmap(BaseRecordingCanvas.java:88)
在华为手机上显示卡了下,后显示白屏,Activity界面未崩溃:
日志如下:
E/BitmapDrawable: Canvas: trying to use a recycled bitmap
2022-03-12 01:04:53.845 31366-31366/com.liwenzhi.bitmapdemo W/System.err: java.lang.RuntimeException: Canvas: trying to draw too large(161566192bytes) bitmap.
2022-03-12 01:04:53.845 31366-31366/com.liwenzhi.bitmapdemo W/System.err: at android.graphics.RecordingCanvas.throwIfCannotDraw(RecordingCanvas.java:282)
2022-03-12 01:04:53.845 31366-31366/com.liwenzhi.bitmapdemo W/System.err: at android.graphics.BaseRecordingCanvas.drawBitmap(BaseRecordingCanvas.java:88)
2022-03-12 01:04:53.845 31366-31366/com.liwenzhi.bitmapdemo W/System.err: at android.graphics.drawable.BitmapDrawable.draw(BitmapDrawable.java:549)
2022-03-12 01:04:53.845 31366-31366/com.liwenzhi.bitmapdemo W/System.err: at android.widget.ImageView.onDraw(ImageView.java:1529)
从上面日志也可以很清楚看到,从ImagView到具体报错的类的地方:
ImageView.onDraw -->BitmapDrawable.draw-->BaseRecordingCanvas.drawBitmap-->RecordingCanvas.throwIfCannotDraw是最后报错的方法
在联想平板上测试,整个应用崩溃了:
2022-03-12 01:20:23.443 11461-11461/? D/ShowBitmapActivity: onCreate
2022-03-12 01:20:26.083 11461-11461/? D/ShowBitmapActivity: show bitmap end
2022-03-12 01:20:26.103 1368-1673/? I/InputDispatcher: c5b948a com.liwenzhi.bitmapdemo/com.liwenzhi.bitmapdemo.MainActivity (server) spent 2713ms processing FocusEvent(hasFocus=false)
2022-03-12 01:20:26.109 7367-9126/? W/FMSC::AppStuckDetectionService: Receive App Stuck Event: PID: 11461 Package: com.liwenzhi.bitmapdemo Type: 3 Level: 0 Timestamp: 1647019226109 Duration: 2732152213 JankCnt: 1
2022-03-12 01:20:26.144 11461-11461/? E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.liwenzhi.bitmapdemo, PID: 11461
java.lang.RuntimeException: Canvas: trying to draw too large(161566192bytes) bitmap.
at android.graphics.RecordingCanvas.throwIfCannotDraw(RecordingCanvas.java:283)
at android.graphics.BaseRecordingCanvas.drawBitmap(BaseRecordingCanvas.java:88)
...//
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:956)
2022-03-12 01:20:26.162 1368-8778/? W/ActivityTaskManager: Force finishing activity com.liwenzhi.bitmapdemo/.ShowBitmapActivity
从上面的日志看,不管是哪个设备,加载到161566192bytes(160M多一点)会发生异常。
尝试添加一张12M的图片,是没问题的,大概一秒后就显示了。
使用联想平板,尝试显示一张18M的图片,应用崩溃了。
2022-03-12 01:40:54.274 12930-12930/com.liwenzhi.bitmapdemo E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.liwenzhi.bitmapdemo, PID: 12930
java.lang.RuntimeException: Canvas: trying to draw too large(120422400bytes) bitmap.
at android.graphics.RecordingCanvas.throwIfCannotDraw(RecordingCanvas.java:283)
...
从上面日志看,是加载到120M左右就崩溃了。
那么13M的图片能不能正常显示呢?
测试结果是崩溃了。
日志入下:
--------- beginning of crash
2022-03-12 01:48:38.555 13216-13216/com.liwenzhi.bitmapdemo E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.liwenzhi.bitmapdemo, PID: 13216
java.lang.RuntimeException: Canvas: trying to draw too large(194510848bytes) bitmap.
at android.graphics.RecordingCanvas.throwIfCannotDraw(RecordingCanvas.java:283)
at android.graphics.BaseRecordingCanvas.drawBitmap(BaseRecordingCanvas.java:88)
194510848bytes–>194 510 848 = 185.5M
不再去测试了,先总结一下情况:
从上面测试结果看,ImageView大概加载13M以上的图片就会崩溃。
下面找出抛出异常崩溃原因:
Android9.0 api28
RecordingCanvas.java
private static int getPanelFrameSize() {
final int DefaultSize = 100 * 1024 * 1024; // 100 MB;
return Math.max(SystemProperties.getInt("ro.hwui.max_texture_allocation_size", DefaultSize),
DefaultSize);
}
/** @hide */
public static final int MAX_BITMAP_SIZE = getPanelFrameSize();
/** @hide */
@Override
protected void throwIfCannotDraw(Bitmap bitmap) {
super.throwIfCannotDraw(bitmap);
int bitmapSize = bitmap.getByteCount();
if (bitmapSize > MAX_BITMAP_SIZE) {
throw new RuntimeException(
"Canvas: trying to draw too large(" + bitmapSize + "bytes) bitmap.");
}
}
所以结论是:系统从ro.hwui.max_texture_allocation_size属性值和100 * 1024 * 1024(100 MB)取其中一个最大的值,
如果图片的数据值大于这个值就会抛出异常错误。
但是我的联想平板Android11(api 30),看了下并没有属性ro.hwui.max_texture_allocation_size,应该是9.0之后就没这个属性了的。
所以查看一下源码发现:
Android11 api30
RecordingCanvas.java
/** @hide */
public static final int MAX_BITMAP_SIZE = 100 * 1024 * 1024; // 100 MB
发现最大加载Bitmap大小是100M,但是为啥12M的图片没事,13M多的图片就会崩溃???
下面就跟大家慢慢分析了:
先公布答案:
图片的像素大小和图片的文件大小并不代表数据大小,图片的数据大小指的是内存数据大小,
具体图片具体内存大小计算方式是每行的像素字节数*图片高度;
注意上面说的是每行的像素字节数,并不是像素数,每个像素占4个字节。
这里可以直接看源码一步步分析,但是我觉得还是先看看报错的实际原因和弄懂基本原理比较好。
下面看看12M 和13M图片的参数情况:
先看会崩溃的13M.jpg
分辨率:13568*3584
其他的位深和分辨率单位那些参数都是不用管的,知道上面这个分辨率参数就行了。
上面的参数表示:图片一行有13568个像素,有3584行
13568*3584大概就40M左右的大小,为啥会导致崩溃呢?
这里就要注意一个概念了,一个像素并不是一个字节大小,而是4个字节,
图片是用一个int(4个字节)记录一个像素大大小的,为啥是4个不是1个或者2个,因为要存储ARGB所以要4个字节。
理解了上面这两句概念,应该就不难理解为啥14M图片直接显示会崩溃了吧。
因为1356843584 内存大小,已经有160M左右的大小了,远超100M,代码直接抛出异常了。
12M.jpg参数情况:
分辨率:5184*3456
518443456 内存大小,大概只有60 M左右大小,未达到抛出异常条件。
所以我们是不是可以先计算图片的内存大小,再决定是否显示这个图片呢?
Bitmap.java 刚好暴露有这个方法是表示内存数据大小的
public final int getByteCount() {
// int result permits bitmaps up to 46,340 x 46,340
return getRowBytes() * getHeight(); //getRowBytes表示行像素的字节数据大小
}
//同样的图片,在不同的设备获取的每行像素值可能不同
//比如我同一张照片华为手机,比如普通平板的高了很多
public final int getRowBytes() {
if (mRecycled) {
Log.w(TAG, "Called getRowBytes() on a recycle()'d bitmap! This is undefined behavior!");
}
return nativeRowBytes(mNativePtr);//每行的像素大小和设备相关
}
当然是可以用这种比较low的方法进行判断,防止设置图片界面崩溃。
但是还是有更好的解决方法的,比如固定图片的采样率,以及设置图片像素模式RGB888/565达到减少图片内存数据的目的
二、如何保证加载大图不发生崩溃?
保证图片的加载内存不超过100M即可
可以通过设置Options对象的inSampleSize 减少采样率(达到之前的几分之一)
也可以通过设置Options对象的inPreferredConfig为Bitmap.Config.RGB_565,
比如下面的这段代码:
/**
* 获取Bitmap对象
*
* @param res Resource对象
* @param resId 图片资源ID
* @return 返回Bitmap对象
*/
private Bitmap decodeSampledBitmapFromResource(Resources res, int resId) {
BitmapFactory.Options options = new BitmapFactory.Options();
//亮点:不加载像素,不占用内存
options.inJustDecodeBounds = true; //超大图缩放一般都有这样设置,否则在底层占用大量内存
BitmapFactory.decodeResource(res, resId, options); //不加载内存的情况下,无返回值
int height = options.outHeight; //图片的宽
int width = options.outWidth; //图片的高
//做一些其他的判断和处理,根据图片的宽高和View的宽高的情况,设置一些参数
//关键点: Calculate inSampleSize 几分之一
options.inSampleSize = 4;
options.inPreferredConfig = Bitmap.Config.RGB_565; //默认是RGB_888
options.inJustDecodeBounds = false; //设置为false,才会从底层申请到内存
return BitmapFactory.decodeResource(res, resId, options);
}
RGB_888到RGB_565,其实也是减少了采样率,大概是原图的5/8.
所有的大图加载框架都是用到了上面这段代码的思想:
第一次在不占用内存的情况加载测量图片的宽高,根据情况适配参数,第二次真正加载并设置相关参数。
三、Glide设置显示大图是否会发生崩溃
Glide加载大图是不会崩溃的
其关键点就是:
把options.inJustDecodeBounds属性设置为true,
对比图片实际大小和ImageView实际大小的情况,设置对应参数,做出相应的缩放等操作。
options.inJustDecodeBounds
也就是加载两次
第一次读取配置,比如图片原生宽高
第二次结合布局的宽高设置图片宽高,
四、大图缩放滑动如何实现
1、写一个自定义View加载图片
2、设置setImage方法设置图片,测量图片宽高
3、调用requestLayout()重新加载图片
4、在onMeasure(...)方法中对比图片宽高和View的宽高,
5、定义使用区域解码器、手势对象、缩放手势,缩放因子等对象
//区域解码器
private BitmapRegionDecoder mDecode;
//手势对象
private GestureDetector mGestureDetector;
//缩放功能
ScaleGestureDetector mScaleGestureDetector;
//滑动帮助类
private Scroller mScroller;
//需要显示的区域
private Rect mRect;
//图片缩放因子
private float mScale;
6、在onDraw(...)做对应的缩放和区域滑动
具体参考demo项目代码。
demo中手写的大图缩放功能,并不是非常完善,
试了下,部分大图正常显示和放大缩小,宽度较大的图片显示有问题,
谁有需求可以参考大图缩放框架自己完善下。
五、大图缩放和滑动框架的使用
大图处理神器: SubsamplingScaleImageView 框架
简称:Subsampling
用法也是比较简单的:
public class ShowFunctionBitmapActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_function_bitmap);
SubsamplingScaleImageView imageView = (SubsamplingScaleImageView)findViewById(R.id.image); //自定义View
imageView.setImage(ImageSource.resource(R.mipmap.test_22m)); //使用ImageSource的静态方法转换成ImageSource对象,加载到View中即可
}
}
demo里面没有进行远程依赖,是把SubsamplingScaleImageView框架的几个类复制到demo使用,需要的可以自己进行适配修改。
Subsampling的其他相关介绍:https://blog.csdn.net/zhangphil/article/details/49557549
六、最后总结一下最开始目录学习的内容:
1、普通设置方法设置大图片是否会导致界面崩溃,多大的图片才会导致崩溃
答:会发生异常,加载的图片数据内存大于100M会发生RuntimeException异常,系统框架未处理的情况会发生崩溃
因为Android系统就是这样限制的。
一般来说加载几M的图片没啥问题,但是加载十几M以上的图片就会有异常,出现图片不加载或者界面崩溃或者应用崩溃的现象。
2、如何保证加载大图不发生崩溃
答:可设置options.inSampleSize设置采样率和options.inPreferredConfig降低图片分辨率达到减少内存加载的目的
3、Glide设置显示大图是否会发生崩溃
Glide加载大图不会发生崩溃
Glide里面会加载两次图片
第一次读取配置,比如图片原生宽高,设置options.inJustDecodeBounds属性设置为true,不占用内存
第二次结合布局的宽高设置图片设置理想的采样率比例。
4、大图缩放滑动如何实现
(1)写一个自定义View加载图片
(2)设置setImage方法设置图片,测量图片宽高
(3)调用requestLayout()重新加载图片
(4)在onMeasure(...)方法中对比图片宽高和View的宽高,
(5)定义使用区域解码器、手势对象、缩放手势,缩放因子等对象
(6)在onDraw(...)做对应的缩放和区域滑动
5、大图缩放和滑动框架的使用
大图处理神器: SubsamplingScaleImageView 框架
(1)定义缩放图片对象
SubsamplingScaleImageView imageView = (SubsamplingScaleImageView)findViewById(R.id.image); //自定义View
(2)缩放图片对象中放入图片数据
imageView.setImage(ImageSource.resource(R.mipmap.test_22m)); //使用ImageSource的静态方法转换成ImageSource对象,加载到View中即可
共勉:自强不息,才是生活的样子。
最后
以上就是安静自行车为你收集整理的Android 大图加载显示Android 大图加载显示共勉:自强不息,才是生活的样子。的全部内容,希望文章能够帮你解决Android 大图加载显示Android 大图加载显示共勉:自强不息,才是生活的样子。所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复