No matter how well a class is designed, it is possible to encounter unpredictable situations in the evolution of future requirements. So how do you extend existing classes? In general, inheritance and composition are good choices. But in Objective-C 2.0, a category language feature is available that dynamically adds new behavior to existing classes. Today, categories are everywhere in Objective-C code, from the official Apple framework to various open source frameworks, from large apps with complex functions to simple applications, catagory is everywhere. This paper makes a comprehensive arrangement of categories, hoping to be of benefit to readers.

Categories are a language feature added after Objective-C 2.0. Their main purpose is to add methods to existing classes. In addition, Apple recommends two other usage scenarios for category 1

• You can separate the implementation of a class into several different files. There are several obvious benefits to doing this: a) reducing the size of a single file, b) organizing different functions into different categories, c) creating a class by multiple developers, d) loading desired categories on demand, and so on.
• Declare private methods

However, in addition to the usage scenarios recommended by Apple, the majority of developers have rich imagination and have derived several other usage scenarios of category:

• Simulated multiple inheritance
• Expose the framework’s private methods

This language feature of Objective-C may be trivial in purely dynamic languages such as javascript, where you can add arbitrary methods and instance variables to a “class” or object at any time. But for languages that aren’t so “dynamic,” this is a great feature.

All OC classes and objects are structs at the Runtime layer. Category is struct at the Runtime layer. Category_t (category_t in objc-Runtime-new.h) It contains 1), the name of the class, 2), class (CLS), 3), a list of all the instanceMethods added to the class in the category (instanceMethods), and a list of all the classMethods added in the category (classMethods). 5) Protocols of all protocols implemented by category 6) instanceProperties added by category

typedef struct category_t {
    const char *name;
    classref_t cls;
    struct method_list_t *instanceMethods;
    struct method_list_t *classMethods;
    struct protocol_list_t *protocols;
    struct property_list_t *instanceProperties;
} category_t;Copy the code

From the definition of category, we can also see that category can be (can add instance methods, class methods, and even implement the protocol, add attributes) and not (can not add instance variables). Ok, let’s go ahead and write a category and see what a category is:

MyClass. H:

#import <Foundation/Foundation.h>

@interface MyClass : NSObject

- (void)printName;

@end

@interface MyClass(MyAddition)

@property(nonatomic, copy) NSString *name;

- (void)printName;

@endCopy the code

MyClass. M:

#import "MyClass.h"

@implementation MyClass

- (void)printName
{
    NSLog(@"%@",@"MyClass");
}

@end

@implementation MyClass(MyAddition)

- (void)printName
{
    NSLog(@"%@",@"MyAddition");
}

@endCopy the code

Let’s use Clang’s command to see what the category actually becomes:

clang -rewrite-objc MyClass.mCopy the code

Well, we’ve got a.cpp file that’s 3M in size, 10W lines long (this is definitely a joke for Apple), we’ve ignored everything that doesn’t concern us, and at the end of the file we find the following code snippet:

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

static struct /*_prop_list_t*/ {
unsigned int entsize;  // sizeof(struct _prop_t)
unsigned int count_of_properties;
struct _prop_t prop_list[1];
} _OBJC_$_PROP_LIST_MyClass_$_MyAddition __attribute__ ((used, section ("__DATA,__objc_const"))) = {
sizeof(_prop_t),
1,
{{"name","T@\"NSString\",C,N"}}
};

extern "C" __declspec(dllexport) struct _class_t OBJC_CLASS_$_MyClass;

