OC底层 - 类的扩展&关联对象 | magic-geng 移动端探索

OC底层 - 类的扩展&关联对象

· 2020-11-07 · # object-c底层探索

经过前3篇博客的总结，类的加载流程基本上过了一遍，下面我们继续来探索类的扩展和关联对象。

二、类的扩展

1、大致总结一下分类和扩展的区别：

分类：

（1）用来给类添加新的方法
（2）不能给类添加成员属性，添加了成员变量，也无法取到
（3）可以通过runtime给分类添加属性
（4）分类中用@property定义变量，只会生成变量的getter，setter方法的声明，不能生成方法实现和带下划线的变量。

（5）重点：

回顾懒加载类和非懒加载，以及attachCategories的加载时机：

 1、懒加载类 + 懒加载分类 ：
 消息第一次调用的时候，加载类的数据 （编译时期就完成分类的加载）

 * 2、非懒加载类 + 懒加载分类：
 read_image时，加载类的数据 （编译时期就完成分类的加载）

 3、非懒加载类 + 非懒加载分类 :
 read_image时，加载类的数据 (分类的加载在运行时，流程为：load_images -> 
 loadAllCategories -> load_categories_nolock -> attachCategories)

 4、懒加载类 + 非懒加载分类:
  read_image时，加载类的数据，迫使类成为非懒加载类样式来提前加载数据。
分类加载有2种情况：
（1）当只有一个分类为非懒加载分类时：分类是在编译期完成加载的。
*（2）当大于一个分类为非懒加载分类时：
分类是在运行时完成加载的（流程是：read_images -> realizeClassWithoutSwift 
->methodizeClass -> attachToClass -> attachCategories）

当以上为第2中情况和第4中情况中第(2)种情况时，都会走attachCategories的流程。

在attachCategories中会创建rwe,同时会把分类中的property拷贝到rwe中去。

如果是其他的情况，分类中的property不会拷贝到rwe中去。

扩展：

（1）可以说是特殊的分类，也叫做匿名分类
（2）可以给类添加成员属性，但是是私有变量
（3）可以给类添加方法，也是私有方法

2、扩展的位置

扩展必须在声明之后，实现之前：

@interface MyTestExtClass : NSObject

@end

 //扩展必须在这之间，否则会报错
 @interface MyTestExtClass ()
//扩展
@end

@implementation MyTestExtClass

@end

3、通过clang -rewrite-objc MyTestExtClass.m -o MyTestExtClass.cpp查看

extern "C" unsigned long OBJC_IVAR_$_MyTestExtClass$_ext_name;
struct MyTestExtClass_IMPL {
	struct NSObject_IMPL NSObject_IVARS;
	NSString *_ext_name;
};

static NSString * _I_MyTestExtClass_ext_name(MyTestExtClass * self, SEL _cmd) { return (*(NSString **)((char *)self + OBJC_IVAR_$_MyTestExtClass$_ext_name)); }
extern "C" __declspec(dllimport) void objc_setProperty (id, SEL, long, id, bool, bool);

static void _I_MyTestExtClass_setExt_name_(MyTestExtClass * self, SEL _cmd, NSString *ext_name) { objc_setProperty (self, _cmd, __OFFSETOFIVAR__(struct MyTestExtClass, _ext_name), (id)ext_name, 0, 1); }

可以看到通过扩展添加的属性，会写入成员变量和get、set方法。
再来看方法：

static struct /*_method_list_t*/ {
	unsigned int entsize;  // sizeof(struct _objc_method)
	unsigned int method_count;
	struct _objc_method method_list[5];
} _OBJC_$_INSTANCE_METHODS_MyTestExtClass __attribute__ ((used, section ("__DATA,__objc_const"))) = {
	sizeof(_objc_method),
	5,
	{{(struct objc_selector *)"ext_instanceMethod", "v16@0:8", (void *)_I_MyTestExtClass_ext_instanceMethod},
	{(struct objc_selector *)"ext_name", "@16@0:8", (void *)_I_MyTestExtClass_ext_name},
	{(struct objc_selector *)"setExt_name:", "v24@0:8@16", (void *)_I_MyTestExtClass_setExt_name_},
	{(struct objc_selector *)"ext_name", "@16@0:8", (void *)_I_MyTestExtClass_ext_name},
	{(struct objc_selector *)"setExt_name:", "v24@0:8@16", (void *)_I_MyTestExtClass_setExt_name_}}
};

