iOS 面试

发表于

atomic nonatomic区别和理解

atomic的意思就是setter/getter这个函数，是一个原语操作。如果有多个线程同时调用setter的话，不会出现某一个线程执行完setter全部语句之前，另一个线程开始执行setter情况，相当于函数头尾加了锁一样，可以保证数据的完整性。nonatomic不保证setter/getter的原语行，所以你可能会取到不完整的东西。因此，在多线程的环境下原子操作是非常必要的，否则有可能会引起错误的结

数据持久化

  • NSKeyedArchiver -> 用户信息
  • NSUserDefaults -> 状态、版本
  • Write􏰴􏱼􏰲􏰳􏲅 -> plist、txt等文件
  • 数据库 -> WCDB、FMDB等
  • CoreData -> 苹果自带的数据库

深、浅拷贝

  • 拷贝需实现 NSCopying协议
  • 浅拷贝: 􏱭􏱙􏰵􏰈􏱊􏱋􏳽􏳄􏱜􏱯􏳾􏴏􏰩􏴐􏱃􏱜􏱯􏱭􏱙􏰵􏰈􏱊􏱋􏳽􏳄􏱜􏱯􏳾􏴏􏰩􏴐􏱃􏱜􏱯􏱭􏱙􏰵􏰈􏱊􏱋􏳽􏳄􏱜􏱯􏳾􏴏􏰩􏴐􏱃􏱜􏱯􏱭􏱙􏰵􏰈􏱊􏱋􏳽􏳄􏱜􏱯􏳾􏴏􏰩􏴐􏱃􏱜􏱯􏱭􏱙􏰵􏰈􏱊􏱋􏳽􏳄􏱜􏱯􏳾􏴏􏰩􏴐􏱃􏱜􏱯copy指针 指向相同地址
  • 深拷贝: 新的对象 新的指针

单例

1
2
3
4
5
6
7
8
+ (AccountManager *)sharedManager
{
       static AccountManager *staticInstance = nil;
       static dispatch_once_t predicate;
       dispatch_once(&predicate, ^{
               staticInstance = [[self alloc] init];
   return staticInstance;
}); }

RunLoop

RunLoop 是什么？RunLoop 还是比较顾名思义的一个东西，说白了就是一种循环，只不过它这种循环比较高级。一般的 while 循环会导致 CPU 进入忙等待状态，而 RunLoop 则是一种“闲”等待，这部分可以类比 Linux 下的 epoll。当没有事件时，RunLoop 会进入休眠状态，有事件发生时， RunLoop 会去找对应的 Handler 处理事件。RunLoop 可以让线程在需要做事的时候忙起来，不需要的话就让线程休眠。

源码

一个RunLoop对象，主要包含了一个线程，若干个Mode，若干个commonMode，还有一个当前运行的Mode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
struct __CFRunLoop {
    CFRuntimeBase _base;
    pthread_mutex_t _lock;  /* locked for accessing mode list */
    __CFPort _wakeUpPort;   // used for CFRunLoopWakeUp 内核向该端口发送消息可以唤醒runloop
    Boolean _unused;
    volatile _per_run_data *_perRunData; // reset for runs of the run loop
    pthread_t _pthread;             //RunLoop对应的线程
    uint32_t _winthread;
    CFMutableSetRef _commonModes;    //存储的是字符串，记录所有标记为common的mode
    CFMutableSetRef _commonModeItems;//存储所有commonMode的item(source、timer、observer)
    CFRunLoopModeRef _currentMode;   //当前运行的mode
    CFMutableSetRef _modes;          //存储的是CFRunLoopModeRef
    struct _block_item *_blocks_head;//doblocks的时候用到
    struct _block_item *_blocks_tail;
    CFTypeRef _counterpart;
};

详见 RunLoop详解

应用场景

一个 Timer 一次只能加入到一个 RunLoop 中。我们日常使用的时候，通常就是加入到当前的 runLoop 的 default mode 中，而 ScrollView 在用户滑动时，主线程 RunLoop 会转到 UITrackingRunLoopMode 。而这个时候， Timer 就不会运行

有如下两种解决方案：

  • 设置 RunLoop Mode，例如 NSTimer,我们指定它运行于 NSRunLoopCommonModes ，这是一个 Mode 的集合。注册到这个 Mode 下后，无论当前 runLoop 运行哪个 mode ，事件都能得到执行。
  • 在另外一个线程执行和处理 Timer 事件，然后在主线程更新 UI

内存管理机制

Autorelease 释放时机

在没有手加Autorelease Pool的情况下，Autorelease对象是在当前的runloop迭代结束时释放的，而它能够释放的原因是系统在每个runloop迭代中都加入了自动释放池Push和Pop(双向链表)

