2020 iOS开发腾讯二面(面试题以及参考思路)
前言:面试题均来源于自己群内成员面试后,口述而成,BAT面试一般3面起步,因为多轮的面试题较难收集,有的到二面三面群内成员就被刷了,希望大家见谅!
欢迎加入iOS交流群763164022,大家互相交流学习!
1.编译过程做了哪些事情;
2.字典大致实现原理;
3.block和函数指针的理解;
4.一般开始做一个项目,你的架构是如何思考的?
5.你了解的UIKit结构?
1.编译过程做了哪些事情?
1.C++,Objective C
都是编译语言。编译语言在执行的时候,必须先通过编译器生成机器码,机器码可以直接在CPU上执行,所以执行效率较高。
iOS开发目前的常用语言是:Objective
和Swift
。二者都是编译语言,换句话说都是需要编译才能执行的。二者的编译都是依赖于Clang + LLVM. OC和Swift
因为原理上大同小异,知道一个即可!
iOS编译
不管是OC还是Swift,都是采用Clang
作为编译器前端,LLVM(Low level vritual machine)
作为编译器后端。所以简单的编译过程如图
编译器前端
编译器前端的任务是进行:语法分析,语义分析,生成中间代码(intermediate representation )
。在这个过程中,会进行类型检查,如果发现错误或者警告会标注出来在哪一行。
编译器后端
编译器后端会进行机器无关的代码优化,生成机器语言,并且进行机器相关的代码优化。iOS的编译过程,后端的处理如下
LVVM优化器会进行BitCode的生成,链接期优化等等
LLVM机器码生成器会针对不同的架构,比如arm64等生成不同的机器码。
执行一次XCode build
的流程
当你在XCode中,选择build的时候(快捷键command+B),会执行如下过程
编译信息写入辅助文件,创建编译后的文件架构(name.app)
处理文件打包信息,例如在debug环境下
执行CocoaPod
编译前脚本
例如对于使用CocoaPod
的工程会执行CheckPods Manifest.lock
编译各个.m
文件,使用CompileC
和clang
命令。
编译各个.m文件,使用CompileC和clang命令。
> 1.CompileC ClassName.o ClassName.m normal x86_64 objective-c com.apple.compilers.llvm.clang.1_0.compiler
>
> 2.export LANG=en_US.US-ASCII
>
> 3.export PATH="..."
>
> 4.clang-x objective-c -arch x86_64 -fmessage-length=0 -fobjc-arc...
>
> -Wno-missing-field-initializers ... -DDEBUG=1 ... -isysroot
>
> iPhoneSimulator10.1.sdk -fasm-blocks ... -I 上文提到的文件 -F 所需要的Framework-iquote 所需要的Framework ... -c ClassName.c -o ClassName.o
通过这个编译的命令,我们可以看到
2.字典大致实现原理;
一:字典原理
NSDictionary(字典)
是使用hash
表来实现key
和value
之间的映射和存储的
方法:- (void)setObject:(id)anObject forKey:(id)aKey;
Objective-C中的字典NSDictionary底层其实是一个哈希表
二:哈希原理
散列表(Hash table
,也叫哈希表),是根据关键码值(Key value
)而直接进行访问的数据结构。也就是说,它通过把关键码值映射到表中一个位置来访问记录,以加快查找的速度。这个映射函数叫做散列函数,存放记录的数组叫做散列表。
给定表M,存在函数f(key)
,对任意给定的关键字值key
,代入函数后若能得到包含该关键字的记录在表中的地址,则称表M为哈希(Hash)表,函数f(key)
为哈希(Hash) 函数。
哈希概念:哈希表的本质是一个数组,数组中每一个元素称为一个箱子(bin),箱子中存放的是键值对。
三:哈希存储过程
1.根据 key 计算出它的哈希值 h。
2.假设箱子的个数为 n,那么这个键值对应该放在第 (h % n) 个箱子中。
3.如果该箱子中已经有了键值对,就使用开放寻址法或者拉链法解决冲突。
在使用拉链法解决哈希冲突时,每个箱子其实是一个链表,属于同一个箱子的所有键值对都会排列在链表中。
哈希表还有一个重要的属性: 负载因子(load factor),它用来衡量哈希表的空/满程度,一定程度上也可以体现查询的效率,计算公式为:
负载因子 = 总键值对数 / 箱子个数
负载因子越大,意味着哈希表越满,越容易导致冲突,性能也就越低。因此,一般来说,当负载因子大于某个常数(可能是 1,或者 0.75 等)时,哈希表将自动扩容。
哈希表在自动扩容时,一般会创建两倍于原来个数的箱子,因此即使 key 的哈希值不变,对箱子个数取余的结果也会发生改变,因此所有键值对的存放位置都有可能发生改变,这个过程也称为重哈希(rehash)。
哈希表的扩容并不总是能够有效解决负载因子过大的问题。假设所有 key 的哈希值都一样,那么即使扩容以后他们的位置也不会变化。虽然负载因子会降低,但实际存储在每个箱子中的链表长度并不发生改变,因此也就不能提高哈希表的查询性能。
基于以上总结,细心的朋友可能会发现哈希表的两个问题:
1.如果哈希表中本来箱子就比较多,扩容时需要重新哈希并移动数据,性能影响较大。
2.如果哈希函数设计不合理,哈希表在极端情况下会变成线性表,性能极低。
3.block和函数指针的理解;
相似点:
函数指针和Block都可以实现回调的操作,声明上也很相似,实现上都可以看成是一个代码片段。
函数指针类型和Block类型都可以作为变量和函数参数的类型。(typedef定义别名之后,这个别名就是一个类型)
不同点:
函数指针只能指向预先定义好的函数代码块(可以是其他文件里面定义,通过函数参数动态传入的),函数地址是在编译链接时就已经确定好的。
Block本质是Objective-C对象,是NSObject的子类,可以接收消息。
函数里面只能访问全局变量,而Block代码块不光能访问全局变量,还拥有当前栈内存和堆内存变量的可读性(当然通过__block访问指示符修饰的局部变量还可以在block代码块里面进行修改)。
从内存的角度看,函数指针只不过是指向代码区的一段可执行代码,而block实际上是程序运行过程中在栈内存动态创建的对象,可以向其发送copy消息将block对象拷贝到堆内存,以延长其生命周期。
4.一般开始做一个项目,你的架构是如何思考的?
5.你了解的UIKit结构?
这题应该是在你回答的基础之上,进行二次提问,主要还是看你的基础!