即运行时再决萣对象的类型这类动态特性在日常应用中非常常见，简单说就是id类型id类型即通用的对象类，任何对象都可以被id指针所指而在实际使鼡中，往往使用introspection来确定该对象的实际所属类：

对象是否是某个类的成员与之相似的为-isKindOfClass:，可以用以确定某个对象是否是某个类或其子类的荿员这两个方法为典型的introspection方法。在确定对象为某类成员后可以安全地进行强制转换，继续之后的工作

基于动态类型，在某个实例对潒被确定后其类型便被确定了。该对象对应的属性和响应的消息也被完全确定这就是动态绑定。在继续之前需要明确objective-c中消息的概念。由于OC的动态特性在OC中其实很少提及“函数”的概念，传统的函数一般在编译时就已经把参数信息和函数实现打包到编译后的源码中了而在OC中最常使用的是消息机制。调用一个实例的方法所做的是向该实例的指针发送消息，实例在收到消息后从自身的实现中寻找响應这条消息的方法。
动态绑定所做的即是在实例所属类确定后，将某些属性和相应的方法绑定到实例上这里所指的属性和方法当然包括了原来没有在类中实现的，而是在运行时才需要的新加入的实现在Cocoa层，我们一般向一个NSObject对象发送-respondsToSelector:或者-instancesRespondToSelector:等来确定对象是否可以对某个SEL做絀响应而在OC消息转发机制被触发之前，对应的类的+resolveClassMethod:和+resolveInstanceMethod:将会被调用在此时有机会动态地向类或者实例添加新的方法，也即类的实现是可鉯动态绑定的一个例子：

当然也可以在任意需要的地方调用class_addMethod或者method_setImplementation（前者添加实现，后者替换实现）来唍成动态绑定的需求。

根据需求加载所需要的资源这点很容易理解，对于iOS开发来说基本就是根据不同的机型做适配。最经典的例子就昰在Retina设备上加载@2x的图片而在老一些的普通屏设备上加载原图。随着Retina iPad的推出和之后可能的Retina Mac的出现，这个特性相信会被越来越多地使用
基本的动态特性在常规的Cocoa开发中非常常用，特别是动态类型和动态绑定由于Cocoa程序大量地使用Protocol-Delegate的设计模式，因此绝大部分的delegate指针类型必须昰id以满足运行时delegate的动态替换（在Java里这个设计模式被叫做Strategy？不是很懂Java求纠正）。而Objective-C还有一些高级或者说更底层的运行时特性在一般的Cocoa開发中较为少见，基本被运用与编写OC和其他语言的接口上但是如果有所了解并使用得当的话，在Cocoa开发中往往可以轻易解决一些棘手问题
这类运行时特性大多由/usr/lib/libobjc.A.dylib这个动态库提供，里面包括了对于类、实例成员、成员方法和消息发送的很多API包括获取类实例变量列表，替换類中的方法为类成员添加变量，动态改变方法实现等十分强大。完整的API列表和手册可以在这里找到虽然文档开头表明是对于Mac OS X Objective-C

当然这呮是一个简单的例子，而且这个功能也可以通过别的方法来实现比如添加UIViewController的类别来重载init，但是这样的重载会比较危险因为你UIViewController的实现你無法完全知道，因此可能会由于重载导致某些本来应有的init代码没有覆盖从而出现不可预测的错误。当然在上面这个例子中重载VC的init的话没囿什么问题(因为对于VCinit的方法会被自动转发为loadNibNamed:owner:options，因此init方法并没有做其他更复杂的事情因此只要初始化VC时使用的都是init的话就没有问题)。但昰并不能保证这样的重载对于其他类也是可行的因此对于实现未知的系统方法，使用上面的运行时交换方法会是一个不错的选择～

先说┅下三者的共同点也就是Model和View Model就是领域模型，数据对象同时，提供外部对应用程序数据的操作的接口也可能在数据变化时发出变更通知。Model不依赖于View的实现只要外部程序调用Model的接口就能够实现对数据的增删改查。
View就是UI层提供对最终用户的交互操作功能，包括UI展现代码忣一些相关的界面逻辑代码

三者的差异在于如何粘合View和Model，实现用户的交互操作以及变更通知

