腾讯面试题及答案（iOS方向）

腾讯一面：

1.使用了第三方库, 有看它们是怎么实现的吗？
答：例：SD、YY、AFN、MJ等！

1.入口 setImageWithURL:placeholderImage:options:
会先把 placeholderImage 显示，然后 SDWebImageManager 根据 URL 开始处理图片。
2.进入 SDWebImageManagerdownloadWithURL:delegate:options:userInfo:，
交给 SDImageCache 从缓存查找图片是否已经下载 queryDiskCacheForKey:delegate:userInfo:.
3.先从内存图片缓存查找是否有图片，
如果内存中已经有图片缓存，SDImageCacheDelegate 回调 imageCache:didFindImage:forKey:userInfo: 到 SDWebImageManager。
4.SDWebImageManagerDelegate 回调 webImageManager:didFinishWithImage:
到 UIImageView+WebCache 等前端展示图片。
5.如果内存缓存中没有，生成 NSInvocationOperation
添加到队列开始从硬盘查找图片是否已经缓存。
6.根据 URLKey 在硬盘缓存目录下尝试读取图片文件。
这一步是在 NSOperation 进行的操作，所以回主线程进行结果回调 notifyDelegate:。
7.如果上一操作从硬盘读取到了图片，将图片添加到内存缓存中
（如果空闲内存过小，会先清空内存缓存）。
SDImageCacheDelegate 回调 imageCache:didFindImage:forKey:userInfo:。
进而回调展示图片。
8.如果从硬盘缓存目录读取不到图片，
说明所有缓存都不存在该图片，需要下载图片，
回调 imageCache:didNotFindImageForKey:userInfo:。
9.共享或重新生成一个下载器 SDWebImageDownloader 开始下载图片。
10.图片下载由 NSURLConnection 来做，
实现相关 delegate 来判断图片下载中、下载完成和下载失败。
11.connection:didReceiveData: 中
利用 ImageIO 做了按图片下载进度加载效果。
12.connectionDidFinishLoading: 数据下载完成后交给 SDWebImageDecoder 做图片解码处理。
13.图片解码处理在一个 NSOperationQueue 完成，
不会拖慢主线程 UI。如果有需要对下载的图片进行二次处理，
最好也在这里完成，效率会好很多。
14.在主线程 notifyDelegateOnMainThreadWithInfo:
宣告解码完成，
imageDecoder:didFinishDecodingImage:userInfo:
回调给 SDWebImageDownloader。
15.imageDownloader:didFinishWithImage:
回调给 SDWebImageManager 告知图片下载完成。
16.通知所有的 downloadDelegates 下载完成，
回调给需要的地方展示图片。
17.将图片保存到 SDImageCache 中，
内存缓存和硬盘缓存同时保存。
写文件到硬盘也在以单独 NSInvocationOperation 完成，
避免拖慢主线程。
18.SDImageCache 在初始化的时候会注册一些消息通知，
在内存警告或退到后台的时候清理内存图片缓存，
应用结束的时候清理过期图片。
19.SDWI 也提供了 UIButton+WebCache 和
MKAnnotationView+WebCache，方便使用。
20.SDWebImagePrefetcher 可以预先下载图片，方便后续使用。

2.强连通量算法了解嘛？

**概念：**
有向图强连通分量：在有向图G中，如果两个顶点vi,vj间（vi>vj）有一条从vi到vj的有向路径，同时还有一条从vj到vi的有向路径，则称两个顶点强连通(strongly
connected)。如果有向图G的每两个顶点都强连通，称G是一个强连通图。有向图的极大强连通子图，称为强连通分量(strongly
connected components)。
定义：
**有向图强连通分量：**
在有向图G中，如果两个顶点间至少存在一条路径，称两个顶点强连通（strongly connected）。
如果有向图G的每两个顶点都强连通，则称G是一个强连通图。
非强连通图有向图的极大强连通子图，成为强连通分量（strongly connected components）。
下图中，子图{1,2,3,4}为一个强连通分量，因为顶点1,2,3,4两两可达，{5}，{6}也分别是两个强连通分量。

3.遇到tableView卡顿嘛？会造成卡顿的原因大致有哪些？

答：
可能造成tableView卡顿的原因有：

1.最常用的就是cell的重用， 注册重用标识符


如果不重用cell时，每当一个cell显示到屏幕上时，就会重新创建一个新的cell；
如果有很多数据的时候，就会堆积很多cell。
如果重用cell，为cell创建一个ID，每当需要显示cell 的时候，都会先去缓冲池中寻找可循环利用的cell，如果没有再重新创建cell

2.避免cell的重新布局

cell的布局填充等操作 比较耗时，一般创建时就布局好
如可以将cell单独放到一个自定义类，初始化时就布局好

3.提前计算并缓存cell的属性及内容

当我们创建cell的数据源方法时，编译器并不是先创建cell 再定cell的高度
而是先根据内容一次确定每一个cell的高度，高度确定后，再创建要显示的cell，滚动时，每当cell进入凭虚都会计算高度，提前估算高度告诉编译器，编译器知道高度后，紧接着就会创建cell，这时再调用高度的具体计算方法，这样可以方式浪费时间去计算显示以外的cell

4.减少cell中控件的数量

