iOS学习之Block内存管理详解

ios开发中,相信说道block大家都不陌生,内存管理问题也是开发者最头疼的问题,网上很多讲block的博客,但大都是理论性多点,今天结合一些实例来讲解下。

  存储域

  首先和大家聊聊block的存储域,根据block在内存中的位置,block被分为三种类型:

  NSGlobalBlock

  NSStackBlock

  NSMallocBlock

  从字面意思上大家也可以看出来

NSGlobalBlock是位于全局区的block,它是设置在程序的数据区域(.data区)中。

  NSStackBlock是位于栈区,超出变量作用域,栈上的Block以及 __block变量都被销毁。

  NSMallocBlock是位于堆区,在变量作用域结束时不受影响。

  注意:在 ARC 开启的情况下,将只会有 NSConcreteGlobalBlock 和 NSConcreteMallocBlock 类型的 block

  说了这么多理论的东西,有些人可能很懵,觉得讲这些有什么用呢,我平时使用block并没有什么问题啊,好了,接下来我们先来个感受下:

  #import "ViewController.h"

  void(^block)(void);@implementation ViewController

  - (void)viewDidLoad {

  [super viewDidLoad];

NSInteger i = 10;

  block = ^{

  NSLog(@"%ld", i);

  };

  }

  - (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {

  block();

  }

  @end

  声明这样一个block,点击屏幕的时候去调用这个block,然后就会发生以下错误:

 野指针错误,显而易见,这个是生成在栈上的block,因为超出了作用域而被释放,所以再调用的时候报错了,通过打印这个block我们也可以看到是生成在栈上的:


 解决办法

  解决办法呢有两种:

  Objective-C为块常量的内存管理提供了复制(Block_copy())和释放(Block_release())命令。 使用Block_copy()命令可以将块常量复制到堆中,这就像实现了一个将块常量引用作为输入参数并返回相同类型块常量的函数。

  - (void)viewDidLoad {

  [super viewDidLoad];

  NSInteger i = 10;

  block = Block_copy(^{

  NSLog(@"%ld", i);

  });

  }

  为了避免内存泄漏,Block_copy()必须与相应的Block_release()命令达到平衡:

  Block_release(block);

  Foundation框架提供了处理块的copyrelease方法,这两个方法拥有与Block_copy()Block_release()函数相同的功能:

  - (void)viewDidLoad {

  [super viewDidLoad]; NSInteger i = 10;

  block = [^{ NSLog(@"%ld", i);

  } copy];

  }

  [block release];

  到这里有人可能会有疑问了,为什么相同的代码我建了一个工程,没有调用copy,也没有报错啊,并且可以正确打印。 那是因为我们上面的操作都是在MRC下进行的,ARC下编译器已经默认执行了copy操作,所以上面的这个例子就解释了Block超出变量作用域可存在的原因。

  接下来可能有人又要问了,block什么时候在全局区,什么时候在栈上,什么时候又在堆上呢?上面的例子是对生成在栈上的Block作了copy操作,如果对另外两种作copy操作,又是什么样的情况呢?

通过这张表我们可以清晰看到三种Block copy之后到底做了什么,接下来我们就来分别看看这三种类型的Block

  NSGlobalBlock

  在记述全局变量的地方使用block语法时,生成的block_NSConcreteGlobalBlock类对象

  void(^block)(void) = ^ { NSLog(@"Global Block");};int main() {

  }

  在代码不截获自动变量时,生成的block也是在全局区:

  int(^block)(int count) = ^(int count) {

  return count;

  };

  block(2);

  但是通过clang改写的底层代码指向的是栈区:

  impl.isa = &_NSConcreteStackBlock

  这里引用巧神的一段话:由于 clang 改写的具体实现方式和 LLVM 不太一样,并且这里没有开启 ARC。所以这里我们看到 isa 指向的还是_NSConcreteStackBlock。但在 LLVM 的实现中,开启 ARC 时,block 应该是 _NSConcreteGlobalBlock 类型

  总结下,生成在全局区block有两种情况:

定义全局变量的地方有block语法时

block语法的表达式中没有使用应截获的自动变量时

  NSStackBlock

  配置在全局区的block,从变量作用域外也可以通过指针安全地使用。但是设置在栈上的block,如果其作用域结束,该block就被销毁。同样的,由于__block变量也配置在栈上,如果其作用域结束,则该__block变量也会被销毁。

  上面举得例子其实就是生成在栈上的block

  NSInteger i = 10;

  block = ^{

  NSLog(@"%ld", i);

  };

  除了配置在程序数据区域的block(全局Block),其余生成的block_NSConcreteStackBlock类对象,且设置在栈上,那么配置在堆上的__NSConcreteMallocBlock类何时使用呢?

  NSMallocBlock

  Blocks提供了将Block__block变量从栈上复制到堆上的方法来解决这个问题,这样即使变量作用域结束,堆上的Block依然存在。

  impl.isa = &_NSConcreteMallocBlock;

  这也是为什么Block超出变量作用域还可以存在的原因。

  那么什么时候栈上的Block会复制到堆上呢?

  调用Blockcopy实例方法时

  Block作为函数返回值返回时

 

  将Block赋值给附有__strong修饰符id类型的类或Block类型成员变量时

  将方法名中含有usingBlockCocoa框架方法或GCDAPI中传递Block

  上面只对Block进行了说明,其实在使用__block变量的Block从栈上复制到堆上时,__block变量也被从栈复制到堆上并被Block所持有。

  接下来我们再来看一个????

  void(^block)(void);99int main(int argc, const char * argv[]) {

  @autoreleasepool {

  __block NSInteger i = 10;

  block = [^{

  ++i;

  } copy];

  ++i;

  block();

  NSLog(@"%ld", i);

  }

  return 0;

  }

  我们对这个生成在栈上的block执行了copy操作,Block__block变量均从栈复制到堆上。

  然后在Block作用域之后我们又使用了与Block无关的变量:

  ++i;

  一个是存在于栈上的变量,一个是复制到堆上的变量,我们是如何做到正确的访问这个变量值的呢?

  通过clang转换下源码来看下:

  void(*block)(void);

  struct __Block_byref_i_0 {

  void *__isa;

  __Block_byref_i_0 *__forwarding;

  int __flags;

  int __size;

  NSInteger i;

  };

  struct __main_block_impl_0 {

  struct __block_impl impl;

  struct __main_block_desc_0* Desc;

  __Block_byref_i_0 *i; // by ref

  __main_block_impl_0(void *fp, struct __main_block_desc_0 *desc, __Block_byref_i_0 *_i, int flags=0) : i(_i->__forwarding) {

  impl.isa = &_NSConcreteStackBlock;

  impl.Flags = flags;

  impl.FuncPtr = fp;

  Desc = desc;

  }

  };static void __main_block_func_0(struct __main_block_impl_0 *__cself) {

  __Block_byref_i_0 *i = __cself->i; // bound by ref

  ++(i->__forwarding->i);

  }static void __main_block_copy_0(struct __main_block_impl_0*dst, struct __main_block_impl_0*src) {_Block_object_assign((void*)&dst->i, (void*)src->i, 8/*BLOCK_FIELD_IS_BYREF*/);}

  static void __main_block_dispose_0(struct __main_block_impl_0*src) {_Block_object_dispose((void*)src->i, 8/*BLOCK_FIELD_IS_BYREF*/);}

  static struct __main_block_desc_0 {

  size_t reserved;

  size_t Block_size;

  void (*copy)(struct __main_block_impl_0*, struct __main_block_impl_0*);

  void (*dispose)(struct __main_block_impl_0*);

  } __main_block_desc_0_DATA = { 0, sizeof(struct __main_block_impl_0), __main_block_copy_0, __main_block_dispose_0};int main(int argc, const char * argv[]) {

  /* @autoreleasepool */ { __AtAutoreleasePool __autoreleasepool;

  __attribute__((__blocks__(byref))) __Block_byref_i_0 i = {(void*)0,(__Block_byref_i_0 *)&i, 0, sizeof(__Block_byref_i_0), 10};

  block = (void (*)())((id (*)(id, SEL))(void *)objc_msgSend)((id)((void (*)())&__main_block_impl_0((void *)__main_block_func_0, &__main_block_desc_0_DATA, (__Block_byref_i_0 *)&i, 570425344)), sel_registerName("copy"));

  ++(i.__forwarding->i);

  ((void (*)(__block_impl *))((__block_impl *)block)->FuncPtr)((__block_impl *)block);

  NSLog((NSString *)&__NSConstantStringImpl__var_folders_47_s4m8c9pj5mg0k9mymsm7rbmw0000gn_T_main_e69554_mi_0, (i.__forwarding->i));

  }

  return 0;

  }

  static struct IMAGE_INFO { unsigned version; unsigned flag; } _OBJC_IMAGE_INFO = { 0, 2 };

  我们发现相比于没有__block关键字修饰的变量,源码中增加了一个名为 __Block_byref_i_0 的结构体,用来保存我们要 capture 并且修改的变量 i

  在__Block_byref_i_0结构体中我们可以看到成员变量__forwarding,它持有指向该实例自身的指针。那么为什么会有这个成员变量__forwarding呢?这也是正是问题的关键。

  我们可以看到源码中这样一句:

  ++(i->__forwarding->i);

  栈上的__block变量复制到堆上时,会将成员变量__forwarding的值替换为复制到堆上的__block变量用结构体实例的地址。所以不管__block变量配置在栈上还是堆上,都能够正确的访问该变量,这也是成员变量__forwarding存在的理由。

  循环引用

  循环引用比较简单,造成循环引用的原因无非就是对象和block相互强引用,造成谁都不能释放,从而造成了内存泄漏。基本的一些例子我就不再重复了,网上很多,也比较简单,我就一个问题来讨论下,也是开发中有人问过我的一个问题:

  block里面使用self会造成循环引用吗?

  很显然答案不都是,有些情况下是可以直接使用self的,比如调用系统的方法:

  [UIView animateWithDuration:0.5 animations:^{

  NSLog(@"%@", self);

  }];

  因为这个block存在于静态方法中,虽然blockself强引用着,但是self却不持有这个静态方法,所以完全可以在block内部使用self

  还有一种情况:

  当block不是self的属性时,self并不持有这个block,所以也不存在循环引用

  void(^block)(void) = ^() {

  NSLog(@"%@", self);

  };

  block();

  只要我们抓住循环引用的本质,就不难理解这些东西。

  希望可以通过上面的一些例子,可以让大家加深对block的理解,知其然并且知其所以然。

 

文章来源:CocoaChina

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: iOS内存管理版本记录如下: 1. iOS 2.0及更早版本:使用手动管理内存的方式。 2. iOS 3.0:引入了基于引用计数的自动内存管理,使用retain和release函数来增加或减少对象的引用计数。 3. iOS 5.0:引入了ARC(自动引用计数)机制,ARC会在编译时自动插入retain和release代码,减少手动管理内存的工作。 4. iOS 7.0:引入了内存诊断工具Memory Usage Report,可以监测App内存使用情况,帮助开发者优化内存管理。 5. iOS 8.0:引入了一些新的API,如NSCache和NSURLSession,使得内存管理更加方便和灵活。 6. iOS 11.0:引入了基于图片大小的UIImage渲染机制,减少了内存占用。 7. iOS 13.0:引入了叫做“Scene”的多任务环境,使得内存管理更加复杂,需要更加小心谨慎地处理内存问题。 总的来说,随着iOS版本的不断更新,内存管理的机制也在不断地完善和优化,使得iOS应用能够更加高效地使用内存,提高用户体验。 ### 回答2: iOS内存管理是由操作系统自动管理的,在不同的版本中有所不同。 在iOS 5之前的版本中,内存管理主要依赖于手动管理引用计数(reference counting)来管理对象的生命周期。开发者需要手动调用retain和release方法来增加或减少对象的引用计数,以确保对象在不再需要时能够被正确释放。这种方式需要开发者非常谨慎地管理对象的引用,以避免内存泄漏或野指针等问题。 从iOS 5开始,iOS引入了自动引用计数(Automatic Reference Counting,ARC)的内存管理机制。ARC可以自动地插入retain、release和autorelease等方法的调用,使得开发者不再需要手动进行内存管理。开发者只需要关注对象的创建和使用,而不需要关心具体的内存管理细节。ARC减少了内存管理的工作量,提高了开发效率,并且减少了内存泄漏和野指针等问题的发生。不过,ARC并不是完全的自动化内存管理,开发者仍然需要遵循一些规则,比如避免循环引用等,以保证内存的正确释放。 随着iOS版本的不断更新,苹果不断改进和优化内存管理机制。每个新版本都带来了更好的性能和更高效的内存管理。开发者可以通过关注苹果的官方文档和开发者社区中的更新内容来了解每个版本中的具体变化和改进。 总结来说,iOS内存管理从手动的引用计数到自动引用计数的演变,极大地简化了开发者的工作,并提高了应用的性能和稳定性。随着不断的改进和优化,iOS内存管理会越来越高效和可靠。 ### 回答3: iOS内存管理版本记录是指苹果公司在不同版本的iOS操作系统中对于内存管理方面的改进和更新记录。随着iOS版本的不断迭代,苹果在内存管理方面进行了一系列的优化和改进,以提高系统的稳定性和性能。 首先,在早期的iOS版本中,苹果采用了手动内存管理的方式,即开发人员需要手动创建和释放内存,容易出现内存泄漏和内存溢出等问题。为了解决这些问题,苹果在iOS5版本中引入了自动引用计数(ARC)机制。ARC机制能够通过编译器自动生成内存管理代码,避免了手动管理内存带来的问题。 其次,iOS6版本引入了内存分页机制。这个机制能够将应用程序内存分成不同的页,将不常用的页置于闲置列表中,从而释放出更多的内存空间。这些闲置列表中的页能够在需要时快速恢复到内存中,减少了内存压力。 此外,iOS7版本中进一步提升了内存管理的能力。苹果在这个版本中引入了内存压缩技术,将内存中的数据进行压缩,从而提高了内存利用率。此外,iOS7还引入了资源清理功能,可以自动清理不再使用的资源,释放内存空间。 最后,在iOS13版本中,苹果进一步改进了内存管理策略。该版本中引入了后台内存优化功能,能够自动优化应用在后台运行时的内存占用,减少了后台应用对于系统内存的占用和影响。 综上所述,iOS内存管理版本记录反映了苹果在不同版本的iOS操作系统中对于内存管理方面的改进和优化。这些改进和优化使得iOS系统更加稳定和高效,并且提升了应用程序的性能和用户体验。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值