通过探索Category底层原理回答以下问题
1) Category是否可以添加方法、属性、成员变量？Category是否可以遵守Protocol？
2) Category的本质是什么，在底层是怎么存储的？
3) Category的实现原理是什么，Catagory中的方法是如何调用到的？
4) Category中是否有Load方法，load方法是什么时候调用的？
5) load、initialize的区别
Category可以直接添加 属性、成员变量吗？
创建一个ZHPerson类
添加分类
发现分类中可以添加属性，方法，协议，但是不能添加成员变量。
分析为什么不能添加成员变量？
Category的底层数据结构
首先创建两个分类 协助测试
将分类文件编译为.cpp文件，切换到文件所在文件夹下执行：
xcrun -sdk iphoneos clang -arch arm64 -rewrite-objc ZHPerson+Sport.m
xcrun -sdk iphoneos clang -arch arm64 -rewrite-objc ZHPerson+Eat.m
检索_I_ZHPerson_Sport_sport 和 _C_ZHPerson_Sport_sport
分析可知：上述代码创建了_method_list_t类型的结构体变量
_OBJC_$_CATEGORY_INSTANCE_METHODS_ZHPerson_$_Sport
和 _OBJC_$_CATEGORY_CLASS_METHODS_ZHPerson_$_Sport
分别用于存储实例方法列表和类方法列表
这里简单说下_objc_method中的method_type，详细介绍后续在探究runtime消息机制时再继续扒。method_type其实可以看做用字符缩写来表达的函数类型字符串，比如 v@:i 就是返回类型为void，第一个参数为id类型，第二个参数为指针类型，第三个参数为int类型的函数，如- (void)addStepCount:(int)count（我们知道iOS中方法调用会默认传入隐式参数 方法调用者：self 和 方法名：_cmd。这也是为什么我们可以在方法内部访问self、cmd的原因)
继续检索_OBJC_$_CATEGORY_ZHPerson_$_Sport
回答第二个问题：分类底层如何存储的
分析可知：上述代码创建了一个_category_t类型的结构体变量 _OBJC_$_CATEGORY_ZHPerson_$_Sport；并且传入了类方法列表、实例方法列表、协议类别、属性列表，具备了Category的所有信息，没错Category在底层就是_category_t类型，下边我们检索结构体类型_category_t，看下_category_t的定义；
到此我们已经清楚的看到了Category在底层的存储结构，并且可以看到底层并没有存储成员变量，这也就是为什么直接添加成员变量会报错的原因。
Category中的属性
并且我们知道在类中添加一个属性，系统为我们做了三件事
@property (nonatomic, copy) NSString *name;
1) 创建了一个成员变量_name
2) 生成了setter、getter方法的声明
3) 生成了setter、getter方法的实现
对比 ZHPerson 编译后的.cpp中的属性和分类中的区别
ZHPerson.cpp:
ZHPerson (Sport).cpp 文件
发现原类中生成了属性的settter 和getter 方法，但是分类中没有属性的settter 和getter 实现。
在Category添加属性系统仅仅只生成了setter、getter方法的声明
如何使Category中的属性与类中的属性具备同样的效果（关联对象）
可以通过runtime中的关联对象方法来实现
关联策略，和@property后的关键字对应.
系统是如何管理关联对象的
去官网下载runtime源码，搜索objc_setAssociatedObject方法，这里不做过多分析，简单说下结论，后续会单开一篇扒关联对象的实现原理。
runtime用四个类来管理关联对象，AssociationsManager、AssociationsHashMap、AssociationsMap、ObjectAssociation，
1）关联对象并不是存储在被关联对象本身内存中
2） 关联对象存储在全局的统一的一个AssociationsManager中
3）设置关联对象为nil，就相当于是移除关联对象
Category中的方法调用顺序 - 表象
再创建一个ZHPerson的子类ZHStudent ,再编写一个ZHStudent的分类，分类里书写life方法
结论：1、分类中方法会覆盖原类中的方法
2.、Compile Sources中编译顺序在后面的文件优先级会更高。
ZHPerson有两个分类Sport 和Eat,并且两个分类都实现了life方法，
但是全部调用的分类Sport的方法，和Build Phases 里的Compile Sources 里的文件编译顺序有关
1、分类中的方法优先级高于原类中的方法
2、后编译的分类优先级高于先编译的分类
3、我们常说的分类方法覆盖原类方法并不是真正的覆盖，只是objc_msgSend在分类中找到方法实现后不再继续查找。
Category方法调用顺序 - 本质
1）OC中的方法调用简单的说就是通过实例对象（或类对象）的isa指针和类对象（或元类对象）的superClass指针去类（或元类）对象中查找方法。
2）Category中的方法、属性等编译后是存储在category_t结构体中的，也就是说编译后分类中的方法并没有合并到类（或元类）中，我们是无法在类对象（或元类对象）中找到Category中的方法的。
3）但是最终调用的时候我们却可以通过isa和superClass指针找到这些方法。所以我们有理由猜测runtime帮我们做了方法合并
4）_objc_init就是runtime的初始化函数，是在app启动过程的"初始化除可执行文件外的所有Mach-O文件初始化调用的；按文件编译倒序将各分类中的方法、协议、属性列表分别整合成一个二维数组后，添加到原类中的方法列表，属性列表，协议列表。（分类中的方法属性等系统是什么时候如何添加到原类中的？）
Category中的+load方法
在创建的两个类文件以及3个分类文件添加+load方法，也添加上initialize()方法，方便后面测试。
不导入上面相关任何文件，不创建对象，直接运行
可以发现未做任何调用和对象创建的情况下，也会执行+ (void)load方法。
尝试在xcode->targets->build phases->compile sources中调整文件编译顺序，发现
1、父类中的load优先于子类中调用，且不受编译顺序影响。
2、原类中的load方法优先于分类调用，且不受编译顺序影响。
3、两个分类中的load方法执行顺序根据编译顺序，且与其继承的父类无关系。
Category中的+ (void)initialize方法
再创建一个新类ZHDog,作对比
像测试load方法一样，不导入创建的任何文件不创建对象，直接运行但是并没有调用initialize方法。
创建对象
情况1
情况2
情况3
以上3种情况的打印结果都是下面结果：
3种情况编译顺序都是
说明同一个类中的initialize方法在多次创建对象时仅调用一次，
现在只调整文件编译顺序：
打印结果没变
initialize调用总结：
1）父类调用优先级高于子类,不受编译顺序影响；
2） 分类会覆盖原类中的方法
注意，如果子类及子类分类没有实现initialize方法，根据runtime消息发送机制，父类中的initialize会调用两次
现在注释掉ZHStudent及其分类的initialize方法，其他全不变
load是只要类所在的文件被引用就会被调用，而initialize在类或其子类的第一个方法调用之前被调用（runtime 中load方法不能认为第一个方法）。load在main函数之前调用，initialize在main函数之后调用。这两个方法会被自动调用。
· load和initialize方法都不用显示的调用父类的方法而是自动调用，即使子类没有initialize方法也会调用父类的方法如果子类显示调用[super initialize]，则父类多次调用，load方法则不会调用父类。
·load方法通常用来进行Method Swizzle，initialize方法一般用于初始化全局变量或静态变量。
·load和initialize方法内部使用了锁，因此它们是线程安全的。实现时要尽可能保持简单，避免阻塞线程，不要再使用锁。
·每个类只调用initialize一次。如果希望为类和类的类别执行独立初始化，则应该实现load方法
