iOS程序员面试分类模拟14

iOS程序员面试分类模拟14简答题1.

什么是ReactiveCocoa?如何使用?正确答案：ReactiveCocoa是GitHub开源的应用于iOS和OSX的FRP框架，它吸取了.Net的R（江南博哥）eactiveExtensions的设计，并实现了Objective-C和Swift两个版本。

ReactiveCocoa的宗旨是Streamsofvaluesovertime(随着时间变化而不断流动的数据流)。它的主要目的是想解决Controller过于臃肿的问题，状态及状态之间的转化问题，数据和事件的绑定问题以及消息传递的问题。RAC中把事件、变量等都看作信号，而信号就对应了FRP中的流，当信号被订阅(subscribing)时，信号的执行才会被触发。

下图是事件和变量随时间的流动图。

事件和变量随时间的流动图

下面简单地介绍RAC的使用。示例代码如下：

/*1.1创建一个信号,并订阅它*/

RACSignal*signal=[RACSignalcreateSignal:^RACDisposable*_Nullable(id＜RACSubscriber＞_Nonnullsubscriber){

inta=0:

[subscribersendNext:@(a)];

[subscribersendCompleted];

returnnil;

}];

/*订阅信号signal*/

[signalsubscribeNext:^(id_Nullablex){

NSLog(@"x:%@",x);

}];

/*1.2监听一个UITextField属性text的变化,并打印text的值*/

[self.textField.rac_textSignalsubscribeNext:^(NSString*text){

NSLog(@"text:%@",text);

}];

/*1.3使用filter过滤UITextField中text长度小于6的字符串*/

[[self.textField.rac_textSignalfilter:^BOOL(NSString*_Nullablevalue){

returnvalue.length＞6;

}]subscribeNext:^(NSString*text){

NSLog(@"textvalue:%@",text);

}];

/*1.4通过map重新映射的信号持有的变量,实现获取UITextField中text的长度*/

RACSignal*textLengthSignal=[self.textField.rac_textSignalmap:^id_Nullable(NSString*value){

return@(value.length);

}];

[textLengthSignalsubscribeNext:^(NSNumber*length){

NSLog(@"textlength:%d",[lengthintValue]);

}];

/*1.5使用signalForControlEvents代替addTarget实现事件绑定*/

[[self.buttonrac_signalForControlEvents:UIControlEventTouchUpInside]subscribeNext:^(__kindofUIControl*_Nullablex){

//dosomething...

VSCog(@"buttonclick");

}];

/*1.6将某个对象的text属性绑定到UITextField的text上*/

RAC(self.model,text)=self.textField.rac_textSignal;

/*1.7RAC遍历数组元素*/

NSArray*numbers=@[@1,@2,@3,@4];

[numbers.rac_sequence.signalsubscribeNext:^(idx){

NSLog(@"%@",x);

}];

RAC的强大远远不止如此，可以用它来封装网络请求，从而帮助Controller减少网络请求的逻辑。开发人员还可以用RAC重新实现MVVM模式，通过RAC实现模型与数据的绑定。如果你是一个有追求的程序员，想更加深入学习RAC，那么请到它的官网或者相关博客中学习。

2.

如何使用RAC防止button短时间内重复单击?正确答案：很多时候，我们要防止按钮或cell的重复单击，特别是当单击按钮会触发网络请求的时候。如果在短时间内多次单击按钮，那么会使得网络在短时间内重复请求，上一个请求未结束，下一个请求又发出了，这样有可能会带来意想不到的后果，严重的话会造成程序崩溃。因此，防止按钮在短时间内重复单击是非常有必要的。如果是经验丰富的程序员，那么他们会想到AOP，利用iOS中的runtime机制，使用MethodSwizzling实现单击事件的hook，然后延时执行单击事件，从而避免短时间内重复单击。如果开发者会RAC，那么这个问题就很简单了，解决方法如下：

