加载高清大图崩溃问题

SDWebImage加载高清大图崩溃问题:

经验证没测试出来,在网上查找根源应该是在iOS7上有问题,特此记录一下

第一种:老版本SDWebImage_v4.2.0

更改源码

这里面对图片的处理是直接按照原大小进行的,如果几千是分辨率这里导致占用了大量内存。

1、在UIImage+MultiFormat 中增加方法,对图片做一次等比的压缩。

+(UIImage *)compressImageWith:(UIImage *)image
{
    float imageWidth = image.size.width;
    float imageHeight = image.size.height;
    float width = 640;
    float height = image.size.height/(image.size.width/width);

    float widthScale = imageWidth /width;
    float heightScale = imageHeight /height;

    // 创建一个bitmap的context
    // 并把它设置成为当前正在使用的context
    UIGraphicsBeginImageContext(CGSizeMake(width, height));

    if (widthScale > heightScale) {
        [image drawInRect:CGRectMake(0, 0, imageWidth /heightScale , height)];
    }
    else {
        [image drawInRect:CGRectMake(0, 0, width , imageHeight /widthScale)];
    }

    // 从当前context中创建一个改变大小后的图片
    UIImage *newImage = UIGraphicsGetImageFromCurrentImageContext();
    // 使当前的context出堆栈
    UIGraphicsEndImageContext();

    return newImage;

}

2、再在上面箭头代码后面对图片进行压缩

        image = [[UIImage alloc] initWithData:data];
        if (data.length/1024 > 128) {
            image = [self compressImageWith:image];
        }

3、 在SDWebImageDownloaderOperation.m 的 -(void)connectionDidFinishLoading:(NSURLConnection *)aConnection 方法中增加代码

-(void)connectionDidFinishLoading:(NSURLConnection *)aConnection {
    SDWebImageDownloaderCompletedBlock completionBlock = self.completedBlock;
    @synchronized(self) {
        CFRunLoopStop(CFRunLoopGetCurrent());
        self.thread = nil;
        self.connection = nil;
        dispatch_async(dispatch_get_main_queue(), ^{
            [[NSNotificationCenter defaultCenter] postNotificationName:SDWebImageDownloadStopNotification object:self];
            [[NSNotificationCenter defaultCenter] postNotificationName:SDWebImageDownloadFinishNotification object:self];
        });
    }

    if (![[NSURLCache sharedURLCache] cachedResponseForRequest:_request]) {
        responseFromCached = NO;
    }

    if (completionBlock) {
        if (self.options & SDWebImageDownloaderIgnoreCachedResponse && responseFromCached) {
            completionBlock(nil, nil, nil, YES);
        } else if (self.imageData) {
            UIImage *image = [UIImage sd_imageWithData:self.imageData];
//增加的代码
            NSData *data = UIImageJPEGRepresentation(image, 1);
            self.imageData = [NSMutableData dataWithData:data];
//
            NSString *key = [[SDWebImageManager sharedManager] cacheKeyForURL:self.request.URL];
            image = [self scaledImageForKey:key image:image];

            // Do not force decoding animated GIFs
            if (!image.images) {
                if (self.shouldDecompressImages) {
                    image = [UIImage decodedImageWithImage:image];
                }
            }
            if (CGSizeEqualToSize(image.size, CGSizeZero)) {
                completionBlock(nil, nil, [NSError errorWithDomain:SDWebImageErrorDomain code:0 userInfo:@{NSLocalizedDescriptionKey : @"Downloaded image has 0 pixels"}], YES);
            }
            else {
                completionBlock(image, self.imageData, nil, YES);
            }
        } else {
            completionBlock(nil, nil, [NSError errorWithDomain:SDWebImageErrorDomain code:0 userInfo:@{NSLocalizedDescriptionKey : @"Image data is nil"}], YES);
        }
    }
    self.completionBlock = nil;
    [self done];
}

4、在控制器的- (void)didReceiveMemoryWarning方法中添加

    [[SDWebImageManager sharedManager] cancelAll];
    [[SDImageCache sharedImageCache] clearMemory];

第二种:新版本

解压缩意义:

当完成图片加载或者从本地加载图片时,还会有轻微的卡顿。因为当显示或者绘制的时候,UIKit 只做了额外的延迟初始化和消耗很高解码。所以从后台线程解压缩成合适的格式,从而让系统不必做额外的转换。然后在主线程上显示,增加流畅性。

