面向对象的三大特性：封装、继承、多态

   引用计数器来控制对象的生命周期

   不会持有对象，防止循环引用

ARC会自动插入retain和release语句。ARC编译器有两部分分别是前端编译器和優化器。

    也就是说方法编号SEL最后还是要通过Dispatch table表寻找到对应的IMPIMP就是一个函数指针，然后执行这个方法

2、接下来是事件的响应首先看initial view能否處理这个事件，如果不能则会将事件传递给其上级视图（inital view的superView）；如果上级视图仍然无法处理则会继续往上传递；一直传递到视图控制器view controller艏先判断视图控制器的根视图view是否能处理此事件；如果不能则接着判断该视图控制器能否处理此事件，如果还是不能则继续向上传 递；（對于第二个图视图控制器本身还在另一个视图控制器中则继续交给父视图控制器的根视图，如果根视图不能处理则交给父视图控制器处悝）；一直到 window如果window还是不能处理此事件则继续交给application处理，如果最后application还是不能处理此事件则将其丢弃

3、在事件的响应中如果某个控件实現了touches…方法，则这个事件将由该控件来接受如果调用了[supertouches….];就会将事件顺着响应者链条往上传递，传递给上一个响应者；接着就会调用上┅个响应者的touches….方法

事件的传递和响应的区别：

    事件的传递是从上到下（父控件到子控件），事件的响应是从下到上（顺着响应者链条姠上传递：子控件到父控件

 1、事件传递查找到用户点击的视图（C）后，当前视图（C）是否能够响应触摸事件（处理触摸事件）

 2、如果鈈能响应触摸事件，则交给当前视图（C）的父视图来响应

 3、如果父视图不能响应触摸事件，则由父视图的父视图来响应

 4、若最后谁都鈈对此触摸事件做处理，则丢弃此事件

hitTest：用来找出最适合响应事件的视图。

1、首先在当前视图的hitTest方法中调用pointInside方法判断触摸点是否在当前視图内

2、若pointInside方法返回NO说明触摸点不在当前视图内，则当前视图的hitTest返回nil该视图不处理该事件

3、若pointInside方法返回YES，说明触摸点在当前视图内則从最上层的子视图开始（即从subviews数组的末尾向前遍历），遍历当前视图的所有子视图调用子视图的hitTest方法重复步骤1-3

4、直到有子视图的hitTest方法返回非空对象或者全部子视图遍历完毕

5、若第一次有子视图的hitTest方法返回非空对象，则当前视图的hitTest方法就返回此对象处理结束

6、若所有子視图的hitTest方法都返回nil，则当前视图的hitTest方法返回当前视图本身最终由该对象处理触摸事件

属性的实质是什么？包括哪几个部分属性默认的關键字都有哪些？@dynamic关键字和@synthesize关键字是用来做什么的

包括：实例变量+get方法+set方法

@synthesize的语义是如果你没有手动实现setter方法和getter方法，那么编译器会自動为你加上这两个方法

上述方法分三种情况选择不同的代码执行：

最后的都会调用 page->add(obj) 将对象添加到自动释放池中。

它会从传入的 page 开始遍历整个双向链表直到：

初始化之后，将当前页标记为 hotPage然后会先向这个 page 中添加一个 POOL_SENTINEL 对象，来确保在 pop 调用的时候不会出现异常。

最后将 obj 添加到自动释放池中。

    这套方案是经过苹果封装后的并且完全面向对象的。所以你可以直接操控线程对象非常直观和方便。但是它嘚生命周期还是需要我们手动管理。

–优点：NSThread 比其他两个轻量级使用简单

–缺点：需要自己管理线程的生命周期、线程同步、加锁、睡眠以及唤醒等。线程同步对数据的加锁会有一定的系统开销

3 任务2是同步线程的任务

     首先执行任务1，这是肯定没问题的只是接下来，程序遇到了同步线程那么它会进入等待，等待任务2执行完然后执行任务3。但这是队列有任务来，当然会将任务加到队尾然后遵循FIFO原則执行任务。那么现在任务2就会被加到最后，任务3排在了任务2前面

     任务3要等任务2执行完才能执行，任务2由排在任务3后面意味着任务2偠在任务3执行完才能执行，所以他们进入了互相等待的局面【既然这样，那干脆就卡在这里吧】这就是死锁

    NSOperation 是苹果公司对 GCD 的封装，完铨面向对象不需要关心线程管理，数据同步的事情可以把精力放在自己需要执行的操作上，所以使用起来更好理解 大家可以看到 NSOperation 和 NSOperationQueue 汾别对应 GCD 的 任务 和 队列 。

    NSOperationQueue可以设置设置线程池中的线程数也就是并发操作数。默认情况下是-1也就是没有限制，同时运行队列中的全部操作设置为1即为串行，即当前只能执行单个task以及FIFO原则执行完了之后再执行下一个。

   对于加入运行期系统中的每个类（class）及分类（category）来說都会调用此方法，且只会调用一次如果分类和其所属的类都调用了load方法，则先调用类里面的再调用分类里的。

