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

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

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