面试

iOS面试题

2018-01-16  本文已影响197人  RocketsChen

前提:上周同事去一家初创型互联网公司去面试iOS开发遇到如下的面试题,也跟我分享了一下具体面试内容,写篇博客总结一下。

面试题如下


看到具体的面试题后,我总结了一下如下分四个部分:

1.第一部分的是对常规SDK的使用和项目中常用框架。

友盟
极光
支付宝微信
高德地图
AFNetworking
SDWebImage
Masonry
MJExtension

2.第二部分的是对概念设计模式的理解。

高并发编程

围绕高并发的核心词 : Grand Central Dispatch(简称GCD)、NSOperation、NSThreadOperation Queues(运行队列)多线程

//dispatch_async:异步执行
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(<#time#> * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
   <#do something#> // 待执行的任务
});
两者区别在于下面获取到了NSThread对象方便终止线程。
[NSThread detachNewThreadSelector:@selector(loadData) toTarget:self withObject:nil];

#pragma mark - 加载耗时数据
- (void)loadData
{
    //并发执行执行任务
}

NSThread *thread = [[NSThread alloc] initWithTarget:self selector:@selector(loadData) object:nil];

[thread start]; //调用

总结:如果选择的话我更倾向于GCD ,GCD是一个轻量级别的级别,底层实现影藏的技术,通过其和Block相结合可以轻松实现多线程编程。

参考博客:使用GCDiOS多线程

你理解的多线程

同一时间,CPU只能处理1条线程,只有1条线程在工作(执行) 多线程并发(同时)执行,其实是CPU快速地在多条线程之间调度(切换) 如果CPU调度线程的时间足够快,就造成了多线程并发执行的假象 思考:如果线程非常非常多,会发生什么情况?
CPU会在N多线程之间调度,CPU会累死,消耗大量的CPU资源 每条线程被调度执行的频次会降低(线程的执行效率降低)

能适当提高程序的执行效率 能适当提高资源利用率(CPU、内存利用率)

开启线程需要占用一定的内存空间(默认情况下,主线程占用1M,子线程占用 512KB),如果开启大量的线程,会占用大量的内存空间,降低程序的性能
线程越多,CPU在调度线程上的开销就越大 程序设计更加复杂:比如线程之间的通信、多线程的数据共享

简单说说TCP和UDP的理解

这两个工作在TCP/IP协议传输层的两个不同的协议,是用来传输数据用的。

TCP:(Transmission Control Protocol)和UDP(User Datagram Protocol)属于传输层协议。这是一个全双工的、面向连接的、可靠的并且是精确控制的协议。
UDP:(User Datagram protocol)是面向数据报的运输层协议。是一个不可靠的传输协议。
两者的区别和联系:

区别:TCP是面向连接的可靠的传输控制协议,UDP是面向非连接的用户数据协议。
联系:TCP(三次握手保证相对可靠性)可传大量数据,速度相对比较慢,UDP一次性传输少量对可靠性要求不高的数据,速度比较快
tcp一般用于音频、视频等数据的传输,资源能耗比较小,对可靠性要求不高,即使丢失一两条数据也不会产生太大影响。

什么是“三次握手”:

是指建立一个TCP连接时,需要客户端和服务器总共发送3个包。三次握手的目的是连接服务器指定端口,建立TCP连接,并同步连接双方的序列号和确认号并交换 TCP 信息。

三次握手

介绍APP启动过程,如果启动比较耗时是否有优化的方法

APP启动过程
1. 解析Info.plist
2. Mach-O加载
3. 程序执行
APP启动缓慢,想到的因素
  1. main( ) 函数内有耗时操作
  2. 动态库加载太多
  3. rootViewControlle以及childViewController的加载,viewsubViews的加载耗时
优化

设计模式

MVC:

MVC(Model View Controller):模型(model)-视图(view)-控制器(controller)

MVC的优点

视图层和业务层分离,这样就允许更改视图层代码而不用重新编译模型和控制器代码,同样,一个应用的业务流程或者业务规则的改变只需要改动MVC的模型层即可。因为模型与控制器和视图相分离,所以很容易改变应用程序的数据层和业务规则。

由于模型返回的数据没有进行格式化,所以同样的构件能被不同的界面使用。例如,很多数据可能用HTML来表示,但是也有可能用WAP来表示,而这些表示所需要的命令是改变视图层的实现方式,而控制层和模型层无需做任何改变。

MVC使开发和维护用户接口的技术含量降低。

分离视图层和业务逻辑层也使得应用更易于维护和修改。

总结优点:提高代码的可读性和可移植性,降低耦合度,提高内聚,大大提高开发的效率。

MVC的缺点:

对于一些接单的界面额外的增加复杂性,视图与控制器间的过于紧密的连接。不适合中小型APP的开发,会额外增加开发成本。

MVC
V向C发消息:

参考:浅谈 MVC、MVP 和 MVVM 架构模式iOS中MVC设计模式

架构设计:

建议可以从以下几个方面回答

APP好的架构的评判标准

说下MD5 base64以及AES加密

MD5:Message Digest Algorithm 5

MD5是iOS中比较常见的加密方法之一,其特点有一下几点

base64加密:使用64个字符来对任意数据进行编码。
如何防止反编译

3.第三部分的是对项目中具体某个功能点的实现。

角色权限和分配,是否做过单点登录

在处理这类问题的时候,角色权限和分配对后台的依赖比较大。拿单点登录来说:单点登录SSO(Single Sign On)是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。简单来说单点登录核心就是要解决,验证信任机制的有效性即存储信任和验证信任。如下优缺点和三种实现方式
单点登录优点
单点登录缺点
1.以Cookie作为凭证媒介

最简单的单点登录实现方式,是使用cookie作为媒介,存放用户凭证。
用户登录父应用之后,应用返回一个加密的cookie,当用户访问子应用的时候,携带上这个cookie,授权应用解密cookie并进行校验,校验通过则登录当前用户。

Cookie凭借
以上通过Cookie的方式实现单点登录很容易发现弊端

第一个Cookie不安全上我们可以通过加密等方式来避免泄露,但第二天跨域是硬伤。

2.通过JSONP实现

相比较Cookie的方法,JSONP更好的在于解决了跨域问题,我们父应用在登录成功后把Session匹配的Cookie会存到应用中。当用户需要登录子应用的时候,授权应用访问父应用提供的JSONP接口,并在请求中带上父应用域名下的Cookie,父应用接收到请求,验证用户的登录状态,返回加密的信息,子应用通过解析返回来的加密信息来验证用户。

JSONP

虽然解决了跨域但是还是存在上一个方法一样的弊端,就是信任机制的不安全性,易泄露。

3.通过页面重定向的方式

通过父应用和子应用来回重定向中进行通信,解决信任机制的不安全性,实现信息的安全传递。
父类提供一个登录接口,用户通过子应用登录连接访问这个接口,判断如果用户还未登录,则返回登录界面输入账号密码登录。如以及登录则声称密码Token,验证Token的接口,检验后是否登录成功。

页面重定向

这个方法固然解决了跨域和安全两个问题,但是相比较上两种而言增加了登录的复杂度。

参考:单点登录的三种实现方式

4.博客,开源。

开源的话,推荐GitHub

坚持开源写博客,对技术的提升还是很有帮助的,如果把平常项目开发中小技巧和问题记录下来,长期积累下去也是一件有意义的事。

最后就总结到这,欢迎补充~

上一篇下一篇

猜你喜欢

热点阅读