7月，iOS求职跳槽的绝对较少，能在这个时间段求职的，不是被迫，就是对本人的技术很自信；
针对7月，特地总结了一份iOS常见大厂面试题（上）;
iOS面试题分为上、中、下三局部，不便大家观看;
请先本人答一答！
话不多说；间接上题本文收录：公众号【iOS进阶宝典《iOS底层面试题（上篇）》】

1：谈谈你对KVC的了解

KVC能够通过key间接拜访对象的属性，或者给对象的属性赋值，这样能够在运行时动静的拜访或批改对象的属性

2：iOS我的项目中援用多个第三方库引发抵触的解决办法

可能有很多小伙伴还不太分明，动动态库的开发，这里举荐一篇博客：iOS-制作.a动态库SDK和应用.a动态库

如果咱们存在三方库抵触就会保留：duplicate symbol _OBJC_IVAR_$_xxxx in:

目前奏效最快的就是把**.framework**选中，**taggert Membership**的对勾勾销掉，就编译没有问题了，然而后续的其余问题可能还会呈现

我想说的是像这种开源的使用率很高的源代码本不应该蕴含在lib库中，就算是你要蕴含那也要改个名字是吧。不过没方法当初人家既然蕴含，咱们就只有想方法拆散了

mkdir armv7：创立长期文件夹
lipo libALMovie.a -thin armv7 -output armv7/armv7.a：取出armv7平台的包
ar -t armv7/armv7.a：查看库中所蕴含的文件列表
cd armv7 && ar xv armv7.a：解压出object file（即.o后缀文件）
rm ALButton.o：找到抵触的包，删除掉（此步能够屡次操作）
cd … && ar rcs armv7.a armv7/*.o：从新打包object file
多平台的SDK的话，须要屡次操作第4步。
操作实现后，合并多个平台的文件为一个.a文件：
lipo -create armv7.a arm64.a -output new.a
将批改好的文件，拖拽到原文件夹下，替换原文件即可。

3：GCD实现多读单写

比方在内存中保护一份数据，有多处中央可能会同时操作这块数据，怎么能保障数据安全？
这道题目总结失去要满足以下三点：

1.读写互斥
2.写写互斥
3.读读并发

@implementation KCPerson- (instancetype)init{    if (self = [super init]) {       _concurrentQueue = dispatch_queue_create("com.kc_person.syncQueue", DISPATCH_QUEUE_CONCURRENT);       _dic = [NSMutableDictionary dictionary];    }    return self;}- (void)kc_setSafeObject:(id)object forKey:(NSString *)key{    key = [key copy];    dispatch_barrier_async(_concurrentQueue, ^{       [_dic setObject:object key:key];    });}- (id)kc_safeObjectForKey：:(NSString *)key{    __block NSString *temp;    dispatch_sync(_concurrentQueue, ^{        temp =[_dic objectForKey：key];    });    return temp;}@end

首先咱们要维系一个GCD 队列，最好不必全局队列，毕竟大家都晓得全局队列遇到栅栏函数是有坑点的，这里就不剖析了！
因为思考性能死锁梗塞的因素不思考串行队列，用的是自定义的并发队列！
_concurrentQueue = dispatch_queue_create("com.kc_person.syncQueue", DISPATCH_QUEUE_CONCURRENT);
首先咱们来看看读操作:kc_safeObjectForKey咱们思考到多线程影响是不能用异步函数的！阐明：
线程2 获取：
name 线程3 获取 age
如果因为异步并发，导致凌乱原本读的是name 后果读到了age
咱们容许多个工作同时进去! 然而读操作须要同步返回，所以咱们抉择:同步函数 （读读并发）
咱们再来看看写操作，在写操作的时候对key进行了copy, 对于此处的解释，插入一段来自参考文献的援用:

函数调用者能够自在传递一个NSMutableString的key，并且可能在函数返回后批改它。因而咱们必须对传入的字符串应用copy操作以确保函数可能正确地工作。如果传入的字符串不是可变的（也就是失常的NSString类型），调用copy基本上是个空操作。

这里咱们抉择dispatch_barrier_async, 为什么是栅栏函数而不是异步函数或者同步函数，上面剖析：
栅栏函数工作：之前所有的工作执行结束，并且在它前面的工作开始之前，期间不会有其余的工作执行，这样比拟好的促使写操作一个接一个写 （写写互斥），不会乱！
为什么不是异步函数？应该很容易剖析，毕竟会产生凌乱！
为什么不必同步函数？如果读写都操作了，那么用同步函数，就有可能存在：我写须要期待读操作回来能力执行，显然这里是不合理！

4:讲一下atomic的实现机制；为什么不能保障相对的线程平安（最好能够联合场景来说）？

A: atomic的实现机制

atomic是property的修饰词之一，示意是原子性的，应用形式为@property(atomic)int age;此时编译器会主动生成 getter/setter 办法，最终会调用objc_getProperty和objc_setProperty办法来进行存取属性。
若此时属性用atomic润饰的话，在这两个办法外部应用os_unfair_lock 来进行加锁，来保障读写的原子性。锁都在PropertyLocks 中保留着（在iOS平台会初始化8个，mac平台64个），在用之前，会把锁都初始化好，在须要用到时，用对象的地址加上成员变量的偏移量为key，去PropertyLocks中去取。因而存取时用的是同一个锁，所以atomic能保障属性的存取时是线程平安的。
注：因为锁是无限的，不必对象，不同属性的读取用的也可能是同一个锁

B: atomic为什么不能保障相对的线程平安？

atomic在getter/setter办法中加锁，仅保障了存取时的线程平安，假如咱们的属性是@property(atomic)NSMutableArray *array;可变的容器时,无奈保障对容器的批改是线程平安的.
在编译器自动生产的getter/setter办法，最终会调用objc_getProperty和objc_setProperty办法存取属性，在此办法外部保障了读写时的线程平安的，当咱们重写getter/setter办法时，就只能依附本人在getter/setter中保障线程平安

5. Autoreleasepool所应用的数据结构是什么？AutoreleasePoolPage构造体理解么？

Autoreleasepool是由多个AutoreleasePoolPage以双向链表的模式连接起来的.
Autoreleasepool的基本原理：在每个主动开释池创立的时候，会在以后的AutoreleasePoolPage中设置一个标记位，在此期间，当有对象调用autorelsease时，会把对象增加 AutoreleasePoolPage中
若当前页增加满了，会初始化一个新页，而后用双向量表链接起来，并把新初始化的这一页设置为hotPage,当主动开释池pop时，从最上面顺次往上pop，调用每个对象的release办法，直到遇到标记位。

AutoreleasePoolPage构造如下

class AutoreleasePoolPage {    magic_t const magic;    id *next;//下一个寄存autorelease对象的地址    pthread_t const thread; //AutoreleasePoolPage 所在的线程    AutoreleasePoolPage * const parent;//父节点    AutoreleasePoolPage *child;//子节点    uint32_t const depth;//深度,也能够了解为以后page在链表中的地位    uint32_t hiwat;}

文末举荐：iOS热门文集

①　Swift

②　iOS底层技术

③　iOS逆向防护

④　iOS面试合集

喜爱的小伙伴记得点赞喔~
珍藏等于白嫖，点赞才是真情( ´･･` )