[[[self.buttonrac_signalForControlEvents:UIControlEventTouchUpInside]throttle:2]subscribeNext:^(__kindofUIControl*_Nullablex){

NSLog(@"buttonciick");

}];

以上代码的功能是使用throttle(节流)方法，实现2s内，多次单击按钮只响应最后一次单击的事件。

3.

什么是单例模式?正确答案：单例模式是一种最基本的设计模式，单例类在系统中只有一个实例，它通过一个全局接口随时进行访问或者更新，起到控制中心的角色，全局协调类的各种服务。

Foundation和ApplicationKit框架中的一些类只允许创建单件对象，即这些类在当前进程中的唯一实例。举例来说，NSFileManager和NSWorkspace类在使用时都是基于进程进行单件对象的实例化。当向这些类请求实例的时候，它们会传递单一实例的一个引用，如果该实例还不存在，那么先进行实例的分配和初始化。如果类在概念上只有一个实例(例如NSWorkspace)，那么就应该产生一个单件实例，而不是多个实例。如果将来可能有多个实例，那么可以使用单件实例机制，而不是工厂方法或方法。

1.Cocoa框架中常用的单例对象

1)UIApplication：应用程序实例对象。一个UIApplication对象就代表一个应用程序，每个应用程序有且只有一个UIApplication对象，开发中最常用的是使用它的openURL函数来跳转到其他应用程序，通过[UIApplicationsharedApplication]类方法可以获得这个单例对象。

2)NSNotificalionCenter：通知中心。iOS中的通知中心是一种消息的广播，采用了观察者模式，同时一个应用应有且只有一个默认通知中心，也就是一个单例，默认的通知中心可通过[NSNotificationCenterdefaultCenter]类方法获得。

3)NSFileManager：文件管理器。它是iOS文件系统的接口，用来创建、修改、访问文件，默认文件管理器单例可通过[NSFileManagerdefaultManager]类函数获得。

4)NSUserDefaults：应用程序用户偏好设置，主要用来存储简单键值对数据，数据持久化最简单基础的一种方案，其单例类可通过[NSUserDefaultsstandardUserDefaults]类函数获得。

5)NSWorkspace：一个比较宏观的应用级控制中心单例类，可以用来打开或操作文件和设备，以及获取文件和设备的信息，跟踪文件或设备以及数据库的变动，设置或获取文件的Finder信息，还可以启动应用程序，可通过[NSWorkspacesharedWorkspace]类函数获得单例。

6)NSURLCache：iOS中设置内存缓存的一个单例类，可通过[NSURLCachesharedURLCachel类函数获得使用。

7)NSHTTPCookieStorage：iOS中的一个管理cooklie的单例对象。

2.Objective-C中单例模式的实现

iOS中单例模式的实现主要考虑两种情况，一种是非ARC下的实现(要考虑内存管理)；另一种是ARC下实现，但目的相同都是实现让某个类在应用中有且只有一个实例。这里只说ARC下的实现方法。假设规定就通过类名的类函数来调用单例类，不允许通过alloc和init创建，也暂时不考虑截断copyWithZone的问题，从而简单实现。但实际上可能会通过其他方式重新初始化创建一个新的对象，为了阻止其发生，还要考虑将其他创建方式进行重写截断，保证对象只会按照预想的被实例化一次。

传统的约定俗成的单例实现方式是类似于下面这样的(静态变量实现)。

+(instancetype)sharedInstance

{

staticidsharedInstance;

@synchronized(self){

if(sharedInstance==nil){

sharedInstance=[[SingletonClassalloc]init];

}

}

returnsharedInstance;

}

现在有了Objective-C中的GCD，还是推荐使用dispatch_once()来控制代码同步从而取代上面的实现方法。dispatch_once()优点是简洁高效，而且含义符合这里的需求，就是“只执行一次”，此外还能避免线程不安全等潜在问题。代码如下：

/*SingletonClass.h*/

#import＜Foundation/Foundation.h＞