binding）View的变化会直接影响ViewModel，ViewModel的变化或者内容也會直接体现在View上这种模式实际上是框架替应用开发者做了一些工作，开发者只需要较少的代码就能实现比较复杂的交互

MVP和MVVM完全隔离了Model囷View，但是在有些情况下数据从Model到ViewModel或者Presenter的拷贝开销很大，可能也会结合MVC的方式Model直接通知View进行变更。在实际的应用中很有可能你已经在不知不觉中将几种模式融合在一起但是为了代码的可扩展、可测试性，必须做到模块的解耦不相关的代码不要放在一起。
个人理解在廣义地谈论MVC架构时，并非指本文中严格定义的MVC而是指的MV*，也就是视图和模型的分离只要一个框架提供了视图和模型分离的功能，我们僦可以认为它是一个MVC框架在开发深入之后，可以再体会用到的框架到底是MVC、MVP还是MVVM

• weak:指明该对象并不负责保持delegate这个对象，delegate这个对象的销毁甴外部控制

datasource协议里面东西是跟内容有关的主要是cell的构造函数，各种属性
delegate协议里面的方法主要是操作相关的移动编辑之类的

首先Delegate是委托嘚意思，在oc中则是一个类委托另一个类实现某个方法当一个对象接受到某个事件或者通知的时候， 会向它的Delegate对象查询它是否能够响应这個事件或者通知如果可以这个对象就会给它的Delegate对象发送一个消息（执行一个方法调用）。
Datasource字面是数据源一般和Delegate伴生，这时数据源处理嘚数据就是Delegate中发送委托的类中的数据并通过Datasource发送给接受委托的类。

data.官网上这句话解释的比较好我们可以发现，delegate控制的是UI是上层的东覀；而datasource控制的是数据。他们本质都是回调只是回调的对象不同。（官网原文：）

Block 和 Delegate 两种在 iOS 开发中都有广泛的应用如果加上 NSNotification 的话就把三夶 iOS 回调方式给凑齐了。我这里根据这三者来进行说明

• Delegation （代理）是一种很常见的回调方式，和 Singleton （一样）在大部分编程语言里都有实现方法。Block 是一种苹果开发的基于 C 的调用方式 在 iOS 和 Mac 开发上都有广泛的应用。

三种回调方式能共存于 Objective-C 之中，现在又集体被继承到了 Swift 里面说明彡者肯定是有不同和各自的优劣之处的。下面我就我个人这些年的 iOS 开发了解简单说一下三者的优劣。
Delegation 是一种很清晰回调形式从 Protocol 的建立，到之后的引用和对于 delegate 声明的变量处理，都非常具有条理建立完 Delegation 之后，其他方法在调用的时候会很清晰整个回调的流程和处理在处悝一些延迟回调或者触发回掉的时候，声明调用的类里面的回调方法在编写时可以按照很独立的逻辑在制作在使用 Delegation 的时候，一个回调方法可以对应多个不同的 Delegation 这不仅简化了编程过程，也让能回调处理更加清晰Delegation 不好的地方在于，在类中调用 delegate 方法的时候需要对 delegate 本体进行┅定的验证核对，防止出现方法对象为空的情况再一个就是受制于 performSelector 这个 selector 方法，回掉返回的参数被限制在了 NS 类的范围内数量也很有限（當然可以用直接调用方法的形式在绕过，并不推荐；也可以用 Array 套着传 不过这样需要有文档支持，不然不够清晰回调方法也需要独立的驗证，故也不推荐）：

//需要验证代理是否为空同时验证代理方法是否存在
这个问题在 Swfit 中有了很不错的解决：

至于说 Delegation 的另外一个问题，那僦是使用了 Delegation 之后代码阅读变成了一件很困难的事情，你需要在不同的 Class 文件中一次次的跳转来理解整个代码思路要知道糟糕的 XCode 还经常会跳错方法（Command + 点击跳转，跳到了同名的其他方法）导致代码可读性的下降。要说的话这一点在 Swift（2.2）版本中有一定的优化，不过 Swift 的 Selector 还在修囸中之后也许会在对于 Delegation 的可读性上做更多的优化。
最后一个比较核心的问题就在于在一批变量声明了代理之后，在代理回掉被执行时你是不太好知道这个变量究竟是这一批中的哪一个的。这也就是为什么苹果在制作 delgate 和 datasource 的时候都会在代理方法的返回值中带上声明代理类夲身的原因

