关于ios:iOS底层面试题上篇

7 月，iOS 求职跳槽的绝对较少，能在这个时间段求职的，不是被迫，就是对本人的技术很自信；
针对 7 月，特地总结了一份 iOS 常见大厂面试题（上）;

iOS 面试题分为上、中、下三局部，不便大家观看;

请先本人 答一答！

话不多说；间接上题 本文收录：公众号【iOS 进阶宝典《iOS 底层面试题（上篇）》】

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

可能有很多小伙伴还不太分明，动动态库的开发，这里举荐一篇博客：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

将批改好的文件，拖拽到原文件夹下，替换原文件即可。

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

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

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 中保障线程平安

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:iOS底层面试题上篇

1：谈谈你对 KVC 的了解

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

3：GCD 实现多读单写

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

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

文末举荐：iOS 热门文集

① Swift

② iOS 底层技术

③ iOS 逆向防护

④ iOS 面试合集