iOS的内存分析和内存管理

简介:

iOS的内存分析和内存管理

【内存管理】一直是iOS开发中的一个重点。

本文就带你从内存分析开始一步步了解内存的占用情况,从真实的情况中领悟真正项目开发过程中的内存的使用情况。

注:本文默认你熟悉 MRC、ARC、熟悉内存管理原则,本文注重实际应用

1.内存分析

内存分析主要有两种方式

  • 静态内存分析

  • 动态内存分析

1.1 静态内存分析

特点:

  • 不运行程序,直接对代码进行分析(根据代码的语法结构分析是否有内存泄露)

缺点:

  • 不能够准确的分析出来内存泄露,但是操作简单.并且如果发现有地方有提示内存泄露,最好根据上下文查看是否有问题

静态分析代码如下

- (void)viewDidLoad {
    [super viewDidLoad];
    
    NSObject *objc = [[NSObject alloc] init];
    [objc release];
    
    NSObject *objc1 = [self objc];
    NSLog(@"%@", objc1);
    
    [objc1 release];
}

- (NSObject *)objc
{
    return [[NSObject alloc] init];
}

通过肉眼分析,从代码结构上来看这段代码是没有内存泄露的。

实际工作中代码量肯定大得多,所以会用系统工具 Analyze

Analyze分析结果来看,创建对象的这一行是有内存泄漏的可能,此时只需要简单定位,在人工分析即可

使用场景:

通常使用在 MRC 时代,在 ARC 时代中我们使用这个通常是使用 CoreFoundation 框架中的内容,需要自己手动管理内存。示例代码如下:

- (void)drawRect:(CGRect)rect {
    
    CGContextRef context = UIGraphicsGetCurrentContext();
    
    CGMutablePathRef path = CGPathCreateMutable();
    
    CGPathAddEllipseInRect(path, NULL, rect);
    
    CGContextAddPath(context, path);
    
    [[UIColor redColor] set];
    
    // CGPathRelease(path); // 此处path 用完之后需要自己释放
    CFRelease(path);
    
    CGContextDrawPath(context, kCGPathFill);
}

1.2 动态内存分析

特点:

  • 真正运行起来程序,查看在程序运行过程中,是否会出现内存泄露的问题

  • 准确,如果发现某些地方提示内存泄露,可以根据提示找到对应的内存泄露位置(Xcode6不好找,需要自己来分析)

使用 Instruments 动态分析:

  • Allocations

    • 运行程序, 通过使用app, 查看内存的分配情况

    • 可以查看做出了某个操作后(比如点击了某个按钮\显示了某个控制器), 内存是否有暴增的情况(突然变化)

  • Leaks

    • 运行程序, 通过使用app, 查看是否有内存泄漏

    • 红色区域代表内存泄漏出现的地方,可点击对应泄露点,定位到可能出现泄漏的代码。

    • 如图绿色部分表示没有内存泄漏

2.内存分配的使用和图片加载分析

通常项目中图片加载方式有两种:

  1. imageWithNamed:

  2. imageWithContentFile:

下面分别来使用 Leaks 来测试一下两种图片加载方式有什么不同。
测试代码如下:

- (void)viewDidLoad {
    [super viewDidLoad];
    
    NSString *imagePath = [[NSBundle mainBundle] pathForResource:@"2.png" ofType:nil];
    self.imageView.image = [UIImage imageWithContentsOfFile:imagePath];
    self.imageView1.image = [UIImage imageWithContentsOfFile:imagePath];
    
    /*
     self.imageView.image = [UIImage imageNamed:@"2"];
     self.imageView1.image = [UIImage imageNamed:@"2"];
     */
}

2.1 imageWithNamed:

imageName:加载图片特点:

  1. 当对象销毁,图片对象不会随着一起销毁

  2. 加载的图片占据的内存较大:8.54MB

  3. 相同的图片只会加载一份到内存中,如果同时使用,使用同一个对象即可

2.2 imageWithContentFile:

imageWithContentOfFile:加载图片特点:

  1. 当对象销毁的时候,图形对象会随着一起销毁

  2. 加载的图片,占据的内存较小:6.25MB(图中是两张,以示例代码为准)

  3. 相同的图片会多次加载到内存中,如果同时使用图片,使用的是不同的对象

两种图片加载方式小结:

  • imageName:如果一些图片在多个界面都会使用,并且图片较小,使用频率高.(图标/小的背景图)

  • imageWithContentOfFile:只在一个地方使用,并且图片较大,使用频率不高.(版本新特性/相册)

3.图片在沙盒中的存在形式

3.1 不支持图片压缩

  1. 如果项目的Deployment Target <= 6.x

    1. 所有图片直接暴露在沙盒的资源包(main Bundle), 不会压缩到Assets.car文件

3.2 支持图片压缩

  1. 如果项目的Deployment Target >= 7.x

    1. 放在Images.xcassets里面的所有图片会压缩到Assets.car文件, 不会直接暴露在沙盒的资源包(main Bundle)

    2. 没有放在Images.xcassets里面的所有图片会直接暴露在沙盒的资源包(main Bundle), 不会压缩到Assets.car文件

3.3 小结

1. 会压缩到Assets.car文件, 没有直接暴露在沙盒的资源包(main Bundle)
    * 条件 : "Deployment Target >= 7.x" 并且是 "放在Images.xcassets里面的所有图片"
    * 影响 : 无法得到图片的全路径, 只能通过图片名(imageNamed:方法)来加载图片, 永远会有缓存