尽量使cell得布局大致相同，不同风格的cell可以使用不用的重用标识符，初始化时添加控件，
不适用的可以先隐藏

5.不要使用ClearColor，无背景色，透明度也不要设置为0

渲染耗时比较长

6.使用局部更新

如果只是更新某组的话，使用reloadSection进行局部更新

7.加载网络数据，下载图片，使用异步加载，并缓存

8.少使用addView 给cell动态添加view

9.按需加载cell，cell滚动很快时，只加载范围内的cell

10.不要实现无用的代理方法，tableView只遵守两个协议

11.缓存行高：estimatedHeightForRow不能和HeightForRow里面的layoutIfNeed同时存在，这两者同时存在才会出现“窜动”的bug。所以我的建议是：只要是固定行高就写预估行高来减少行高调用次数提升性能。如果是动态行高就不要写预估方法了，用一个行高的缓存字典来减少代码的调用次数即可

12.不要做多余的绘制工作。在实现drawRect:的时候，它的rect参数就是需要绘制的区域，这个区域之外的不需要进行绘制。例如上例中，就可以用CGRectIntersectsRect、CGRectIntersection或CGRectContainsRect判断是否需要绘制image和text，然后再调用绘制方法。

13.预渲染图像。当新的图像出现时，仍然会有短暂的停顿现象。解决的办法就是在bitmap context里先将其画一遍，导出成UIImage对象，然后再绘制到屏幕；

14.使用正确的数据结构来存储数据。

4.M、V、C相互通讯规则你知道的有哪些？
答：MVC 是一种设计思想，一种框架模式，是一种把应用中所有类组织起来的策略，它把你的程序分为三块，分别是：

M（Model）：实际上考虑的是“什么”问题，你的程序本质上是什么，独立于 UI 工作。是程序中用于处理应用程序逻辑的部分，通常负责存取数据。

C（Controller）：控制你 Model 如何呈现在屏幕上，当它需要数据的时候就告诉 Model，你帮我获取某某数据；当它需要 UI 展示和更新的时候就告诉 View，你帮我生成一个 UI 显示某某数据，是 Model 和 View 沟通的桥梁。

V（View）：Controller 的手下，是 Controller 要使用的类，用于构建视图，通常是根据 Model 来创建视图的。

Controller to Model
可以直接单向通信。Controller 需要将 Model 呈现给用户，因此需要知道模型的一切，还需要有同 Model 完全通信的能力，并且能任意使用 Model 的公共 API。
Controller to View
可以直接单向通信。Controller 通过 View 来布局用户界面。
Model to View
永远不要直接通信。Model 是独立于 UI 的，并不需要和 View 直接通信，View 通过 Controller 获取 Model 数据。
View to Controller
View 不能对 Controller 知道的太多，因此要通过间接的方式通信。

腾讯二面：

1.编译过程做了哪些事情；
答：C++,Objective C都是编译语言。编译语言在执行的时候，必须先通过编译器生成机器码，机器码可以直接在CPU上执行，所以执行效率较高。iOS开发目前的常用语言是：Objective和Swift。二者都是编译语言，换句话说都是需要编译才能执行的。

编译器前端的任务是进行：语法分析，语义分析，生成中间代码(intermediate representation )。在这个过程中，会进行类型检查，如果发现错误或者警告会标注出来在哪一行。

编译器后端会进行机器无关的代码优化，生成机器语言，并且进行机器相关的代码优化。

2.OC你了解的锁有哪些？
答：在iOS中，锁分为递归锁、条件锁、分布式锁、一般锁（根据NSLock类里面的分类进行划分）。
其他常见的锁：
答：1.@synchronized 关键字加锁
2. NSLock 对象锁
3. NSCondition
4. NSConditionLock 条件锁
5. NSRecursiveLock 递归锁
6. pthread_mutex 互斥锁（C语言）
7. dispatch_semaphore 信号量实现加锁（GCD）

追问一：自旋和互斥对比？
答：**相同点：**都能保证同一时间只有一个线程访问共享资源。都能保证线程安全。
不同点：
互斥锁：如果共享数据已经有其他线程加锁了，线程会进入休眠状态等待锁。一旦被访问的资源被解锁，则等待资源的线程会被唤醒。
自旋锁：如果共享数据已经有其他线程加锁了，线程会以死循环的方式等待锁，一旦被访问的资源被解锁，则等待资源的线程会立即执行。自旋锁的效率高于互斥锁。

3.内存泄漏可能会出现的几种原因，聊聊你的看法？
答：一种可能：第三方框架不当使用；

第二种可能：block循环引用；

第三种可能：delegate循环引用；

第四种可能：NSTimer循环引用

第五种可能：非OC对象内存处理

第六种可能：地图类处理

第七种可能：大次数循环内存暴涨

4.如果项目开始容错处理没做？如何防止拦截潜在的崩溃？
答：
1、category给类添加方法用来替换掉原本存在潜在崩溃的方法。

2、利用runtime方法交换技术，将系统方法替换成类添加的新方法。
3、利用异常的捕获来防止程序的崩溃，并且进行相应的处理。

如需要更多的面试资料，请加扣扣：3434583796

转载链接：https://www.jianshu.com/p/0e9e7486e1a7