1堆和栈的区别
1.内存管理范围
只有oc对象需要进行内存管理
非oc对象类型比如基本数据类型不需要进行内存管理
2.内存管理本质
因为：Objective-C的对象在内存中是以堆的方式分配空间的,并且堆内存是由你释放的，就是release
OC对象存放于堆里面(堆内存要程序员手动回收)
非OC对象一般放在栈里面(栈内存会被系统自动回收)
堆里面的内存是动态分配的，所以也就需要程序员手动的去添加内存、回收内存
3.内存分配以及管理方式
- 按分配方式分
堆是动态分配和回收内存的，没有静态分配的堆
栈有两种分配方式：静态分配和动态分配
静态分配是系统编译器完成的，比如局部变量的分配
动态分配是有alloc函数进行分配的，但是栈的动态分配和堆是不同的，它的动态分配也由系统编译器进行释放，不需要程序员手动管理 - 按管理方式分
对于栈来讲，是由系统编译器自动管理，不需要程序员手动管理
对于堆来讲，释放工作由程序员手动管理，不及时回收容易产生内存泄露 - 堆：是大家共有的空间，分全局堆和局部堆。全局堆就是所有没有分配的空间，局部堆就是用户分配的空间。堆在操作系统对进程 初始化的时候分配，运行过程中也可以向系统要额外的堆，但是记得用完了要还给操作系统，要不然就是内存泄漏。堆里面一般 放的是静态数据，比如static的数据和字符串常量等，资源加载后一般也放在堆里面。一个进程的所有线程共有这些堆 ，所以对堆的操作要考虑同步和互斥的问题。程序里面编译后的数据段都是堆的一部分。
- 栈：是个线程独有的，保存其运行状态和局部自动变量的。栈在线程开始的时候初始化，每个线程的栈互相独立，因此 ，栈是 thread safe的。每个c++对象的数据成员也存在在栈中，每个函数都有自己的栈，栈被用来在函数之间传递参数。操作系统在切换线程的时候会自动的切换栈，就是切换ss/esp寄存器。栈空间不需要在高级语言里面显式的分配 和释放。
一句话总结就是 堆：由程序员分配和释放,如果不释放可能会引起内存泄漏 栈：由编译器自动分配和释放，一般存放参数值，局部变量
2.KVO和KVC
KVC，即是指 NSKeyValueCoding(键值编码),提供一种机制来间接访问对象的属性。KVC 就是基于KVO技术来实现的。
KVO，提供了一种观察者的机制，通过对某个对象的某个属性添加观察者，当该属性改变，就会调用"observeValueForKeyPath:"方法。
3.OC中创建线程的方法是什么?如果在主线程中执行代码， 方法是什么?如果想延时执行代码、方法是什么?
1、线程创建有三种方法：使用NSThread创建、使用GCD的dispatch、使用子类化的NSOperation,然后将其加入NSOperationQueue;
2、在主线程执行代码，方法是performSelectorOnMainThread:withObject:waitUntilDone:;
3、如果想延时执行代码可以用performSelector:onThread:withObject:waitUntilDone:；
4.指针与数组名的关系?
int arrayName[4] = {10, 20, 30, 40};
int *p = (int *)(&arrayName + 1);
NSLog(@"%d", (&arrayName - 1));
1.(&arrayName + 1)：&arrayName是数组的地址（等价于指向arrayName数组的指针）
2.增加 1 会往后移动16个字节，开始是4个字节的位置，移动后就是16个字节后面的位置（也就是目前位置是20个字节）
3.最后又赋值给，int类型的指针p（int类型占4个字节）
4.所以(p - 1)就是减去4个字节，变成为16个字节的位置，输出的(p - 1)值为40
int *p = (int *)(&arrayName + 1);
NSLog(@"%d", *(p - 1));//输出结果为 40
5.#import 和#include有 么区别?@class呢?#import <>和 #import"" 有 么区别?
import是OC导入头文件的关键字,#include是C/C++导入头文件的关键字
使用#import只导入一次不会重复导入,相当于#include和#pragma once;(使用#include可能会出现循环引用,使用#pragma once消除这种可能)
@class一般用于声明某个字符串作为类名使用,它只是声明了一个类名,没有导入.h文件中的内容,不会引起交叉编译问题
import< >代表导入系统自带的框架
import" "代表导入我们自己创建的文件,导入的使我们.h文件,也就是头文件
6.属性readwrite.readonly,assign,retain,copy,nonatomic 什么作用 ? 在哪种情况下 ?
readwrite 是可读可写特性；需要生成getter方法和setter方法时（补充：默认属性，将生成不带额外参数的getter和setter方法（setter方法只有一个参数））
readonly 是只读特性 只会生成getter方法 不会生成setter方法 ;不希望属性在类外改变
assign 是赋值特性，setter方法将传入参数赋值给实例变量；仅设置变量时；
retain 表示持有特性，setter方法将传入参数先保留，再赋值，传入参数的retaincount会+1;
copy 表示拷贝特性，setter方法将传入对象复制一份；需要完全一份新的变量时。
nonatomic 非原子操作，决定编译器生成的setter getter是否是原子操作，atomic表示多线程安全，一般使
用nonatomic
7.IBOutlet 连出来的视图属性为什么可以被设置成weak?
在 storyboard 中添加一个控件引用关系是这样的(以 UIbutton 为例): UIviewController -> UIview -> UIbutton
此时 UIviewController 强引用着 UIview , UIview 强引用着 UIbutton , IBoutlet 连线到控制器的. m 或者. h 中作为视图的属性时用 weak 修饰就可以了, (觉得用 strong 修饰也可以但是没有必要)
添加到子控件也是强引用: UIbutton 就是添加到了 UIviewController 的 view 上
8 预处 指令define 声明 个常数， 以表明 中有多 少秒(忽 闰 问题)。
define SECONDS_PER_YEAR (60 * 60 * 24 * 365)UL
9.重写-个NSString类型的，retain 式声明name属性的 setter和getter 法(MRC)
属性的三大特性:语义特性,原子特性,读写特性.
同时重写setter和getter方法,@synchronized name = _name,关联属性和实例变量
如 -(void)setName:(NSString *)name{
if(_name != name){
[_name retain];
[_name release];
_name = name;
}
}
-(NSString *)name{
return [[_name retain]autorelease]
}
10.分析json、xml 的区别? json、xml 解析 式的底层是如何让处理的
(一)JSON与XML的区别：
（1）可读性方面：基本相同，XML的可读性比较好；
（2）可扩展性方面：都具有良好的扩展性；
（3）编码难度方面：相对而言，JSON的编码比较容易；
（4）解码难度：JSON的解码难度基本为零，XML需要考虑子节点和父节点；
（5）数据体积方面：JSON相对于XML来讲，数据体积小，传递的速度比较快；
（6）数据交互方面：JSON与javascript的交互更加方便，更容易解析处理，更好的数据交互；
（7）数据描述方面：XML对数据描述性比较好
（8）传输速度方面：JSON的速度远远快于XML。
（二）JSON与XML底层实现原理：
（1）JSON底层原理：遍历字符串中的字符，最终根据格式规定的特殊字符，比如{}、[]、：等进行区分，{}号表示字典，[]号表示数组，：号是字典的键和值的分水岭，最终仍是将JSON转化为字典，只不过字典中的值可能是“字典、数组或者字符串而已”。
（2）XML底层原理：XML解析常用的解析方法有两种：DOM解析和SAX解析；DOM采用的是树形结构的方式访问XML文档，而SAX采用的是事件模型；DOM解析把XML文档转化为一个包含其内容的树，并可以对树进行遍历，使用DOM解析器的时候需要处理整个XML文档，所以对内存和性能的要求比较高；SAX在解析XML文档的时候可以触发一系列的事件，当发现给定的tag的时候，他可以激活一个回调方法，告诉该方法指定的标签已经找到，SAX对内存的要求通常会比较低，因为他让开发人员自己来决定所要处理的tag，特别是当开发人员只需要处理文档中所包含部分数据时，SAX这种扩展能力得到了更好的体现。
11.对程序性能的优化你有什么建议?
1.使用复用机制
2.尽可能设置 View 为不透明
3.避免臃肿的 XIB 文件
4.不要阻塞主线程
5.图片尺寸匹配 UIImageView
6.选择合适的容器
7.启用 GZIP 数据压缩
8.View 的复用和懒加载机制
9、缓存
服务器的响应信息（response）。
图片。
计算值。比如：UITableView 的 row heights。
10.关于图形绘制
11.处理 Memory Warnings
在 AppDelegate 中实现 - [AppDelegate applicationDidReceiveMemoryWarning:] 代理方法。
在 UIViewController 中重载 didReceiveMemoryWarning 方法。
监听 UIApplicationDidReceiveMemoryWarningNotification 通知。
12.复用高开销的对象
13.减少离屏渲染(设置圆角和阴影的时候可以选用绘制的方法)
14.优化 UITableView
通过正确的设置 reuseIdentifier 来重用 Cell。
尽量减少不必要的透明 View。
尽量避免渐变效果、图片拉伸和离屏渲染。
当不同的行的高度不一样时，尽量缓存它们的高度值。
如果 Cell 展示的内容来自网络，确保用异步加载的方式来获取数据，并且缓存服务器的 response。
使用 shadowPath 来设置阴影效果。
尽量减少 subview 的数量，对于 subview 较多并且样式多变的 Cell，可以考虑用异步绘制或重写 drawRect。
尽量优化 - [UITableView tableView:cellForRowAtIndexPath:] 方法中的处理逻辑，如果确实要做一些处理，可以考虑做一次，缓存结果。
选择合适的数据结构来承载数据，不同的数据结构对不同操作的开销是存在差异的。
对于 rowHeight、sectionFooterHeight、sectionHeaderHeight 尽量使用常量。
15.选择合适的数据存储方式
在 iOS 中可以用来进行数据持有化的方案包括：
NSUserDefaults。只适合用来存小数据。
XML、JSON、Plist 等文件。JSON 和 XML 文件的差异在「选择正确的数据格式」已经说过了。
使用 NSCoding 来存档。NSCoding 同样是对文件进行读写，所以它也会面临必须加载整个文件才能继续的问题。
使用 SQLite 数据库。可以配合 FMDB 使用。数据的相对文件来说还是好处很多的，比如可以按需取数据、不用暴力查找等等。
使用 CoreData。也是数据库技术，跟 SQLite 的性能差异比较小。但是 CoreData 是一个对象图谱模型，显得更面向对象；SQLite 就是常规的 DBMS。
16.减少应用启动时间
快速启动应用对于用户来说可以留下很好的印象。尤其是第一次使用时。
保证应用快速启动的指导原则：
尽量将启动过程中的处理分拆成各个异步处理流，比如：网络请求、数据库访问、数据解析等等。
避免臃肿的 XIB 文件，因为它们会在你的主线程中进行加载。重申：Storyboard 没这个问题，放心使用。
注意：在测试程序启动性能的时候，最好用与 Xcode 断开连接的设备进行测试。因为 watchdog 在使用 Xcode 进行调试的时候是不会启动的。
17.使用 Autorelease Pool （内存释放池）
18.imageNamed 和 imageWithContentsOfFile
12.runloop 和线程有什么关系?
runloop与线程是一一对应的，一个runloop对应一个核心的线程，为什么说是核心的，是因为runloop是可以嵌套的，但是核心的只能有一个，他们的关系保存在一个全局的字典里。
runloop是来管理线程的，当线程的runloop被开启后，线程会在执行完任务后进入休眠状态，有了任务就会被唤醒去执行任务。
runloop在第一次获取时被创建，在线程结束时被销毁。
对于主线程来说，runloop在程序一启动就默认创建好了。
对于子线程来说，runloop是懒加载的，只有当我们使用的时候才会创建，所以在子线程用定时器要注意：确保子线程的runloop被创建，不然定时器不会回调。
13 介绍下layoutSubview和drawRect
layoutSubviews调用情况
init初始化UIView不会触发调用
addSubview会触发调用
改变view的width和height的时候回触发调用
一个UIScrollView滚动会触发调用
旋转screen会触发调用
改变一个UIView大小的时候会触发superView的layoutSubviews事件
直接调用setLayoutSubviews会触发调用
-(void)viewWillAppear:(BOOL)animated会触发一次调用
-(void)viewDidAppear:(BOOL)animated 看情况，可能有调用
drawRect调用情况
如果UIView没有设置frame大小，直接导致drawRect不能被自动调用。
drawRect在loadView和viewDidLoad这两个方法之后调用
调用sizeToFit后自动调用drawRect
通过设置contentMode值为UIViewContentModeRedraw。那么每次设置或者更改frame自动调用drawRect。
直接调用setNeedsDisplay或者setNeedsDisplayInRect会触发调用
14.写个“标准“宏MIN，这个宏输两个参数并返回较小的那个
MIN(A,B) ((A) <= (B) ? (A) : (B))
15.类别有什么作用
1.扩展已有的类（添加方法）
2.可以通过runtime添加属性
16.什么是method swizzing?讲 讲你的使 场景以及使 时的注意事项
1.给扩展添加属性
2.替换系统方法的的实现
17..讲讲iOS事件响应链的原理
1、响应者链通常是由视图（UIView）构成的；
2、一个视图的下一个响应者是它视图控制器（UIViewController）（如果有的话），然后再转给它的父视图（Super View）；
3、视图控制器（如果有的话）的下一个响应者为其管理的视图的父视图；
4、单例的窗口（UIWindow）的内容视图将指向窗口本身作为它的下一个响应者
需要指出的是，Cocoa Touch应用不像Cocoa应用，它只有一个UIWindow对象，因此整个响应者链要简单一点；
5、单例的应用（UIApplication）是一个响应者链的终点，它的下一个响应者指向nil，以结束整个循环。
18.你在什么场景下会选择使 Category
1.扩展已有的类（添加方法）
19.UIview 和CAlayer 是什么关系? 你 CLayer做过什么?
首先UIView可以响应事件，Layer不可以.
UIView是CALayer的delegate 3. UIView主要处理事件，CALayer负责绘制就更好 4. 每个 UIView 内部都有一个 CALayer 在背后提供内容的绘制和显示，并且 UIView 的尺寸样式都由内部的 Layer 所提供。两者都有树状层级结构，layer 内部有 SubLayers，View 内部有 SubViews.但是 Layer 比 View 多了个AnchorPoint
创建隐式动画 绘制边框圆角
20.如何处理UITableVier 中Cell 动态计算高度的问题，都有哪些方案?
1、你的Cell要使用AutoLayout来布局约束这是必须的；
设置tableview的estimatedRowHeight为一个非零值，这个属性是设置一个预估的高度值，不用太精确。
设置tableview的rowHeight属性为UITableViewAutomaticDimension
2.第三方 UITableView+FDTemplateLayoutCell
21.AutoLayout 中的优先级是什么? UIScrollView 中使用Autolayout 会出现什么问题?
代码计算frame -> autoreszing(父控件和子控件的关系) -> autolayout(任何控件都可以产生关系) -> sizeclass
可以设置两个看似有冲突的约束，但设置不同的优先级之后就不会有冲突了，当其中一个约束失效之后，另一个优先级比较低的约束就会起作用
22.NSURLConnection 和NSURLSession 的区别是 么? NSURLProtocol是做什么的?
1.下载
NSURLConnection下载文件时，先是将整个文件下载到内存，然后再写入到沙盒，如果文件比较大，就会出现内存暴涨的情况。
而使用NSURLSessionUploadTask下载文件，会默认下载到沙盒中的tem文件中，不会出现内存暴涨的情况，但是在下载完成后会把tem中的临时文件删除，需要在初始化任务方法时，在completionHandler回调中增加保存文件的代码
2.请求方法的控制
NSURLConnection实例化对象，实例化开始，默认请求就发送(同步发送),不需要调用start方法。而cancel可以停止请求的发送，停止后不能继续访问，需要创建新的请求。
NSURLSession有三个控制方法，取消(cancel)、暂停(suspend)、继续(resume)，暂停以后可以通过继续恢复当前的请求任务。
使用NSURLSession进行断点下载更加便捷.
NSURLSession的构造方法（sessionWithConfiguration:delegate:delegateQueue）中有一个NSURLSessionConfiguration类的参数可以设置配置信息，其决定了cookie，安全和高速缓存策略，最大主机连接数，资源管理，网络超时等配置。NSURLConnection不能进行这个配置，相比较与NSURLConnection依赖与一个全局的配置对象，缺乏灵活性而言，NSURLSession有很大的改进
23.怎么高效的实现控件的圆角效果
绘制圆角
-(UIImageView *)roundedRectImageViewWithCornerRadius:(CGFloat)cornerRadius {
UIBezierPath *bezierPath = [UIBezierPath bezierPathWithRoundedRect:self.bounds cornerRadius:cornerRadius];
CAShapeLayer *layer = [CAShapeLayer layer];
layer.path = bezierPath.CGPath;
self.layer.mask = layer;
return self;
}
24.说说你了解weak属性?
weak关键字在OC中属于比较基础的知识此特性表明该属性定义了一种关系“非拥有关系”（nonowning relationship）。为这种属性设置新值得时，设置方法既不保留新值，也不释放旧值。此特性同assign类似，然后在属性所指的对象遭到摧毁时，属性值也会清空（nil out）。
弱引用，不决定对象的存亡。即使一个对象被持有无数个弱引用，只要没有强引用指向它，那么还是会被清除。
25.假如Controller太臃肿，如何优化?
1.将网络请求抽象到单独的类中
方便在基类中处理公共逻辑；
方便在基类中处理缓存逻辑，以及其它一些公共逻辑；
方便做对象的持久化。
2.将界面的封装抽象到专门的类中
构造专门的 UIView 的子类，来负责这些控件的拼装。这是最彻底和优雅的方式，不过稍微麻烦一些的是，你需要把这些控件的事件回调先接管，再都一一暴露回 Controller。
3.构造 ViewModel
借鉴MVVM。具体做法就是将 ViewController 给 View 传递数据这个过程，抽象成构造 ViewModel 的过程。
4.专门构造存储类
专门来处理本地数据的存取。
5.整合常量
26.项目中网络层如何做安全处理?
1.判断API的调用请求是否来自于经过授权的APP。如若不是则拒绝请求访问
2.在数据请求的过程中进行URL加密处理：防止反编译，接口信息被静态分析。
3.数据传输加密：对客户端传输数据提供有效的加密方案，以防止网络接口的拦截。
如果可以尽量使用HTTPS，可以有效的避免接口数据在传输中被攻击。
27.main()之前的过程有哪些?
在ios中
在iOS中 main.m 是我们所熟悉的程序入口。但是在在此之前其实程序以及做了很多事了。如系统会获取dyld的路径，并加载。加载程序中的依赖库。调用所有的+ load方法，并返回main函数地址。
28.使用了第三方库, 有看他们是怎么实现的吗？
例：SD、YY、AFN、MJ等！
<1>.SD为例：
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 可以预先下载图片，
方便后续使用。
29.遇到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.使用正确的数据结构来存储数据。
30.M、V、C相互通讯规则你知道的有哪些？
MVC 是一种设计思想，一种框架模式，是一种把应用中所有类组织起来的策略，它把你的程序分为三块，分别是：
M（Model）：实际上考虑的是“什么”问题，你的程序本质上是什么，独立于 UI 工作。是程序中用于处理应用程序逻辑的部分，通常负责存取数据。
C（Controller）：控制你 Model 如何呈现在屏幕上，当它需要数据的时候就告诉 Model，你帮我获取某某数据；当它需要 UI 展示和更新的时候就告诉 View，你帮我生成一个 UI 显示某某数据，是 Model 和 View 沟通的桥梁。
V（View）：Controller 的手下，是 Controller 要使用的类，用于构建视图，通常是根据 Model 来创建视图的。
要了解 MVC 如何工作，首先需要了解这三个模块间如何通信。
MVC通信规则
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 知道的太多，因此要通过间接的方式通信。
Target
action。首先 Controller 会给自己留一个 target，再把配套的 action 交给 View 作为联系方式。那么 View
接收到某些变化时，View 就会发送 action 给 target 从而达到通知的目的。这里 View 只需要发送
action，并不需要知道 Controller 如何去执行方法。
代理。有时候 View 没有足够的逻辑去判断用户操作是否符合规范，他会把判断这些问题的权力委托给其他对象，他只需获得答案就行了，并不会管是谁给的答案。
DataSoure。View 没有拥有他们所显示数据的权力，View 只能向 Controller 请求数据进行显示，Controller 则获取 Model 的数据整理排版后提供给 View。
Model 访问 Controller
同样的 Model 是独立于 UI 存在的，因此无法直接与 Controller 通信，但是当 Model 本身信息发生了改变的时候，会通过下面的方式进行间接通信。
Notification & KVO一种类似电台的方法，Model 信息改变时会广播消息给感兴趣的人 ，只要 Controller 接收到了这个广播的时候就会主动联系 Model，获取新的数据并提供给 View。
从上面的简单介绍中我们来简单概括一下 MVC 模式的优点。
1.低耦合性
2.有利于开发分工
3.有利于组件重用
4.可维护性
31.NStimer准吗？谈谈你的看法？如果不准该怎样实现一个精确的NSTimer?
1.不准
2.不准的原因如下：
1、NSTimer加在main runloop中，模式是NSDefaultRunLoopMode，main负责所有主线程事件，例如UI界面的操作，复杂的运算，这样在同一个runloop中timer就会产生阻塞。
2、模式的改变。主线程的 RunLoop 里有两个预置的 Mode：kCFRunLoopDefaultMode 和 UITrackingRunLoopMode。
当你创建一个 Timer 并加到 DefaultMode 时，Timer 会得到重复回调，但此时滑动一个ScrollView时，RunLoop 会将 mode 切换为 TrackingRunLoopMode，这时 Timer 就不会被回调，并且也不会影响到滑动操作。所以就会影响到NSTimer不准的情况。
PS:DefaultMode 是 App 平时所处的状态，rackingRunLoopMode 是追踪 ScrollView 滑动时的状态。
方法一：
1、在主线程中进行NSTimer操作，但是将NSTimer实例加到main runloop的特定mode（模式）中。避免被复杂运算操作或者UI界面刷新所干扰。
self.timer = [NSTimer timerWithTimeInterval:1 target:self selector:@selector(showTime) userInfo:nil repeats:YES];
[[NSRunLoop currentRunLoop] addTimer:self.timer forMode:NSRunLoopCommonModes];
2、在子线程中进行NSTimer的操作，再在主线程中修改UI界面显示操作结果；
- (void)timerMethod2 {
NSThread *thread = [[NSThread alloc] initWithTarget:self selector:@selector(newThread) object:nil];
[thread start];
}
- (void)newThread
{
@autoreleasepool
{
[NSTimer scheduledTimerWithTimeInterval:1.0 target:self selector:@selector(showTime) userInfo:nil repeats:YES];
[[NSRunLoop currentRunLoop] run];
}
}
总结：
一开始的时候系统就为我们将主线程的main runloop隐式的启动了。
在创建线程的时候，可以主动获取当前线程的runloop。每个子线程对应一个runloop
方法二：使用示例
使用mach内核级的函数可以使用mach_absolute_time()获取到CPU的tickcount的计数值，
可以通过”mach_timebase_info”函数获取到纳秒级的精确度 。
然后使用mach_wait_until(uint64_t deadline)函数，直到指定的时间之后，就可以执行指定任务了。
关于数据结构mach_timebase_info的定义如下：
struct mach_timebase_info {uint32_t numer;uint32_t denom;};
#include
#include
static const uint64_t NANOS_PER_USEC = 1000ULL;
static const uint64_t NANOS_PER_MILLISEC = 1000ULL * NANOS_PER_USEC;
static const uint64_t NANOS_PER_SEC = 1000ULL * NANOS_PER_MILLISEC;
static mach_timebase_info_data_t timebase_info;
static uint64_t nanos_to_abs(uint64_t nanos) {
return nanos * timebase_info.denom / timebase_info.numer;
}
void example_mach_wait_until(int seconds)
{
mach_timebase_info(&timebase_info);
uint64_t time_to_wait = nanos_to_abs(seconds * NANOS_PER_SEC);
uint64_t now = mach_absolute_time();
mach_wait_until(now + time_to_wait);
}
32.多线程有哪几种？你更倾向于哪一种？
WeChat7d5b6317cd34a3bd430b22a64f32b769.png
第一种：pthread
.特点：
1）一套通用的多线程API
2）适用于Unix\Linux\Windows等系统
3）跨平台\可移植
4）使用难度大
b.使用语言：c语言
c.使用频率：几乎不用
d.线程生命周期：由程序员进行管理
第二种：NSThread
a.特点：
1）使用更加面向对象
2）简单易用，可直接操作线程对象
b.使用语言：OC语言
c.使用频率：偶尔使用
d.线程生命周期：由程序员进行管理
第三种：GCD
a.特点：
1）旨在替代NSThread等线程技术
2）充分利用设备的多核（自动）
b.使用语言：C语言
c.使用频率：经常使用
d.线程生命周期：自动管理
第四种：NSOperation
a.特点：
1）基于GCD（底层是GCD）
2）比GCD多了一些更简单实用的功能
3）使用更加面向对象
b.使用语言：OC语言
c.使用频率：经常使用
d.线程生命周期：自动管理
多线程的原理
同一时间，CPU只能处理1条线程，只有1条线程在工作（执行）
多线程并发（同时）执行，其实是CPU快速地在多条线程之间调度（切换）
如果CPU调度线程的时间足够快，就造成了多线程并发执行的假象
思考：如果线程非常非常多，会发生什么情况？
CPU会在N多线程之间调度，CPU会累死，消耗大量的CPU资源
每条线程被调度执行的频次会降低（线程的执行效率降低）
多线程的优点
能适当提高程序的执行效率
能适当提高资源利用率（CPU、内存利用率）
多线程的缺点
开启线程需要占用一定的内存空间（默认情况下，主线程占用1M，子线程占用512KB），如果开启大量的线程，会占用大量的内存空间，降低程序的性能
线程越多，CPU在调度线程上的开销就越大
程序设计更加复杂：比如线程之间的通信、多线程的数据共享
你更倾向于哪一种？
倾向于GCD：
GCD 技术是一个轻量的，底层实现隐藏的神奇技术，我们能够通过GCD和block轻松实现多线程编程，有时候，GCD相比其他系统提供的多线程方法更加有效，当然，有时候GCD不是最佳选择，另一个多线程编程的技术 NSOprationQueue 让我们能够将后台线程以队列方式依序执行，并提供更多操作的入口，这和 GCD 的实现有些类似。
这种类似不是一个巧合，在早期，MacOX 与 iOS 的程序都普遍采用Operation Queue来进行编写后台线程代码，而之后出现的GCD技术大体是依照前者的原则来实现的，而随着GCD的普及，在iOS 4 与 MacOS X 10.6以后，Operation Queue的底层实现都是用GCD来实现的。
- 那这两者直接有什么区别呢？
- GCD是底层的C语言构成的API，而NSOperationQueue及相关对象是Objc的对象。在GCD中，在队列中执行的是由block构成的任务，这是一个轻量级的数据结构；而Operation作为一个对象，为我们提供了更多的选择；
- 在NSOperationQueue中，我们可以随时取消已经设定要准备执行的任务(当然，已经开始的任务就无法阻止了)，而GCD没法停止已经加入queue的block(其实是有的，但需要许多复杂的代码)；
- NSOperation能够方便地设置依赖关系，我们可以让一个Operation依赖于另一个Operation，这样的话尽管两个Operation处于同一个并行队列中，但前者会直到后者执行完毕后再执行；
- 我们能将KVO应用在NSOperation中，可以监听一个Operation是否完成或取消，这样子能比GCD更加有效地掌控我们执行的后台任务；
- 在NSOperation中，我们能够设置NSOperation的priority优先级，能够使同一个并行队列中的任务区分先后地执行，而在GCD中，我们只能区分不同任务队列的优先级，如果要区分block任务的优先级，也需要大量的复杂代码；
- 我们能够对NSOperation进行继承，在这之上添加成员变量与成员方法，提高整个代码的复用度，这比简单地将block任务排入执行队列更有自由度，能够在其之上添加更多自定制的功能。
- 总的来说，Operation queue 提供了更多你在编写多线程程序时需要的功能，并隐藏了许多线程调度，线程取消与线程优先级的复杂代码，为我们提供简单的API入口。从编程原则来说，一般我们需要尽可能的使用高等级、封装完美的API，在必须时才使用底层API。但是我认为当我们的需求能够以更简单的底层代码完成的时候，简洁的GCD或许是个更好的选择，而Operation queue 为我们提供能更多的选择。
- 倾向于：NSOperation
NSOperation相对于GCD：
1，NSOperation拥有更多的函数可用，具体查看api。NSOperationQueue 是在GCD基础上实现的，只不过是GCD更高一层的抽象。
2，在NSOperationQueue中，可以建立各个NSOperation之间的依赖关系。
3，NSOperationQueue支持KVO。可以监测operation是否正在执行（isExecuted）、是否结束（isFinished），是否取消（isCanceld）
4，GCD 只支持FIFO 的队列，而NSOperationQueue可以调整队列的执行顺序（通过调整权重）。NSOperationQueue可以方便的管理并发、NSOperation之间的优先级。
使用NSOperation的情况：各个操作之间有依赖关系、操作需要取消暂停、并发管理、控制操作之间优先级，限制同时能执行的线程数量.让线程在某时刻停止/继续等。
使用GCD的情况：一般的需求很简单的多线程操作，用GCD都可以了，简单高效。
从编程原则来说，一般我们需要尽可能的使用高等级、封装完美的API，在必须时才使用底层API。
当需求简单，简洁的GCD或许是个更好的选择，而Operation queue 为我们提供能更多的选择。
33.单例弊端？
优点：
1：一个类只被实例化一次，提供了对唯一实例的受控访问。
2：节省系统资源
3：允许可变数目的实例。
缺点：
1：一个类只有一个对象，可能造成责任过重，在一定程度上违背了“单一职责原则”。
2：由于单利模式中没有抽象层，因此单例类的扩展有很大的困难。
3：滥用单例将带来一些负面问题，如为了节省资源将数据库连接池对象设计为的单例类，可能会导致共享连接池对象的程序过多而出现连接池溢出；如果实例化的对象长时间不被利用，系统会认为是垃圾而被回收，这将导致对象状态的丢失。
网友评论