static struct /*_method_list_t*/ {
	unsigned int entsize;  // sizeof(struct _objc_method)
	unsigned int method_count;
	struct _objc_method method_list[1];
} _OBJC_$_CLASS_METHODS_MyTestExtClass __attribute__ ((used, section ("__DATA,__objc_const"))) = {
	sizeof(_objc_method),
	1,
	{{(struct objc_selector *)"ext_classMethod", "v16@0:8", (void *)_C_MyTestExtClass_ext_classMethod}}
};

添加的实例方法和类方法，也写入到了method_list中了。说明在编译的时候就都添加到了类中。

1、_object_set_associative_reference中会调用association.acquireValue()来retain新值
这里OBJC_ASSOCIATION_RETAIN和OBJC_ASSOCIATION_RETAIN_NONATOMIC是都会执行objc_retain。
2、在设置完了之后，会判断是否需要释放旧值association.releaseHeldValue()
同样的OBJC_ASSOCIATION_RETAIN和OBJC_ASSOCIATION_RETAIN_NONATOMIC是都会执行objc_release。前提是已经设置了key对应的数据。

取值的逻辑：

id
_object_get_associative_reference(id object, const void *key)
{
    ObjcAssociation association{};
    {
        AssociationsManager manager;
        AssociationsHashMap &associations(manager.get());
        AssociationsHashMap::iterator i = associations.find((objc_object *)object);
        if (i != associations.end()) {
            ObjectAssociationMap &refs = i->second;
            ObjectAssociationMap::iterator j = refs.find(key);
            if (j != refs.end()) {
                association = j->second;
                association.retainReturnedValue();
            }
        }
    }
    return association.autoreleaseReturnedValue();
}

主要看retainReturnedValue和autoreleaseReturnedValue

 inline void retainReturnedValue() {
        if (_value && (_policy & OBJC_ASSOCIATION_GETTER_RETAIN)) {
            objc_retain(_value);
        }
        int a = 0;
    }

    inline id autoreleaseReturnedValue() {
        if (slowpath(_value && (_policy & OBJC_ASSOCIATION_GETTER_AUTORELEASE))) {
            return objc_autorelease(_value);
        }
        return _value;
    }

我们做一下位运算就知道，OBJC_ASSOCIATION_RETAIN会走objc_retain和objc_autorelease流程。
相当于返回了[[_value retain] autorelease]，但是注意一个细节，[_value retain]的时候是加锁的，解锁之后才相当于返回了[[_value retain] autorelease]。
而OBJC_ASSOCIATION_RETAIN_NONATOMIC则直接返回了_value。
这和我们在属性上直接设置atomic和nonatomic不是一个概念。
那么个人认为苹果在这里备注的"The association is made atomically."

    OBJC_ASSOCIATION_RETAIN = 01401,       /**< Specifies a strong reference to the associated object.
                                            *   The association is made atomically. */

并不是真正的原子性。而且在存值和取值的过程中，都会通过AssociationsManager加锁。所以我们一般使用NONATOMIC的策略比较好。

五、association属性的weak实现

在实现weak策略之前，先来实现一个之前面试过我的问题：

问题：如何监听一个对象释放？

这个问题有人会说，直接在dealloc中做一些释放工作不就行了吗？干嘛还要再做一个监听呢？是的，当时我面试的时候也是这么说的...
但是举2个场景来说一下这个监听的作用：

场景1：我们在类中使用kvo、notification的时候，添加observer之后，在dealloc里面需要去remove的。如果有了一层监听，那我们是不是就可以统一的在这个监听里面去remove了呢，而不用在每一个dealloc里面做remove的操作了（当然特殊的释放操作还是要放在dealloc里面去做）。

场景2: 比如我们有些业务，需要依赖于某一个类A释放之后继续操作。那直接从类A的dealloc方法回调给当前类处理也太麻烦了吧。

那么针对这个问题，我们首先从dealloc的底层分析：

- (void)dealloc {
    _objc_rootDealloc(self);
}
void _objc_rootDealloc(id obj) {
    ASSERT(obj)
    obj->rootDealloc();
}

inline void objc_object::rootDealloc() {    
    if (isTaggedPointer()) return;  // fixme necessary?
    
    if (fastpath(isa.nonpointer                     &&
                 !isa.weakly_referenced             &&
                 !isa.has_assoc                     &&
#if ISA_HAS_CXX_DTOR_BIT
                 !isa.has_cxx_dtor                  &&
#else
                 !isa.getClass(false)->hasCxxDtor() &&
#endif
                 !isa.has_sidetable_rc))
    {
        assert(!sidetable_present());
        free(this);
    }
    else {
        object_dispose((id)this);
    }
}