@interfaceSingtetonClass:NSObject

/*测试变量*/

@property(nonatomic,copy)NSString*name;

/*class单例*/

+(instancetype*)sharedInstance;

@end

/*SingletonClass.m*/

#import"SingletonClass.h"

@implementationSingletonClass

/*class单例*/

+(instancetype)sharedInstance{

staticdispatch_once_tonce=0;

staticidsharedInstance=nil;

dispatch_once(&once,^{

/*只实例化一次*/

sharedInstance=[[selfalloc]init];

});

returnsharedInstance;

}

/*测试*/

-(void)test{

/*可在整个工程中调用如下代码:*/

[SingletonClasssharedInstance].name=@"sharedInstnce";

NSString*name=[SingletonClasssharedInstance].name;

}

@end

4.

什么是MVC设计模式?正确答案：MVC是iOS开发中一种很基础的工程架构模式，也是构建iOS应用的标准模式。它将数据模型、UI视图和逻辑控制器分开并规定它们之间的通信方式，大大优化了程序的结构组织。

M表示Model，专门用来存储对象数据的模型，一般使用一个继承NSObject的基本类对模型的数据进行封装，在.h文件中声明一些用来存放数据的属性。在CoreData中模型即ManagedObject。

V表示View的可见元素，展示UI界面给用户，主要为UIKit中UIView的子类，其中和用户进行交互的视图元素为UIKit子类UIControl下的子类视图，非UIControl子类的视图不能交互。

C表示Controller，逻辑控制器，对应于UIKit中UIViewController及其子类控制器，负责协调View和Model。

Controller和View的通信主要通过一些代理协议以及block代码块等实现；而Controller和Model的通信主要用到Notification消息通知和KVO等典型观察者模式实现；View和Model是隔离的，不可以直接相互通信。

MVC设计模式是官方推荐在iOS开发中使用的规范模式，应用的数据存储在Model层，逻辑处理在Controller中进行，而用户界面在View中展示。

5.

如何理解MVC设计模式?正确答案：MVC全名是ModelViewController，是模型(Model)一界面视图(View)一控制器(Controller)的缩写，它是一种软件设计规范，用一种将业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到Controller中，在改进和个性化定制界面及用户交互的同时，不需要编写业务逻辑。可以用下图来描述通过控制器实现的视图到模型的交互过程。

MVC设计模式结构

1.模型对象

模型对象封装了应用程序的数据，并定义了操控和处理该数据的逻辑和运算规则。用户在视图层中所进行的创建或者修改数据的操作，会通过控制器对象传达出去，最终会创建或更新模型对象。另外，当模型对象更改时(例如，通过网络连接接收到新数据)，模型对象会通知控制器对象，控制器对象更新相应的视图对象。被模型返回的数据是中立的，也就是说模型和数据格式无关，这样一个模型能为多个视图提供数据。由于应用于模型的代码只需要写一次就可以被多个视图重用，所以减少了代码的重复性。

2.视图对象

视图对象是应用程序中用户可以看到并且能够与之交互的界面。视图对象对外提供显示自身和响应用户操作的接口。视图对象的主要作用就是显示来自应用程序模型对象的数据，并使该数据可被编辑。在iOS应用程序开发中，所有的控件、窗口等都继承自UIView，对应于MVC中的View。

3.控制器对象

在应用程序的一个或多个视图对象和一个或多个模型对象之间，控制器对象充当媒介。因此，控制器对象是同步管理程序，通过控制器对象，视图对象了解模型对象的更改，反之亦然。控制器对象还可以为应用程序执行设置和协调任务，并管理其他对象的生命周期。控制器对象解释在视图对象中进行的用户操作，并将新的或更改过的数据传达给模型对象。模型对象更改时，一个控制器对象会将新的模型数据传达给视图对象，以便视图对象可以显示它。