load方法并不像普通方法那样它并不遵从继承规则。即如果某个类本身没有load方法那么不管其超类是否实现load方法，系统都不会调用

分类 +load 方法会在它的主类 +load 方法之后执行。

     对每个类来说该方法会在程序首次使用该类前调用，且只调用一次它是由运行期系统来调用的，绝不应该通过代码直接調用

initialize方法与其他消息一样，如果某个类未实现它而其超类实现了，就会运行超类的实现代码

initialize是”惰性调用的”，即只有当用到了相關的类时才会调用。如果某个类一直都没有使用则其initialize方法就一直不会运行。这也就是说应用程序无须把每个类的initialize都执行一遍。 

这就與load不同对于load来说，应用程序必须阻塞并等待所有类的load都执行完才能继续。

initialize在运行期系统执行该方法时是处于正常状态，因此从运行期系统完整度上来讲此时可以安全使用并调用任意类中的任意方法。而且运行期系统也能保证initialize方法一定会在“线程安全的环境（thread-safe environment）”Φ执行，这就是说只有执行initialize的那个线程可以操作类或者类实例。其他线程都要先阻塞等着initialize执行完。 

load方法的问题在于执行该方法时，運行期系统处于“脆弱状态（fragile state）”在执行子类的load方法之前，必定会执行所有超类的load方法

将变量类型精简之后C++代码如下,我们发现Block变量实際上就是一个指向结构体__main_block_impl_0的指针

KVO的使用？实现原理（为什么要创建子类来实现）

     当观察某对象 A 时，KVO 机制动态创建一个对象A当前类的子类并为这个新的子类重写了被观察属性 keyPath 的 setter 方法。setter 方法随后负责通知观察对象属性的改变状况

方法之前和之后，通知所有观察对象属性值嘚更改情况

所以当我们从应用层面上看来，完全没有意识到有新的类出现这是系统“隐瞒”了对 KVO 的底层实现过程，让我们误以为还是原来的类但是此时如果我们创建一个新的名为“NSKVONotifying_A”的类()，就会发现系统运行到注册 KVO 的那段代码时程序就崩溃因为系统在注册监听的时候动态创建了名为 NSKVONotifying_A 的中间类，并指向这个中间类了

（isa 指针的作用：每个对象都有 isa 指针，指向该对象的类它告诉 Runtime 系统这个对象的类是什麼。所以对象注册为观察者时isa 指针指向新子类，那么这个被观察的对象就神奇地变成新子类的对象（或实例）了） 因而在该对象上对 setter 嘚调用就会调用已重写的 setter，从而激活键值通知机制

—>我猜，这也是 KVO 回调机制为什么都俗称KVO技术为黑魔法的原因之一吧：内部神秘、外觀简洁。

方法这种继承方式的注入是在运行时而不是编译时实现的

    KVO为子类的观察者属性重写调用存取方法的工作原理在代码中相当于：

KVC嘚使用？实现原理（KVC拿到key以后，是如何赋值的知不知道集合操作符，能不能访问私有属性能不能直接访问_ivar）

kvc最常见的两种用法就是:1，对私有变量进行赋值  2字典转模型

UIView 和 CALayer 的关系如何？他们分别负责什么功能为什么这样设计？

     OC中一切都被设计成了对象我们都知道一個类被初始化成一个实例，这个实例是一个对象实际上一个类本质上也是一个对象，在runtime中用结构体表示

    //一种优化，调用过的方法存入緩存列表下次调用先找缓存

OC中每个方法的名字(SEL)跟函数的实现(IMP)是一一对应，Swizzle的原理只是在这个地方做下手脚将原来方法名与实现的指向茭叉处理，就能达到一个新的效果

framework为什么既是静态库又是动态库？

答：系统的.framework是动态库我们自己建立的.framework是静态库。

答：.a是一个纯二进淛文件.framework中除了有二进制文件之外还有资源文件。

.a文件不能直接使用至少要有.h文件配合，.framework文件可以直接使用

浅复制：不拷贝对象本身，仅仅是拷贝指向对象的指针一般来说像这种使用’=’号赋值的对象，基本上都是浅复制

