北戴河最孤独的图书馆
引言
我在github上写了一个GJAlertController的开源库，是为了解决在iOS8以下的系统中使用UIAlertController的问题，结果收到了100多个星星，让我受宠若惊，感谢各位的支持，也感谢我的同事"芋头"帮我在微博上转发，下面详细说明一下实现原理。
iOS8中苹果用UIAlertController来统一管理alert和actionSheet了，之前的UIAlertView和UIActionSheet已经废弃了。通常我们要兼容iOS7的时候，要这样：
if ([[[UIDevice currentDevice] systemVersion] floatValue] <= 8.0) { //用UIAlertView或UIActionSheet} else { //用UIAlertController}而GJAlertController解决了这里的系统版本兼容问题，不需要判断版本，直接使用：
UIAlertController *alertVC = [UIAlertController alertControllerWithTitle:@"title" message:@"message" preferredStyle:UIAlertControllerStyleAlert];
[alertVC addAction:[UIAlertAction actionWithTitle:@"ok" style:UIAlertActionStyleDefault handler:^(UIAlertAction * _Nonnull action) {
NSLog(@"button ok pressed");
}]];
[alertVC addAction:[UIAlertAction actionWithTitle:@"cancel" style:UIAlertActionStyleDefault handler:^(UIAlertAction * _Nonnull action) {
NSLog(@"button cancel pressed);
}]];
[alertVC addTextFieldWithConfigurationHandler:^(UITextField *textField) {
textField.placeholder = @"请输入用户名";
}];
[self presentViewController:alertVC animated:YES completion:nil];如果创建的时候PreferredStyle传入UIAlertControllerStyleActionSheet，则显示actionSheet。
大家可能很好奇，UIAlertController明明是iOS8才引入的，怎么能够在iOS8以下的系统中跑呢？下面进入正题。
原理概述
简单来说就是三个字——黑魔法。
利用这种黑魔法的例子已经越来越多，我所知道的最早使用这种方法的是一个老外在三年为了解决NSUUID而使用的。
我们国内团队开发的FDStackView是一个非常好的开源库，已经有1500+颗星星了，希望大家多多支持我们国内的团队，在FDStackView库中也用到了相同的技术，网上有人发出了分析实现原理的文章，但分析的很浅，而且根本没有说在点子上，使得这种黑魔法的魅力并没有被大家欣赏到，我这里做了一些功课，把这个原理详细的阐述一下，以及这里的关键点在哪里。如果中间过程中有什么错误，还请大家指正，谢谢。
下面简单说一下实现思路。
1.运行时去判断系统中是否已经存在UIAlertController，如果存在，那就什么都不做，静静的看着UIAlertController装逼，这就是iOS8及其之上版本的情况。
2.如果系统中没有UIAlertController类，我们在运行时中做一些“手脚”，让我们的GJAlertController在低版本中去完成这个问题。这一步是精华所在，下面分析代码的时候回详细说明
详细分析
实现的代码本身其实并不重要，下面先讲最重要的一个东西，它是这种黑魔法能够得以实现的前提。
在揭示这个重要前提之前，我们先来简单说说内存。内存有好多种，我们最熟悉的有：栈：函数的实现就依赖于栈，函数中简单类型的局部变量也都开辟在栈上；堆：我们平时用的Object都是开辟在堆上的；数据段：这个对我们相对陌生，但是其实静态字符串就是存在数据段的eg：
NSString *testStr = @"hello world";NSLog(@"testStr:%p", testStr); testStr:0xb4338 //32位的机器上testStr:0x106326580 //64位的机器上
数据段的内存有些特殊，并不是我们理解的32上的指针是4Byte=32bit，64位上指针是8Byte=64bit，大家这里对数据段先有个概念，一会要用它来解释一些现象。
下面开始讲这个黑魔法能够实现的前提，是很重要的部分。在编译的时候，系统中的每个类都在数据段上有一个标签(形式是这样的：OBJC_CLASS$_ClassName)，这个标签你可以理解成key，它的value就是该类的类名，举例：数据段中会有一个key是OBJC_CLASS$_UIAlertController，它对应的value就是UIAlertController的类名，当然也就会有OBJC_CLASS$_UIStackView这个标签，标识着UIStackView这个类。
最重要的一点是：在iOS7中，还没有UIAlertController的时候，这个标签OBJC_CLASS$_UIAlertController已经存在了，只是这个标签对应的value值是nil，因为没有这个类，我们可以认为是苹果在给高版本的这个类站位，就是苹果的这个站位才使得我们有幸用上了这个黑魔法。当然每个后出现的类都是有站位的，比如UIStackView。
if this label is Nil or doesnt exist, the class does not exist and cannot be allocated/used
这是我看到的老外在用该种黑魔法实现UUID的时候其中的一句说明，意思是：如果我们没找找到这个标签，就不能为该申请内存，也就不能使用了。
我对这句话的结论持怀疑态度，但又无法做实验验证，因为“标签站位”在早期版本中就存在了，而要找到“更早期”的版本验证该没有标签是很困难的，因为Xcode已经不能支持对“更早期”的版本的编译了，这段话表述有些混乱，大家还是往后看吧。
下面我们看看runtime里动态添加类的方法：
Creates a new class and metaclass.
@param superclass The class to use as the new class's superclass, or \c Nil to create a new root class.
@param name The string to use as the new class's name. The string will be copied.
@param extraBytes The number of bytes to allocate for indexed ivars at the end of
the class and metaclass objects. This should usually be \c 0.@return The new class, or Nil if the class could not be created (for example, the desired name is already in use).
OBJC_EXPORT Class objc_allocateClassPair(Class superclass, const char *name, size_t extraBytes) __OSX_AVAILABLE_STARTING(__MAC_10_5, __IPHONE_2_0);
大家看官方对函数的说明可以知道：superClass 是你要添加的类的父类，name是你要添加的类的名字，extraBytes一般传0，它会返回一个新类，如果名字被占用了会返回Nil。
由此要说明的两个重要结论：
1.如果OBJC_CLASS$_ClassName标签存在，但是对应的类不存在(相当于有key，但是value是nil)此时动态添加类是可以成功的。
2.如果OBJC_CLASS$_ClassName标签和对应的类都有的话，此时动态添加类是不成功的，返回nil。
我们黑魔法的实现思路就是基于这两个重要结论，下面我们具体看代码。
代码讲解
__asm( ".section __DATA,__objc_classrefs,regular,no_dead_strip\n"#if TARGET_RT_64_BIT ".align 3\n" "L_OBJC_CLASS_UIAlertController:\n" ".quad _OBJC_CLASS_$_UIAlertController\n"#else ".align 2\n" "_OBJC_CLASS_UIAlertController:\n" ".long _OBJC_CLASS_$_UIAlertController\n"#endif ".weak_reference _OBJC_CLASS_$_UIAlertController\n");
这是一段汇编代码，不用担心看不懂它，我也不懂汇编，这不影响我们分析，我简单的解释一下：
1.__asm是在C、C++源码中放入汇编代码(OC是C的超集)。
2..align是对指令或数据的存放地址进行对齐，有些CPU架构要求固定的指令长度，并且存放地址相对于2的幂指数圆整，否则无法运行，比如arm。有些不要这样也能运行，就是执行效率稍微低点，如i386。
3.64位的对齐方式是8位（23(.align后面的数))，32位的对齐方式是4位（22(.align后面的数)）。对齐只对紧挨着它的那条语句起作用，既，L_OBJC_CLASS_UIAlertController或_OBJC_CLASS_UIAlertController。
4..quad声明一组数占64位，.long声明一组数占32位
5..secton 后是指定参数用的，上述汇编的大体意思是在数据段(就是我们之前提到的数据段)找到OBJC_CLASS$_UIAlertController标签并利用.quad、.long声明的一组数来存放它，取名为：_OBJC_CLASS_UIAlertController。
这是一段枯燥又非重点的代码，如果大家心情不好直接忽略掉就可以了。
__attribute__((constructor)) static void GJAlertControllerPatchEntry(void) { static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ @autoreleasepool { // >= iOS8.
if (objc_getClass("UIAlertController")) { return;
}
Class *alertController = NULL;#if TARGET_CPU_ARM
__asm("movw %0, :lower16:(_OBJC_CLASS_UIAlertController-(LPC0+4))\n"
"movt %0, :upper16:(_OBJC_CLASS_UIAlertController-(LPC0+4))\n"
"LPC0: add %0, pc" : "=r"(alertController));
#elif TARGET_CPU_ARM64
__asm("adrp %0, L_OBJC_CLASS_UIAlertController@PAGE\n"
"add %0, %0, L_OBJC_CLASS_UIAlertController@PAGEOFF" : "=r"(alertController));
#elif TARGET_CPU_X86_64
__asm("leaq L_OBJC_CLASS_UIAlertController(%%rip), %0" : "=r"(alertController));
#elif TARGET_CPU_X86
void *pc = NULL;
__asm("calll L0\n"
"L0: popl %0\n"
"leal _OBJC_CLASS_UIAlertController-L0(%0), %1" : "=r"(pc), "=r"(alertController));
#else#error Unsupported CPU#endif
if (alertController && !*alertController) {
Class class = objc_allocateClassPair([GJAlertController class], "UIAlertController", 0); if (class) {
objc_registerClassPair(class);
*alertController = class;
}
}
}
});
}大家坚持住，这是要分析的最后一段代码了。
__attribute__((constructor)) static void GJAlertControllerPatchEntry(void){
}总的来说上面的代码是一个函数，
__attribute__((constructor))只是用来修饰函数的，它起什么作用呢？这里涉及一个关于__attribute__的黑魔法，有兴趣的人可以看我同事的一篇专门介绍__attribute__的文章。
__attribute__((constructor))修饰的函数会在main函数之前执行，这是我们的最好时机，有了runtime环境，但是main函数还没有执行，一切都“来得及”。
if (objc_getClass("UIAlertController")) { return;
}系统中有UIAlertController类的话，直接返回，这个逻辑之前已经提到过了。
Class *alertController = NULL;#if TARGET_CPU_ARM
__asm("movw %0, :lower16:(_OBJC_CLASS_UIAlertController-(LPC0+4))\n"
"movt %0, :upper16:(_OBJC_CLASS_UIAlertController-(LPC0+4))\n"
"LPC0: add %0, pc" : "=r"(alertController));
#elif TARGET_CPU_ARM64
__asm("adrp %0, L_OBJC_CLASS_UIAlertController@PAGE\n"
"add %0, %0, L_OBJC_CLASS_UIAlertController@PAGEOFF" : "=r"(alertController));
#elif TARGET_CPU_X86_64
__asm("leaq L_OBJC_CLASS_UIAlertController(%%rip), %0" : "=r"(alertController));
#elif TARGET_CPU_X86
void *pc = NULL;
__asm("calll L0\n"
"L0: popl %0\n"
"leal _OBJC_CLASS_UIAlertController-L0(%0), %1" : "=r"(pc), "=r"(alertController));
#else#error Unsupported CPU#endif这段汇编大家直接忽略，意思就是把之前_OBJC_CLASS_UIAlertController中的值拿出来放到alertController里，之所以这么麻烦是因为不同架构的CPU运行的指令集不同，例如，32位就要这样弄：MOVW 把16位立即数放到寄存器的底16位，高16位清0
MOVT 把16位立即数放到寄存器的高16位，低16位不影响。
if (alertController && !*alertController) {
Class class = objc_allocateClassPair([GJAlertController class], "UIAlertController", 0); if (class) {
objc_registerClassPair(class);
*alertController = class;
}
}如果alertController存在，证明OBJC_CLASS$_UIAlertController标签存在，即key存在，*alertController不存在，证明当前系统中没有这个类，即value不存在。这正是我们之前说的情况，如果我们此时打印alertController的地址，会发现，它的位数和上面数据段中的一样而不是32位或64位，也再次印证了标签在数据段上。
此时执行最重要的一句代码——动态添加类
Class class = objc_allocateClassPair([GJAlertController class], "UIAlertController", 0);
这决对是画龙点睛的一笔，我们之前用的时候都是继承一个系统类，动态添加一个自定义的类:
Class person = objc_allocateClassPair([NSObject class], "Person", 0);
这里正好相反，这里是在判断了没有系统类的时候，添加一个系统类，继承自我们的类：GJAlertController，也就是说，在低版本中，没有UIAlerController，我们动态添加这个类，让他继承GJAlertController，我们在GJAlertController中，实现一套与系统UIAlertController一模一样的API给人造成的错觉好像是在低版本中也能使用UIAlertController，其实只是一个魔术。
我们在低版本下使用的UIAlertController是我们动态添加的，它什么也没有做，直接继承了GJAlertController，而GJAlertController声明并实现了和系统UIAlertController一模一样的一套API。我们的GJAlertController根本不是一个VC是一个NSObject，只是自己用UIAlertView和UIActionSheet封装成了UIAlertController的API罢了，到这里你应该对所有的一切都明白了吧。
我之所以要写这篇文章，主要是在欣赏：
Class class = objc_allocateClassPair([GJAlertController class], "UIAlertController", 0);
这段代码的美丽与魅力，表达我对这段代码，及其想到这样使用这段代码的人的敬佩当然其实用其他的runtime函数在这里也也可以做相同的事情，具体看我刚刚发的那个老外的链接。
几点说明：
1.为什么要使用汇编？
因为在寻找数据段上OBJC_CLASS$_ClassName标签的时候不支持C、C++、OC等高级语言，只能用汇编。
2.代码中出现的OBJC_CLASS$_UIAlertController与_OBJC_CLASS_UIAlertController有什么关系？
没有任何关系，OBJC_CLASS$_UIAlertController这个是系统中类标签的格式，必须是这样子才可以，而_OBJC_CLASS_UIAlertController只是一个参数名，你叫hellworld也可以（已经测试过可以），大家不要被它俩弄晕了，_OBJC_CLASS_UIAlertController这个写法只是约定俗称的写法，就像我们在GCD中用到的onceToken一样，没多大意义。
3.文中我用了老外一词，给人的感觉像是带有些许轻蔑和嘲讽的口气，我这里正式声明，其实并没有此意，我们应该理解为国外友人，相反，正是他们无私的分享才使得开源具有很大的意义，给人类进步做出了巨大贡献，在这里也对一切做出分享、开源的朋友们加以感谢。
后记
这里可能我表达不是很清晰，我们使用GJAlertController来使得UIAlertController兼容低版本其实是基于Xcode的baseSDK的，就是Xcode编译的SDK，我们要使用UIAlertController，那我们编译的SDK肯定要大于等于iOS8.0，否则都没有UIAlertController这个类，当我们baseSDK的版本大于等于iOS8的时候能够确定有这个类，我们基于这个baseSDK打包出来的app如果运行在低版本中的时候就是有代表UIAlertController这个类的标签，但是没有值，也就是没有类，因为是低于iOS8的系统，这时我们才执行上面说的逻辑，正式由于基于baseSDK，所以编译时不会报警告的。