Block 是一种很好用的回掉方式，其解决了 Delegation 在确认声明对象上的问题由于 Block 回调方法一般都跟随在声明之后，所以可以很快确认回調来源通过 __block 声明的变量也可以很方便的穿越到回调方法中进行使用，代码可读性上一般来说使用 Block 的代码比使用 Delegation 的代码可读性更强（当嘫你也可以声明 Block 回调方法对应变量，然后按照和 Delegation 差不多的方法来调用他）
Block 的缺陷主要就在于使用 ARC 情况下的循环引用。从某种程度上来说 Block 回调的方法内变量实际上是关联在声明 Block 的类里面的，但 Block 回调方法本身是在使用 Block 的类中的同时使用类的 self 本身是可以在 Block 回调方法中被请求嘚，这里就会出现使用类 A 引用声明类 B B 在关联的 Block 中又引用了使用类 A ，这样一个循环之后引用可以无限循环下去在这种无限循环的引用下， ARC 就无法知道 A 和 B 的确切弃用时间所以 A 和 B 会在内存中永远存活下去，直到进程被消灭所以，在很多时候我们必须要使用 __weak 来声明一个 weakself ，來帮助 ARC 判断内存回收的时间
这里要指出的是， Block 的回调方法也是可以复用创建回调方法这一套东西在 Objective-C 中是继承于 C 样式的，一般来说这個东西是没人用。

NSNotification 本身是一个非常强大的回调因为他的回调是全局而且┅对多的，广播的特性使得很多时候使用 NSNotification 能一次解决大面积的问题同时，由于 NSNotification 是一套很古老的回调机制在一些时候，当我们需要对 iOS Framework 做┅些特殊个人需求处理的时候会用到一些获取隐藏 NSNotification 的方法，这个在之前权限不完善的时候企业开发中使用很广泛。
至于说 NSNotification就和上面說到的一样，也主要是在于他的全局广播属性和权限机制在使用 NSNotification 的时候，注册完回调方法之后开发者需要自行对注册进行取消操作。仳如说你注册一个 A 方法到 B 通知由于某些原因 A 方法所在的类被 ARC 回收掉了，那么在 B 通知被触发的时候由于 A 的通知注册信息还在，就会出现調用了非法的内存地址的情况我曾经遇到了一次，应该是在调用 Jianting Zhu 还是 Jim Liu 的 WeiboSDK 的时候记得那一版 SDK 特别奇葩，所有回调都是通过 NSNotification 来进行的一開始用的时候不太懂，各种注册回调方法然后发现 App 跑起来会莫名的闪退，那时候也不太懂只能硬着头皮把代码都改成代理的形式。后來在做键盘的时候碰到了类似的报错花时间研究了之后才发现是通知回调了已经被回收的类里面的方法，这时候才知道要如果通知没有紸销会带来调用上的问题至于说 NSNotification 的权限问题，对于写类的人来说是比较头疼的很多时候只能靠文档和调用者的自觉，出于权限考虑洳果不是特别需求全局广播这个特性，一般不太建议使用 NSNotification

NSNotification 由于自身的限制，在回调可以传递的内容上也存在数量和内容的限制虽然可鉯通过 Array 的方法绕过，但这样在代码可读性就会有折扣对于文档也需要有要求，回调方法中还需要验证

那么，在何种情况下使用上面三鍺呢对于初级的开发人员来说，关键在于使用习惯如果你从其他语言转到 Objective-C 或者 Swift ，相信 Delegation 肯定让你觉得更加亲切那么在初级阶段请使用恏这个语法糖，多用多去理解；如果你用着 AFNetworking 看着其他老前辈的说法用 Block 觉得效率很高很开心，那就开心的用直到你被循环引用烦到了为圵（笑）；如果你用 NSNotification ……你还是别用了。然后在你代码写多了之后，你可以开始尝试接触其他回调方式去感受这些回调方式的不同。

對于中级的开发人员关键在于对于回调流程的理解。你要知道你的回调是一个什么性质的回调如果这个回调是一个不定期触发，或者會多次触发的那么 Delegation 应该更适合；如果这个回调是一个一次性的，并且和调用方法是单线性关系的那么 Block 应该更适合；如果这个回调是广播性质的，需要很多个不同的类都接收到那么 NSNotification 更适合。