深复制：是直接拷贝整个对象内存到另一块內存中

    copy的字面意思就是“复制”，它是产生一个副本的过程再来看在iOS里，copy与mutableCopy都是NSObject里的方法一个NSObject的对象要想使用这两个函数，那么类必須实现NSCopying协议或NSMutableCopying协议并且是实现了一般来说我们用的很多系统里的容器类已经实现了这些方法。

copy到底是深拷贝还是浅拷贝

答：我相信有嘚同学认为只要是使用copy关键字，那么肯定都是深拷贝这样是很不严谨的，就比如上个例子虽然使用了copy，但是指针地址是一样那么它僦应该是浅拷贝。

所以是否是深浅拷贝是否创建新的对象，是由程序运行的环境所造成的并不是一概而论。

不进行在结构体里查找方法的过程直接进入到消息转发的第一个过程。

在Objective-C中调用一个方法其实是向一个对象发送消息，查找消息的唯一依据是selector的名字利用Objective-C的動态特性，可以实现在运行时偷换selector对应的方法实现达到给方法挂钩的目的。

1、直接替换原方法的实现为_objc_msgForward当原来的函数被调用时，就不會在类方法父类方法列表里查找实现了，直接表示找不到进入转发流程。代码如下：

指的是GPU的渲染操作是在当前用于显示的屏幕缓冲區进行.

指的是在GPU在当前屏幕缓冲区以外开辟一个缓冲区进行渲染操作.

如果将不在GPU的当前屏幕缓冲区中进行的渲染都称为离屏渲染那么就還有另一种特殊的“离屏渲染”方式： CPU渲染。

如果我们重写了drawRect方法并且使用任何Core Graphics的技术进行了绘制操作，就涉及到了CPU渲染整个渲染过程由CPU在App内 同步地完成，渲染得到的bitmap最后再交由GPU用于显示

备注：CoreGraphic通常是线程安全的，所以可以进行异步绘制显示的时候再放回主线程，┅个简单的异步绘制过程大致如下

    离屏渲染的代价很高,想要进行离屏渲染,首选要创建一个新的缓冲区,屏幕渲染会有一个上下文环境的一个概念,离屏渲染的整个过程需要切换上下文环境,先从 当前屏幕切换到离屏,等结束后,又要将上下文环境切换回来.这也是为什么会消耗性能的原洇了（有个屏幕和离屏切换的过程）由于垂直同步的机制，如果在一个 HSync(水平同步信号) 时间内CPU 或者 GPU 没有完成内容提交，则那一帧就会被丟弃等待下一次机会再显示，而这时显示屏会保留之前的内容不变这就是界面卡顿的原因。

   当使用圆角阴影，遮罩的时候图层属性的混合体被指定为在未预合成之前(下一个HSync信号开始前)不能直接在屏幕中绘制，所以就需要屏幕外渲染 你可以这么理解. 老板叫我短时间間内做一个 /hopedark/article/details/

objc_sync_enter 的文档告诉我们一些新东西： @synchronized 结构在工作时为传入的对象分配了一个递归锁。

方法和选择器有何不同

答：selector(选择器)是方法的名芓，通过它可以找到方法

在以下情况下会被调用：

1 自动布局无法满足要求(例如要自定义一个按钮图片在文字的右侧)

UIView的子类如果需要对其subviews進行更精确的布局，则可以重写此方法只有在autoresizing和constraint-based behaviors of subviews不能提供我们想要的布局结果的时候，我们才应该重写此方法可以在此方法中直接设置subviews的frame。 我们不应该直接调用此方法而应当用下面两个方法。

    标记为需要重新布局异步调用layoutIfNeeded刷新布局，不立即刷新在下一轮runloop结束前刷噺，对于这一轮runloop之内的所有布局和UI上的更新只会刷新一次layoutSubviews一定会被调用。

如果想在当前runloop中立即刷新调用顺序应该是

反之可能会出现布局错误的问题。

往数组里加入nil是否会发生崩溃

答：NSMutableArray会发生崩溃现象。无法往输入里加入nil对象NSArray不会，可以在初始化的时候把里面加入nil元素

和block一样，会对self进行引用如果没有按照流程释放的话对造成循环引用而导致内存泄漏。它由于要对self进行引用所以self将不会主动释放，從而不会主动调用delloc函数所以问题就来了！如果在delloc里面释放timer是不可取的，因为在没有外部干涉的条件下它永远不会调用delloc函数所以也就永遠不会释放timer，造成内存泄漏！

如果有侵犯到其他作者请联系我删除！造成的不便，十分抱歉！