导语
几乎每一个iOS开发者都知道，在block中无法修改非静态局部变量的值，也知道解决方案是用__block来修饰一下变量。
但是，有没有深入地思考挖掘过呢？比如：
1.为什么block中无法修改非静态局部变量呢？
第一反应是变量是值传递到block中的，故无法修改。为什么对待非静态局部变量不能像对待静态局部变量那样，直接用指针传递呢？说到这就不得不说，静态局部变量和非静态局部变量的区别了，静态变量存在于应用程序的整个生命周期，而非静态局部变量，仅仅是存在于一个局部的上下文中。如果block执行过程中其所指向的非静态局部变量还没有被栈回收的话，这样执行是ok，然后绝大多数情况下，block都是延后执行的，故这样非常不妥。
在谈为什么加__block可以解决此问题之前，我们先讨论一个问题，为什么需要我们手动的去添加__block呢，编译器不能默认都给加上__block呢？如果编译器这么干了，那么block中所用到的非静态全局变量在block中都是可以修改的，其实block就是一个匿名函数，而非静态变量相对于block而言就是外部变量，这就是典型的在函数内修改外部变量，造成了副作用啊。此外，这么干也是有违非静态变量的初衷，造成了极大的混乱。所以，编译器默认都加上__block修饰符是不妥的，只能将这个决定权交给开发者自己去决定是加__block还是不加。
2.加__block后是什么鬼？
通过clang 重写源代码可以发现用__block修饰后，原来的变量已经被替换成一个与之相对应的struct变量（新变量），比如，定义一个
__block NSMutableArray *array = [NSMutableArray new]; 会变成
__Block_byref_array_1 array = {0,&array, 33554432, size, copyFunc, disposeFunc,[NSMutableArray new] };(经删除修改)
__Block_byref_array_1的结构体如下所示，
struct __Block_byref_array_1 {
void *__isa;
__Block_byref_array_1 *__forwarding;
int __flags;
int __size;
void (*__Block_byref_id_object_copy)(void*, void*);
void (*__Block_byref_id_object_dispose)(void*);
NSMutableArray *array;
};
通过分析发现，结构体中有一个__forwarding指针，初始化时此指针指向转换后变量本身；结构体中也有一个原变量一样类型的变量。
同时，此后代码中涉及到原变量的地方，都会转换成新变量->__forwarding->原变量同类型变量，其实关于这一点很少有书籍或者文章中提及，如果不能意识到这一点，对于很多问题理解起来会觉得很诧异！
3.__block为什么可行？
通过上面的分析，如果在block中直接修改变量的值，它实质上会转化成新变量->__forwarding->原变量同类型变量。 所以最终修改的其实是结构体中原变量同类型变量，而这个变量明显已经不属于block的外部变量了，所以是在block中是可以修改的。
此时，分析到这里，还是有两个疑问：
- 这个新变量也是非静态局部变量，block执行的时候，新变量可能已经被栈回收
如果block执行时，新变量也已经被释放的话，程序是会crash的，其实就算用了__block也不能解决这个问题，或者说__block 和这种情况似乎也没有什么联系吧！
日常开发中，好像很少遇到这种crash啊？因为实际开发中遇到的block大多数都已经copy到了堆上面，block在copy的时候，也会触发这个
__block变量的copy，会将变量从栈空间copy 到堆空间，所以block在执行的时候，使用的是堆空间上相应的变量，因而不会产生crash!
- __forwarding的作用是啥？为什么要这么设计？
-
__forwarding有什么用? 哪些地方会涉及到呢？
从代码层面上分析，如前文，在使用
__block变量时经转换后，其实都是通过其__forwarding来访问的从现象结果来看，如果在block中修改了
__block变量，block外修改亦有效，其实这也是__forwarding的功效 编译器是怎么用的？这样用有什么好处？
这个可以结合__block变量的copy源码来分析：
-
static void _Block_byref_assign_copy(void *dest, const void *arg, const int flags) {
struct Block_byref **destp = (struct Block_byref **)dest;
struct Block_byref *src = (struct Block_byref *)arg;
//printf("_Block_byref_assign_copy called, byref destp %p, src %p, flags %x\n", destp, src, flags);
//printf("src dump: %s\n", _Block_byref_dump(src));
if (src->forwarding->flags & BLOCK_IS_GC) {
; // don't need to do any more work
}
else if ((src->forwarding->flags & BLOCK_REFCOUNT_MASK) == 0) {
//printf("making copy\n");
// src points to stack
bool isWeak = ((flags & (BLOCK_FIELD_IS_BYREF|BLOCK_FIELD_IS_WEAK)) == (BLOCK_FIELD_IS_BYREF|BLOCK_FIELD_IS_WEAK));
// if its weak ask for an object (only matters under GC)
struct Block_byref *copy = (struct Block_byref *)_Block_allocator(src->size, false, isWeak);
copy->flags = src->flags | _Byref_flag_initial_value; // non-GC one for caller, one for stack
copy->forwarding = copy; // patch heap copy to point to itself (skip write-barrier)
src->forwarding = copy; // patch stack to point to heap copy
copy->size = src->size;
if (isWeak) {
copy->isa = &_NSConcreteWeakBlockVariable; // mark isa field so it gets weak scanning
}
if (src->flags & BLOCK_HAS_COPY_DISPOSE) {
// Trust copy helper to copy everything of interest
// If more than one field shows up in a byref block this is wrong XXX
copy->byref_keep = src->byref_keep;
copy->byref_destroy = src->byref_destroy;
(*src->byref_keep)(copy, src);
}
else {
// just bits. Blast 'em using _Block_memmove in case they're __strong
_Block_memmove(
(void *)©->byref_keep,
(void *)&src->byref_keep,
src->size - sizeof(struct Block_byref_header));
}
}
// already copied to heap
else if ((src->forwarding->flags & BLOCK_NEEDS_FREE) == BLOCK_NEEDS_FREE) {
latching_incr_int(&src->forwarding->flags);
}
// assign byref data block pointer into new Block
_Block_assign(src->forwarding, (void **)destp);
}
从源码中可以清晰的看到各种细节，这里不做过多解释！需要注意的一点就是
src->forwarding = copy;这里将原对象的forwarding指向了新创建的对象。很明显开始__block变量是在栈空间，其forwarding指向自身，当变量从栈空间copy到堆空间时，原来栈空间的变量的forwarding指向了新创建的变量（堆空间上），这其实就达到了从Objective C层面改变原变量的效果
- 不用__forwarding行不行？
暂时没有想到好的代替方案！欢迎补充！可见
__forwarding确实是整个方案设计的一大亮点！