MVC设计模式的低耦合性、高重用性、可维护性等优点显而易见，使得原本复杂的代码与界面的交互变得简单、清晰、明了，开发者可以把更多的精力放在前端界面的设计上，而不用绞尽脑汁去思考究竟应该如何使界面得到同步，这样减轻了设计压力，也从另一方面使用户得到更多更好的享受体验。事实上，MVC设计模式也是苹果公司推荐并在大量实践的设计模式。例如，对于不同的UIView类型的视图对象，都有相应地控制器对象(即UIViewController)与之对应。例如，常用的视图类UITableView，它所对应的控制器对象就是UITableViewController类对象。

6.

MVC设计模式有哪些优缺点?正确答案：MVC的优点如下：

1.代码具有低耦合的特性

耦合性，也称块间联系，指程序结构中各模块间相互联系紧密程度的一种度量。模块之间联系越紧密，其耦合性就越强，模块的独立性越差。在MVC设计模式中，由于视图层、业务层和数据层的分离，每个模块之间相互独立，这样就允许更改视图层代码而不用重新编译模型和控制器代码。同样，一个应用程序的业务流程或者业务规则的改变只需要改动MVC的模型层即可。因为模型与控制器和视图相分离，所以很容易改变应用程序的数据层和业务规则。

2.高重用性和可适用性

随着技术的不断进步，现在需要用越来越多的方式来访问应用程序。MVC设计模式允许用户使用各种不同样式的视图来访问同一个服务器端的代码。它包括任何Web(HTTP)浏览器或者无线浏览器(WAP)。例如，用户可以通过计算机也可通过手机来订购某样产品，虽然订购的方式不一样，但处理订购产品的方式是一样的。由于模型返回的数据没有进行格式化，所以同样的构件能被不同的界面使用。例如，很多数据可能用HTML来表示，也有可能用WAP来表示，这些表示所需要的命令是改变视图层的实现方式，而控制层和模型层无须做任何改变。

3.较低的生命周期成本和高可维护性

MVC设计模式使视图层和业务逻辑层分离，使得应用更易于维护和修改，开发和维护用户接口的技术含量降低，技术人员只要关心指定模块的代码逻辑即可。

4.有利于软件工程化管理

由于不同的层各司其职，每一层不同的应用具有某些相同的特征，有利于通过工程化、工具化管理程序代码。

MVC的缺点如下：

1.增加了系统结构和实现的复杂性

MVC设计模式适合用户界面和业务逻辑比较复杂的应用程序。对于简单的界面，严格遵循MVC设计模式，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。

2.视图与控制器间的过于紧密的连接

虽然视图与控制器之间是相互分离的，但在实际开发中，视图与控制器确又是联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了它们的独立重用。

3.视图对模型数据的低效率访问

依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。

4.控制器臃肿

大量逻辑处理代码全部放入ViewController控制器中，加上要遵循很多协议，会导致其变得臃肿和混乱，难以维护和管理，也难以分离模块进行测试。

5.缺少专门放网络逻辑代码的部分

导致网络逻辑处理只能放在Controller控制器中，加剧了Controller控制器部分的臃肿问题。

7.

如何理解MVVM设计模式?正确答案：随着业务规模的不断扩大，业务逻辑也越来越复杂，这使得Controller中的任务越来越繁重，传统的MVC架构已经很难满足低耦合、高内聚的设计要求。在这样的背景下，MVVM(Model-View-ViewModel)诞生了。MVVM是由微软公司提出的一种新的设计架构，它基于MVC架构，其特点是在View和Model之间多加了一层ViewModel来实现数据的绑定(data-binding)，从而很好地解决了MVC中Controller过于臃肿的问题。下图展示了MVVM设计模式的结构。

MVVM设计模式结构

MVVM中的ViewModel有以下几个特点：

1)ViewModel是有状态的。ViewModel有自己的属性，还会持有Model对象。

2)ViewModel与UI控件的无关性。ViewModel并不关心UI控件的相关逻辑，只关心自己的数据处理逻辑。