2. 不会压缩到Assets.car文件, 直接暴露在沙盒的资源包(main Bundle)
    * 条件 : 除1> 以外的所有情况
    * 影响 : 可以得到图片的全路径, 可以通过全路径(imageWithContentsOfFile:方法)来加载图片, 不会有缓存

4.综上:图片资源加载结论

  • 小图片\使用频率比较高的图片

    • 放在Images.xcassets里面

  • 大图片\使用频率比较低的图片(一次性的图片, 比如版本新特性的图片)

    • 不要放在Images.xcassets里面














本文转自xsster51CTO博客,原文链接:http://blog.51cto.com/12945177/1950775 ,如需转载请自行联系原作者




相关文章
|
11月前
|
Web App开发 监控 JavaScript
监控和分析 JavaScript 内存使用情况
【10月更文挑战第30天】通过使用上述的浏览器开发者工具、性能分析工具和内存泄漏检测工具,可以有效地监控和分析JavaScript内存使用情况,及时发现和解决内存泄漏、过度内存消耗等问题,从而提高JavaScript应用程序的性能和稳定性。在实际开发中,可以根据具体的需求和场景选择合适的工具和方法来进行内存监控和分析。
|
11月前
|
开发框架 前端开发 Android开发
Flutter 与原生模块(Android 和 iOS)之间的通信机制,包括方法调用、事件传递等,分析了通信的必要性、主要方式、数据传递、性能优化及错误处理,并通过实际案例展示了其应用效果,展望了未来的发展趋势
本文深入探讨了 Flutter 与原生模块(Android 和 iOS)之间的通信机制,包括方法调用、事件传递等,分析了通信的必要性、主要方式、数据传递、性能优化及错误处理,并通过实际案例展示了其应用效果,展望了未来的发展趋势。这对于实现高效的跨平台移动应用开发具有重要指导意义。
1063 4
|
4月前
|
存储 弹性计算 缓存
阿里云服务器ECS经济型、通用算力、计算型、通用和内存型选购指南及使用场景分析
本文详细解析阿里云ECS服务器的经济型、通用算力型、计算型、通用型和内存型实例的区别及适用场景,涵盖性能特点、配置比例与实际应用,助你根据业务需求精准选型,提升资源利用率并降低成本。
368 3
|
14天前
|
设计模式 缓存 Java
【JUC】(4)从JMM内存模型的角度来分析CAS并发性问题
本篇文章将从JMM内存模型的角度来分析CAS并发性问题; 内容包含:介绍JMM、CAS、balking犹豫模式、二次检查锁、指令重排问题
58 1
|
3月前
|
存储 人工智能 自然语言处理
AI代理内存消耗过大?9种优化策略对比分析
在AI代理系统中,多代理协作虽能提升整体准确性,但真正决定性能的关键因素之一是**内存管理**。随着对话深度和长度的增加,内存消耗呈指数级增长,主要源于历史上下文、工具调用记录、数据库查询结果等组件的持续积累。本文深入探讨了从基础到高级的九种内存优化技术,涵盖顺序存储、滑动窗口、摘要型内存、基于检索的系统、内存增强变换器、分层优化、图形化记忆网络、压缩整合策略以及类操作系统内存管理。通过统一框架下的代码实现与性能评估,分析了每种技术的适用场景与局限性,为构建高效、可扩展的AI代理系统提供了系统性的优化路径和技术参考。
192 4
AI代理内存消耗过大?9种优化策略对比分析
|
11月前
|
安全 Android开发 数据安全/隐私保护
深入探讨iOS与Android系统安全性对比分析
在移动操作系统领域,iOS和Android无疑是两大巨头。本文从技术角度出发,对这两个系统的架构、安全机制以及用户隐私保护等方面进行了详细的比较分析。通过深入探讨,我们旨在揭示两个系统在安全性方面的差异,并为用户提供一些实用的安全建议。
|
7月前
|
存储 Java
课时4:对象内存分析
接下来对对象实例化操作展开初步分析。在整个课程学习中,对象使用环节往往是最棘手的问题所在。
|
7月前
|
Java 编译器 Go
go的内存逃逸分析
内存逃逸分析是Go编译器在编译期间根据变量的类型和作用域,确定变量分配在堆上还是栈上的过程。如果变量需要分配在堆上,则称作内存逃逸。Go语言有自动内存管理(GC),开发者无需手动释放内存,但编译器需准确分配内存以优化性能。常见的内存逃逸场景包括返回局部变量的指针、使用`interface{}`动态类型、栈空间不足和闭包等。内存逃逸会影响性能,因为操作堆比栈慢,且增加GC压力。合理使用内存逃逸分析工具(如`-gcflags=-m`)有助于编写高效代码。
145 2
|
11月前
|
JavaScript
如何使用内存快照分析工具来分析Node.js应用的内存问题?
需要注意的是,不同的内存快照分析工具可能具有不同的功能和操作方式,在使用时需要根据具体工具的说明和特点进行灵活运用。
346 62
|
10月前
|
存储 监控 算法
Java内存管理深度剖析:从垃圾收集到内存泄漏的全面指南####
本文深入探讨了Java虚拟机(JVM)中的内存管理机制,特别是垃圾收集(GC)的工作原理及其调优策略。不同于传统的摘要概述,本文将通过实际案例分析,揭示内存泄漏的根源与预防措施,为开发者提供实战中的优化建议,旨在帮助读者构建高效、稳定的Java应用。 ####
173 35