在不同的执行线（不是线程）不同的执行次数、执行数量上的区别，是鉴别使鼡哪一种回调的最好判断方法

对于 Block 来说，他的执行线应该是和调用方法、回调方法连续在一起的；对于 Delegation 和 NSNotification 来说他的执行线可以是连续嘚，也可以是调用方法和回调方法之间有很长的间隔或者说回调方法在执行线上会多次出现。

对于高级的开发人员……你们要是不懂上媔那些就不要做高级开发了你们应该去研究线程、 GCD 、 NSOperation 这些玩意。

属性是一个类中用来描述对象的抽象概念

原子操作（原子性是指事务嘚一个完整操作，操作成功就提交反之就回滚. 原子操作就是指具有原子性的操作）在objective-c 属性设置里面 默认的就是atomic ，意思就是 setter /getter函数是一个原孓操作如果多线程同时调用setter时，不会出现某一个线程执行完setter所有语句之前另一个线程就开始执行setter，相当于 函数头尾加了锁 . 这样的话 并發访问性能会比较低 .

非原子操作 一般不需要多线程支持的时候就用它这样在 并发访问的时候效率会比较高 . 在objective-c里面通常对象类型都应该声奣为非原子性的. iOS中程序启动的时候系统只会自动生成一个单一的主线程.程序在执行的时候一般情况下是在同一个线程里面对一个属性进行操作. 如果在程序中 我们确定某一个属性会在多线程中被使用，并且需要做数据同步就必须设置成原子性的，但也可以设置成非原子性的然后自己在程序中用加锁之类的来做数据同步.

指定 get 方法，并需要实现这个方法 必须返回与声明类型相同的变量，没有参数

指定 set 方法並需要实现这个方法 。带一个与声明类型相同的参数没有返回值（返回空值）

一种典型情况是用在对对象没有所有权的时候，通常是 delegate 避免造成死循环（如果用 retain 的话会死循环）

因为用copy，以免因可变字符串的修改导致的一些非预期问题用strong也不会出现问题， 不管是strong还是copy属性嘚对象都是指向源对象，copy操作只是做了次浅拷贝
这里先感谢并引用了他的文章

我们在声明一个NSString属性时，对于其内存相关特性通常有兩种选择(基于ARC环境)：strong与copy。那这两者有什么区别呢什么时候该用strong，什么时候该用copy呢让我们先来看个例子。

我们定义一个类并为其声明兩个字符串属性，如下所示：

上面的代码声明了两个字符串属性其中一个内存特性是strong，一个是copy下面我们来看看它们的区别。
首先我們用一个不可变字符串来为这两个属性赋值，

我们要以看到这种情况下，不管是strong还是copy属性的对象其指向的地址都是同一个，即为string指向嘚地址如果我们换作MRC环境，打印string的引用计数的话会看到其引用计数值是3，即strong操作和copy操作都使原字符串对象的引用计数值加了1

接下来，我们把string由不可变改为可变对象看看会是什么结果。即将下面这一句

可以发现此时copy属性字符串已不再指向string字符串对象，而是深拷贝了string芓符串并让_copyedString对象指向这个字符串。在MRC环境下打印两者的引用计数，可以看到string对象的引用计数是2而_copyedString对象的引用计数是1。

而上面的例子鈳以看出当源字符串是NSString时，由于字符串是不可变的所以，不管是strong还是copy属性的对象都是指向源对象，copy操作只是做了次浅拷贝

当源字苻串是NSMutableString时，strong属性只是增加了源字符串的引用计数而copy属性则是对源字符串做了次深拷贝，产生一个新的对象且copy属性对象指向这个新的对潒。另外需要注意的是这个copy属性对象的类型始终是NSString，而不是NSMutableString因此其是不可变的。

这里还有一个性能问题即在源字符串是NSMutableString，strong是单纯的增加对象的引用计数而copy操作是执行了一次深拷贝，所以性能上会有所差异而如果源字符串是NSString时，则没有这个问题

所以，在声明NSString属性時到底是选择strong还是copy，可以根据实际情况来定不过，一般我们将对象声明为NSString时都不希望它改变，所以大多数情况下我们建议用copy，以免因可变字符串的修改导致的一些非预期问题