优化为何适得其反?最后在SDWebImage的issues找到了相关的讨论:
https://github.com/rs/SDWebImage/issues/538
其中一个harishkashyap大神是这么回答的:

harishkashyap commented on Dec 23, 2014
Its the memory issue again. decodedImageWithImage takes up huge memory and causes the app to crash. I have added an option to put this off in the library but defaulting to YES so there aren‘t any breaking changes. If you put off the decodeImageWithImage method in both image cache and image downloader then you shouldn‘t be seeing the VM: CG Raster data on the top consuming lots of memory

decodeImageWithImage is supposed to decompress images and cache them so the loading on tableviews/collectionviews become better. However, with large set of images being loaded, the experience worsened and the memory of uncompressed images even with thumbnails can consume GBs of memory. Putting this off only improved performance.

https://github.com/harishkashyap/SDWebImage/tree/fix-memory-issues

这位大神提到,decodeImageWithImage这个方法用于对图片进行解压缩并且缓存起来,以保证tableviews/collectionviews 交互更加流畅,但是如果是加载高分辨率图片的话,会适得其反,有可能造成上G的内存消耗。该大神建议,对于高分辨率的图片,应该在图片解压缩后,禁止缓存解压缩后的数据,相关的代码处理为:

[[SDImageCache sharedImageCache] setShouldDecompressImages:NO];
[[SDWebImageDownloader sharedDownloader] setShouldDecompressImages:NO];

当然,你也可以设置SDWebImage的其他参数,比如是否缓存到内存以及内存缓存最高限制等,来保证内存安全:

shouldCacheImagesInMemory 是否缓存到内存
maxMemoryCost  内存缓存最高限制

号外:苹果官方给出了一个下载高清大图的demo,内存消耗很低。感兴趣的朋友也可以看看:

https://developer.apple.com/library/ios/samplecode/LargeImageDownsizing/Introduction/Intro.html

CGBitmap两个参数

bitsPerComponent 表示存入内存中的每个像素中的每一个组件所占的位数;
bytesPerRow 表示存入内存中的位图的每一行所占的字节数;

猜测,解压缩操作中,每一个像素点都会分配一个空间来存储相关值,那么分辨率越高的图片,就意味着更多数量的像素点,也就意味着需要分配更多的空间!所以对于高分辨率图来说,如果缓存解压缩之后的数据,即使是几M的图片,也是有可能消耗上G的内存!
既然如此,我决定按照harishkashyap大神的方法,直接让下载高分辨率图的地方,避免缓存解压缩后的数据操作!

摘自链接:https://www.jianshu.com/p/1c9de8dea3ea

原文地址:https://www.cnblogs.com/oc-bowen/p/9040476.html

时间: 2024-08-25 13:34:36

加载高清大图崩溃问题的相关文章

浅谈android中加载高清大图及图片压缩方式(二)

这一讲就是本系列的第二篇,一起来聊下关于android中加载高清大图的问题,我们都知道如果我们直接加载原图的话,一个是非常慢,需要等待一定时间,如果没有在一定的时间内给用户响应的话,将会极大影响用户的体验.另一个是如果你的手机内存小的话,可能会直接崩溃.这也就是直接加载高清原图问题.遇到这些问题很容易想到的一点就是图片压缩,本篇文章也就是讲述图片压缩方式来实现加载高清大图的效果.但是现在问题就来了,通过上篇博客我们知道,手机的分辨率有很多,如何保证我同一张图片在不同分辨率的手机上能适当的压缩比例

IOS 多个UIImageView 加载高清大图时内存管理

当我们在某一个View  多个UIImageView,且UIImageView都显示的是高清大图,就有可能出现内存警告的问题.如果第一次进入这个view,没有发生内存警告,当再次进入这个view,如果上一次的内存没有及时释放,这一次次的累加,便可导致内存崩溃. 1,UIImage 加载图片的方式.      如果是本地图片,尽量不要使用 [UIImage  imageNamed:nil]; 这种方式,如果使用这种方式加载,只要程序不退出,它便一直会在内存中.     我们可以使用 :      

WPF 异步加载高清大图