3)易于单元测试。以往的Controller过于复杂，无法进行单元测试，而ViewModel测试起来简单很多。

4)ViewModel可以抽离出来做转换器给其他项目使用，从而最大程度上实现了代码的复用。

MVVM设计模式的目的是帮助MVC设计模式中的(Sontroiler瘦身，将数据加工的任务从Controller中解放了出来，使得Controller只需要专注于业务分配的工作，让MVVM中的ViewModel负责Model与View之间的通信，并完成通信间的额外操作，如数据转换、字符拼接等操作。因此，ViewModel经常作为转换器使用，从而提高了代码的复用性。ViewModel还能帮助Controller完成复杂的网络请求逻辑，从而大大降低了Controller的复杂度。这里需要强调的是，ViewModel具有独立性，它并不关心UI的业务逻辑，也不持有任何UI对象，只关心自己的数据处理逻辑是否正确。很多初学者不清楚ViewModel的用法，往往会错误地将UI对象当作ViewModel的属性或者将UI对象的操作放入ViewModel的方法中，这些做法都是不正确的，没有正真理解MVVM的含义。尽管MVVM带来了很多好处，降低了代码的耦合度和复杂度，但它往往要写更多的代码来实现一个功能，同时还增加了工程的规模，使得工程中的目录比以前要稍多一些，不易查找文件。MVVM并不是iOS开发中的“银弹”，没有那种方法能完全解决软件开发中的问题，但相对于MVC来说，MVVM无疑是一个更好的选择。

8.

MVVM设计模式能够减少总体的代码量吗?能够在开发中代替MVC设计模式吗?正确答案：事实上，MVVM设计模式在实际使用中，虽然能够将诸多非业务逻辑从Controller中抽离，减少了代码的复杂性，但是总体的代码量不会减少，甚至会有些许增加。

MVVM设计模式作为一种新颖的编程框架，能够帮助开发者解决一些旧编程框架带来的问题，但是也会带来一些新问题。例如：

1)MVVM将Model通过ViewModel与View绑定使得bug很难被调试。你看到界面异常了，有可能是你View的代码有bug，也可能是Model的代码有问题。数据绑定使得一个位置的bug被快速传递到别的位置，要定位原始出问题的地方就变得不那么容易了。

2)对于过大的项目，数据绑定需要花费更多的内存。某种意义上来说，数据绑定使得MVVM设计模式变得复杂和难用了。

综上所述，在iOS应用程序开发过程中，MVC设计模式和MVVM设计模式都有适合自己的应用场景，应该根据具体的业务需要，客观评估项目的具体情况，既不能守旧，又不能盲目追赶新技术，这样才能应对技术的变化。

9.

MVVM设计模式中如何实现数据绑定?正确答案：MVVM设计模式的核心是、ViewModel，当ViewModel发生变化时需要及时通知View更新(即Updates)，这就需要将ViewModel和View进行数据绑定。目前在iOS开发中较为常用的是以下两种方式：

1)使用KVO(Key-Value-Observer)的绑定机制，在轻量级的开发中，它能够很好地将Objective-C与Cocoa结合起来，不需要借用第三方的类库进行数据绑定。

2)除了使用KVO，业界通常还采用ReactiveCocoa作为绑定机制。ReactiveCocoa是函数响应式编程(FRP)在iOS中的一个实现框架，后文会详细介绍其用法。

10.

SDWebImage是什么?加载图片的原理是什么?正确答案：SDWebImage是一个针对图片加载的插件库，提供了一个支持缓存的用于异步加载图片的下载工具，特别为常用的UI元素：UIImageView、UIButton和MKAnnotationView提供了类别扩展，可以作为一个很方便的工具。其中，SDWebImagePrefetcher可以预先下载图片，方便后续使用。

SDWebImage的几点特性：

1)为UIImageView、UIButton和MKAnnotationView进行了类别扩展，添加了Web图片和缓存管理。

2)是一个异步图片下载器。