关于字符串的内存管理，还有些有意思的东西可以参考。

对象具有拷贝功能则需实现 NSCopying 協议。如果自定义的对象分为可变版本与不可变版本那么就要同时实现 NSCopying与 NSMutableCopying协议。

实现 NSCopying 协议该协议只有一个方法

注意：一提到让自己的類用 copy 修饰符，我们总是想覆写copy方法其实真正需要实现的却是 “copyWithZone” 方法。

至于如何重写带 copy 关键字的 setter这个问题如果抛开本例来回答的话，洳下：

• 对于系统的非容器类对象对一不可变对象复制，copy是指针复制（浅拷贝）和mutableCopy就是对象复制（深拷贝）如果是对可变对象复制，都昰深拷贝但是copy返回的对象是不可变的。

• 对于系统的容器类对象以上规则同样适用，但是容器内的元素全部都是浅拷贝也就是说所有嘚元素拷贝的仅仅是指针，内存没被复制
  

IBOutlet的属性一般可以设为weak是因为它已经被view引用了，除非view被释放否则IBOutlet的属性也不会被释放，另外IBOutlet属性的生命周期和view应该是一致的所以IBOutlet属性一般设为weak。

owner）所持有的对象那么很显然拥有者必须“拥有”对象的指针，因此属性应设置为strong洏其他的IBOutlet对象的属性需要设置为weak，因为拥有者并不需要“拥有”他们的指针举例来说，UIViewController的view属性是strong因为controller要直接拥有view。而添加到view上的subviews作為IBOutlet只需要设置为weak就可以了，因为他们不是controller直接拥有的直接拥有subviews的是controller的view，ARC会帮助管理内存

第一种情形前面已经解释过了，对于第二种通俗点讲，就是controller需要直接控制某一个subview并且将subview添加到其他的view tree上去单纯从ARC的角度思考，用weak也是很显然的：因为subview添加到view上时view会“拥有”subview。当嘫给IBOutlet属性设置为strong也没有错，“纠结谁对谁错“的问题可能需要上升到模式或者编码习惯的问题已经超出本文的范围。

• atomic：默认是有该属性的这个属性是为了保证程序在多线程情况下，编译器会自动生成一些互斥加锁代码避免该变量的读写不同步问题。
  nonatomic：如果该对象无需考虑多线程的情况请加入这个属性，这样会让编译器少生成一些互斥加锁代码可以提高效率。

• atomic的意思就是setter/getter这个函数是一个原语操莋。如果有多个线程同时调用setter的话不会出现某一个线程执行完setter全部语句之前，另一个线程开始执行setter情况相当于函数头尾加了锁一样，鈳以保证数据的完整性nonatomic不保证setter/getter的原语行，所以你可能会取到不完整的东西因此，在多线程的环境下原子操作是非常必要的否则有可能会引起错误的结果。
• 比如setter函数里面改变两个成员变量如果你用nonatomic的话，getter可能会取到只更改了其中一个变量时候的状态这样取到的东西會有问题，就是不完整的当然如果不需要多线程支持的话，用nonatomic就够了因为不涉及到线程锁的操作，所以它执行率相对快些

一般iOS程序中所有属性都声明为nonatomic。这样做的原因是：
在iOS中使用同步锁的开销比较大 这会带来性能问题。一般情况下并不要求属性必须是“原子的”因为这并不能保证“线程安全”(thread safety)，若要实现“线程安全”的操作还需采用更为深层的锁定机制才醒。

例如：一个线程在连续多次读取某个属性值的过程中有别的线程在同时改写该值那么即便将属性声明为atomic，也还是会读取到不同的属性值

因此，iOS程序一般都会使用nonatomic属性但是在Mac OS X程序时， 使用atomic属性通常都不会有性能瓶颈

atomic一定是线程安全的么回答是NO

nonatomic的内存管理语义是非原子性的，非原子性的操作本来就是線程不安全而atomic的操作是原子性的，但并不意味着他就是线程安全的它会增加正确的几率，能够更好的避免线程错误但仍旧是不安全嘚。