id object_dispose(id obj) {
    if (!obj) return nil;
    objc_destructInstance(obj);
    free(obj);
    return nil;
}

void *objc_destructInstance(id obj) 
{
    if (obj) {
        // Read all of the flags at once for performance.
        bool cxx = obj->hasCxxDtor();
        bool assoc = obj->hasAssociatedObjects();
        // This order is important.
        if (cxx) object_cxxDestruct(obj);
        //编译器会在object_cxxDestruct之后插入cxx_destruct，在cxx_destruct中又会调用objc_destroyWeak(引用 "弱引用的对象",也就是有弱引用属性的对象，释放时会调用)
        if (assoc) _object_remove_assocations(obj, /*deallocating*/true);
        obj->clearDeallocating();
    }
    return obj;
}

以上代码就是整个dealloc的流程。
dealloc -> _objc_rootDealloc -> object_dispose(主要判断了是否被弱引用，是否有关联对象)
-> objc_destructInstance -> _object_remove_assocations ，clearDeallocating。
由于对象dealloc时候，如果有关联对象，会先移除关联对象。
方案如下：

1、我们可以给NSObject增一个分类，添加一个关联对象。因为当关联对象释放之后，当前对象也会释放。所以我们可以监听这个关联对象。

2、在这个关联对象里面加一个target属性，用来弱引用宿主对象。

3、给外界提供一个block回调，在关联对象释放的时候回调回来做额外的操作。

看代码：
自定义的关联对象：


@interface MGAssociatedObject : NSObject

- (instancetype)initWithTarget:(NSObject *)target;
- (void)addActionBlock:(MGBlock)block;

@end

@interface MGAssociatedObject ()
/*
 这里不用weak是由于在target释放的时候，先释放关联对象。
 然后有weak引用会调用objc_destroyWeak，清除weak表中对应的弱引用指针，并将弱引用指针指向nil
 （通过源码分析，在dealloc回调的时候weak表并没有清除。
 objc_destroyWeak也是在MGBlock回调之后才走的。
 但是可能是内部的多线程引起，系统不让你读到弱引用对象）。
 所以回调的地方拿到的就是nil了，此时应该使用unsafe_unretained
 （由于target一定是在之后才彻底释放的，所以这里用unsafe_unretained不会产生野指针问题）。
 **/
@property (nonatomic, unsafe_unretained) NSObject *target;
@property (nonatomic, strong) NSMutableArray<MGBlock> *deallocBlocks;

@end

@implementation MGAssociatedObject

- (instancetype)initWithTarget:(NSObject *)target {
    self = [super init];
    if (self) {
        _deallocBlocks = [NSMutableArray arrayWithCapacity:0];
        _target = target;
    }
    
    return self;
}

- (void)addActionBlock:(MGBlock)block {
    [self.deallocBlocks addObject:[block copy]];
}

- (void)dealloc {
    [_deallocBlocks enumerateObjectsUsingBlock:^(MGBlock  _Nonnull obj, NSUInteger idx, BOOL * _Nonnull stop) {
        obj ? obj(_target) : nil;
    }];
}
@end

自定义的分类：

typedef void(^MGBlock)(__unsafe_unretained NSObject *target);

@interface NSObject (MGWillDealloc)

- (void)mg_doSthWhenDeallocWithBlock:(MGBlock)block;

@end

@implementation NSObject (MGWillDealloc)

