1、copy 和 mutableCopy介绍和用法
copy （是NSCopying协议的方法）
"Returns the object returned by copyWithZone:"
翻译：返回的对象是通过调用 copyWithZone: 这个方法返回的。
2、为什么block使用copy
block是一个对象, 所以block理论上是可以retain/release的.但是block在创建的时候它的内存是默认是分配在栈(stack)上, 而不是堆(heap)上的. 所以它的作用域仅限创建时候的当前上下文(函数, 方法...), 当你在该作用域外调用该block时, 程序就会崩溃.
其实block使用copy是MRC时代留下来的传统。 在MRC下, 在方法中的block创建在栈区, 使用copy就能把他放到堆区, 这样在作用域外调用该block程序就不会崩溃.但在ARC下, 使用copy与strong其实都一样,因为block的retain就是用copy来实现的。之所以大家都习惯用copy就是MRC时代留下的习惯。
3、id和NSObject ,instancetype的区别？
4、 GCD 对比 NSOprationQueue
我们要明确NSOperationQueue与GCD之间的关系
GCD是面向底层的C语言的API，NSOpertaionQueue用GCD构建封装的，是GCD的高级抽象。
1、GCD执行效率更高，而且由于队列中执行的是由block构成的任务，这是一个轻量级的数据结构，写起来更方便
2、GCD只支持FIFO的队列，而NSOperationQueue可以通过设置最大并发数，设置优先级，添加依赖关系等调整执行顺序
3、NSOperationQueue甚至可以跨队列设置依赖关系，但是GCD只能通过设置串行队列，或者在队列内添加barrier(dispatch_barrier_async)任务，才能控制执行顺序,较为复杂
4、NSOperationQueue因为面向对象，所以支持KVO，可以监测operation是否正在执行（isExecuted）、是否结束（isFinished）、是否取消（isCanceld）
实际项目开发中，很多时候只是会用到异步操作，不会有特别复杂的线程关系管理，所以苹果推崇的且优化完善、运行快速的GCD是首选
如果考虑异步操作之间的事务性，顺序行，依赖关系，比如多线程并发下载，GCD需要自己写更多的代码来实现，而NSOperationQueue已经内建了这些支持
不论是GCD还是NSOperationQueue，我们接触的都是任务和队列，都没有直接接触到线程，事实上线程管理也的确不需要我们操心，系统对于线程的创建，调度管理和释放都做得很好。而NSThread需要我们自己去管理线程的生命周期，还要考虑线程同步、加锁问题，造成一些性能上的开销
5、 MVC 、MVVM
ViewModel：是把MVC里的controller的数据加载，加工功能分离出来
MVVM设计模式的优点
双向绑定技术，当Model变化时，View-Model会自动更新，View也会自动变化。很好的做到数据的一致性
由于控制器的功能大都移动到View上处理，大大的对控制器进行了瘦身
-
View的功能进一步强化，具有控制的部分功能，
若想无限增强它的功能，甚至控制器的全部功能几乎都可以迁移到各个View上
（不过这样不可取，那样View干不了属于它职责范围内的事情）。
View可以像控制器一样具有自己都View-Model
-
可以对View或ViewController的数据处理部分抽象出来一个函数处理model。
这样它们专职页面布局和页面跳转，它们必然更一步的简化。
MVVM设计模式的缺点
数据绑定也使得bug很难被调试。比如你看到页面异常了，有可能是你的View的代码有bug，也可能是你的model的代码有问题。数据绑定使得一个位置的Bug被快速传递到别的位置，要定位原始出问题的地方就变得不那么容易了。
数据双向绑定不利于代码重用。客户端开发最常用的是View，但是数据双向绑定技术，让你在一个View都绑定了一个model，不同的模块model都不同。那就不能简单重用view了
一个大的模块中model也会很大，虽然使用方便了也很容易保证数据的一致性，但是长期持有，不释放内存就造成话费更多的内存。
主要就是MVC中Controller演变成MVVM中的viewModel。
MVVM主要解决了MVC中大量的DOM操作使页面渲染性能降低，加载速度变慢，影响用户体验。
当和Model频繁发生变化，开发者需要主动更新到View。
iOS事件响应原理
代理和Block的区别
Https的SSL加密原理
ViewController生命周期
- init
- loadView
当view需要被展示而它却是nil时，viewController会调用该方法。
如果代码维护View的话需要重写此方法，使用xib维护View的话不用重写。
在这里会看它的子类是否有重写这个函数，如果重写了则调用子类的，否则就调用她自己的。注意，这个时候视图还是没有没加载进来的哦。
- viewDidLoad
执行完loadView后继续执行viewDidLoad，loadView时还没有view，而viewDidLoad时view已经创建好了。 - viewWillAppear
- viewDidApper
- viewWillDisappear
- viewDidDisappear
- viewDidUnload
当系统内存吃紧的时候会调用该方法，内存吃紧时，在iPhone OS 3.0之前didReceiveMemoryWarning是释放无用内存的唯一方式，但是OS 3.0及以后viewDidUnload方法是更好的方式。
在该方法中将所有IBOutlet（无论是property还是实例变量）置为nil（系统release view时已经将其release掉了）。
在该方法中释放其他与view有关的对象、其他在运行时创建（但非系统必须）的对象、在viewDidLoad中被创建的对象、缓存数据等。
一般认为viewDidUnload是viewDidLoad的镜像，因为当view被重新请求时，viewDidLoad还会重新被执行。 - dealloc
KVO 实现原理
KVO是基于runtime机制实现的，KVO运用了一个isa-swizzling技术.isa-swizzling就是类型混合指针机制, 将2个对象的isa指针互相调换, 就是俗称的黑魔法.
当某个类的属性对象第一次被观察时，系统就会在运行期动态地创建该类的一个派生类，在这个派生类中重写基类中任何被观察属性的setter 方法。派生类在被重写的setter方法内实现真正的通知机制
如果原类为Person，那么生成的派生类名为NSKVONotifying_Person
每个类对象中都有一个isa指针指向当前类，当一个类对象的第一次被观察，那么系统会偷偷将isa指针指向动态生成的派生类，从而在给被监控属性赋值时执行的是派生类的setter方法
键值观察通知依赖于NSObject 的两个方法: willChangeValueForKey: 和 didChangevlueForKey:；在一个被观察属性发生改变之前， willChangeValueForKey:一定会被调用，这就 会记录旧的值。而当改变发生后，didChangeValueForKey:会被调用，继而 observeValueForKey:ofObject:change:context: 也会被调用。
补充：的这套实现机制中苹果还偷偷重写了class方法，让我们误认为还是使用的当前类，从而达到隐藏生成的派生
KVO的基础是KVC，KVC主要通过isa来实现其内部查找定位的. 默认的实现方法由NSOject提供isa指针, 如其名称所指,(就是is a kind of的意思), 指向分发表对象的类. 该分发表实际上包含了指向实现类中的方法的指针, 和其它数据
