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

67次阅读

共计 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, 对于此处的解释,插入一段来自参考文献的援用:

函数调用者能够自在传递一个 NSMutableStringkey,并且可能在函数返回后批改它。因而咱们必须对传入的字符串应用 copy 操作以确保函数可能正确地工作。如果传入的字符串不是可变的(也就是失常的 NSString 类型),调用 copy 基本上是个空操作。

  • 这里咱们抉择dispatch_barrier_async, 为什么是栅栏函数而不是异步函数或者同步函数,上面剖析:
  • 栅栏函数工作:之前所有的工作执行结束,并且在它前面的工作开始之前,期间不会有其余的工作执行,这样比拟好的促使 写操作一个接一个写 (写写互斥),不会乱!
  • 为什么不是异步函数?应该很容易剖析,毕竟会产生凌乱!
  • 为什么不必同步函数?如果读写都操作了,那么用同步函数,就有可能存在:我写须要期待读操作回来能力执行,显然这里是不合理!

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

A: atomic 的实现机制

  • atomicproperty 的修饰词之一,示意是原子性的,应用形式为 @property(atomic)int age; 此时编译器会主动生成 getter/setter 办法,最终会调用objc_getPropertyobjc_setProperty办法来进行存取属性。
  • 若此时属性用 atomic 润饰的话,在这两个办法外部应用 os_unfair_lock 来进行加锁,来保障读写的原子性。锁都在PropertyLocks 中保留着(在 iOS 平台会初始化 8 个,mac 平台 64 个),在用之前,会把锁都初始化好,在须要用到时,用对象的地址加上成员变量的偏移量为key,去PropertyLocks 中去取。因而存取时用的是同一个锁,所以 atomic 能保障属性的存取时是线程平安的。
  • 注:因为锁是无限的,不必对象,不同属性的读取用的也可能是同一个锁

B: atomic 为什么不能保障相对的线程平安?

  • atomicgetter/setter 办法中加锁,仅保障了存取时的线程平安,假如咱们的属性是@property(atomic)NSMutableArray *array; 可变的容器时, 无奈保障对容器的批改是线程平安的.
  • 在编译器自动生产的 getter/setter 办法,最终会调用 objc_getPropertyobjc_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 面试合集

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

珍藏等于白嫖,点赞才是真情ღ(´・ᴗ・`)ღ

正文完
 0