- (void)mg_doSthWhenDeallocWithBlock:(MGBlock)block {
    if (block) {
        //设置关联对象
        MGAssociatedObject *associatedObject = objc_getAssociatedObject(self, &kMGAssociatedObjectKey);
        if (!associatedObject) {
            associatedObject = [[MGAssociatedObject alloc] initWithTarget:self];
            objc_setAssociatedObject(self, &kMGAssociatedObjectKey, associatedObject, OBJC_ASSOCIATION_RETAIN_NONATOMIC);
        }
        [associatedObject addActionBlock:block];
    }
@end

这样我们就可以在任何oc的类中去通过mg_doSthWhenDeallocWithBlock来监听它的释放了。

接下来就看怎么实现关联对象的weak策略了。

weak策略

首先关联对象中有OBJC_ASSOCIATION_ASSIGN策略，那么assign如果修饰oc对象的话，确实不会产生引用计数+1，但是当对象释放之后，会造成野指针。

- (void)testAssignCase {
    {
        UILabel *associatedLabel = [UILabel new];
        objc_setAssociatedObject(self, @selector(associatedLabel), associatedLabel, OBJC_ASSOCIATION_RETAIN);
    }
    UILabel *label = objc_getAssociatedObject(self, @selector(associatedLabel)); // EXC_BAD_ACCESS
    [self.view addSubview:label];
}

例如以上代码，当associatedLabel出了作用域之后，就被释放了。后面通过objc_getAssociatedObject拿到已经释放的内存地址，无法访问。

所以我们需要自己实现一个weak策略：

因为assign会造成野指针问题，那么当关联对象释放时，将ObjectAssociationMap表中key对应的association也移除。就可以避免由于assign的方式访问了非法内存的异常了。也就达到了weak的效果了。

/// 设置关联对象支持weak的方式
/// @param object 宿主对象
/// @param key 关联key
/// @param value 关联的对象
//声明:
extern void objc_setWeakAssociatedObject(id _Nonnull object, const void * _Nonnull key, id _Nullable value);
//实现:
void objc_setWeakAssociatedObject(id _Nonnull object, const void * _Nonnull key, id _Nullable value) {
    if (value) {
        [value mg_doSthWhenDeallocWithBlock:^(NSObject *__unsafe_unretained  _Nonnull target) {
            objc_setAssociatedObject(object, key, nil, OBJC_ASSOCIATION_ASSIGN); // clear association
        }];
    }
    objc_setAssociatedObject(object, key, value, OBJC_ASSOCIATION_ASSIGN); 
}

可以测试一下:

- (void)testWeakCase {
    {
        UILabel *associatedLabel = [UILabel new];
        objc_setWeakAssociatedObject(self, @selector(associatedLabel), associatedLabel);
    }
    UILabel *label = objc_getAssociatedObject(self, @selector(associatedLabel)); // EXC_BAD_ACCESS
    [self.view addSubview:label];
}

完美达到weak的效果，但是某些场景下，记得判空处理。

六、关联对象是线程安全的吗？

是线程安全的。当我们调用get和set方法时，都会通过底层的AssociationsManager管理的一张AssociationsHashMap表来设置值和取值的。

以get方法为例：首先会以对象的地址为key，计算出下标值，从AssociationsHashMap取出对应的ObjectAssociationMap表，再以void *key 去ObjectAssociationMap表中取到ObjcAssociation，ObjcAssociation中包含了value和policy，从而取到value。而刚才说的AssociationsManager（关联对象管理器）在构造方法中会加一把自旋锁，从而保证了取值过程和设置值的过程线程安全。

追问：那在什么时候解锁的呢？

是在AssociationsManager析构的时候，也就是设置完值，或者取完值的时候，AssociationsManager被系统释放时，会调用析构方法，从而解锁。
关于锁的分析，后面会具体探索。

七、关联对象总结

1、流程图：

2、设置值流程：

（1）创建一个AssociationsManager管理类
（2）获取唯一的全局静态哈希Map (_mapStorage)
（3）判断要插入的关联值是存在，如果存在走第(4)步，否则走插入空流程
（4）创建一个空的ObjectAssociatioinMap去取查询的键值对
（5）如果发现没有这个关联对象，就插入一个空的BuckeT进去，然后返回。再设置isFirstAssociation = true，标记为第一次创建关联对象。
（6）拿当前的key和当前策略以及值组成的ObjectAssociatioin，去查找对应的key是否设置了关联值，如果没有设置则设置，如果设置了，就替换原来的策略和值。
（7）标记此对象存在关联对象（修改isa中has_assoc=true）

3、插入空的流程

（1）根据DisguisedPtr找到AssociationsHashMap中的iterator迭代查询器
（2）清理迭代器
（3）相当于清除AssociationsHashMap中的关联对象。

4、取值流程

（1）创建一个AssociationsManager管理类
（2）获取唯一的全局静态哈希Map
（3）根据DisgusedPtr找到AssociationsHasMap中的iterator迭代查询器
（4）通过迭代器，获取ObjectAssociationMap (这里有策略和value)
（5）找到ObjcetAssociationMap的迭代查询器获取一个经过属性修饰符（key）修饰的value
（6）返回value

5、关联对象怎么释放，对象释放时怎么释放关联对象？

当我们设置的值为nil的时候，会从ObjectAssociationMap中，移除objcAssociation。
而整个关联对象会跟随对象释放。在对象释放的时候，会走dealloc方法。此时底层会判断，当前对象isa中保存的has_assoc（关联对象标志）是否为true，也就是,是否包含关联对象。如果包含会走object_dispose->objc_destructInstance->_object_remove_assocations，从AssociationHashMap中移除此关联对象。