3)异步的内存+硬盘二级缓冲以及自动的缓冲过期处理。

4)后台图片解压缩功能。

5)可以保证相同的URL(图片的检索key)不会被重复多次下载。

6)可以保证假的无效URL不会不断尝试去加载。

7)保证主线程不会被阻塞。

8)性能高。

9)使用GCD和ARC。

支持的图片格式：

1)UIImage支持的图片格式有JPEG、PNG等，包括GIF都可以被支持。

2)Web图片格式，包括动态的Web图片(使用WebPsubspec)。

使用方法示例：

SDWebImage的使用非常简单，开发中需要的主要就是为一个UIImageView添加在线图片，用到的方法主要就是sd_setImageWithURL方法(新版本方法名都加了sd前缀)。sd_setImageWithURL方法提供了几种重载方法，包括只使用图片URL参数的，以及设置占位图片placeholderImage参数的等，这个方法也是框架封装的最顶层的应用方法，开发中实际主要就用这个方法。以这个方法为入口，可以层层打开往底层看，可以对应到SDWebImage的整个加载逻辑和流程。

/*bjective-C:*/

#import＜SDWebImage/UIImageView+WebCache.h＞

/*使用SDWebImage框架为UIImageView加载在线图片*/

[imageViewsd_setImageWithURL:[NSURLURLWithString:@"http://www.***.com/***/image.jpg"]

placeholderImage:[UIImageimageNamed:@"placeholder.png"]];

/*Swift:*/

imageView.sd_setImageWithURL(NSURL(string:"http://www.***.com/***/image.jpg"),placeholderImage:UIImage(imageNamed:"placeholder.png"))

SDWebImage加载图片的流程原理：

SDWebImage异步加载图片的使用非常简单，一个方法调用即可完成，但实际上这个方法的调用会使得框架立刻完成一系列的逻辑处理，以最高效的方式加载需要的图片。具体加载流程逻辑如图所示。

SDWebImage异步加载图片流程逻辑图

根据流程可以知道，图片的加载采用了一种二级缓存机制，简单概括意思就是：能从内存缓存直接取就从内存缓存取，内存缓存没有就去硬盘缓存里取，再没有就根据提供的URL到网上下载(下载自然会慢很多)，下载的图片还有一个解码的过程，解码后就可以直接用了，另外下载的图片会保存到内存缓存和硬盘缓存，从而下次再取同样的图片就可以直接取了而不用重复下载。

上面的整个流程对应到SDWebImage框架内部，依次会挖掘出下面几个关键方法。最外层的是程序员直接调用的sd_setImageWithURL方法，以此方法为入口依次可能会调用到后面的方法，来完成上面的整个优化加载流程，这里以其中一个入口方法为例：

(1)sd_setImageWithURL

UIImageView(WebCache)的sdsetImageWithURL方法只是个UIView的类扩展接口方法，负责调用并将参数传给UIView(WebCache)的sdintemalSetImageWithWRL方法，参数这里有图片的URL和placeholder占位图片。

(2)sd_internalSetImageWithURL

UIView(WebCache)的sd_internalSetImageWithURL方法先将placeholder占位图片异步显示，然后给SDWebImageManager单例发送loadImageWithURL消息，传给它URL参数让其再给它的SDImageCache对象发送queryCacheOperationForKey消息先从本地搜索缓存图片。

(3)loadImageWithURL

收到loadImageWithURL消息后，SDWebImageManager单例向SDImageCache对象发送queryCacheOperationForKey消息开始在本地搜索缓存图片，SDImageCache对象先对自己发送imageFromMemoryCacheForKey消息从内存中搜索图片缓存，搜到则取出图片并通过SDCacheQueryCompletedBlock回调返回，否则再对自己发送diskImageForKey消息去硬盘搜索图片，搜到则取出图片通过SDCacheQueryCompletedBlock回调返回，内存和硬盘都搜不到则只好重新下载。