关键字

  • retain(􏰀􏰁􏰂􏰃􏰄引用计数+1)->release􏰅􏰀􏰁􏰂􏰃􏰆1(引用计数-1)
  • alloc（申请内存空间）-> dealloc（释放内存空间）
  • readwrite 既有getter,也有setter（默认）
  • readonly 只有getter,没有setter
  • nonatomic 不考虑线程安全
  • 原子性: atomic 线程操作安全（默认）nonatomic不使用自旋锁
    比如，线程 A 的 getter 方法运行到一半，线程 B 调用了 setter：那么线程 A 的 getter 还是能得到一个完好无损的对象。
    而nonatomic就没有这个保证了。所以，nonatomic的速度要比atomic快。
    不过atomic可并不能保证线程安全。如果线程 A 调了 getter，与此同时线程 B 、线程 C 都调了 setter——那最后线程 A get 到的值，3种都有可能：可能是 B、C set 之前原始的值，也可能是 B set 的值，也可能是 C set 的值。同时，最终这个属性的值，可能是 B set 的值，也有可能是 C set 的值。
    保证数据完整性——这个多线程编程的最大挑战之一——往往还需要借助其他手段

线程安全下的 setter、getter

1
2
3
4
5
6
7
8
9
10
11
12
- (NSString *) value
{
  @synchronized(self) {
     return [[_value retain] autorelease];
} }
- (void)setValue:(NSString *)aValue
{
  @synchronized(self) {
   [aValue retain];
   [_value release];
   _value = aValue;
} }
  • retain： release旧的对象 retain新的对象
  • assign：简单赋值 不更改引用计数（默认）
  • copy：copy相同对象（retain指针拷贝，copy：内容拷贝）
  • strong： ARC中 同MRC retain一样
  • weak：同assign一样，weak当指向的内存释放后自动nil话，防止野指针 assign 可以用非 OC 对象,而 weak 必须用于 OC 对象(weak：a.delegate = b, a和b指向同一位置，当b释放 a也释放，如果delegate用assign就会变成野指针)
  • unsafe_unretained：weak修饰的对象被释放后，指向对象的指针会置空，也就是指向nil,不会产生野指针；而unsafe_unretained修饰的对象被释放后，指针不会置空，而是变成一个野指针，那么此时如果访问这个对象的话，程序就会Crash，抛出BAD_ACCESS的异常（它会比weak性能更好，明确对象声明周期时可使用，YYModel内大量使用）

序列化和反序列化

  • 序列化：对象->字节序列
  • 反序列化：字节-> 对象
  • NSCoding协议、Codable协议

多线程

进程、线程

  • 进程：操作系统多个软件在运行（微信、抖音等）
  • 线程：进程内好多线程
  • 线程是进程的基本组成单元

多线程的好处

  • 时间长的任务放到后台处理
  • 程序运行更快
  • 等待任务

    多线程的缺点

  • 大量影响性能、因为操作系统需要在他们之间切换
  • 占用更多的内存空间
  • 线程死锁

多线程实现

  • Thread
  • NSOperation
  • GCD

字符串去重

1
2
3
4
5
6
7
8
9
10
11
12
func testString(str: String) -> String{
        var dict: [String: Int] = [:]
        var result: String = ""
        let _ = str.map { (char) in
            let temp = "\(char)"
            if dict[temp] == nil {
                result += "\(char)"
                dict[temp] = 10
            }
        }
        return result
    }

UIImage初始化

  • imageNamed 检查系统缓存
  • contentsOfFile: 直接加载
  • cgImage

便利构造器

1
2
3
4
5
extension UIButton {
    convenience init(imageName: String) {
        self.init()
    }
}

继承

iOS 类不可以多继承 可protocol实现

APP启动流程

main函数 -> UIApplication -> rootVC

  • application:willFinishLaunchingWithOptions: - 这个方法是你在启动时的第一次机会来执行代码

  • application:didFinishLaunchingWithOptions: - 这个方法允许你在显示app给用户之前执行最后的初始化操作

  • applicationDidBecomeActive: - app已经切换到active状态后需要执行的操作

  • applicationWillResignActive: - app将要从前台切换到后台时需要执行的操作

  • applicationDidEnterBackground: - app已经进入后台后需要执行的操作

  • applicationWillEnterForeground: - app将要从后台切换到前台需要执行的操作，但app还不是active状态

  • applicationWillTerminate: - app将要结束时需要执行的操作

ViewController 生命周期

init loadView viewDidLoad viewWillAppear viewWillDisAppear viewDidDisappear didReceiveMemoryWarning deinit/dealloc

字典的工作原理

使用hash表来实现key-value之间的映射和存储的

哈希冲突

  • 1.开放定址法（线性探测再散列，二次探测再散列，伪随机探测再散列）
  • 2.再哈希法
  • 3.链地址法(Java hashmap就是这么做的)
  • 4.建立一个公共溢出区

什么是hash冲突？

假设hash表的大小为9（即有9个槽），现在要把一串数据存到表里：5,28,19,15,20,33,12,17,10

