前言
日常开发中，为一个已有的类(比如说不想影响其文件结构)、第三方库提供的类增加几个property，已经是十分常见且需要的操作了，有人会单独起草一份category.m文件，也有人直接继承，像我一般会用category，一是能减少类文件的数量提高编译速度，二也是为了代码结构更加清晰。
这篇文章是用来写Category的进行属性扩展的行为的，所以我还是言归正传，首先，我要阐述一下目前比较主流的几个属性扩展形式，再往下进行分析:
- 利用 objc_setAssociatedObject函数进行对象的联合。
- 利用 class_addProperty 函数进行类属性的扩展
- 通过内部创建一个其他对象(比如字典),通过重写本对象set和get或者消息转发。
下面对这三种常用方法进行分析，其实常见的都是前面两种，第三种也是比较非主流。在分析这三种之前，我要谈一下为什么不能用 class_addIvar 函数。
- class_addIvar 函数
在苹果文档中，对 class_addIvar 函数有下面一段话:
This function may only be called after objc_allocateClassPair(_:_:_:) and before objc_registerClassPair(_:). Adding an instance variable to an existing class is not supported.
The class must not be a metaclass. Adding an instance variable to a metaclass is not supported.
这个功能只能在 objc_allocateClassPair(_:_:_:) 之后和 objc_registerClassPair(_:) 之前调用。不支持将实例变量添加到现有的类。
该类不能是元类。不支持将实例变量添加到元类。
文档是说不能将此函数用于已有的类，必须是动态创建的类，为了能够知道为何会这样，我们需要翻阅一下苹果开源的 runtime 源码。
- 首先看一下关于 objc_allocateClassPair 函数的代码实现:
去除干扰代码，我们寻找到下面的函数调用链条:
objc_allocateClassPair -> objc_initializeClassPair_internal
// 下面的代码已经被我大部分剔除，只留下我们分析所需要用到的代码
static void objc_initializeClassPair_internal(Class superclass, const char *name, Class cls, Class meta)
{
// Set basic info
cls->data()->flags = RW_CONSTRUCTING | RW_COPIED_RO | RW_REALIZED | RW_REALIZING;
meta->data()->flags = RW_CONSTRUCTING | RW_COPIED_RO | RW_REALIZED | RW_REALIZING;
cls->data()->version = 0;
meta->data()->version = 7;
// RW_CONSTRUCTING 类已分配但还未注册
// RW_COPIED_RO class_rw_t->ro 来自 class_ro_t 结构的复制
// RW_REALIZED // class_t->data 的结构为 class_rw_t
// RW_REALIZING // 类已开始分配，但并未完成
// 以上几个宏都是对新类的class_rw_t结构设置基本信息
}
- 下面是class_addIvar的与我分析所需要的实现代码
// 无关代码已经剔除
BOOL
class_addIvar(Class cls, const char *name, size_t size,
uint8_t alignment, const char *type)
{
if (!cls) return NO;
if (!type) type = "";
if (name && 0 == strcmp(name, "")) name = nil;
rwlock_writer_t lock(runtimeLock);
assert(cls->isRealized());
// No class variables
if (cls->isMetaClass()) {
return NO;
}
// Can only add ivars to in-construction classes.
if (!(cls->data()->flags & RW_CONSTRUCTING)) {
return NO;
}
}
// 重点在这最后一句，前面我们已经看到 objc_allocateClassPair 函数所分配的新类的flags位信息，在此处 & RW_CONSTRUCTING，必定为真，取反后跳过大括号向下执行。
- 已经存在的类，经过测试，flag位为 RW_REALIZED|RW_REALIZING,设置函数如下:
static Class realizeClass(Class cls)
{
runtimeLock.assertWriting();
const class_ro_t *ro;
class_rw_t *rw;
Class supercls;
Class metacls;
bool isMeta;
if (!cls) return nil;
if (cls->isRealized()) return cls;
assert(cls == remapClass(cls));
// fixme verify class is not in an un-dlopened part of the shared cache?
ro = (const class_ro_t *)cls->data();
if (ro->flags & RO_FUTURE) {
// This was a future class. rw data is already allocated.
rw = cls->data();
ro = cls->data()->ro;
cls->changeInfo(RW_REALIZED|RW_REALIZING, RW_FUTURE);
} else {
// Normal class. Allocate writeable class data.
rw = (class_rw_t *)calloc(sizeof(class_rw_t), 1);
rw->ro = ro;
rw->flags = RW_REALIZED|RW_REALIZING;
cls->setData(rw);
}
}
所以在经过条件 !((RW_REALIZED | RW_REALIZING) & RW_CONSTRUCTING) 时返回NO。
以上便是对已有类不能使用 class_addIvar 函数的分析
好了，回到真正的话题，对上面三种操作的分析:
- objc_setAssociatedObject
我们都知道，在category中使用property，可以生成set和get的方法声明，原因在此不做分析，一般为了方便的调用，我们都会写上property，关键在于没有set和get的实现，于是就会有下面这样的代码:
static void *key = "key";
@implementation Person (Extra)
// 此处不考虑读写锁的问题
- (void)setName:(NSString *)name{
objc_setAssociatedObject(self, key, name, OBJC_ASSOCIATION_COPY_NONATOMIC);
}
- (NSString *)name{
return objc_getAssociatedObject(self, key);
}
@end
上面的 objc_setAssociatedObject 函数内部的调用链条如下:
objc_setAssociatedObject -> objc_setAssociatedObject_non_gc -> _object_set_associative_reference
// 其中主要操作都在 _object_set_associative_reference 函数中，内部实现类似一般属性的set实现(保留新值，释放旧值)，在此我们不进行深究，具体可以参考业内大佬的博客文章。
这种操作很直观的表达了我们的需要，且API十分友好，仅仅是对于 weak 策略我们需要自己设计一个。
并且这种操作的好处是我们无需关系关联对象的声明周期，因为和普通的属性一样，会随着宿主对象的释放而释放,具体可以看以下代码:
dealloc -> _objc_rootDealloc -> rootDealloc -> object_dispose -> objc_destructInstance
// 大部分释放操作在 objc_destructInstance 函数中完成
// 下面是 objc_destructInstance 函数的实现代码
void *objc_destructInstance(id obj)
{
if (obj) {
// Read all of the flags at once for performance.
bool cxx = obj->hasCxxDtor();
bool assoc = !UseGC && obj->hasAssociatedObjects();
bool dealloc = !UseGC;
// This order is important.
// 内部通过C++的析构函数进行对象属性的释放，具体可看sunny大神的博文
if (cxx) object_cxxDestruct(obj);
// 此处会移除所有的关联对象，也就是objc_setAssociatedObject 函数所设置上去的对象
if (assoc) _object_remove_assocations(obj);
// 清空引用计数与weak表
if (dealloc) obj->clearDeallocating();
}
return obj;
}
当然也有不足之处，利用 objc_setAssociatedObject 生成的关联对象无法直接利用目前主流的Json转Model库(原因是无法在ivar及property中遍历出来)。
- 利用 class_addProperty 函数进行类属性的扩展
class_addProperty 函数可以为我们生成类的property，@property是编译器的标识符，在普通类中可生成property、ivar、setMethod与getMethod，在我看来property的真实作用类似于方法的声明，后面我会再谈为什么。
在分类中使用class_addProperty和普通类一样， 只能生成set和get方法的声明，无论有没有被实现，我们都可以用 class_copyMethodList 函数得到property的list，如果这时候你想存储属性值，你依然必须手动或动态实现那些set和get方法，并且真实数据的存储也必须由你自己提供实现，比如可以使用前面所说的objc_setAssociatedObject 函数。
现在说说为啥property只是一个类似声明的作用呢，我们可以从苹果开源的代码中找到蛛丝马迹:
Class 是一个指向结构体 objc_class 的指针，而此结构体的结构如下所示:
struct objc_class : objc_object {
// Class ISA;
Class superclass; // 指向父类
cache_t cache; // 缓存指针与vtable(没学过C++,没了解过虚函数这些)，加速方法的调用
class_data_bits_t bits; // 真正保存对象的ivar，property与method等信息的地方
}
在源码中大部分时候表现为将类的大部分信息保存在 class_rw_t *rw指针中，不过内部也是返回bits中处理后的信息
class_rw_t *data() {
return bits.data();
}
在class_rw_t的结构中，结构如下所示:
struct class_rw_t {
// Be warned that Symbolication knows the layout of this structure.
uint32_t flags; // 类的信息标记
uint32_t version; // 当前运行时版本
const class_ro_t *ro;
method_array_t methods;
property_array_t properties;
protocol_array_t protocols;
}
可以看到在class_rw_t的结构中，包含了另一个十分相似的 const class_ro_t *ro 成员变量。
这个成员变量为一个不可修改内容的结构体指针，其中存储了类在编译时就已经确定好的ivar、 property、method、protocol等信息，在类的初始化时会通过 methodizeClass 函数将其大部分内容都拷贝到 class_rw_t *rw中，其中 ivar 不会被拷贝，这也是前面所说的不能在运行时给已有的类增加 ivar的原因。
像property、method、protocol都是可以在运行时动态添加的，且存储到 rw 的结构中去。
好像说的有点跑题了，咱们还是一起看看property到底存储了什么信息:
struct property_t {
const char *name;
const char *attributes;
};
可以看到，propperty中并没有存储很多信息，只有name和配置的属性，也没有实现函数的地址，所以前面我说property的作用其实和方法的声明是差不多的。
关于property的好处，也就是在使用网上json转model库时可以被遍历到了，但是如果你没有实现set和get，那依然会导致KVC的crash。
- 通过内部创建一个其他对象(比如字典),通过重写本对象set和get或者消息转发。
最后一种方法，也是比较少用的方式，说起来也比较简单，比如定义一个静态的字典变量，然后通过实现interface中声明的set和get的实现对这个字典变量做存取操作，或者通过消息转发中的 (id)forwardingTargetForSelector:(SEL)aSelector 方法返回这个字典变量，但是要注意本类中没有对转发做过什么事，不然这种方法也是不适用的。
对上文的总结
其实刚刚所描述的三种分类策略并不是很严谨，因为其中几种总是会搭配着使用，所以在此也要选择一个比较均衡的策略来实现Category属性的绑定。
建议的策略:
- 由于我们肯定会在interface 中提供生的property（由于没有合成实现与ivar，在此称为生的），所以这样对于在外部访问时和普通property相同。
- 由于缺乏的是实现以及可以存取的数据量，这里我们可以直接实现这些set与get。
- set与get的实现可以通过 associatedObject 进行对对象的存取操作。
好处： 这种操作由于提供了生的property，所以在第三方的json转model库遍历property时可以直接遍历到，由于你手动实现了set与get，所以在遍历后的KVC赋值时也能起到作用，保证了和普通成员变量的操作一致性。
估计会有人看完结论后觉得:“ 我本来就是这么写的啊，你写这么多字到头来得出的结论和我平时写的也一样。”是的，我只能略表抱歉啦😏！
网友评论