(4)downloadImageWithURL

如果本地搜索失败，那么SDWebImageManager会新建一个SDWebImageDownloader下载器，并向下载器发送downloadImageWithURL消息开始下载网络图片；下载成功并解码后一方面将图片缓存到本地，另一方面取出图片进行显示。其中，像图片下载以及图片解码等耗时操作都是异步执行，不会拖慢主线程。

SDImageCache在初始化的时候会注册一些消息通知，在内存警告或退到后台的时候会清理内存图片缓存，应用结束的时候会清理掉过期的图片。

11.

SDWebImage在iOS93DTouch下出现什么问题?正确答案：1)iOS9使用SDWebImage加载图片时，在SDWebImageDownloaderOperation.m文件内有操作可能会在后台线程中更新UI，可能导致意想不到的结果甚至程序崩溃。因此，在想更新UI时一定要保证将UI更新操作同步到主线程。UI更新同步到主线程有3种方法，推荐使用GCD来实现，代码形式如下：

dispatch_async(dispatch_get_main_queue(),^{

/*这里写更新UI操作*/

/*写完UI更新操作要根据需要重新布局layout*/

});

2)iOS9考虑到HTTP的不安全性，系统要求所有的网络请求都使用HTTPS，因此之前的HTTP请求会失效报错，可以通过设置允许继续使用HTTP解决，具体在工程的info.plist配置文件中添加如图所示配置即可(添加AppTransportSecuritySettings配置字段在将其下的AllowArbitaryLoads的值改为YES)。

配置info.plist字段

12.

SDWebImage框架内部在清理磁盘缓存的时候clearDisk方法和cleanDisk方法有什么区别?正确答案：clearDisk方法清空磁盘缓存，删除缓存目录中的所有文件，然后创建一个新的同名空文件。

cleanDisk方法按照磁盘清理缓存策略清理缓存，没有直接将所有缓存删除，而是先遍历缓存文件并删除已经过期的文件，如果剩余缓存空间超出了限额，那么按照文件创建的时间从远到近依次删除，清理到低于期望的缓存限额为止。SDWebImage中的期望缓存限额为最大限额的一半。

13.

SDWebImage框架的框架结构是怎么样的?正确答案：SDWebImage框架的3个核心组件。

1)SDWebImageManager：核心管理器。

2)SDImageCache：缓存处理组件，主要对下载的图片进行内存缓存和磁盘缓存处理。

3)SDWebImageDownloader|SDWebImageDownloadOperation：下载处理组件，主要负责在子线程中发送异步网络请求下载图片以及其他相关操作。

14.

网络图片处理问题中怎么解决一个相同的网络地址重复请求的问题?正确答案：可以通过建立一个以图片下载地址为key，以下载操作为value的字典，图片地址是唯一的，可以保证key值唯一。当需要加载该图片时，先根据key值去本地缓存中找，看该图片是否已经下载，如果key值匹配，那么直接从本地取图片资源从而避免重复下载操作，如果本地找不到，那么需要根据key值中的网络图片地址重新去网络上下载。

15.

什么是CocoaPods?正确答案：1.CocoaPods的介绍

在iOS开发的过程中，为了避免重复开发，往往会在项目中导入许多优秀的开源工具，如网络框架AFNetworking、异步加载图片框架SDWebImage、下拉刷新框架MJRefresh等。添加框架最原始的方法就是将框架下载，然后手动拖动框架到自己的项目中再使用。这样会带来许多问题，例如：框架更新后需要重新下载再拖进项目，框架之间代码集成难度大很难解决框架之间的依赖问题，每次运行都必须重新编译导入的框架浪费时间等。为了解决iOS第三方框架的管理的问题，提高开发效率，因此诞生了CocoaPods。CocoaPods(官网指南：,git:/CocoaPods/CocoaPods)是iOS上开源的依赖管理工具(DependencyManagerTool)或叫第三方框架管理工具，用来高效地管理iOS项目上的第三方框架。如果学习过Java语言，那么CocoaPods就和Java语言中Maven的功能类似；如果是Python，那么它就和pip的功能类似；如果是Nodejs，那么它就和npm功能类似。

