前言
日常开发中,为一个已有的类(比如说不想影响其文件结构)、第三方库提供的类增加几个property,已经是十分常见且需要的操作了,有人会单独起草一份category.m文件,也有人直接继承,像我一般会用category,一是能减少类文件的数量提高编译速度,二也是为了代码结构更加清晰。
这篇文章是用来写Category的进行属性扩展的行为的,所以我还是言归正传,首先,我要阐述一下目前比较主流的几个属性扩展形式,再往下进行分析:
-
利用 objc_setAssociatedObject函数进行对象的联合。
-
利用 class_addProperty 函数进行类属性的扩展
-
通过内部创建一个其他对象(比如字典),通过重写本对象set和get或者消息转发。
下面对这三种常用方法进行分析,其实常见的都是前面两种,第三种也是比较非主流。在分析这三种之前,我要谈一下为什么不能
class_addIvar 函数。
-
class_addIvar 函数
在苹果文档中,对 class_addIvar 函数有下面一段话:
1
2
3
4
|
This
function
may only be called after objc_allocateClassPair(_:_:_:) and before objc_registerClassPair(_:). Adding an instance
var
iable to an existing
class
is
not supported.
The
class
must not be a metaclass. Adding an instance
var
iable to a metaclass
is
not supported.
这个功能只能在 objc_allocateClassPair(_:_:_:) 之后和 objc_registerClassPair(_:) 之前调用。不支持将实例变量添加到现有的类。
该类不能是元类。不支持将实例变量添加到元类。
|
文档是说不能将此函数用于已有的类,必须是动态创建的类,为了能够知道为何会这样,我们需要翻阅一下苹果开源的 runtime 源码。
1.首先看一下关于 objc_allocateClassPair 函数的代码实现:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
去除干扰代码,我们寻找到下面的函数调用链条:
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结构设置基本信息
}
|
2.下面是class_addIvar的与我分析所需要的实现代码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
// 无关代码已经剔除
BOOL
class_addI
var
(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,必定为真,取反后跳过大括号向下执行。
|
3.已经存在的类,经过测试,flag位为 RW_REALIZED|RW_REALIZING,设置函数如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
|
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的实现,于是就会有下面这样的代码:
1
2
3
4
5
6
7
8
9
10
|
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 函数内部的调用链条如下:
1
2
|
objc_setAssociatedObject -> objc_setAssociatedObject_non_gc -> _object_set_associative_reference
// 其中主要操作都在 _object_set_associative_reference 函数中,内部实现类似一般属性的set实现(保留新值,释放旧值),在此我们不进行深究,具体可以参考业内大佬的博客文章。
|
这种操作很直观的表达了我们的需要,且API十分友好,仅仅是对于 weak 策略我们需要自己设计一个。
并且这种操作的好处是我们无需关系关联对象的声明周期,因为和普通的属性一样,会随着宿主对象的释放而释放,具体可以看以下代码:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
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只是一个类似声明的作用呢,我们可以从苹果开源的代码中找到蛛丝马迹:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
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到底存储了什么信息:
1
2
3
4
|
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赋值时也能起到作用,保证了和普通成员变量的操作一致性。
估计会有人看完结论后觉得:“ 我本来就是这么写的啊,你写这么多字到头来得出的结论和我平时写的也一样。”是的,我只能略表抱歉啦!