简单计算一下：hash(5)=5, 所以数据5应该放在hash表的第5个槽里；hash(28)=1，所以数据28应该放在hash表的第1个槽里；hash(19)=1，也就是说，数据19也应该放在hash表的第1个槽里——于是就造成了碰撞（也称为冲突，collision）。

常用的Hash冲突解决方法有以下几种：

1.开放定址法
这种方法也称再散列法，其基本思想是：当关键字key的哈希地址p=H（key）出现冲突时，以p为基础，产生另一个哈希地址p1，如果p1仍然冲突，再以p为基础，产生另一个哈希地址p2，…，直到找出一个不冲突的哈希地址pi ，将相应元素存入其中。这种方法有一个通用的再散列函数形式：

Hi=（H（key）+di）% m i=1，2，…，n

其中H（key）为哈希函数，m 为表长，di称为增量序列。增量序列的取值方式不同，相应的再散列方式也不同。主要有以下三种：

线性探测再散列

dii=1，2，3，…，m-1

这种方法的特点是：冲突发生时，顺序查看表中下一单元，直到找出一个空单元或查遍全表。

二次探测再散列

di=12，-12，22，-22，…，k2，-k2 ( k<=m/2 )

这种方法的特点是：冲突发生时，在表的左右进行跳跃式探测，比较灵活。

伪随机探测再散列

di=伪随机数序列。

具体实现时，应建立一个伪随机数发生器，（如i=(i+p) % m），并给定一个随机数做起点。

例如，已知哈希表长度m=11，哈希函数为：H（key）= key % 11，则H（47）=3，H（26）=4，H（60）=5，假设下一个关键字为69，则H（69）=3，与47冲突。

如果用线性探测再散列处理冲突，下一个哈希地址为H1=（3 + 1）% 11 = 4，仍然冲突，再找下一个哈希地址为H2=（3 + 2）% 11 = 5，还是冲突，继续找下一个哈希地址为H3=（3 + 3）% 11 = 6，此时不再冲突，将69填入5号单元。

如果用二次探测再散列处理冲突，下一个哈希地址为H1=（3 + 12）% 11 = 4，仍然冲突，再找下一个哈希地址为H2=（3 - 12）% 11 = 2，此时不再冲突，将69填入2号单元。

如果用伪随机探测再散列处理冲突，且伪随机数序列为：2，5，9，……..，则下一个哈希地址为H1=（3 + 2）% 11 = 5，仍然冲突，再找下一个哈希地址为H2=（3 + 5）% 11 = 8，此时不再冲突，将69填入8号单元。

2.再哈希法
这种方法是同时构造多个不同的哈希函数：

Hi=RH1（key） i=1，2，…，k

当哈希地址Hi=RH1（key）发生冲突时，再计算Hi=RH2（key）……，直到冲突不再产生。这种方法不易产生聚集，但增加了计算时间。

3.链地址法
这种方法的基本思想是将所有哈希地址为i的元素构成一个称为同义词链的单链表，并将单链表的头指针存在哈希表的第i个单元中，因而查找、插入和删除主要在同义词链中进行。链地址法适用于经常进行插入和删除的情况。

4.建立公共溢出区
这种方法的基本思想是：将哈希表分为基本表和溢出表两部分，凡是和基本表发生冲突的元素，一律填入溢出表。

拉链法与开放地址法相比的缺点：
拉链法的优点

与开放定址法相比，拉链法有如下几个优点：

①拉链法处理冲突简单，且无堆积现象，即非同义词决不会发生冲突，因此平均查找长度较短；

②由于拉链法中各链表上的结点空间是动态申请的，故它更适合于造表前无法确定表长的情况；

③开放定址法为减少冲突，要求装填因子α较小，故当结点规模较大时会浪费很多空间。而拉链法中可取α≥1，且结点较大时，拉链法中增加的指针域可忽略不计，因此节省空间；

④在用拉链法构造的散列表中，删除结点的操作易于实现。只要简单地删去链表上相应的结点即可。而对开放地址法构造的散列表，删除结点不能简单地将被删结 点的空间置为空，否则将截断在它之后填人散列表的同义词结点的查找路径。这是因为各种开放地址法中，空地址单元(即开放地址)都是查找失败的条件。因此在 用开放地址法处理冲突的散列表上执行删除操作，只能在被删结点上做删除标记，而不能真正删除结点。

拉链法的缺点

　拉链法的缺点是：指针需要额外的空间，故当结点规模较小时，开放定址法较为节省空间，而若将节省的指针空间用来扩大散列表的规模，可使装填因子变小，这又减少了开放定址法中的冲突，从而提高平均查找速度。

反射机制

OC：字符串访问 类和方法
NSClassFromString NSSelectorFromString
Swift: Mirror Class

KVO 实现

热修复

Block

Block和函数指针的区别

函数指针是函数地址的引用 block是函数对象