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面试合集
喜欢的小伙伴记得点赞喔~
收藏等于白嫖，点赞才是真情ღ( ´･ᴗ･` )ღ
