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

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

请先本人 答一答！

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

6: iOS 中内省的几个办法？class 办法和 objc_getClass 办法有什么区别?

• 1: 什么是内省？

在计算机科学中，内省是指计算机程序在运行时（Run time）查看对象（Object）类型的一种能力，通常也能够称作运行时类型查看。不应该将内省和反射混同。绝对于内省，反射更进一步，是指计算机程序在运行时（Run time）能够拜访、检测和批改它自身状态或行为的一种能力。

• 2：iOS 中内省的几个办法？

isMemberOfClass // 对象是否是某个类型的对象
isKindOfClass // 对象是否是某个类型或某个类型子类的对象
isSubclassOfClass // 某个类对象是否是另一个类型的子类
isAncestorOfObject // 某个类对象是否是另一个类型的父类
respondsToSelector // 是否能响应某个办法
conformsToProtocol // 是否遵循某个协定

• 3:class办法分类办法和对象办法。

• 实例 class 办法就间接返回object_getClass(self)
• 类 class 办法间接返回self

• 4.object_getClass()获取的是类型，对象.isa —> 类.isa —> 元类.isa —> 父元类.isa —> 根元类.isa —> 本人（还是根元类）

7: 分类和扩大有什么区别？能够别离用来做什么？分类有哪些局限性？分类的构造体外面有哪些成员？

• 1: 分类次要用来为某个类增加办法，属性，协定（我个别用来为零碎的类扩大办法或者把某个简单的类的依照性能拆到不同的文件里）
• 2: 扩大次要用来为某个类原来没有的成员变量、属性、办法。注：办法只是申明（我个别用扩大来申明公有属性，或者把.h 的只读属性重写成可读写的）

分类和扩大的区别：

• 分类是在运行时把分类信息合并到类信息中，而扩大是在编译时，就把信息合并到类中的
• 分类申明的属性，只会生成对应的成员变量，不会有 getter/setter 办法的申明和实现，而扩大会有。
• 分类不可用为类增加实例变量，而扩大能够
  分类能够为类增加办法的实现，而扩大只能申明办法，而不能实现

分类的局限性：

无奈为类增加实例变量，但可通过关联对象进行实现，注：关联对象中内存治理没有 weak，用时须要留神野指针的问题，可通过其余方法来实现，具体可参考 iOS weak 关键字漫谈
分类的办法若和类中本来的实现重名，会笼罩本来办法的实现，注：并不是真正的笼罩

多个分类的办法重名，会调用最初编译的那个分类的实现

分类的构造体里有哪些成员

struct category_t {
    const char *name; // 名字
    classref_t cls; // 类的援用
    struct method_list_t *instanceMethods;// 实例办法列表
    struct method_list_t *classMethods;// 类办法列表
    struct protocol_list_t *protocols;// 协定列表
    struct property_list_t *instanceProperties;// 实例属性列表
    // 此属性不肯定真正的存在
    struct property_list_t *_classProperties;// 类属性列表
};

8：能不能简述一下 Dealloc 的实现机制

Dealloc 的实现机制是内容治理局部的重点，把这个知识点弄明确，对于全方位的了解内存治理的只是很有 必要。

1.Dealloc 调用流程

• 1. 首先调用 _objc_rootDealloc()
• 2. 接下来调用 rootDealloc()

• 3. 这时候会判断是否能够被开释，判断的根据次要有 5 个，判断是否有以上五种状况

  • NONPointer_ISA
  • weakly_reference
  • has_assoc
  • has_cxx_dtor
  • has_sidetable_rc
• 4-1. 如果有以上五中任意一种，将会调用 object_dispose()办法，做下一步的解决。
• 4-2. 如果没有之前五种状况的任意一种，则能够执行开释操作，C 函数的 free()。
• 5. 执行结束。

2.object_dispose() 调用流程。

• 间接调用 objc_destructInstance()。
• 之后调用 C 函数的 free()。

3.objc_destructInstance() 调用流程

• 先判断 hasCxxDtor，如果有 C++ 的相干内容，要调用 object_cxxDestruct() ，销毁 C++ 相干的内容。
• 再判断 hasAssocitatedObjects，如果有的话，要调用 object_remove_associations()，销毁关联对象的一系列操作。
• 而后调用 clearDeallocating()。
• 执行结束。

4.clearDeallocating() 调用流程。

• 先执行 sideTable_clearDellocating()。
• 再执行 weak_clear_no_lock, 在这一步骤中，会将指向该对象的弱援用指针置为 nil。
• 接下来执行 table.refcnts.eraser()，从援用计数表中擦除该对象的援用计数。
• 至此为止，Dealloc 的执行流程完结。

9：HTTPS 和 HTTP 的区别

HTTPS 协定 = HTTP 协定 + SSL/TLS 协定

• SSL的全称是Secure Sockets Layer，即安全套接层协定，是为网络通信提供平安及数据完整性的一种平安协定。
• TLS 的全称是Transport Layer Security，即平安传输层协定。

即 HTTPS 是平安的 HTTP。

https, 全称 Hyper Text Transfer Protocol Secure，相比http，多了一个secure，这一个secure 是怎么来的呢？
这是由 TLS（SSL） 提供的！大略就是一个叫 openSSL 的library提供的。
https和 http 都属于 application layer，基于 TCP（以及 UDP）协定，然而又齐全不一样。
TCP 用的 port 是 80，https 用的是 443
（值得一提的是，google 创造了一个新的协定，叫 QUIC，并不基于 TCP，用的 port 也是 443，同样是用来给 https 的。谷歌好牛逼啊。）
总体来说，https 和 http 相似，然而比 http 平安。