不管什么东西,但凡太大了,总是让人又爱又恨啊!(很有道理的样子,大家鼓掌└( ̄  ̄└)(┘ ̄  ̄)┘) 猿:老板,现在这社会啊,真是浮躁啊,之前还是什么1080P,然后就到了2K,现在又到了4K……他们是想把毛孔都看清楚? 老板:能不能做? 猿:已经做好了啊,但是……反正这次我们能说会道的X经理也没能忽……说服客户. 老板:是什么问题嘛,说出来我帮你想想办法.(老板真是好人啊,语重心长) 猿(ノへ ̄.):客户不是升级了4K摄像机吗,哎哟,那玩意儿,老长了,就跟火箭筒似的,扛起来那感觉(? •?_

利用runLoop加载高清大图

一.什么是runLoop 1.说白了,runloop就是运行循环 2.runloop,他是多线程的法宝 通常来讲,一个线程一次只能执行一个任务,执行完之后就退出线程.但是,对于主线程是不能退出的,因此我们需要让主线程即使任务执行完毕,也可以继续等待接收事件而不退出,那么runloop就可以做到. 但是非主线程通常来说就是为了执行某一任务的,执行完毕就需要归还资源,因此默认是不运行runloop的. 3.每一个线程对应都有一个runloop,只是默认只有主线程的runloop是开启的,其他子线程的

关于SDWebImage加载高清图片导致app崩溃的问题

链接是对于SDWebImage的使用方法 http://www.cnblogs.com/JimmyBright/p/4457258.html 使用SDWebImage加载高清图片的时候,往往会报内存溢出的错误导致程序直接crash.比如说,你的程序加载10张左右的单反相片,这些相片每张都在10M左右,使用SDWebImage下载缓存再显示的方法,程序肯定会直接挂掉,查看内存图标一般是这种情况 这个程序一般运行内存消耗是13M左右,但是在加载了某张10M左右的图片后,突然有一个上升,飙升到178M

Android_性能优化之ViewPager加载成百上千高清大图oom解决方案

一.背景 最近做项目需要用到选择图片上传,类似于微信.微博那样的图片选择器,ContentResolver读取本地图片资源并用RecyclerView+Glide加载图片显示就搞定列表的显示,这个没什么大问题,重点是,点击图片进入大图浏览,比如你相册有几百张图片,也就意味着在ViewPager中需要加载几百个view,况且手机拍出来的图片都是1-2千万左右像素的高清大图(笔者手机2千万像素 也就是拍照出来的照片3888*5152),大小也有5-7个兆,ViewPager滑动不了十几张就oom了,

FineUI小技巧(5)向子窗口传值,向父窗口传值(另附24张专业版高清大图)

前言 FineUI中经常会用到启用IFrame的Window控件,这样有助于从物理上进行代码解耦和.IFrame的引入就会涉及传值问题,如何在父窗口和子窗口之间相互传值呢? 向子窗口传值 向子窗口传值只需要把要传递的参数放在页面URL中即可,一般有两种做法: 页面回发,在后台通过C#代码拼接需要的URL(推荐做法,方便!) 页面第一次加载时,即注册需要的URL(如果参数是页面上某输入框的值,则需要在URL中嵌入JavaScript代码) 来看一个例子,分别用上述两种方式实现: 页面的初始显示 点

FineUI(专业版)高清大图赏析!(第二波)

FineUI(专业版)是由三生石上全新打造的基于 jQuery 的专业 ASP.NET 控件库,计划在七月下旬正式发布. 选择FineUI(专业版)的四大理由:1. 简单:专业版和开源版兼容(v4.x),您现在就可以使用开源版进行开发,等正式版发布时只需替换 DLL 即可.2. 极速:专业版基于 jQuery 库重写,使得 JS 和 CSS 体积大幅减少,页面加载速度将是开源版的 2 倍以上.3. 多彩:专业版不仅保留 Neptune 皮肤,而且兼容 jQueryUI 的 ThemeRoller

FineUI小技巧(4)关闭窗体那些事(另附24张专业版高清大图)

前言 FineUI中的Window控件常用作选择.新增或编辑内容.而关闭Window控件却有很多技巧,了解这些技巧有助于项目的快速开发. 如何关闭Window控件 第一个问题就是如何关闭Window控件,最明显的方式就是右上角的关闭图标了.总的说来,有三种方式: ESC按键(在Window控件所在页面获取焦点的情况下,按下键盘的ESC将会关闭当前激活窗体) 窗体右上角的关闭图标 用户自定义的关闭按钮 前两种方式自不必说,那么如何自定义关闭按钮呢?有两种做法: 按钮禁用回发,在页面初始化时注册关闭