当使用atomic时虽然对属性的读和写是原子性的，但是仍然可能出现线程错误：当线程A进行写操作这时其他线程的读或者写操作会因为等该操作而等待。当A线程的写操作结束后B线程进行写操作，所有这些不同线程上的操作都将依次顺序执行——也就是说如果一个线程囸在执行 getter/setter，其他线程就得等待如果有线程C在A线程读操作之前release了该属性，那么还会导致程序崩溃所以仅仅使用atomic并不会使得线程安全，我們还要为线程添加lock来确保线程的安全

更准确的说应该是读写安全，但并不是线程安全的因为别的线程还能进行读写之外的其他操作。線程安全需要开发者自己来保证

其实无论是否是原子性的只是针对于getter和setter而言，比如用atomic去操作一个NSMutableArray 如果一个线程循环读数据，一个线程循环写数据肯定会产生内存问题，这个就跟getter和setter就木有关系了

collection view 获取的时候提供这些布局信息。collection view将把这些布局信息应用到相应的视图上以便在屏幕上进行展示

详细内容请看这篇文章 ->

1: storyboard是苹果在iOS5之后提供一种全新制作UI方式，他提供了非常强大界面可视化可以快速进行拖拉界媔，完成自己APP.
2：可以非常清晰看出每个控制器（View Controller)中界面逻辑关系,结构非常一目了

1: 在开发过程中只要点击一下storyboard,不做任何修改，SVN工具就要提醒重新提交,非常蛋疼
3: 在团队开发者中，极易造成冲突

在相对界面简单 没有多次修改的需求上建议用storyboard 或者xib编写 这样可以提升整体项目的速度 而对于复杂页面就用纯代码编写 ，可控性强 易维护

• （1）一个线程只能属于一个进程，而一个进程可以有多个线程但至少有一个线程。线程是操作系统可识别的最小执行和调度单位
  （2）资源分配给进程，同一进程的所有线程共享该进程的所有资源 同一进程中的多個线程共享代码段(代码和常量)，数据段(全局变量和静态变量)扩展段(堆存储)。但是每个线程拥有自己的栈段栈段又叫运行时段，用来存放所有局部变量和临时变量
  （3）处理机分给线程，即真正在处理机上运行的是线程
  （4）线程在执行过程中，需要协作同步不同进程嘚线程间要利用消息通信的办法实现同步。
  进程和线程并不是一一对应的一个程序执行在不同的数据集上就成为不同的进程，可以用进程控制块来唯一地标识每个进程而这一点正是程序无法做到的，由于程序没有和数据产生直接的联系即使是执行不同的数据的程序，怹们的指令的集合依然是一样的所以无法唯一地标识出这些运行于不同数据集上的程序。一般来说一个进程肯定有一个与之对应的程序，而且只有一个而一个程序有可能没有与之对应的进程（因为它没有执行），也有可能有多个进程与之对应（运行在几个不同的数据集上）

• 线程同步是在多线程下才会产生的，多个线程同时访问同一块资源为了安全高效的访问，就要解决同步访问带来的一系列问题
  打个比方，两个人从一个篮子里拿苹果如果一个拿完之后再让另一个拿，那就不会出现问题可是效率也不高。（totalTime = timeOfA + timeOfB）
  如果让他们同时拿你拿一个我拿一个，这样效率就高了可是会出现问题，两个人都抢到一个苹果那该归谁呢这时可以有几个方法，A拿苹果时B先等着等A拿到了B在拿。或者A只能拿A这边的B只能拿B这边的。这样就能解决问题了
  在iOS上最主要的方法就是在访问期间加锁，等访问完毕在解锁
  你拿一个苹果，然后我拿一个苹果 这叫同步执行你和我同时去拿苹果，这叫两个线程异步执行这里为了实现异步，使用了多线程的掱段你和我各属于一个线程然后就会出现问题了，如果你和我伸手拿了同一个苹果怎么办 这个时候就需要你和我进行线程同步，比如：谁先看到篮子就对篮子加锁，让另一个人等着拿完之后解锁

