共计 3481 个字符,预计需要花费 9 分钟才能阅读完成。
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 面试合集
喜爱的小伙伴记得点赞喔~
珍藏等于白嫖,点赞才是真情ღ(´・ᴗ・`)ღ