10：TCP 为什么要三次握手，四次挥手？

三次握手：

• 客户端向服务端发动申请链接，首先发送 SYN 报文，SYN=1，seq=x, 并且客户端进入 SYN_SENT 状态
• 服务端收到申请链接，服务端向客户端进行回复，并发送响应报文，SYN=1，seq=y,ACK=1,ack=x+1, 并且服务端进入到 SYN_RCVD 状态
• 客户端收到确认报文后，向服务端发送确认报文，ACK=1，ack=y+1，此时客户端进入到 ESTABLISHED，服务端收到用户端发送过去的确认报文后，也进入到ESTABLISHED 状态，此时链接创立胜利

四次挥手：

• 客户端向服务端发动敞开链接，并进行发送数据
• 服务端收到敞开链接的申请时，向客户端发送回应，我晓得了，而后进行接收数据
• 当服务端发送数据完结之后，向客户端发动敞开链接，并进行发送数据
• 客户端收到敞开链接的申请时，向服务端发送回应，我晓得了，而后进行接收数据

为什么须要三次握手：

为了避免已生效的连贯申请报文段忽然又传送到了服务端，因此产生谬误，假如这是一个早已生效的报文段。
但 server 收到此生效的连贯申请报文段后，就误认为是 client 再次收回的一个新的连贯申请。
于是就向 client 收回确认报文段，批准建设连贯。
假如不采纳“三次握手”，那么只有 server 收回确认，新的连贯就建设了。
因为当初 client 并没有收回建设连贯的申请，因而不会理会 server 的确认，也不会向 server 发送数据。
但 server 却认为新的运输连贯曾经建设，并始终期待 client 发来数据。
这样，server的很多资源就白白浪费掉了。

为什么须要四次挥手：

因为 TCP 是全双工通信的，在接管到客户端的敞开申请时，还可能在向客户端发送着数据，因而不能再回应敞开链接的申请时，同时发送敞开链接的申请

11. 对称加密和非对称加密的区别？别离有哪些算法的实现？

对称加密，加密的加密和解密应用同一密钥。

• 非对称加密，应用一对密钥用于加密和解密，别离为公开密钥和公有密钥。公开密钥所有人都能够取得，通信发送方取得接管方的公开密钥之后，就能够应用公开密钥进行加密，接管方收到通信内容后应用公有密钥解密。
• 对称加密罕用的算法实现有 AES,ChaCha20,DES, 不过 DES 被认为是不平安的; 非对称加密用的算法实现有 RSA，ECC

12. HTTPS 的握手流程？为什么密钥的传递须要应用非对称加密？双向认证理解么？

HTTPS 的握手流程，如下图，摘自图解 HTTP

• 客户端发送 Client Hello 报文开始 SSL 通信。报文中蕴含客户端反对的 SSL 的版本，加密组件列表。
• 服务器收到之后，会以 Server Hello 报文作为应答。和客户端一样，报文中蕴含客户端反对的 SSL 的版本，加密组件列表。服务器的加密组件内容是从接管到的客户端加密组件内筛选进去的
• 服务器发送 Certificate 报文。报文中蕴含公开密钥证书。
• 而后服务器发送 Server Hello Done 报文告诉客户端，最后阶段的 SSL 握手协商局部完结
• SSL 第一次握手完结之后，客户端以 Client Key Exchange 报文作为会议。报文中蕴含通信加密中应用的一种被称为 Pre-master secret 的随机明码串
• 接着客户端发送 Change Cipher Space 报文。该报文会提醒服务器，在次报文之后的通信会采纳 Pre-master secret 密钥加密
• 客户端发送 Finished 报文。该报文蕴含链接至今全副报文的整体校验值。这次握手协商是否可能胜利，要以服务器是否可能正确揭秘该报文作为断定规范
• 服务器同样发送 Change Cipher Space 报文。
• 服务器同样发送 Finished 报文。
• 服务器和客户端的 Finished 报文交换结束之后，SSL 连贯建设实现，从此开始 HTTP 通信，通信的内容都应用 Pre-master secret 加密。而后开始发送 HTTP 申请
• 应用层收到 HTTP 申请之后，发送 HTTP 响应
• 最初有客户端断开连接

为什么密钥的传递须要应用非对称加密？

应用非对称加密是为了前面客户端生成的 Pre-master secret 密钥的平安，通过下面的步骤能得悉，服务器向客户端发送公钥证书这一步是有可能被他人拦挡的，如果应用对称加密的话，在客户端向服务端发送 Pre-master secret 密钥的时候，被黑客拦挡的话，就可能应用公钥进行解码，就无奈保障 Pre-master secret 密钥的平安了

双向认证理解么？

下面的 HTTPS 的通信流程只验证了服务端的身份，而服务端没有验证客户端的身份，双向认证是服务端也要确保客户端的身份，大略流程是客户端在校验完服务器的证书之后，会向服务器发送本人的公钥，而后服务端用公钥加密产生一个新的密钥，传给客户端，客户端再用私钥解密，当前就用此密钥进行对称加密的通信

文末举荐：iOS 热门文集 & 视频解析

① Swift

② iOS 底层技术

③ iOS 逆向防护

④ iOS 面试合集

⑤ 大厂面试题 + 底层技术 + 逆向安防 +Swift

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

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