static struct _category_t _OBJC_$_CATEGORY_MyClass_$_MyAddition __attribute__ ((used, section ("__DATA,__objc_const"))) =
{
"MyClass",
0, // &OBJC_CLASS_$_MyClass,
(const struct _method_list_t *)&_OBJC_$_CATEGORY_INSTANCE_METHODS_MyClass_$_MyAddition,
0,
0,
(const struct _prop_list_t *)&_OBJC_$_PROP_LIST_MyClass_$_MyAddition,
};
static void OBJC_CATEGORY_SETUP_$_MyClass_$_MyAddition(void ) {
_OBJC_$_CATEGORY_MyClass_$_MyAddition.cls = &OBJC_CLASS_$_MyClass;
}
#pragma section(".objc_inithooks$B", long, read, write)
__declspec(allocate(".objc_inithooks$B")) static void *OBJC_CATEGORY_SETUP[] = {
(void *)&OBJC_CATEGORY_SETUP_$_MyClass_$_MyAddition,
};
static struct _class_t *L_OBJC_LABEL_CLASS_$ [1] __attribute__((used, section ("__DATA, __objc_classlist,regular,no_dead_strip")))= {
&OBJC_CLASS_$_MyClass,
};
static struct _class_t *_OBJC_LABEL_NONLAZY_CLASS_$[] = {
&OBJC_CLASS_$_MyClass,
};
static struct _category_t *L_OBJC_LABEL_CATEGORY_$ [1] __attribute__((used, section ("__DATA, __objc_catlist,regular,no_dead_strip")))= {
&_OBJC_$_CATEGORY_MyClass_$_MyAddition,
};Copy the code

$CATEGORY_INSTANCE_METHODS_MyClass$MyAddition $OBJC$PROP_LIST_MyClass$MyAddition Both are named using the common prefix + class name +category name, and the instance method list is filled with the method printName that we wrote in the MyAddition category, The property list is filled with the name property we added in MyAddition. Also note the fact that category names are used to name lists and the category structure itself, and are static, so we can’t repeat category names in the same compilation unit or we’ll get a compilation error. 2) Second, the compiler generates the category itself _OBJC$CATEGORY_MyClass$MyAddition and initializes the category itself with the previously generated list. 3) Finally, the compiler stores a category_T array L_OBJC_LABEL_CATEGORY$in the objc_catList section of the DATA section (of course, if there are more than one category, the array will be generated.) For run-time category loading. At this point, the compiler’s work is almost done, and we’ll show you how to load a category at runtime in the next section.

We know that the +load method can be used in both classes and categories, so there are two questions: 1) Can we call the method declared in the category when the +load method is called? 2) What is the call order of these +load methods? Given the amount of code we’ve looked at in the preceding sections, let’s start with a bit of intuition for these two problems:

Category1 and Category2. MyClass = Category1 and Category2. MyClass = Category1 and Category2. And Category1 and Category2 both write printName method of MyClass. In Xcode, click the Edit Scheme and add the following two environment variables (log can be printed when executing the load method and loading the category, see objc-private.h for more environment variable options) :

Running the project, we’ll see the console print a lot of things out. We’ll just find the information we want, in this order:

objc[1187]: REPLACED: -[MyClass printName] by category Category1

objc[1187]: REPLACED: -[MyClass printName] by category Category2

.

.

.

objc[1187]: LOAD: class ‘MyClass’ scheduled for +load

objc[1187]: LOAD: category ‘MyClass(Category1)’ scheduled for +load

objc[1187]: LOAD: category ‘MyClass(Category2)’ scheduled for +load

objc[1187]: LOAD: +[MyClass load]

.

.

.

objc[1187]: LOAD: +[MyClass(Category1) load]

.

.

.

objc[1187]: LOAD: +[MyClass(Category2) load]

The answer to the above two questions is obvious: 1) it can be called, because the task of attaching a category to a class precedes the execution of the +load method. 2) the +load method is executed in the order of the class before the category method, and the +load method is executed in the order of the compilation. The current compilation order looks like this:

We adjust the compilation order of Category1 and Category2, run. Ok, we can see that the output order of the console has changed:

objc[1187]: REPLACED: -[MyClass printName] by category Category2

objc[1187]: REPLACED: -[MyClass printName] by category Category1

.

.

.

objc[1187]: LOAD: class ‘MyClass’ scheduled for +load

objc[1187]: LOAD: category ‘MyClass(Category2)’ scheduled for +load

objc[1187]: LOAD: category ‘MyClass(Category1)’ scheduled for +load

objc[1187]: LOAD: +[MyClass load]

.

.

.

objc[1187]: LOAD: +[MyClass(Category2) load]

.

.

.

objc[1187]: LOAD: +[MyClass(Category1) load]

