iOS底层面试题（上篇）

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面试合集

喜欢的小伙伴记得点赞喔~

收藏等于白嫖，点赞才是真情ღ( ´･ᴗ･` )ღ