2.CocoaPods的原理

CocoaPods的原理就是将所有的依赖库都放到一个名为Pods的项目中，然后让主项目依赖这个Pods项目，这样就分离第三方依赖和主项目之间的依赖关系，所有第三方依赖都由Pods项目管理。Pods项目最终会被编译为一个libPods.a的文件，主项目中引用这个libPods文件就能使用所有的第三方框架。

3.为什么要使用CocoaPods

当我们需要使用第三方框架的时候，使用CocoaPods能够快速地将开源框架的代码集成到项目中，并自动添加动态库和依赖框架，设置预编译-ObjC，fno-objc-arc等，从而实现第三方框架的使用和更新管理。

4.CocoaPods的核心组件

(1)Podfile

配置文件，将需要用到的第三方框架写入到这个文件中，并根据项目的需要标注好版本号。

(2)Podfile.lock

版本控制文件，里面记录了每个第三方框架的版本，防止项目中不同成员使用的第三方框架的版本号不一致。

(3).xcworkspace

工程的入口文件。

(4)Pods

里面存放了所有使用到的第三方框架。

16.

CocoaPods是什么?工作原理是什么?正确答案：CocoaPods是用来管理iOS项目中第三方框架的工具，主要是通过建立Podfile文件，在文件中指定项目中需要的第三方框架，然后使用podinstall安装框架。

其主要原理是：Pods项目中的第三方框架最终会编译成一个名为libPods.a的文件，主项目依赖这个.a文件即可；对于资源文件，CocoaPods提供了一个名为Pods-resources.sh的bash脚本，该脚本在每次项目编译的时候都会执行，将第三方的各种资源文件复制到目标目录中；CocoaPods通过一个名为Pods.xcconfig的文件在编译时设置所有的依赖和参数。

17.

BAD_ACCESS在什么情况下出现?正确答案：BAD_ACCESS报错属于内存访问错误，它会导致程序崩溃，而错误的原因是访问了野指针(悬挂指针)。野指针指本来指针指向的对象已经释放了，但指向该对象的指针没有置nil，指针指向随机的未知的内存，程序还以为该指针指向日标对象，导致存在一些潜在的危险访问操作，这些危险访问操作无法被指针指向的未知内存所处理，就会导致BAD_ACCESS错误造成程序崩溃。访问的含义包括多种情况，如向野指针发送消息，读写野指针本来指向的对象的成员变量等。

18.

如何调试BAD_ACCESS错误?正确答案：调试BAD_ACCESS错误是比较困难的事情，BAD_ACCESS错误是由于访问了野指针，但程序不会在野指针出现时或者在访问野指针的代码处报错，这就导致对其难以察觉。调试BAD_ACCESS错误的思路如下。

1.开启僵尸对象诊断

开启僵尸对象诊断，利用僵尸对象来对野指针的出现位置提供线索。僵尸对象指的是引用计数为0被系统回收的对象，但这些对象暂时还存在内存中，且理论上还是可以使用的，但是不稳定。开启僵尸对象诊断后，僵尸对象会暂时保持活跃用于调试，野指针在对象回收后依然指向该僵尸对象，访问野指针也就是访问僵尸对象的情况下可以被编辑器检测出来。这个时候还是会报BAD_ACCESS错误，但是后台会打印出该线索，例如下面的访问野指针打印的后台信息：

2017-03-1216:28:31.501Debug[2371:1379247]-[TestViewControllerrespondsToSelector:]messagesenttodeallocatedinstance0x16749682

可以看出消息发送给了一个僵尸对象，僵尸对象原本是TestViewController的一个实例，但现在该对象被回收了而开发者还试图访问它，由此可以很容易定位问题所在。

另外，开启僵尸对象诊