This is the order of execution for +load, but for methods that are “overridden”, the corresponding method in the last compiled category is found first. In this section, we just got the answer to the question in a very intuitive way. If you are interested, you can continue to explore the OC runtime code.

As we saw above, we know that you can’t add instance variables to a category in a category. But most of the time, we need to add the value associated with the object in the category, so we can use the associated object to do this.

MyClass+Category1.h:

#import "MyClass.h"

@interface MyClass (Category1)

@property(nonatomic,copy) NSString *name;

@endCopy the code

MyClass+Category1.m:

#import "MyClass+Category1.h"
#import <objc/runtime.h>

@implementation MyClass (Category1)

+ (void)load
{
    NSLog(@"%@",@"load in Category1");
}

- (void)setName:(NSString *)name
{
    objc_setAssociatedObject(self,
                             "name",
                             name,
                             OBJC_ASSOCIATION_COPY);
}

- (NSString*)name
{
    NSString *nameObject = objc_getAssociatedObject(self, "name");
    return nameObject;
}

@endCopy the code

But where do the associated objects exist? How to store it? How do you deal with associated objects when you destroy them? Objc-references. Mm file contains a method called _object_set_associative_reference:

void _object_set_associative_reference(id object, void *key, id value, uintptr_t policy) { // retain the new value (if any) outside the lock. ObjcAssociation old_association(0, nil); id new_value = value ? acquireValue(value, policy) : nil; { AssociationsManager manager; AssociationsHashMap &associations(manager.associations()); disguised_ptr_t disguised_object = DISGUISE(object); if (new_value) { // break any existing association. AssociationsHashMap::iterator i = associations.find(disguised_object); if (i ! = associations.end()) { // secondary table exists ObjectAssociationMap *refs = i->second; ObjectAssociationMap::iterator j = refs->find(key); if (j ! = refs->end()) { old_association = j->second; j->second = ObjcAssociation(policy, new_value); } else { (*refs)[key] = ObjcAssociation(policy, new_value); } } else { // create the new association (first time). ObjectAssociationMap *refs = new ObjectAssociationMap; associations[disguised_object] = refs; (*refs)[key] = ObjcAssociation(policy, new_value); _class_setInstancesHaveAssociatedObjects(_object_getClass(object)); } } else { // setting the association to nil breaks the association. AssociationsHashMap::iterator i = associations.find(disguised_object); if (i ! = associations.end()) { ObjectAssociationMap *refs = i->second; ObjectAssociationMap::iterator j = refs->find(key); if (j ! = refs->end()) { old_association = j->second; refs->erase(j); } } } } // release the old value (outside of the lock). if (old_association.hasValue()) ReleaseValue()(old_association);  }Copy the code

We can see that all associated objects are managed by AssociationsManager, which is defined as follows:

class AssociationsManager { static OSSpinLock _lock; static AssociationsHashMap *_map; // associative references: object pointer -> PtrPtrHashMap. public: AssociationsManager() { OSSpinLockLock(&_lock); } ~AssociationsManager() { OSSpinLockUnlock(&_lock); } AssociationsHashMap &associations() { if (_map == NULL) _map = new AssociationsHashMap(); return *_map; }};Copy the code

AssociationsManager is a static AssociationsHashMap that stores all associated objects. This is equivalent to storing all associated objects in a global map. The key of the map is the pointer address of this object (the pointer address of any two different objects must be different), and the value of this map is another AssociationsHashMap, which stores the KV pair of the associated object. Objc-runtimenew.mm: objc-runtimenew.mm:

void *objc_destructInstance(id obj) { if (obj) { Class isa_gen = _object_getClass(obj); class_t *isa = newcls(isa_gen); // Read all of the flags at once for performance. bool cxx = hasCxxStructors(isa); bool assoc = ! UseGC && _class_instancesHaveAssociatedObjects(isa_gen); // This order is important. if (cxx) object_cxxDestruct(obj); if (assoc) _object_remove_assocations(obj); if (! UseGC) objc_clear_deallocating(obj); } return obj; }Copy the code

Well, the Runtime’s objc_destructInstance function determines whether the object has any associated objects, and if so, calls _object_remove_assocations to clean up associated objects.