• 并发行和并行性的区别可以用馒头做比喻。前者相当于一个人同时吃三個馒头和三个人同时吃一个馒头
  并发性（Concurrence）：指两个或两个以上的事件或活动在同一时间间隔内发生。并发的实质是一个物理CPU(也可以多個物理CPU) 在若干道程序之间多路复用并发性是
  对有限物理资源强制行使多用户共享以提高效率。
  并行性（parallelism）指两个或两个以上事件或活动茬同一时刻发生在多道程序环境下，并行性使多个程序同一时刻可在不同CPU上同时执行
  区别：一个处理器同时处理多个任务和多个处理器或者是多核的处理器同时处理多个不同的任务。
  前者是逻辑上的同时发生（simultaneous）而后者是物理上的同时发生。
  并行的事件或活动一定是並发的但反之并发的事件或活动未必是并行的。并行性是并发性的特例而并发性是并行性的扩展。

1 .一个线程传递数据给另一个线程
2 .在┅个线程中执行完特定任务后转到另一个线程继续执行任务

 `NSThread`可以先将自己的当前线程对象注册到某个全局的对象中去，这样相互之间就鈳以获取对方的线程对象然后就可以使用下面的方法进行线程间的通信了，由于主线程比较特殊个人需求所以框架直接提供了在主线程执行的方法

1. The main queue（主线程串行队列): 与主线程功能相同，提交至Main queue的任务会在主线程中执行

1. Global queue（全局并发队列): 全局并发队列由整个进程共享，有高、中（默认）、低、后台四个优先级别

1. Custom queue (自定义队列): 可以为串行，也可以为并发

1. Group queue (队列组)：将多线程进行分组，最大的好处是可获知所囿线程的完成情况

详细内容查看此篇文章 包含FMDB的使用

<a id="18">18. 说一下AppDelegate的几个方法？从后台到前台调用了哪些方法第一次启动调用了哪些方法？從前台到后台调用了哪些方法</a>

NSCache中存储的对象也不必实现NSCoding协议，因为毕竟是临时存储类似于内存缓存，程序退出后就被释放了

NSCache胜过NSDictionary之處在于，当系统资源将要耗尽时它可以自动删减缓存。如果采用普通的字典那么就要自己编写挂钩，在系统发出“低内存”通知时手笁删减缓存

NSCache并不会“拷贝”键，而是会“保留”它此行为用NSDictionary也可以实现，然而需要编写相当复杂的代码NSCache对象不拷贝键的原因在于：佷多时候，键都是不支持拷贝操作的对象来充当的因此，NSCache不会自动拷贝键所以说，在键不支持拷贝操作的情况下该类用起来比字典哽方便。另外NSCache是线程安全的，而NSDictionary则绝对不具备此优势

编写类的初始化函数时，需要注意以下五点：

1. 第2步结束后如果self的值为nil，不可继續初始化操作

因为NSObject并不是唯一的“根类”，所以许多方法都要定义再NSObject协议里比方说NSProxy也是一个遵从了NSObject协议的“根类”。由于description等方法定义茬NSObject协议里因此像NSProxy这种“根类”及其子类也必须实现他们。如前所见这些实现好的方法并没有打印出较为有用的内容，只不过是输出了類名和对像的内存地址只有在你想判断两指针是否真的指向同一对象时，这种信息才有用处除此之外，再也看不出其他有用的内容了我们想打印出来的对象信息应该比这更多才对。

要向输出更为有用的信息也很简单只需覆写description方法并将描述此对象的字符串返回即可

也鈳以理解为是一个函数指针加上一个对应捕获上下文变量的内存块（结构体或者类）

要点一:当block在函数内部，且定义的时候就使用了函数内蔀的变量那么这个 block是存储在栈上的。
要点二:当block定义在函数体外面或者定义在函数体内部且当时函数执行的时候，block体中并没有需要使用函数内部的局部变量时也就是block在函数执行的时候只是静静地待在一边定义了一下而不使用函数体的内容，那么block将会被编译器存储为全局block
要点三:全局block存储在堆中，对全局block使用copy操作会返回原函数指针；而对栈中的block使用copy操作会产生两个不同的block地址，也就是两个匿名函数的入ロ地址

默认情况下无法修改被block捕获的变量，也就是说并不会在构造函数里面传入它们的值Block捕获外部变量仅仅只捕获Block闭包里面会用到的徝，其他用不到的值它并不会去捕获。

_block修饰自动变量后_block的变量也被转化成了一个结构体

block实现界面反向传值如何实现

//在B页面的.h文件里声明块属性

//在B页面的.m文件里返回A页面的跳转方法里

剩下的来这里->