一、Instruments介绍

Instruments 一个很灵活的、强大的工具，是性能分析、动态跟踪 和分析OS X以及iOS代码的测试工具，用它可以极为方便收集关于一个或多个系统进程的性能和行为的数据，并能及时随着时间跟踪而产生的数据，并检查所收集的数据，还可以广泛收集不同类型的数据.也可以追踪程序运行的过程，这样instrument就可以帮助我们了解用户的应用程序和操作系统的行为。

总结一下instrument能做的事情：

1. Instruments是用于动态调追踪和分析OS X和iOS的代码的性能分析和测试工具；
2.Instruments支持多线程的调试；
3.可以用Instruments去录制和回放，图形用户界面的操作过程
4.可将录制的图形界面操作和Instruments保存为模板，供以后访问使用。

1.追踪代码中的（甚至是那些难以复制的）问题；
2.分析程序的性能；
3.实现程序的自动化测试；
4.部分实现程序的压力测试；
5.执行系统级别的通用问题追踪调试；
6.使你对程序的内部运行过程更加了解。

 打开方式：
Xcode -> Open Developer Tool -> Instruments

其中比较常用的有四种：

1.Allocations：用来检查内存分配，跟踪过程的匿名虚拟内存和堆的对象提供类名和可选保留/释放历史

2.Leaks：一般的查看内存使用情况，检查泄漏的内存，并提供了所有活动的分配和泄漏模块的类对象分配统计信息以及内存地址历史记录

3.Time Profiler：分析代码的执行时间，执行对系统的CPU上运行的进程低负载时间为基础采样

4.Zombies：检查是否访问了僵尸对象

其他的：

Blank：创建一个空的模板，可以从Library库中添加其他模板

Activity Monitor：显示器处理的CPU、内存和网络使用情况统计

Automation：用JavaScript语言编写，主要用于分析应用的性能和用户行为，模仿/击发被请求的事件，利用它可以完成对被测应用的简单的UI测试及相关功能测试

Cocoa Layout：观察约束变化，找出布局代码的问题所在。

Core Animation：用来检测Core Animation性能的，给我们提供了周期性的FPS，并且考虑到了发生在程序之外的动画，界面滑动FPS可以进行测试

Core Data：监测读取、缓存未命中、保存等操作，能直观显示是否保存次数远超实际需要

Energy Diagnostic ：用于Xcode下的Instruments来分析手机电量消耗的。（必须是真机才有电量）

GPU Driver ：可以测量GPU的利用率，同样也是一个很好的来判断和GPU相关动画性能的指示器。它同样也提供了类似Core Animtaion那样显示FPS的工具。

Network：分析应用程序如何使用TCP / IP和UDP / IP连接使用连接仪器。就是检查手机网速的。（这个最好是真机）

二、Allocations（分配）

1.内存分类：

Leaked memory：泄漏的内存，如为对象A申请了内存空间，之后再也没用到A，也没有释放A导致内存泄漏（野指针。。。）

Abandoned memory：被遗弃的内存，如循环引用，递归不断申请内存而导致的内存泄漏

Cached memory：缓存的内存

2.Abandoned memory

其中内存泄漏我们可以用Leaks，野指针可以用Zombies（僵尸对象），而在这里我们就可以用Allocations来检测Abandoned memory的内存。

即我们采用Generational Analysis的方法来分析，反复进入退出某一场景，查看内存的分配与释放情况，以定位哪些对象是属于Abandoned Memory的范畴。

在Allocations工具中，有专门的Generational Analysis设置，如下：

我们可以在程序运行时，在进入某个模块前标记一个Generation，这样会生成一个快照。然后进入、退出，再标记一个Generation，如下图：

在详情面板中我们可以看到两个Generation间内存的增长情况，其中就可能存在潜在的被遗弃的对象，如下图：

其中growth就是我们增长的内存，GenerationA是程序启动到进入该场景增长的内存，GenerationB就是第二次进入该场景所增长的内存，查看子类可以发现有两个管理类造成了Abandoned memory。

3.设置Generations

使用instrument测试内存泄露 工具 Allocations 测试是否内存泄露 使用标记，可以更省事省力的测试页面是否有内存泄露
1）设置Generations

2）选择mark generation

3）使用方法 在进入测试页面之前，mark一下----->进入页面----->退出----->mark------>进入------->退出------->mark------>进入如此往复5、6次，就可以看到如下结果

这种情况下是内存有泄露，看到每次的增量都是好几百K或者上M的，都是属于内存有泄露的，这时候就需要检测下代码一般情况

100K以下都属于正常范围，growth表示距离你上次mark的增量

三、Leaks（泄漏）

1.内存溢出和内存泄漏的区别

内存溢出 out of memory，是指程序在申请内存时，没有足够的内存空间供其使用，出现out of memory；比如申请了一个integer,但给它存了long才能存下的数，那就是内存溢出

内存泄露 memory leak，是指程序在申请内存后，无法释放已申请的内存空间，一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存,迟早会被占光。

memory leak会最终会导致out of memory！

在前面的ALLcations里面我们提到过内存泄漏就是应该释放而没有释放的内存。而内存泄漏分为两种：Leaked Memory 和 Abandoned Memory。前面我们讲到了如何找到Abandoned Memory被遗忘的内存，现在我们研究的就是Leaked Memory。

以发生的方式来分类，内存泄漏可以分为4类：

常发性内存泄漏。发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。
偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。
一次性内存泄漏。发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如，在类的构造函数中分配内存，在析构函数中却没有释放该内存，所以内存泄漏只会发生一次。
隐式内存泄漏。程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏。

影响：从用户使用程序的角度来看，内存泄漏本身不会产生什么危害，作为一般的用户，根本感觉不到内存泄漏的存在。真正有危害的是内存泄漏的堆积，这会最终消耗尽系统所有的内存。从这个角度来说，一次性内存泄漏并没有什么危害，因为它不会堆积，而隐式内存泄漏危害性则非常大，因为较之于常发性和偶发性内存泄漏它更难被检测到。

下边我们介绍Instruments里面的Leaked的用法，首先打开Leaked，跑起工程来，点击要测试的页面，如果有内存泄漏，会出现下图中的红色的❌。然后按照后边的步骤进行修复即可

上面的旧版的样式，下面的是新版的样式，基本操作差不多

在详情面板选中显示的若干条中的一条，双击，会自动跳到内存泄露代码处，然后点击右上角 Xcode 图标进行修改。

下图是对Leaked页面进一步的理解：

内存泄漏动态分析技巧：

1.在 Display Settings 界面建议把 Snapshot Interval （snapʃɒt, 数据快照）间隔时间设置为10秒，勾选Automatic Snapshotting，Leaks 会自动进行内存捕捉分析。（新版本直接在底部修改）

2.熟练使用 Leaks 后会对内存泄漏判断更准确，在可能导致泄漏的操作里，在你怀疑有内存泄漏的操作前和操作后，可以点击 Snapshot Now 进行手动捕捉。

3.开始时如果设备性能较好，可以把自动捕捉间隔设置为 5 秒钟。

4.使用ARC的项目，一般内存泄漏都是 malloc、自定义结构、资源引起的，多注意这些地方进行分析。

5.开启ARC后，内存泄漏的原因,开启了ARC并不是就不会存在内存问题，苹果有句名言：ARC is only for NSObject。

注：如果你的项目使用了ARC，随着你的操作，不断开启或关闭视图，内存可能持续上升，但这不一定表示存在内存泄漏，ARC释放的时机是不固定的

这里对 Display Settings中 的 Call tree 选项做一下说明 [官方user guide翻译]：

Separate By Thread：线程分离,只有这样才能在调用路径中能够清晰看到占用CPU最大的线程.每个线程应该分开考虑。只有这样你才能揪出那些大量占用CPU的"重"线程，按线程分开做分析，这样更容易揪出那些吃资源的问题线程。特别是对于主线程，它要处理和渲染所有的接口数据，一旦受到阻塞，程序必然卡顿或停止响应。

Invert Call Tree：从上到下跟踪堆栈信息.这个选项可以快捷的看到方法调用路径最深方法占用CPU耗时（这意味着你看到的表中的方法,将已从第0帧开始取样,这通常你是想要的,只有这样你才能看到CPU中花费时间最深的方法）,比如FuncA{FunB{FunC}},勾选后堆栈以C->B->A把调用层级最深的C显示最外面.反向输出调用树。把调用层级最深的方法显示在最上面，更容易找到最耗时的操作。

Hide Missing Symbols：如果dSYM无法找到你的APP或者调用系统框架的话，那么表中将看到调用方法名只能看到16进制的数值,勾选这个选项则可以隐藏这些符号，便于简化分析数据.

Hide System Libraries：表示隐藏系统的函数，调用这个就更有用了,勾选后耗时调用路径只会显示app耗时的代码,性能分析普遍我们都比较关系自己代码的耗时而不是系统的.基本是必选项.注意有些代码耗时也会纳入系统层级，可以进行勾选前后前后对执行路径进行比对会非常有用.因为通常你只关心cpu花在自己代码上的时间不是系统上的，隐藏系统库文件。过滤掉各种系统调用，只显示自己的代码调用。隐藏缺失符号。如果 dSYM 文件或其他系统架构缺失，列表中会出现很多奇怪的十六进制的数值，用此选项把这些干扰元素屏蔽掉，让列表回归清爽。

Show Obj-C Only：只显示oc代码 ,如果你的程序是像OpenGl这样的程序,不要勾选侧向因为他有可能是C++的

Flatten Recursion：递归函数, 每个堆栈跟踪一个条目，拼合递归。将同一递归函数产生的多条堆栈（因为递归函数会调用自己）合并为一条。

Top Functions：找到最耗时的函数或方法。 一个函数花费的时间直接在该函数中的总和，以及在函数调用该函数所花费的时间的总时间。因此，如果函数A调用B，那么A的时间报告在A花费的时间加上B.花费的时间,这非常真有用，因为它可以让你每次下到调用堆栈时挑最大的时间数字，归零在你最耗时的方法。

四、Time Profiler（时间分析器）

用来检测app中每个方法所用的时间，并且可以排序，并查找出哪些函数占用了大量时间。

使用Time Profile前有两点需要注意的地方：

1、一定要使用真机调试

在开始进行应用程序性能分析的时候，一定要使用真机。因为模拟器运行在Mac上，然而Mac上的CPU往往比iOS设备要快。相反，Mac上的GPU和iOS设备的完全不一样，模拟器不得已要在软件层面（CPU）模拟设备的GPU，这意味着GPU相关的操作在模拟器上运行的更慢，尤其是使用CAEAGLLayer来写一些OpenGL的代码时候，这就导致模拟器性能数据和用户真机使用性能数据相去甚远

2、应用程序一定要使用发布配置

在发布环境打包的时候，编译器会引入一系列提高性能的优化，例如去掉调试符号或者移除并重新组织代码。另iOS引入一种"Watch Dog"[看门狗]机制，不同的场景下，“看门狗”会监测应用的性能，如果超出了该场景所规定的运行时间，“看门狗”就会强制终结这个应用的进程。开发者可以crashlog看到对应的日志，但Xcode在调试配置下会禁用"Watch Dog"

1）界面详情：

2）详细面板

主要是看Call Tree和Sample List这两种视图：

3）调用树

Running Time：函数运行的时间，这个时间是累积时间

Self：在栈顶次数

Symbol Name：被调用函数的符号信息

4）详情面板更多的信息选项

5）样本列表

五、Zombies（僵尸）

1.概念

翻译英文：专注于检测过度释放的“僵尸”对象。还提供了数据对象分配的类以及所有活动分配内存地址的历史。

这里我们可以看到一个词语叫“over-release”,过度释放。我们在项目中见到最多的就是“EXC_BAD_ACCESS”或者是这样的：Thread 1: Program received signal:"EXC_BAD_ACCESS"，这就是访问了被释放的内存地址造成的

过度释放，是对同一个对象释放了过多的次数，其实当引用计数降到0时，对象占用的内存已经被释放掉，此时指向原对象的指针就成了“悬垂指针”，如若再对其进行任何方法的调用，（原则上）都会直接crash（然而由于某些特殊的情况，不会马上crash）。过度释放简单的说就是对release的对象再release，就是过度释放。

我们需要知道这几个概念：

1、内存泄漏：对象使用完没有释放，导致内存浪费。
2、僵尸对象：已经被销毁的对象(不能再使用的对象)
3、野指针：指向僵尸对象(不可用内存)的指针。给野指针发消息会报EXC_BAD_ACCECC错误。
4、空指针：没有指向储存空间的指针(里面存的是nil,也就是0)。在oc中使用空指针调中方法不会报错。

注意:为了避免野指针错误的常见方法:在对象被销毁之后,将指向对象的指针变为空指针。

对于过度释放的问题，可以直接使用Zombie，当过度释放发生时会立即停在发生问题的位置，同时结合内存分配释放历史和调用栈，可以发现问题。至于上文提到的不会crash的原因，其实有很多，比如：

对象内存释放时，所用内存并没有完全被擦除，仍有旧对象部分数据可用
原内存位置被写入同类或同样结构的数据

2.原理

我们将僵尸对象“复活”的目的：僵尸对象就是让已经释放了的对象重新复活，便于调试；是为了让已经释放了的对象在被再次访问时能够输出一些错误信息。其实这里的“复活”并不是真的复活，而是强行不死：这么说吧 相当于 他的RC=0的时候 系统再强行让他RC=1，顺便打上一个标记 zoom，等到你去掉那个沟以后 系统会把带有标记zoom的对象RC=0。

3.用法

下边是Instruments里面的Zombies的用法：

在Launch Configuration中勾选Record reference counts和Enable NSZombie detection。其中Recordreference counts是显示引用计数，Enable NSZombie detection是能够检测僵尸对象。

这样在程序运行的时候，如果发现僵尸对象它就会弹出一个对话框，点击其中“→”按钮，在屏幕的下方会显示僵尸对象的详细信息，下图可以看到僵尸对象的引用计数变化情况。

注意：Zombies模版在使用的时候会导致内存的飙升，这是因为所有被释放的对象被僵尸对象取代，并未真的释放掉，在结束Zombies时会释放，这是预知行为，这就意味着instrument里的其它工具和Zombies是不能同时使用的，Zombies会导致其它的数据不准。包括leaks，你也不应该把它加到Zombies模版中，即使这么做了结果也没什么意义。对于iOS应用来说，在用Zombies模版时使用iOS模拟器比真机要好。

另外XCode也提供了手动设置NSZombieEnabled环境变量的方法，不过设置NSZombieEnabled为True后，会导致内存占用的增长，同时会影响Leaks工具的调试，这是因为设置NSZombieEnabled会用僵尸对象来代替已释放对象

点击Product菜单Edit Scheme打开该页面，然后勾选Enable Zombie Objects复选框：

最后提醒的是NSZombieEnabled只能在调试的时候使用，千万不要忘记在产品发布的时候去掉，因为NSZombieEnabled不会真正去释放dealloc对象的内存，一直开启的话，该死去的对象会一直存在，后果可想而知，自重！

六、扩展

野指针

僵尸对象

内存回收的本质.

申请1块空间,实际上是向系统申请1块别人不再使用的空间.
释放1块空间,指的是占用的空间不再使用,这个时候系统可以分配给别人去使用.
在这个个空间分配给别人之前 数据还是存在的.
OC对象释放以后,表示OC对象占用的空间可以分配给别人.
但是再分配给别人之前 这个空间仍然存在 对象的数据仍然存在.

僵尸对象: 1个已经被释放的对象 就叫做僵尸对象.

使用野指针访问僵尸对象.有的时候会出问题,有的时候不会出问题.

当野指针指向的僵尸对象所占用的空间还没有分配给别人的时候, - 这个时候其实是可以访问的.
因为对象的数据还在.
当野指针指向的对象所占用的空间分配给了别人的时候 这个时候访问就会出问题.
所以,你不要通过1个野指针去访问1个僵尸对象.
虽然可以通过野指针去访问已经被释放的对象,但是我们不允许这么做.

僵尸对象检测.

默认情况下. Xcode不会去检测指针指向的对象是否为1个僵尸对象. 能访问就访问 不能访问就报错.

可以开启Xcode的僵尸对象检测.

那么就会在通过指针访问对象的时候,检测这个对象是否为1个僵尸对象 如果是僵尸对象 就会报错.

为什么不默认开启僵尸对象检测呢?

因为一旦开启,每次通过指针访问对象的时候.都会去检查指针指向的对象是否为僵尸对象.
那么这样的话 就影响效率了.

如何避免僵尸对象报错.

当1个指针变为野指针以后. 就把这个指针的值设置为nil

僵尸对象无法复活.

当1个对象的引用计数器变为0以后 这个对象就被释放了.
就无法取操作这个僵尸对象了. 所有对这个对象的操作都是无效的.
因为一旦对象被回收 对象就是1个僵尸对象 而访问1个僵尸对象 是没有意义.

摘自：https://blog.csdn.net/weixin_41963895/article/details/107231347

如果想让某个view不能处理事件（或者说，事件传递到某个view那里就断了），那么可以通过刚才提到的三种方式。比如，设置其userInteractionEnabled = NO;那么传递下来的事件就会由该view的父控件处理。
例如，不想让蓝色的view接收事件，那么可以设置蓝色的view的userInteractionEnabled = NO;那么点击黄色的view或者蓝色的view所产生的事件，最终会由橙色的view处理，橙色的view就会成为最合适的view。
所以，不管视图能不能处理事件，只要点击了视图就都会产生事件，关键在于该事件最终是由谁来处理！也就是说，如果蓝色视图不能处理事件，点击蓝色视图产生的触摸事件不会由被点击的视图（蓝色视图）处理！

注意：如果设置父控件的透明度或者hidden，会直接影响到子控件的透明度和hidden。如果父控件的透明度为0或者hidden = YES，那么子控件也是不可见的！

3.3.如何寻找最合适的view

应用如何找到最合适的控件来处理事件？
1.首先判断主窗口（keyWindow）自己是否能接受触摸事件

2.触摸点是否在自己身上

3.从后往前遍历子控件，重复前面的两个步骤（首先查找数组中最后一个元素）

4.如果没有符合条件的子控件，那么就认为自己最合适处理

详述：

1.主窗口接收到应用程序传递过来的事件后，首先判断自己能否接手触摸事件。如果能，那么在判断触摸点在不在窗口自己身上
2.如果触摸点也在窗口身上，那么窗口会从后往前遍历自己的子控件（遍历自己的子控件只是为了寻找出来最合适的view）
3.遍历到每一个子控件后，又会重复上面的两个步骤（传递事件给子控件，1.判断子控件能否接受事件，2.点在不在子控件上）
4.如此循环遍历子控件，直到找到最合适的view，如果没有更合适的子控件，那么自己就成为最合适的view。
找到最合适的view后，就会调用该view的touches方法处理具体的事件。所以，只有找到最合适的view，把事件传递给最合适的view后，才会调用touches方法进行接下来的事件处理。找不到最合适的view，就不会调用touches方法进行事件处理。

注意：之所以会采取从后往前遍历子控件的方式寻找最合适的view只是为了做一些循环优化。因为相比较之下，后添加的view在上面，降低循环次数。

3.3.1.寻找最合适的view底层剖析

两个重要的方法：
hitTest:withEvent:方法
pointInside方法

3.3.1.1.hitTest：withEvent：方法

什么时候调用？

只要事件一传递给一个控件,这个控件就会调用他自己的hitTest：withEvent：方法

作用

寻找并返回最合适的view(能够响应事件的那个最合适的view)

注 意：不管这个控件能不能处理事件，也不管触摸点在不在这个控件上，事件都会先传递给这个控件，随后再调用hitTest:withEvent:方法

拦截事件的处理

// 这里redView是whiteView的第0个子控件
#import "redView.h"
 
@implementation redView
- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event{ 
   return self;
}
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event{ 
   NSLog(@"red-touch");
}@end
// 或者
#import "whiteView.h"
 
@implementation whiteView
- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event{ 
   return self.subviews[0];
}
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event{ 
   NSLog(@"white-touch");
}
@end

#import "WYWindow.h"
@implementation WYWindow
// 什么时候调用:只要事件一传递给一个控件，那么这个控件就会调用自己的这个方法
// 作用:寻找并返回最合适的view
// UIApplication -> [UIWindow hitTest:withEvent:]寻找最合适的view告诉系统
// point:当前手指触摸的点
// point:是方法调用者坐标系上的点
- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event{
    // 1.判断下窗口能否接收事件
     if (self.userInteractionEnabled == NO || self.hidden == YES ||  self.alpha <= 0.01) return nil; 
    // 2.判断下点在不在窗口上 
    // 不在窗口上 
    if ([self pointInside:point withEvent:event] == NO) return nil; 
    // 3.从后往前遍历子控件数组 
    int count = (int)self.subviews.count; 
    for (int i = count - 1; i >= 0; i--)     { 
    // 获取子控件
    UIView *childView = self.subviews[i]; 
    // 坐标系的转换,把窗口上的点转换为子控件上的点 
    // 把自己控件上的点转换成子控件上的点 
    CGPoint childP = [self convertPoint:point toView:childView]; 
    UIView *fitView = [childView hitTest:childP withEvent:event]; 
    if (fitView) {
    // 如果能找到最合适的view 
    return fitView; 
    }
    } 
    // 4.没有找到更合适的view，也就是没有比自己更合适的view 
    return self;
    }
    // 作用:判断下传入过来的点在不在方法调用者的坐标系上
    // point:是方法调用者坐标系上的点
    //- (BOOL)pointInside:(CGPoint)point withEvent:(UIEvent *)event
    //{
    // return NO;
    //}
    - (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event{ 
    NSLog(@"%s",__func__);
    }
    @end

- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event{
    UIView *view = [super hitTest:point withEvent:event];
    if (view == self) {
        return nil;
    }
    return view;
}

@implementation WYView 
//只要点击控件,就会调用touchBegin,如果没有重写这个方法,自己处理不了触摸事件
// 上一个响应者可能是父控件
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event{ 
// 默认会把事件传递给上一个响应者,上一个响应者是父控件,交给父控件处理
[super touchesBegan:touches withEvent:event]; 
// 注意不是调用父控件的touches方法，而是调用父类的touches方法
// super是父类 superview是父控件 
}
@end

- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event{ 
// 1.自己先处理事件...
NSLog(@"do somthing...");
// 2.再调用系统的默认做法，再把事件交给上一个响应者处理
[super touchesBegan:touches withEvent:event]; 
}

前言：

按照时间顺序，事件的生命周期：
　　事件的产生和传递（事件如何从父控件传递到子控件并寻找到最合适的view、寻找最合适的view的底层实现、拦截事件的处理）->找到最合适的view后事件的处理（touches方法的重写，也就是事件的响应）

重点和难点是：
　　1.如何寻找最合适的view
　　2.寻找最合适的view的底层实现（hitTest:withEvent:底层实现）

（一）iOS中的事件

iOS中的事件可以分为3大类型：
1.触摸事件

2.加速计事件

3.远程控制事件

这里我们只讨论iOS中的触摸事件。

1.1.响应者对象(UIResponder)

在iOS中不是任何对象都能处理事件，只有继承了UIResponder的对象才能接受并处理事件，我们称之为“响应者对象”。以下都是继承自UIResponder的，所以都能接收并处理事件。

UIApplication
UIWindows
UIViewController
UIView

那么为什么继承自UIResponder的类就能够接收并处理事件呢？

因为UIResponder中提供了以下4个对象方法来处理触摸事件。UIResponder内部提供了以下方法来处理事件触摸事件

- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event;
- (void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event;
- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event;
- (void)touchesCancelled:(NSSet *)touches withEvent:(UIEvent *)event;
加速计事件
- (void)motionBegan:(UIEventSubtype)motion withEvent:(UIEvent *)event;
- (void)motionEnded:(UIEventSubtype)motion withEvent:(UIEvent *)event;
- (void)motionCancelled:(UIEventSubtype)motion withEvent:(UIEvent *)event;
远程控制事件
- (void)remoteControlReceivedWithEvent:(UIEvent *)event;

（二）事件的处理

下面以UIView为例来说明触摸事件的处理。

// UIView是UIResponder的子类，可以覆盖下列4个方法处理不同的触摸事件
// 一根或者多根手指开始触摸view，系统会自动调用view的下面方法
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
// 一根或者多根手指在view上移动，系统会自动调用view的下面方法（随着手指的移动，会持续调用该方法）
- (void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event
// 一根或者多根手指离开view，系统会自动调用view的下面方法
- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event
// 触摸结束前，某个系统事件(例如电话呼入)会打断触摸过程，系统会自动调用view的下面方法
- (void)touchesCancelled:(NSSet *)touches withEvent:(UIEvent *)event
// 提示：touches中存放的都是UITouch对象

需要注意的是：以上四个方法是由系统自动调用的，所以可以通过重写该方法来处理一些事件。

1.如果两根手指同时触摸一个view，那么view只会调用一次touchesBegan:withEvent:方法，touches参数中装着2个UITouch对象

2.如果这两根手指一前一后分开触摸同一个view，那么view会分别调用2次touchesBegan:withEvent:方法，并且每次调用时的touches参数中只包含一个UITouch对象

3.重写以上四个方法，如果是处理UIView的触摸事件。必须要自定义UIView子类继承自UIView。因为苹果不开源，没有把UIView的.m文件提 供给我们。我们只能通过子类继承父类，重写子类方法的方式处理UIView的触摸事件（注意：我说的是UIView触摸事件而不是说的 UIViewController的触摸事件）。

4.如果是处理UIViewController的触摸事件，那么在控制器的.m文件中直接重写那四个方法即可！

/************************自定义UIView的.h.m文件************************/

#import 
 
@interface WYView : UIView
@end

#import "WYView.h"
@implementation WYView
// 开始触摸时就会调用一次这个方法
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event{ 
    NSLog(@"摸我干啥！");
}
// 手指移动就会调用这个方法
// 这个方法调用非常频繁
- (void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event{ 
    NSLog(@"移动过程中持续调用！");
}
// 手指离开屏幕时就会调用一次这个方法
- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event{ 
    NSLog(@"手放开还能继续玩耍！");
}
@end

/**************************控制器的.m文件*************************/

#import "ViewController.h"
#import "WYView.h"
@interface ViewController ()
@end@implementation ViewController
- (void)viewDidLoad { 
    [super viewDidLoad]; 
// 创建自定义view 
    WYView *touchView = [[WYView alloc] initWithFrame:CGRectMake(100, 100, 100, 100)]; 
// 背景颜色 
    touchView.backgroundColor = [UIColor redColor]; 
// 添加到父控件 
    [self.view addSubview:touchView]; 
}
@end

注 意：有人认为，我要是处理控制器的自带的view的事件就不需要自定义UIView子类继承于UIView，因为可以在viewController.m 文件中重写touchBegan:withEvent:方法，但是，我们此处讨论的是处理UIView的触摸事件，而不是处理 UIViewController的触摸事件。你如果是在viewController.m文件中重写touchBegan:withEvent:方法，相当于处理的是viewController的触摸事件，因为viewController也是继承自UIResponder，所以会给人一种错觉。
所以，还是那句话，想处理UIView的触摸事件，必须自定义UIView子类继承自UIView。

2.1.UIView的拖拽

那么，如何实现UIView的拖拽呢?也就是让UIView随着手指的移动而移动。
　　- 重写touchsMoved:withEvent:方法
此时需要用到参数touches，下面是UITouch的属性和方法：

NS_CLASS_AVAILABLE_IOS(2_0) @interface UITouch : NSObject
 
@property(nonatomic,readonly) NSTimeInterval      timestamp;
@property(nonatomic,readonly) UITouchPhase        phase;
@property(nonatomic,readonly) NSUInteger          tapCount;   // touch down within a certain point within a certain amount of time
 
// majorRadius and majorRadiusTolerance are in points
// The majorRadius will be accurate +/- the majorRadiusTolerance
@property(nonatomic,readonly) CGFloat majorRadius NS_AVAILABLE_IOS(8_0);
@property(nonatomic,readonly) CGFloat majorRadiusTolerance NS_AVAILABLE_IOS(8_0);
 
@property(nullable,nonatomic,readonly,strong) UIWindow                        *window;
@property(nullable,nonatomic,readonly,strong) UIView                          *view;
@property(nullable,nonatomic,readonly,copy)   NSArray  *gestureRecognizers NS_AVAILABLE_IOS(3_2);
 
- (CGPoint)locationInView:(nullable UIView *)view;
- (CGPoint)previousLocationInView:(nullable UIView *)view;
 
// Force of the touch, where 1.0 represents the force of an average touch
@property(nonatomic,readonly) CGFloat force NS_AVAILABLE_IOS(9_0);
// Maximum possible force with this input mechanism
@property(nonatomic,readonly) CGFloat maximumPossibleForce NS_AVAILABLE_IOS(9_0);

2.1.1.UITouch对象

当用户用一根手指触摸屏幕时，会创建一个与手指相关的UITouch对象

一根手指对应一个UITouch对象

如果两根手指同时触摸一个view，那么view只会调用一次touchesBegan:withEvent:方法，touches参数中装着2个UITouch对象

如果这两根手指一前一后分开触摸同一个view，那么view会分别调用2次touchesBegan:withEvent:方法，并且每次调用时的touches参数中只包含一个UITouch对象

2.1.1.1.UITouch的作用

保存着跟手指相关的信息，比如触摸的位置、时间、阶段

当手指移动时，系统会更新同一个UITouch对象，使之能够一直保存该手指在的触摸位置

当手指离开屏幕时，系统会销毁相应的UITouch对象
提 示:iPhone开发中，要避免使用双击事件！

2.1.1.2.UITouch的属性


触摸产生时所处的窗口
@property(nonatomic,readonly,retain) UIWindow *window;
 
触摸产生时所处的视图
@property(nonatomic,readonly,retain) UIView *view
;
 
短时间内点按屏幕的次数，可以根据tapCount判断单击、双击或更多的点击
@property(nonatomic,readonly) NSUInteger tapCount;
 
记录了触摸事件产生或变化时的时间，单位是秒
@property(nonatomic,readonly) NSTimeInterval timestamp;
 
当前触摸事件所处的状态
@property(nonatomic,readonly) UITouchPhase phase;

2.1.1.3.UITouch的方法


(CGPoint)locationInView:(UIView *)view;
// 返回值表示触摸在view上的位置
// 这里返回的位置是针对view的坐标系的（以view的左上角为原点(0, 0)）
// 调用时传入的view参数为nil的话，返回的是触摸点在UIWindow的位置
 
(CGPoint)previousLocationInView:(UIView *)view;
// 该方法记录了前一个触摸点的位置

- (void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event{ 
    // 想让控件随着手指移动而移动,监听手指移动 
    // 获取UITouch对象 
    UITouch *touch = [touches anyObject]; 
    // 获取当前点的位置 
    CGPoint curP = [touch locationInView:self]; 
    // 获取上一个点的位置 
    CGPoint preP = [touch previousLocationInView:self]; 
    // 获取它们x轴的偏移量,每次都是相对上一次 
    CGFloat offsetX = curP.x - preP.x; 
    // 获取y轴的偏移量 
    CGFloat offsetY = curP.y - preP.y; 
    // 修改控件的形变或者frame,center,就可以控制控件的位置 
    // 形变也是相对上一次形变(平移) 
    // CGAffineTransformMakeTranslation:会把之前形变给清空,重新开始设置形变参数 
    // make:相对于最原始的位置形变 
    // CGAffineTransform t:相对这个t的形变的基础上再去形变 
    // 如果相对哪个形变再次形变,就传入它的形变 
    self.transform = CGAffineTransformTranslate(self.transform, offsetX, offsetY);}

（三）iOS中的事件的产生和传递

3.1.事件的产生

发生触摸事件后，系统会将该事件加入到一个由UIApplication管理的事件队列中,为什么是队列而不是栈？因为队列的特点是FIFO，即先进先出，先产生的事件先处理才符合常理，所以把事件添加到队列。

UIApplication会从事件队列中取出最前面的事件，并将事件分发下去以便处理，通常，先发送事件给应用程序的主窗口（keyWindow）。

主窗口会在视图层次结构中找到一个最合适的视图来处理触摸事件，这也是整个事件处理过程的第一步。

找到合适的视图控件后，就会调用视图控件的touches方法来作具体的事件处理。

3.2.事件的传递

触摸事件的传递是从父控件传递到子控件
也就是UIApplication->window->寻找处理事件最合适的view
注 意: 如果父控件不能接受触摸事件，那么子控件就不可能接收到触摸事件

应用如何找到最合适的控件来处理事件？

1.首先判断主窗口（keyWindow）自己是否能接受触摸事件

2.判断触摸点是否在自己身上

3.子控件数组中从后往前遍历子控件，重复前面的两个步骤（所谓从后往前遍历子控件，就是首先查找子控件数组中最后一个元素，然后执行1、2步骤）

4.view，比如叫做fitView，那么会把这个事件交给这个fitView，再遍历这个fitView的子控件，直至没有更合适的view为止。

5.如果没有符合条件的子控件，那么就认为自己最合适处理这个事件，也就是自己是最合适的view。

UIView不能接收触摸事件的三种情况：

1.不允许交互：userInteractionEnabled = NO
2.隐藏：如果把父控件隐藏，那么子控件也会隐藏，隐藏的控件不能接受事件
3.透明度：如果设置一个控件的透明度<0.01，会直接影响子控件的透明度。alpha：0.0~0.01为透明。

注 意:默认UIImageView不能接受触摸事件，因为不允许交互，即userInteractionEnabled = NO。所以如果希望UIImageView可以交互，需要设置UIImageView的userInteractionEnabled = YES。


总结一下

1.点击一个UIView或产生一个触摸事件A，这个触摸事件A会被添加到由UIApplication管理的事件队列中（即，首先接收到事件的是UIApplication）。

2.UIApplication会从事件对列中取出最前面的事件（此处假设为触摸事件A），把事件A传递给应用程序的主窗口（keyWindow）。

3.窗口会在视图层次结构中找到一个最合适的视图来处理触摸事件。（至此，第一步已完成）

在 UIView 中有一个 CALayer 的属性，负责 UIView 具体内容的显示。具体过程是系统会把 UIView 显示的内容（包括 UILabel 的文字，UIImageView 的图片等）绘制在一张画布上，完成后倒出图片赋值给 CALayer 的 contents 属性，完成显示。

这其中的工作都是在主线程中完成的，这就导致了主线程频繁的处理 UI 绘制的工作，如果要绘制的元素过多，过于频繁，就会造成卡顿。

那么是否可以将复杂的绘制过程放到后台线程中执行，从而减轻主线程负担，来提升 UI 流畅度呢？

答案是可以的，系统给我们留下的异步绘制的口子，请看下面的流程图，它是我们进行基本绘制的基础。

UIView 调用 setNeedsDisplay 方法其实是调用其 layer 属性的同名方法，这时 layer 并不会立刻调用 display 方法，而是要等到当前 runloop 即将结束的时候调用 display，进入到绘制流程。在 UIView 中 layer.delegate 就是 UIView 本身，UIView 并没有实现 displayLayer: 方法，所以进入系统的绘制流程，我们可以通过实现 displayLayer: 方法来进行异步绘制。

有了上面的异步绘制原理流程图，我们可以得到一个实现异步绘制的初步思路：
在“异步绘制入口”去开辟子线程，然后在子线程中实现和系统类似的绘制流程。

二、系统绘制流程

要实现异步绘制，我们首先要了解系统的绘制流程，看下面一张流程图：

三、异步绘制流程

我们看一幅时序图

#import "AsyncDrawLabel.h"
#import <CoreText/CoreText.h>
 
@implementation AsyncDrawLabel
 
- (void)setText:(NSString *)text {
    _text = text;
    [self.layer setNeedsDisplay];
}
 
- (void)setFont:(UIFont *)font {
    _font = font;
    [self.layer setNeedsDisplay];
}
 
- (void)displayLayer:(CALayer *)layer {
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        __block CGSize size;
        dispatch_sync(dispatch_get_main_queue(), ^{
            size = self.bounds.size;
        });
        UIGraphicsBeginImageContextWithOptions(size, NO, UIScreen.mainScreen.scale);
        CGContextRef context = UIGraphicsGetCurrentContext();
        [self draw:context size:size];
        UIImage *image = UIGraphicsGetImageFromCurrentImageContext();
        UIGraphicsEndImageContext();
        dispatch_async(dispatch_get_main_queue(), ^{
            self.layer.contents = (__bridge id)image.CGImage;
        });
    });
}
 
- (void)draw:(CGContextRef)context size:(CGSize)size {
    // 将坐标系上下翻转，因为底层坐标系和 UIKit 坐标系原点位置不同。
    CGContextSetTextMatrix(context, CGAffineTransformIdentity);
    CGContextTranslateCTM(context, 0, size.height); // 原点为左下角
    CGContextScaleCTM(context, 1, -1);
    
    CGMutablePathRef path = CGPathCreateMutable();
    CGPathAddRect(path, NULL, CGRectMake(0, 0, size.width, size.height));
    
    NSMutableAttributedString *attrStr = [[NSMutableAttributedString alloc]initWithString:self.text];
    [attrStr addAttribute:NSFontAttributeName value:self.font range:NSMakeRange(0, self.text.length)];
    
    CTFramesetterRef framesetter = CTFramesetterCreateWithAttributedString((CFAttributedStringRef)attrStr);
    CTFrameRef frame = CTFramesetterCreateFrame(framesetter, CFRangeMake(0, attrStr.length), path, NULL);
    CTFrameDraw(frame, context);
}
 
@end

AsyncDrawLabel 是一个继承 UIView 的类，其 Label 的文本绘制功能需要我们自己实现。

我们在 - (void)displayLayer:(CALayer *)layer 方法中异步在全局队列中创建上下文环境然后使用 - (void)draw:(CGContextRef)context size:(CGSize)size 方法进行文本的简单绘制，再回到主线程为 self.layer.contents 赋值。从而完成了一个简单的异步绘制。

当然这样的绘制的问题是，如果绘制数量较多，绘制频繁，会阻塞全局队列，因为全局队列中还有一些系统提交的任务需要执行，可能会对其造成影响。

YYAsyncLayer

我们需要更加优化的方式去管理异步绘制的线程和执行流程，使用 YYAsyncLayer 可以让我们把注意力放在具体的绘制（需要我们做的是上面代码中 - draw: size: 做的事情），而不需要考虑线程的管理，绘制的时机等，大大提高绘制的效率以及我们编程的速度。

YYAsyncLayer 的主要流程如下

在主线程的 RunLoop 中注册一个 observer，它的优先级要比系统的 CATransaction 低，保证系统先做完必须的工作。

把需要异步绘制的操作集中起来。比如设置字体、颜色、背景色等，不是设置一个就绘制一个，而是把它们集中起来，RunLoop 会在 observer 需要的时机通知统一处理。

处理时机到时，执行异步绘制，并在主线程中把绘制结果传递给 layer.contents。

流程图如下：

使用 YYAsyncLayer 的代码：

#import "AsyncDrawLabel.h"
#import <YYAsyncLayer.h>
#import <CoreText/CoreText.h>
 
@interface AsyncDrawLabel ()<YYAsyncLayerDelegate>
 
@end
 
@implementation AsyncDrawLabel
 
+ (Class)layerClass {
    return YYAsyncLayer.class;
}
 
- (void)setText:(NSString *)text {
    _text = text.copy;
    [self commitTransaction];
}
 
- (void)setFont:(UIFont *)font {
    _font = font;
    [self commitTransaction];
}
 
- (void)layoutSubviews {
    [super layoutSubviews];
    [self commitTransaction];
}
 
- (void)contentsNeedUpdated {
    [self.layer setNeedsDisplay];
}
 
- (void)commitTransaction {
    [[YYTransaction transactionWithTarget:self selector:@selector(contentsNeedUpdated)] commit];
}
 
// 在这里创建异步绘制的任务
- (YYAsyncLayerDisplayTask *)newAsyncDisplayTask {
    YYAsyncLayerDisplayTask *task = [YYAsyncLayerDisplayTask new];
    task.willDisplay = ^(CALayer * _Nonnull layer) {
        
    };
    task.display = ^(CGContextRef  _Nonnull context, CGSize size, BOOL (^ _Nonnull isCancelled)(void)) {
        if (isCancelled() || self.text.length == 0) {
            return;
        }
        // 在这里进行异步绘制
        [self draw:context size:size];
    };
    task.didDisplay = ^(CALayer * _Nonnull layer, BOOL finished) {
        if (finished) {
            
        } else {
            
        }
    };
    return task;
}
 
- (void)draw:(CGContextRef)context size:(CGSize)size {
    // 将坐标系上下翻转，因为底层坐标系和 UIKit 坐标系原点位置不同。
    CGContextSetTextMatrix(context, CGAffineTransformIdentity);
    CGContextTranslateCTM(context, 0, size.height); // 原点为左下角
    CGContextScaleCTM(context, 1, -1);
    
    CGMutablePathRef path = CGPathCreateMutable();
    CGPathAddRect(path, NULL, CGRectMake(0, 0, size.width, size.height));
    
    NSMutableAttributedString *attrStr = [[NSMutableAttributedString alloc]initWithString:self.text];
    [attrStr addAttribute:NSFontAttributeName value:self.font range:NSMakeRange(0, self.text.length)];
    
    CTFramesetterRef framesetter = CTFramesetterCreateWithAttributedString((CFAttributedStringRef)attrStr);
    CTFrameRef frame = CTFramesetterCreateFrame(framesetter, CFRangeMake(0, attrStr.length), path, NULL);
    CTFrameDraw(frame, context);
}
@end

原文链接：https://blog.csdn.net/wywinstonwy/article/details/105660643

Auto Layout 原理

前言

Category是我们平时用到的比较多的一种技术，比如说给某个类增加方法，添加成员变量，或者用Category优化代码结构。
我们通过下面这几个问题作为切入点，结合runtime的源码，探究一下Category的底层原理。
我们在Category中，可以直接添加方法，而且我们也都知道，添加的方法会合并到本类当中，同时我们也可以声明属性，但是此时的属性没有功能，也就是不能存值，这就类似于Swift中的计算属性，如果我们想让这个属性可以储存值，就要用runtime的方式，动态的添加。

探究

1. Category为什么能添加方法不能添加成员变量
首先我们先创建一个Person类，然后创建一个Person+Run的Category，并在Person+Run中实现-run方法。
我们可以使用命令行对Person+Run.m进行编译

xcrun -sdk iphonesimulator clang -rewrite-objc Person+Run.m

得到一个Person+Run.cpp文件，在文件的底部，可以找到这样一个结构体

struct _category_t {
    const char *name;
    struct _class_t *cls;
    const struct _method_list_t *instance_methods;
    const struct _method_list_t *class_methods;
    const struct _protocol_list_t *protocols;
    const struct _prop_list_t *properties;
};

这些字段几乎都是见名知意了。
每一个Category都会编译然后存储在一个_category_t类型的变量中

static struct _category_t _OBJC_$_CATEGORY_Person_$_Run __attribute__ ((used, section ("__DATA,__objc_const"))) = 
{
    "Person",
    0, // &OBJC_CLASS_$_Person,
    (const struct _method_list_t *)&_OBJC_$_CATEGORY_INSTANCE_METHODS_Person_$_Run,
    0,
    0,
    0,
};

因为我们的Person+Run里面只有一个实例方法，从上述代码中来看，也只有对应的位置传值了。
通过这个_category_t的结构结构我们也可以看出，属性存储在_prop_list_t，这里并没有类中的objc_ivar_list结构体，所以Category的_category_t结构体中根本没有储存ivar的地方，所以不能添加成员变量。
如果我们在分类中手动为成员变量添加了set和get方法之后，也可以调用，但实际上是没有内存来储值的，这就好像Swift中的计算属性，只起到了计算的作用，就相当于是两个方法（set和get），但是并不能拥有真用的内存来存储值。
举个例子

@property (copy, nonatomic) NSString * name;

下面这个声明如果实在类中，系统会默认帮我们声明一个成员变量_name, 在.h中声明setName和name两个方法，并提供setName和name方法的默认实现。
如果是在Category中，只相当于声明setName和name两个方法，没有实现也没有_name。

2. Category的方法是何时合并到类中的
大家都知道Category分类肯定是我们的应用启动是，通过运行时特性加载的，但是这个加载过程具体的细节就要结合runtime的源码来分析了。
runtime源码太多了，我们先通过大概浏览代码来定位实现功能的相关位置。
我从objc-runtime-new.mm中找到了下面这个方法。

void attachLists(List* const * addedLists, uint32_t addedCount)

而且他的注释一些的很清楚，修复类的方法，协议和变量列表，关联还未关联的分类。
然后我们继续找，就找到了我们需要的这个方法。

void attachLists(List* const * addedLists, uint32_t addedCount)

我们从其中摘出一段代码来分析就可以解决我们的问题了。

// many lists -> many lists
  uint32_t oldCount = array()->count;
  uint32_t newCount = oldCount + addedCount;
  setArray((array_t *)realloc(array(), array_t::byteSize(newCount)));
  array()->count = newCount;
  memmove(array()->lists + addedCount, array()->lists, 
          oldCount * sizeof(array()->lists[0]));
  memcpy(array()->lists, addedLists, 
         addedCount * sizeof(array()->lists[0]));

在调用此方法之前我们所有的分类会被方法一个list里面（每一个分类都是一个元素），然后再调用attachLists方法，我们可以看到，在realloc的时候传进一个newCount，这是因为要增加分类中的方法，所以需要对之前的数组扩容，在扩容结束后先调用了memmove方法，在调用memcopy，大家可以上网查一下这两个方法具体的区别，这里简单一说，其实完成的效果都是把后面的内存的内容拷贝到前面内存中去，但是memmove可以处理内存重叠的问题。
其实也就是首先将原来数组中的每个元素先往后移动（我们要添加几个元素，就移动几位），因为移动后的位置，其实也是数组自己的内存空间，所以存在重叠问题，直接移动会导致元素丢失的问题，所以用memmove（会检测是否有内存重叠）。
移动完之后，把我们储存分类中方法的list中的元素移动到数组前面位置。
过程就是这样子了，其实我们第三个问题就顺便解决完了。

3. Category方法和类中方法的执行顺序
上面其实说到了，类中原来的方法是要往后面移动的，分类的方法添加到前面的位置，而且调用方法的时候是在list中遍历查找，所以我们调用方法的时候，肯定会先调用到Category中的方法，但是这并不是覆盖，因为我们的原方法还在，只是这中机制保证了如果分类中有重写类的方法，会被优先查找到。

4. +load和+initialize的区别
对于这个问题我们从两个角度出发分析，调用方式和调用时刻。

+load
简单的举一个例子，我们创建一个Person类，然后重写+load方法，然后为Person新建两个Category，都分别实现+load。

@implementation Person
+ (void)load {
    NSLog(@"Person - load");
}
@end

@implementation Person (Test1)
+ (void)load {
    NSLog(@"Person Test1 - load");
}
@end

@implementation Person (Test2)
+ (void)load {
    NSLog(@"Person Test2 - load");
}
@end

当我们进行项目的时候，会得到下面的打印结果。

2020-09-14 09:34:41.900161+0800 Category[4533:53426] Person - load
2020-09-14 09:34:41.900629+0800 Category[4533:53426] Person Test1 - load
2020-09-14 09:34:41.900700+0800 Category[4533:53426] Person Test2 - load

我们并没有使用这个Person类和他的Category，所以应该是项目运行后，runtime在加载类和分类的时候，就会调用+load方法。
我们从源码中找到下面这个方法
void load_images(const char *path __unused, const struct mach_header *mh)
方法中的最后一行调用了call_load_methods()，这个call_load_methods()中就是实现了+load的调用方式。
下面是call_load_methods()函数的实现 ，大家简单浏览一遍

void call_load_methods(void)
{
    static bool loading = NO;
    bool more_categories;

    loadMethodLock.assertLocked();

    // Re-entrant calls do nothing; the outermost call will finish the job.
    if (loading) return;
    loading = YES;

    void *pool = objc_autoreleasePoolPush();

    do {
        // 1. Repeatedly call class +loads until there aren't any more
        while (loadable_classes_used > 0) {
            call_class_loads();
        }

        // 2. Call category +loads ONCE
        more_categories = call_category_loads();

        // 3. Run more +loads if there are classes OR more untried categories
    } while (loadable_classes_used > 0  ||  more_categories);

    objc_autoreleasePoolPop(pool);

    loading = NO;
}

从源码中很清楚的可以看到， 先调用call_class_loads()， 再调用call_category_loads()，这就说明了在调用所有的+load方法时，实现调用了所有类的+load方法，再去调用分类中的+load方法。
然后我们在进入到call_class_loads()函数中

static void call_class_loads(void)
{
    int i;
    
    // Detach current loadable list.
    struct loadable_class *classes = loadable_classes;
    int used = loadable_classes_used;
    loadable_classes = nil;
    loadable_classes_allocated = 0;
    loadable_classes_used = 0;
    
    // Call all +loads for the detached list.
    for (i = 0; i < used; i++) {
        Class cls = classes[i].cls;
        load_method_t load_method = (load_method_t)classes[i].method;
        if (!cls) continue; 

        if (PrintLoading) {
            _objc_inform("LOAD: +[%s load]\n", cls->nameForLogging());
        }
        (*load_method)(cls, @selector(load));
    }
    
    // Destroy the detached list.
    if (classes) free(classes);
}

从中间的循环中可以看出，是取到了每个类的+load函数的指针，直接通过指针调用了这个函数。 call_category_loads()函数中体现出来的Category的+load方法的调用，也是同理。
同时这也解答了我们的另一个疑惑，那就是为什么总是先调用类的+load，在调用Category的+load。
思考：如果存在继承的情况，+load又会是怎样的调用顺序呢？
从上面call_class_loads()函数中可以看到有一个list：loadable_classes，我们猜测这里面应该就是存放着我们所有的类，因为下面的循环是从0开始循环，所以我们要研究所有的类的+load方法的执行顺序，就要看这个list中的类的顺序是怎么样的。
我们从个源码中可以找到这样一个方法，prepare_load_methods，在其实现中调用了schedule_class_load方法，我们看一下schedule_class_load的源码

static void schedule_class_load(Class cls)
{
    if (!cls) return;
    ASSERT(cls->isRealized());  // _read_images should realize

    if (cls->data()->flags & RW_LOADED) return;

    // Ensure superclass-first ordering
    schedule_class_load(cls->superclass);

    add_class_to_loadable_list(cls);
    cls->setInfo(RW_LOADED); 
}

从源码中schedule_class_load(cls->superclass);这一句中可以看出，递归调用自己本身，并且传入自己的父类，结果递归之后，才调用add_class_to_loadable_list，这就说明父类总是在子类前面加入到list当中，所有在调用一个类的+load方法之前，肯定要先调用其父类的+load方法。
那如果是其他没有继承关系的类呢，这就跟编译顺序有关系了，大家可以自己尝试验证一下。
小结：

• +load方法会在runtime加载类和分类时调用

• 每个类和分类的+load方法之后调用一次

• 调用顺序：先调用类的+load

+initialize
+initialize的调用是不同的，如果某一个类我们没有使用过，他的+initialize方法是不会调用的，到我们使用这个类（调用了类的某个方法）的时候，才会触发+initialize方法的调用。

@implementation Person
+ (void)initialize {
    NSLog(@"Person - initialize");
}
@end

@implementation Person (Test1)
+ (void)initialize {
    NSLog(@"Person Test1 - initialize");
}
@end

@implementation Person (Test2)
+ (void)initialize {
    NSLog(@"Person Test2 - initialize");
}
@end

当我们执行[Person alloc];的时候，才会走+initialize方法，而且执行的Category中的+initialize：

2020-09-14 10:40:23.579623+0800 Category[9134:94173] Person Test2 - initialize

这个我们之前已经说过了，Category的方法会添加list的前面，所以会先被找到并且执行，所以我们猜测+initialize的执行是走的正常的消息机制，objc_msgSend。

由于objc_msgSend实现并没有完全开源，都是汇编代码，所以我们需要换一个思路来研究源码。

objc_msgSend本质是什么？以调用实例方法为例，其实就是通过isa指针找到该类，然后寻找方法，找到之后调用。如果没有找到则通过superClass找到父类，继续查找方法。上面的例子中，我们仅仅是调用了一个alloc方法，但是也执行了+initialize方法，所以我们猜测+initialize会在查找方法的时候调用到。通过这个思路，我们定位到了class_getInstanceMethod()函数（class_getInstanceMethod函数就是在类中查找某个sel时候调用的），在这个函数中，又调用了IMP lookUpImpOrForward(id inst, SEL sel, Class cls, int behavior)

在该函数中我们可以找到下面这段代码

if ((behavior & LOOKUP_INITIALIZE)  &&  !cls->isInitialized()) {
    initializeNonMetaClass (_class_getNonMetaClass(cls, inst));
}

可以看出如果类还没有执行+initialize 就会先执行，我们再看一下if语句中的initializeNonMetaClass函数，他会先拿到superClass，执行superClass的+initialize

supercls = cls->superclass;
if (supercls  &&  !supercls->isInitialized()) {
    initializeNonMetaClass(supercls);
}

这就是存在继承的情况，为什么会先执行父类的+initialize。

大总结

1. 调用方式：
   load是根据函数地址直接调用
   initialize是通过消息机制objc_msgSend调用
   

2. 调用时刻：
   

   load是在runtime加载类和分类时调用（只会调用一次）
   initialize是在类第一次收到消息时调用个，默认没有继承的情况下每个类只会initialize一次（父类的initialize可能会被执行多次）

3. 调用顺序
   

   load
   先调用类的load：先编译的类先调用，子类调用之前，先调用父类的
   在调用Category的load：先编译的先调用
   

   initialize
   先初始化父类
   在初始化子类（初始化子类可能调用父类的initialize）

补充
上面总结的时候说到父类的initialize会被执行多次，什么情况下会被执行多次，为什么？举个例子：

@implementation Person
+ (void)initialize {
    NSLog(@"Person - initialize");
}
@end

@implementation Student
@end

Student类继承Person类，并且只有父类Person中实现了+initialize，Student类中并没有实现
此时我们调用[Student alloc];， 会得到如下的打印。

2020-09-14 11:31:55.377569+0800 Category[11483:125034] Person - initialize
2020-09-14 11:31:55.377659+0800 Category[11483:125034] Person - initialize

Person的+initialize被执行了两次，但这两个意义是不同的，第一次执行是因为在调用子类的+initialize方法之前必须先执行父类的了+initialize，所以会打印一次。当要执行子类的+initialize时，通过消息机制，student类中并没有找到实现的+initialize的实现，所以要通过superClass指针去到父类中继续查找，因为父类中实现了+initialize，所以才会有了第二次的打印。

结尾
本文的篇幅略长，笔者按照自己的思路和想法写完了此文，陈述过程不一定那么调理和完善，大家在阅读过程中发现问题，可以留言交流。
感谢阅读。

转自：https://www.jianshu.com/p/141b04e376d4

接上一章。。。。。。。

三、NSNotification Crash

#import 

/**
 当一个对象添加了notification之后，如果dealloc的时候，仍然持有notification，就会出现NSNotification类型的crash。
 
 iOS9之后专门针对于这种情况做了处理，所以在iOS9之后，即使开发者没有移除observer，Notification crash也不会再产生了
 */

NS_ASSUME_NONNULL_BEGIN

@interface NSObject (NSNotificationCrash)

+ (void)xz_enableNotificationProtector;

@end

NS_ASSUME_NONNULL_END

#import "NSObject+NSNotificationCrash.h"
#import "NSObject+XZSwizzle.h"
#import 


static const char *isNSNotification = "isNSNotification";

@implementation NSObject (NSNotificationCrash)


+ (void)xz_enableNotificationProtector {
    
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        NSObject *objc = [[NSObject alloc] init];
        
        [objc xz_instanceSwizzleMethod:@selector(addObserver:selector:name:object:) replaceMethod:@selector(xz_addObserver:selector:name:object:)];
        
        // 在ARC环境下不能显示的@selector dealloc。
        [objc xz_instanceSwizzleMethod:NSSelectorFromString(@"dealloc") replaceMethod:NSSelectorFromString(@"xz_dealloc")];
    });
}

- (void)xz_addObserver:(id)observer selector:(SEL)aSelector name:(nullable NSNotificationName)aName object:(nullable id)anObject {
    
    // 添加标志位，在delloc中只有isNSNotification是YES，才会移除通知
    [observer setIsNSNotification:YES];
    [self xz_addObserver:observer selector:aSelector name:aName object:anObject];
}


- (void)setIsNSNotification:(BOOL)yesOrNo {
    objc_setAssociatedObject(self, isNSNotification, @(yesOrNo), OBJC_ASSOCIATION_RETAIN_NONATOMIC);
}

- (BOOL)isNSNotification {
    NSNumber *number = objc_getAssociatedObject(self, isNSNotification);;
    return  [number boolValue];
}

/**
 如果一个对象从来没有添加过通知，那就不要remove操作
 */
- (void)xz_dealloc
{
    if ([self isNSNotification]) {
        NSLog(@"CrashProtector: %@ is dealloc，but NSNotificationCenter Also exsit",self);
        [[NSNotificationCenter defaultCenter] removeObserver:self];
    }
    
    [self xz_dealloc];
}

@end

#import 

NS_ASSUME_NONNULL_BEGIN

@interface XZProxy : NSProxy

+ (instancetype)proxyWithTarget:(id)target;

@end

NS_ASSUME_NONNULL_END

#import "XZProxy.h"


@interface XZProxy ()

/// 消息转发的对象
@property (nonatomic, weak) id target;

@end

@implementation XZProxy

+ (instancetype)proxyWithTarget:(id)target {
    // NSProxy没有init方法, 只需要调用alloc创建对象即可
    XZProxy *proxy = [XZProxy alloc];
    proxy.target = target;
    return proxy;
}

- (nullable NSMethodSignature *)methodSignatureForSelector:(SEL)sel {
    return [self.target methodSignatureForSelector:sel];
}

- (void)forwardInvocation:(NSInvocation *)invocation {
    [invocation invokeWithTarget:self.target];
}

@end

#import 

NS_ASSUME_NONNULL_BEGIN

@interface NSObject (NSTimerCrash)

+ (void)xz_enableTimerProtector;

@end

NS_ASSUME_NONNULL_END

#import "NSObject+NSTimerCrash.h"
#import "NSObject+XZSwizzle.h"
#import "XZProxy.h"

@implementation NSObject (NSTimerCrash)


+ (void)xz_enableTimerProtector {
    
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        
        // 创建一个timer并把它指定到一个默认的runloop模式中，并且在 TimeInterval时间后 启动定时器
        [NSTimer xz_classSwizzleMethod:@selector(scheduledTimerWithTimeInterval:target:selector:userInfo:repeats:) replaceMethod:@selector(xz_scheduledTimerWithTimeInterval:target:selector:userInfo:repeats:)];
        
        // 创建一个定时器，但是么有添加到运行循环，我们需要在创建定时器后手动的调用 NSRunLoop 对象的 addTimer:forMode: 方法。
        [NSTimer xz_classSwizzleMethod:@selector(timerWithTimeInterval:target:selector:userInfo:repeats:) replaceMethod:@selector(xz_timerWithTimeInterval:target:selector:userInfo:repeats:)];
    });
}


+ (NSTimer *)xz_scheduledTimerWithTimeInterval:(NSTimeInterval)timeInterval target:(id)target selector:(SEL)selector userInfo:(id)userInfo repeats:(BOOL)repeats {
    
    return [self xz_scheduledTimerWithTimeInterval:timeInterval target:[XZProxy proxyWithTarget:target] selector:selector userInfo:userInfo repeats:repeats];
}

+ (NSTimer *)xz_timerWithTimeInterval:(NSTimeInterval)timeInterval target:(id)target selector:(SEL)aSelector userInfo:(nullable id)userInfo repeats:(BOOL)yesOrNo {
    
    return [self xz_timerWithTimeInterval:timeInterval target:[XZProxy proxyWithTarget:target] selector:aSelector userInfo:userInfo repeats:yesOrNo];
}

@end

摘自链接：https://www.jianshu.com/p/3324786893a1

iOS 的崩溃

我们常见的crash有哪些呢？

1.unrecognized selector crash (没找到对应的函数)

2.KVO crash :(KVO的被观察者dealloc时仍然注册着KVO导致的crash，添加KVO重复添加观察者或重复移除观察者 )

3.NSNotification crash:(当一个对象添加了notification之后，如果dealloc的时候，仍然持有notification)

4.NSTimer类型crash:(需要在合适的时机invalidate 定时器，否则就会由于定时器timer强引用target的关系导致 target不能被释放，造成内存泄露，甚至在定时任务触发时导致crash)

5.Container类型crash:(数组，字典，常见的越界，插入，nil)

6.野指针类型的crash

7.非主线程刷UI类型：(在非主线程刷UI将会导致app运行crash）……

如何防护crash

一、unrecognized selector crash

unrecognized selector类型的crash，通常是因为一个对象调用了一个不属于它方法的方法导致的。而我们可以从方法调用的过程中，寻找到避免程序崩溃的突破口。

方法调用的过程是哪样的呢？

方法调用的过程--调用实例方法
1.在对象的<缓存方法列表> 中去找要调用的方法，找到直接执行其实现。
2.对象的<缓存方法列表> 里没找到，就去<类的方法列表>里找，找到了就执行其实现。
3.还没找到，说明这个类自己没有了，就会通过isa去向其父类里执行1、2。
4.如果找到了根类还没找到，那么就是没有了，会转向一个拦截调用的方法，可以自己在拦截调用方法里面做一些处理。
5.如果没有在拦截调用里做处理，那么就会报错崩溃。

方法调用的过程--调用类方法
1.在类的<缓存方法列表> 中去找要调用的方法，找到直接执行其实现。
2.类的<缓存方法列表> 里没找到，就去里找，找到了就执行其实现。
3.还没找到，说明这个类自己没有了，就会通过isa去meta类的父类里执行1、2。
4.如果找到了根meta类还没找到，那么就是没有了，会转向一个拦截调用的方法，可以自己在拦截调用方法里面做一些处理。
5.如果没有在拦截调用里做处理，那么就会报错崩溃。

从上面的方法调用过程可以看出，在找不到调用的方法程序崩溃之前，我们可以通过重写NSObject方法进行拦截调用，阻止程序的crash。这里面就用到了消息的转发机制：

runtime提供了3种方式去补救：

1：调用resolveInstanceMethod给个机会让类添加这个实现这个函数
2：调用forwardingTargetForSelector让别的对象去执行这个函数
3：调用forwardInvocation(函数执行器)灵活的将目标函数以及其他形式执行。

#import 


@interface XZUnrecognizedSelectorSolveObject : NSObject

@property (nonatomic, weak) NSObject *objc;

@end

#Import "XZUnrecognizedSelectorSolveObject.h"
#import 

@interface XZUnrecognizedSelectorSolveObject ()

@end

@implementation XZUnrecognizedSelectorSolveObject

+ (BOOL)resolveInstanceMethod:(SEL)sel {
    // 如果没有动态添加方法的话，还会调用forwardingTargetForSelector:方法，从而造成死循环
    class_addMethod([self class], sel, (IMP)addMethod, "v@:@");
    return YES;
}

id addMethod(id self, SEL _cmd) {
    NSLog(@"WOCrashProtector: unrecognized selector: %@", NSStringFromSelector(_cmd));
    return 0;
}

@end

#import 

NS_ASSUME_NONNULL_BEGIN

@interface NSObject (SelectorCrash)

+ (void)xz_enableSelectorProtector;

@end

NS_ASSUME_NONNULL_END

#import "NSObject+SelectorCrash.h"
#import 
#import "NSObject+XZSwizzle.h"
#Import "XZUnrecognizedSelectorSolveObject.h"

@implementation NSObject (SelectorCrash)

+ (void)xz_enableSelectorProtector {
    
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        NSObject *object = [[NSObject alloc] init];
        [object xz_instanceSwizzleMethod:@selector(forwardingTargetForSelector:) replaceMethod:@selector(xz_forwardingTargetForSelector:)];
    });
}

- (id)xz_forwardingTargetForSelector:(SEL)aSelector {
    // 判断某个类是否有某个实例方法，有则返回YES，否则返回NO
    if (class_respondsToSelector([self class], @selector(forwardInvocation:))) {
        // 有forwardInvocation实例方法
        IMP impOfNSObject = class_getMethodImplementation([NSObject class], @selector(forwardInvocation:));
        IMP imp = class_getMethodImplementation([self class], @selector(forwardInvocation:));
        
        if (imp != impOfNSObject) {
            return nil;
        }
    }
    
    // 新建桩类转发消息
    XZUnrecognizedSelectorSolveObject *solveObject = [XZUnrecognizedSelectorSolveObject new];
    solveObject.objc = self;
    return solveObject;
}

@end

#import 

NS_ASSUME_NONNULL_BEGIN

@interface NSObject (XZSwizzle)

/**
 对类方法进行拦截并替换
 
 @param originalSelector 原有类方法
 @param replaceSelector 自定义类替换方法
 */
+ (void)xz_classSwizzleMethod:(SEL _Nonnull)originalSelector replaceMethod:(SEL _Nonnull)replaceSelector;

/**
 对类方法进行拦截并替换
 
 @param kClass 具体的类
 @param originalSelector 原有类方法
 @param replaceSelector 自定义类替换方法
 */
+ (void)xz_classSwizzleMethodWithClass:(Class _Nonnull)kClass orginalMethod:(SEL _Nonnull)originalSelector replaceMethod:(SEL _Nonnull)replaceSelector;



/**
 对实例方法进行拦截并替换
 
 @param originalSelector 原有实例方法
 @param replaceSelector 自定义实例替换方法
 */
- (void)xz_instanceSwizzleMethod:(SEL _Nonnull)originalSelector replaceMethod:(SEL _Nonnull)replaceSelector;

/**
 对实例方法进行拦截并替换
 
 @param kClass 具体的类
 @param originalSelector 原有实例方法
 @param replaceSelector 自定义实例替换方法
 */
- (void)xz_instanceSwizzleMethodWithClass:(Class _Nonnull)kClass orginalMethod:(SEL _Nonnull)originalSelector replaceMethod:(SEL _Nonnull)replaceSelector;

@end

NS_ASSUME_NONNULL_END

#import "NSObject+XZSwizzle.h"
#import 

@implementation NSObject (XZSwizzle)


/**
 对类方法进行拦截并替换
 
 @param originalSelector 类原有方法
 @param replaceSelector 自定义替换方法
 */
+ (void)xz_classSwizzleMethod:(SEL _Nonnull)originalSelector replaceMethod:(SEL _Nonnull)replaceSelector {
    Class class = [self class];
    
    [self xz_classSwizzleMethodWithClass:class orginalMethod:originalSelector replaceMethod:replaceSelector];
}

/**
 对类方法进行拦截并替换
 
 @param kClass 具体的类
 @param originalSelector 原有类方法
 @param replaceSelector 自定义类替换方法
 */
+ (void)xz_classSwizzleMethodWithClass:(Class _Nonnull)kClass orginalMethod:(SEL _Nonnull)originalSelector replaceMethod:(SEL _Nonnull)replaceSelector {
    
    // Method中包含IMP函数指针，通过替换IMP，使SEL调用不同函数实现
    Method originalMethod = class_getClassMethod(kClass, originalSelector);
    Method replaceMethod = class_getClassMethod(kClass, replaceSelector);
    
    // 获取MetaClass (交换、添加等类方法需要用metaClass)
    Class metaClass = objc_getMetaClass(NSStringFromClass(kClass).UTF8String);
    
    // class_addMethod:如果发现方法已经存在，会失败返回，也可以用来做检查用,我们这里是为了避免源方法没有实现的情况;如果方法没有存在,我们则先尝试添加被替换的方法的实现
    BOOL didAddMethod = class_addMethod(metaClass, originalSelector, method_getImplementation(replaceMethod), method_getTypeEncoding(replaceMethod));
    
    if (didAddMethod) {
        // 添加成功（原方法未实现，为防止crash，需要将刚添加的原方法替换）
        class_replaceMethod(metaClass, replaceSelector, method_getImplementation(originalMethod), method_getTypeEncoding(originalMethod));
    } else {
        // 添加失败（原本就有原方法, 直接交换两个方法）
        method_exchangeImplementations(originalMethod, replaceMethod);
    }
}


/**
 对实例方法进行拦截并替换
 
 @param originalSelector 原有实例方法
 @param replaceSelector 自定义实例替换方法
 */
- (void)xz_instanceSwizzleMethod:(SEL _Nonnull)originalSelector replaceMethod:(SEL _Nonnull)replaceSelector {
    Class class = [self class];
    
    [self xz_instanceSwizzleMethodWithClass:class orginalMethod:originalSelector replaceMethod:replaceSelector];
}

/**
 对实例方法进行拦截并替换
 
 @param kClass 具体的类
 @param originalSelector 原有实例方法
 @param replaceSelector 自定义实例替换方法
 */
- (void)xz_instanceSwizzleMethodWithClass:(Class _Nonnull)kClass orginalMethod:(SEL _Nonnull)originalSelector replaceMethod:(SEL _Nonnull)replaceSelector {
    
    Method originalMethod = class_getInstanceMethod(kClass, originalSelector);
    Method replaceMethod = class_getInstanceMethod(kClass, replaceSelector);
    
    // class_addMethod:如果发现方法已经存在，会失败返回，也可以用来做检查用,我们这里是为了避免源方法没有实现的情况;如果方法没有存在,我们则先尝试添加被替换的方法的实现
    BOOL didAddMethod = class_addMethod(kClass, originalSelector, method_getImplementation(replaceMethod), method_getTypeEncoding(replaceMethod));
    
    if (didAddMethod) {
        // 添加成功（原方法未实现，为防止crash，需要将刚添加的原方法替换）
        class_replaceMethod(kClass, replaceSelector, method_getImplementation(originalMethod), method_getTypeEncoding(originalMethod));
    } else {
        // 添加失败（原本就有原方法, 直接交换两个方法）
        method_exchangeImplementations(originalMethod, replaceMethod);
    }
}

@end

#import 
#import "XZKVOProxy.h"

NS_ASSUME_NONNULL_BEGIN

@interface NSObject (KVOCrash)

@property (nonatomic, strong) XZKVOProxy * _Nullable KVOProxy;  // 自定义的kvo关系的代理

@end

NS_ASSUME_NONNULL_END

#import "NSObject+KVOCrash.h"
#import "XZKVOProxy.h"
#import 


#pragma mark - NSObject + KVOCrash

static void *NSObjectKVOProxyKey = &NSObjectKVOProxyKey;

@implementation NSObject (KVOCrash)

- (XZKVOProxy *)KVOProxy {
    id proxy = objc_getAssociatedObject(self, NSObjectKVOProxyKey);
    
    if (nil == proxy) {
        proxy = [XZKVOProxy kvoProxyWithObserver:self];
        self.KVOProxy = proxy;
    }
    
    return proxy;
}

- (void)setKVOProxy:(XZKVOProxy *)proxy
{
    objc_setAssociatedObject(self, NSObjectKVOProxyKey, proxy, OBJC_ASSOCIATION_RETAIN_NONATOMIC);
}

@end

#import 


typedef void (^XZKVONitificationBlock)(id _Nullable observer, id _Nullable object, NSDictionary * _Nullable change);

/**
 KVO配置类
 用于存储KVO里面的相关设置参数
 */
@interface XZKVOInfo : NSObject

//- (instancetype _Nullable)initWithObserver:(id _Nonnull)object keyPath:(NSString * _Nullable)keyPath options:(NSKeyValueObservingOptions)options context:(void * _Nullable)context block:(XZKVONitificationBlock _Nonnull )block;

@end


NS_ASSUME_NONNULL_BEGIN
/**
 KVO管理类
 用于管理object添加和移除的消息，（通过Map进行KVO之间的关系）（字典应该也可以）
 */
@interface XZKVOProxy : NSObject

@property (nullable, nonatomic, weak, readonly) id observer;


+ (instancetype)kvoProxyWithObserver:(nullable id)observer;

- (void)xz_observer:(id _Nullable)object keyPath:(NSString * _Nullable)keyPath options:(NSKeyValueObservingOptions)options context:(void * _Nullable)context block:(XZKVONitificationBlock)block;

- (void)xz_unobserver:(id _Nullable)object keyPath:(NSString * _Nullable)keyPath;
- (void)xz_unobserver:(id _Nullable)object;

- (void)xz_unobserverAll;

@end

NS_ASSUME_NONNULL_END

#import "XZKVOProxy.h"
#import 


@interface XZKVOInfo ()
{
    @public
    __weak id _object;  // 观察对象
    NSString *_keyPath;
    NSKeyValueObservingOptions _options;
    SEL _action;
    void *_context;
    XZKVONitificationBlock _block;
}
@end

@implementation XZKVOInfo

- (instancetype _Nullable)initWithObserver:(id _Nonnull)object
                                   keyPath:(NSString * _Nullable)keyPath
                                   options:(NSKeyValueObservingOptions)options
                                   context:(void * _Nullable)context {
    return [self initWithObserver:object keyPath:keyPath options:options block:NULL action:NULL context:context];
}

- (instancetype _Nullable)initWithObserver:(id _Nonnull)object
                                   keyPath:(NSString * _Nullable)keyPath
                                   options:(NSKeyValueObservingOptions)options
                                   context:(void * _Nullable)context
                                     block:(XZKVONitificationBlock)block {
    
    return [self initWithObserver:object keyPath:keyPath options:options block:block action:NULL context:context];
}

- (instancetype _Nullable)initWithObserver:(id _Nonnull)object
                                   keyPath:(NSString * _Nullable)keyPath
                                  options:(NSKeyValueObservingOptions)options
                                    block:(_Nullable XZKVONitificationBlock)block
                                   action:(_Nullable SEL)action
                                  context:(void * _Nullable)context {
    if (self = [super init]) {
        _object = object;
        _block = block;
        _keyPath = [keyPath copy];
        _options = options;
        _action = action;
        _context = context;
    }
    return self;
}

@end



/**
 此类用来管理混乱的KVO关系
 让被观察对象持有一个KVO的delegate，所有和KVO相关的操作均通过delegate来进行管理，delegate通过建立一张map来维护KVO整个关系
 
 好处：
 不会crash如果出现KVO重复添加观察者或重复移除观察者（KVO注册观察者与移除观察者不匹配）的情况，delegate可以 1.直接阻止这些非正常的操作。
 
 crash 2.被观察对象dealloc之前，可以通过delegate自动将与自己有关的KVO关系都注销掉，避免了KVO的被观察者dealloc时仍然注册着KVO导致的crash。
 
 👇：
 重复添加观察者不会crash，即不会走@catch
 多次添加对同一个属性观察的观察者，系统方法内部会强应用这个观察者，同理即可remove该观察者同样次数。
 
 */
@interface XZKVOProxy ()
{
    pthread_mutex_t _mutex;
    NSMapTable *> *_objectInfoMap;///< map来维护KVO整个关系
}
@end

@implementation XZKVOProxy

+ (instancetype)kvoProxyWithObserver:(nullable id)observer {
    return [[self alloc] initWithObserver:observer];
}

- (instancetype)initWithObserver:(nullable id)observer {
    if (self = [super init]) {
        _observer = observer;
        _objectInfoMap = [[NSMapTable alloc] initWithKeyOptions:NSPointerFunctionsStrongMemory | NSPointerFunctionsObjectPointerPersonality valueOptions:NSPointerFunctionsStrongMemory | NSPointerFunctionsObjectPointerPersonality capacity:0];
    }
    return self;
}

/**
 加锁、解锁
 */
- (void)lock {
    pthread_mutex_lock(&_mutex);
}

- (void)unlock {
    pthread_mutex_unlock(&_mutex);
}


/**
 添加、删除 观察者
 */
- (void)xz_observer:(id _Nullable)object keyPath:(NSString * _Nullable)keyPath options:(NSKeyValueObservingOptions)options context:(void * _Nullable)context block:(XZKVONitificationBlock)block {
    
    // 断言
    NSAssert(0 != keyPath.length && NULL != block, @"missing required parameters observe:%@ keyPath:%@ block:%p", object, keyPath, block);
    if (nil == object || 0 == keyPath.length || NULL == block) {
      return;
    }
    
    // 将观察的信息转成info对象
    // self即kvoProxy是观察者；object是被观察者
    XZKVOInfo *info = [[XZKVOInfo alloc] initWithObserver:self keyPath:keyPath options:options context:context block:block];
    
    if (info) {
        // 将info以key-value的形式存储到map中。key是被观察对象；value是观察信息的集合。
        // 加锁
        [self lock];
        
        NSMutableSet *infos = [_objectInfoMap objectForKey:object];
        
        
        BOOL _isExisting = NO;
        for (XZKVOInfo *existingInfo in infos) {
            if ([existingInfo->_keyPath isEqualToString:info->_keyPath]) {
                // 观察者已存在
                _isExisting = YES;
                break;
            }
        }
        
        if (_isExisting == YES) {
            // 解锁
            [self unlock];
            return;
        }
//        // check for info existence
//        XZKVOInfo *existingInfo = [infos member:info];
//        if (nil != existingInfo) {
//            // observation info already exists; do not observe it again
//
//            // 解锁
//            [self unlock];
//            return;
//        }
        
        // 不存在
        if (infos == nil) {
            // 创建set，并将set添加进Map里
            infos = [NSMutableSet set];
            [_objectInfoMap setObject:infos forKey:object];
        }
        // 将要添加的KVOInfo添加进set里面
        [infos addObject:info];
        
        // 解锁
        [self unlock];
        
        
        // 将 kvoProxy 作为观察者；添加观察者
        [object addObserver:self forKeyPath:info->_keyPath options:info->_options context:info->_context];
    }
}

- (void)xz_unobserver:(id _Nullable)object keyPath:(NSString * _Nullable)keyPath {
    
    // 将观察的信息转成info对象
    // self即kvoProxy是观察者；object是被观察者
    XZKVOInfo *info = [[XZKVOInfo alloc] initWithObserver:self keyPath:keyPath options:0 context:nil];
    
    // 加锁
    [self lock];
    
    // 从map中获取object对应的KVOInfo集合
    NSMutableSet *infos = [_objectInfoMap objectForKey:object];
    
    BOOL _isExisting = NO;
    for (XZKVOInfo *existingInfo in infos) {
        if ([existingInfo->_keyPath isEqualToString:info->_keyPath]) {
            // 观察者已存在
            _isExisting = YES;
            info = existingInfo;
            break;
        }
    }
    
    if (_isExisting == YES) {
        // 存在
        [infos removeObject:info];
        
        // remove no longer used infos
        if (0 == infos.count) {
            [_objectInfoMap removeObjectForKey:object];
        }
        
        // 解锁
        [self unlock];
        
        
        // 移除观察者
        [object removeObserver:self forKeyPath:info->_keyPath context:info->_context];
    } else {
        // 解锁
        [self unlock];
    }
    
//    XZKVOInfo *registeredInfo = [infos member:info];
//
//    if (nil != registeredInfo) {
//        [infos removeObject:registeredInfo];
//
//        // remove no longer used infos
//        if (0 == infos.count) {
//            [_objectInfoMap removeObjectForKey:object];
//        }
//
//        // 解锁
//        [self unlock];
//
//
//        // 移除观察者
//        [object removeObserver:self forKeyPath:registeredInfo->_keyPath context:registeredInfo->_context];
//    } else {
//        // 解锁
//        [self unlock];
//    }
}

- (void)xz_unobserver:(id _Nullable)object {
    // 加锁
    [self lock];
    
    // 从map中获取object对应的KVOInfo集合
    NSMutableSet *infos = [_objectInfoMap objectForKey:object];

    [_objectInfoMap removeObjectForKey:object];
    // 解锁
    [self unlock];
    
    // 批量移除观察者
    for (XZKVOInfo *info in infos) {
        // 移除观察者
        [object removeObserver:self forKeyPath:info->_keyPath context:info->_context];
    }
}

- (void)xz_unobserverAll {
    
    if (_objectInfoMap) {
        // 加锁
        [self lock];
        
        // copy一份map，防止删除数据异常冲突
        NSMapTable *objectInfoMaps = [_objectInfoMap copy];
        
        [_objectInfoMap removeAllObjects];
        
        // 解锁
        [self unlock];
        
        // 移除全部观察者
        for (id object in objectInfoMaps) {
            
            NSSet *infos = [objectInfoMaps objectForKey:object];
            if (!infos || infos.count == 0) {
                continue;
            }
            
            for (XZKVOInfo *info in infos) {
                [object removeObserver:self forKeyPath:info->_keyPath context:info->_context];
            }
        }
        
    }
}



- (void)observeValueForKeyPath:(NSString *)keyPath
                      ofObject:(id)object
                        change:(NSDictionary *)change
                       context:(void *)context {
    
//    NSAssert(context, @"missing context keyPath:%@ object:%@ change:%@", keyPath, object, change);
    
    
    
    NSLog(@"%@",keyPath);
    NSLog(@"%@",object);
    NSLog(@"%@",change);
    NSLog(@"%@",context);
    
    
    // 从map中获取object对应的KVOInfo集合
    NSMutableSet *infos = [_objectInfoMap objectForKey:object];
    
    BOOL _isExisting = NO;
    XZKVOInfo *info;
    for (XZKVOInfo *existingInfo in infos) {
        if ([existingInfo->_keyPath isEqualToString:keyPath]) {
            // 观察者已存在
            _isExisting = YES;
            info = existingInfo;
            break;
        }
    }
    
    if (_isExisting == YES && info) {
        XZKVOProxy *proxy = info->_object;
        id observer = proxy.observer;
        
        XZKVONitificationBlock block = info->_block;
        
        if (block) {
            block(observer, object, change);
        }
    }
}



- (void)dealloc {
    
    // 移除所有观察者
    [self xz_unobserverAll];
    
    // 销毁mutex
    pthread_mutex_destroy(&_mutex);
}

@end

性能优化的几个点：

1.卡顿优化

在了解卡顿优化相关的前头，首先要了解 CPU 和 GPU。

CPU（Central Processing Unit，中央处理器）
对象的创建和销毁、对象属性的调整、布局计算、文本的计算和排版、图片的格式转换和解码、图像的绘制（Core Graphics）都是通过 CPU 来做的。

GPU（Graphics Processing Unit，图形处理器）
纹理的渲染、

所要显示的信息一般是通过 CPU 计算或者解码，经过 CPU 的数据交给 GPU 渲染，渲染的工作在帧缓存的地方完成，然后从帧缓存读取数据到视频控制器上，最终显示在屏幕上。

在 iOS 中有双缓存机制，有前帧缓存、后帧缓存，这样渲染的效率很高。

屏幕成像原理

我们所看到的动态的屏幕的成像其实和视频一样也是一帧一帧组成的。为了把显示器的显示过程和系统的视频控制器进行同步，显示器（或者其他硬件）会用硬件时钟产生一系列的定时信号。当电子枪换到新的一行，准备进行扫描时，显示器会发出一个水平同步信号（Horizonal Synchronization），简称 HSync；而当一帧画面绘制完成后，电子枪回复到原位，准备画下一帧前，显示器会发出一个垂直同步信号（Vertical Synchronization），简称 VSync。显示器通常以固定频率进行刷新，这个刷新率就是 VSync 信号产生的频率。

卡顿成因

前面我们知道，完成显示信息的过程是：CPU 计算数据 -> GPU 进行渲染 -> 屏幕发出 VSync 信号 -> 成像，假如屏幕已经发出了 VSync 但 GPU 还没有渲染完成，则只能将上一次的数据显示出来，以致于当前计算的帧数据丢失，这样就产生了卡顿，当前的帧数据计算好后只能等待下一个周期去渲染。

解决办法

解决卡顿现象的主要思路就是：尽可能减少 CPU 和 GPU 资源的消耗。
按照 60fps 的刷帧率，每隔 16ms 就会有一次 VSync 信号产生。那么针对 CPU 和 GPU 有以下优化方案：

CPU

尽量用轻量级的对象 如：不用处理事件的 UI 控件可以考虑使用 CALayer；

不要频繁地调用 UIView 的相关属性 如：frame、bounds、transform 等；

尽量提前计算好布局，在有需要的时候一次性调整对应属性，不要多次修改；

Autolayout 会比直接设置 frame 消耗更多的 CPU 资源；

图片的 size 和 UIImageView 的 size 保持一致；

控制线程的最大并发数量；

耗时操作放入子线程；如文本的尺寸计算、绘制，图片的解码、绘制等；

GPU

• 尽量避免短时间内大量图片显示；

• GPU 能处理的最大纹理尺寸是 4096 * 4096，超过这个尺寸就会占用 CPU 资源，所以纹理不能超过这个尺寸；

• 尽量减少透视图的数量和层次；

• 减少透明的视图（alpha < 1），不透明的就设置 opaque 为 YES；

• 尽量避免离屏渲染；

离屏渲染

在 OpenGL 中，GPU 有两种渲染方式：

On-Screen Rendering：当前屏幕渲染，在当前用于显示的屏幕缓冲区进行渲染操作；
Off-Screen Rendering：离屏渲染，在当前屏幕缓冲区外开辟新的缓冲区进行渲染操作；

离屏渲染消耗性能的原因：

离屏渲染的整个过程，需要多次切换上下文环境，先是从当前屏幕（On-Screen）切换到离屏（Off-Screen），渲染结束后，将离屏缓冲区的渲染结果显示到屏幕上，上下文环境从离屏切换到当前屏幕，这个过程会造成性能的消耗。

哪些操作会触发离屏渲染？

光栅化，layer.shouldRasterize = YES

遮罩，layer.mask

圆角，同时设置 layer.masksToBounds = YES，layer.cornerRadius > 0

• 可以用 CoreGraphics 绘制裁剪圆角

阴影

• 如果设置了 layer.shadowPath 不会产生离屏渲染

卡顿检测

这里的卡顿检测主要是针对在主线程执行了耗时的操作所造成的，这样可以通过 RunLoop 来检测卡顿：添加 Observer 到主线程 RunLoop 中，通过监听 RunLoop 状态的切换的耗时，达到监控卡顿的目的。

耗电优化

耗电的主要来源为：

1.CPU 处理；

2.网络请求；

3.定位；

4.图像渲染；

优化思路

1.尽可能降低 CPU、GPU 功耗；

2.少用定时器；

3.优化 I/O 操作；

尽量不要频繁写入小数据，最好一次性批量写入；
读写大量重要数据时，可以用 dispatch_io，它提供了基于 GCD 的异步操作文件的 API，使用该 API 会优化磁盘访问；
数据量大时，用数据库管理数据；

4.网络优化；

减少、压缩网络数据（JSON 比 XML 文件性能更高）；

若多次网络请求结果相同，尽量使用缓存；

使用断点续传，否则网络不稳定时可能多次传输相同的内容；

网络不可用时，不进行网络请求；

让用户可以取消长时间运行或者速度很慢的网络操作，设置合适的超时时间；

批量传输，如下载视频，不要传输很小的数据包，直接下载整个文件或者大块下载，然后慢慢展示；

5.定位优化

如果只是需要快速确定用户位置，用 CLLocationManager 的 requestLocation 方法定位，定位完成后，定位硬件会自动断电；

若不是导航应用，尽量不要实时更新位置，并为完毕就关掉定位服务；

尽量降低定位精度，如不要使用精度最高的 KCLLocationAccuracyBest；

需要后台定位时，尽量设置 pausesLocationUpdatesAutomatically 为 YES，若用户不怎么移动的时候，系统会自暂停位置更新；

启动优化

App 的启动分为两种：冷启动（Cold Launch） 和热启动（Warm Launch）。
前者表示从零开始启动 App，后者表示 App 已经存在内存中，在后台依然活着，再次点击图标启动 App。

App 启动的优化主要是针对冷启动的优化，通过添加环境变量可以打印出 App 的启动时间分析：Edit Scheme -> Run -> Arguments -> Environment Variables 添加 DYLD_PRINT_STATISTICS 设置为 1。

运行程序则会打印：

这里打印的是在执行 main 函数之前的耗时信息，若想打印更详细的信息则添加环境变量为：
DYLD_PRINT_STATISTICS_DETAILS 设置为 1。

App 冷启动

冷启动可分为三个阶段：dyld 阶段、Runtime 阶段、main 阶段。

第一个阶段就是处理程序的镜像的阶段，第二个阶段是加载本程序的类、分类信息等等的 Runtime 阶段，最后是调用 main 函数阶段。

dyld

dyld（Dynamic Link Editor），Apple 的动态链接器，可以用来装载 Mach-O 文件（可执行文件、动态库等）

启动 App 时，dyld 会装载 App 的可执行文件，同时会递归加载所有依赖的动态库，当 dyld 把可执行文件、动态库都装载完毕后，会通知 Runtime 进行做下一步的处理。

Runtime

启动 App 时，调用 map_images 进行可执行文件的内容解析和处理，再 load_images 中调用 call_load_methods调用所有 Class 和 Category 的 load 方法，然后进行 objc 结构的初始化（注册类、初始化类对象等）。然后调用 C++ 静态初始化器和 __attribute_((constructor)) 修饰的函数，到此为止，可执行文件的和动态库中所有的符号（类、协议、方法等）都已经按照格式加载到内存中，被 Runtime 管理。

main

在 Runtime 阶段完成后，dyld 会调用 main 函数，接下来是 UIApplication 函数，AppDelegate 的 application: didFinishLaunchingWithOptions: 函数。

启动优化思路

针对不同的阶段，有不同的优化思路：
dyld

1.减少动态库、合并动态库，定期清理不必要的动态库；

2.减少类、分类的数量，减少 Selector 的数量，定期清理不必要的类、分类；

3.减少 C++ 虚函数数量；

4.Swift 开发尽量使用 struct；

虚函数和 Java 中的抽象函数有点类似，但区别是，基类定义的虚函数，子类可以实现也可以不实现，而抽象函数子类一定要实现。

Runtime

用 inilialize 方法和 dispatch_once 取代所有的 __attribute_((constructor))、C++ 静态构造器、以及 Objective-C 中的 load 方法；

main
将一些耗时操作延迟执行，不要全部都放在 finishLaunching 方法中；

安装包瘦身

安装包（ipa）主要由可执行文件和资源文件组成，若不管理妥善则会造成安装包体积越来越大，所以针对资源优化我们可以将资源采取无损压缩，去除没用的资源。

对于可执行文件的瘦身，我们可以：

1.从编译器层面优化

1.Strip Linked Product、Make Strings Read-Only、Symbols Hidden by Default 设置为 YES
2.去掉异常支持，Enable C++ Exceptions、Enable Objective-C Exceptions 设置为 NO，Other C Flags 添加 -fno-exceptions；
3.利用 AppCode，检测未使用代码检测：菜单栏 -> Code -> Inspect Code；
4.编写 LLVM 插件检测重复代码、未调用代码；
5.通过生成 LinkMap 文件检测；

LinkMap

Build Setting -> LD_MAP_FILE_PATH: 设置文件路径 ，Build Setting -> LD_GENERSTE_MAP_FILE -> YES

运行程序可看到：

打开可看见各种信息：

我们可根据这个信息针对某个类进行优化。

摘自链接：https://www.jianshu.com/p/fe566ec32d28

Universe Link跳转流程

步骤

1.登录苹果开发者中心  选择对应的appid ☑️勾选 Associated Domains  此处标记的Team ID 和 bundle ID  后面文件会用到

2. 用text   创建  apple-app-site-association  文件     去掉后缀！！！！！

3.打开xcode 工程 配置下图文件

4.在appdelegate 里面 回调接收url  获取链接里面的参数

引言

作为程序员，我们或多或少知道可视化应用程序都是由 CPU 和 GPU 协作执行的。那么我们就先来了解一下两者的基本概念：

1.CPU（Central Processing Unit）：现代计算机的三大核心部分之一，作为整个系统的运算和控制单元。CPU 内部的流水线结构使其拥有一定程度的并行计算能力。

2.GPU（Graphics Processing Unit）：一种可进行绘图运算工作的专用微处理器。GPU 能够生成 2D/3D 的图形图像和视频，从而能够支持基于窗口的操作系统、图形用户界面、视频游戏、可视化图像应用和视频播放。GPU 具有非常强的并行计算能力。

这时候可能会产生一个问题：CPU 难道不能代替 GPU 来进行图形渲染吗？答案当然是肯定的，不过在看了下面这个视频就明白为什么要用 GPU 来进行图形渲染了。

GPU CPU 模拟绘图视频

使用 GPU 渲染图形的根本原因就是：速度。GPU 的并行计算能力使其能够快速将图形结果计算出来并在屏幕的所有像素中进行显示。

那么像素是如何绘制在屏幕上的？计算机将存储在内存中的形状转换成实际绘制在屏幕上的对应的过程称为 渲染。渲染过程中最常用的技术就是 光栅化。

关于光栅化的概念，以下图为例，假如有一道绿光与存储在内存中的一堆三角形中的某一个在三维空间坐标中存在相交的关系。那么这些处于相交位置的像素都会被绘制到屏幕上。当然这些三角形在三维空间中的前后关系也会以遮挡或部分遮挡的形式在屏幕上呈现出来。一句话总结：

光栅化就是将数据转化成可见像素的过程。

GPU 则是执行转换过程的硬件部件。由于这个过程涉及到屏幕上的每一个像素，所以 GPU 被设计成了一个高度并行化的硬件部件。

下面，我们来简单了解一下 GPU 的历史。

GPU 历史

GPU 还未出现前，PC 上的图形操作是由 视频图形阵列（VGA，Video Graphics Array） 控制器完成。VGA 控制器由连接到一定容量的DRAM上的存储控制器和显示产生器构成。

1997 年，VGA 控制器开始具备一些 3D 加速功能，包括用于 三角形生成、光栅化、纹理贴图 和 阴影。

2000 年，一个单片处图形处理器继承了传统高端工作站图形流水线的几乎每一个细节。因此诞生了一个新的术语 GPU 用来表示图形设备已经变成了一个处理器。

随着时间的推移，GPU 的可编程能力愈发强大，其作为可编程处理器取代了固定功能的专用逻辑，同时保持了基本的 3D 图形流水线组织。

近年来，GPU 增加了处理器指令和存储器硬件，以支持通用编程语言，并创立了一种编程环境，从而允许使用熟悉的语言（包括 C/C++）对 GPU 进行编程。

如今，GPU 及其相关驱动实现了图形处理中的 OpenGL 和 DirectX 模型，从而允许开发者能够轻易地操作硬件。OpenGL 严格来说并不是常规意义上的 API，而是一个第三方标准（由 khronos 组织制定并维护），其严格定义了每个函数该如何执行，以及它们的输出值。至于每个函数内部具体是如何实现的，则由 OpenGL 库的开发者自行决定。实际 OpenGL 库的开发者通常是显卡的生产商。DirectX 则是由 Microsoft 提供一套第三方标准。

GPU 图形渲染流水线

GPU 图形渲染流水线的主要工作可以被划分为两个部分：

把 3D 坐标转换为 2D 坐标

把 2D 坐标转变为实际的有颜色的像素

GPU 图形渲染流水线的具体实现可分为六个阶段，如下图所示。

顶点着色器（Vertex Shader）
形状装配（Shape Assembly），又称 图元装配
几何着色器（Geometry Shader）
光栅化（Rasterization）
片段着色器（Fragment Shader）
测试与混合（Tests and Blending）

第一阶段，顶点着色器。该阶段的输入是 顶点数据（Vertex Data） 数据，比如以数组的形式传递 3 个 3D 坐标用来表示一个三角形。顶点数据是一系列顶点的集合。顶点着色器主要的目的是把 3D 坐标转为另一种 3D 坐标，同时顶点着色器可以对顶点属性进行一些基本处理。

第二阶段，形状（图元）装配。该阶段将顶点着色器输出的所有顶点作为输入，并将所有的点装配成指定图元的形状。图中则是一个三角形。图元（Primitive） 用于表示如何渲染顶点数据，如：点、线、三角形。

第三阶段，几何着色器。该阶段把图元形式的一系列顶点的集合作为输入，它可以通过产生新顶点构造出新的（或是其它的）图元来生成其他形状。例子中，它生成了另一个三角形。

第四阶段，光栅化。该阶段会把图元映射为最终屏幕上相应的像素，生成片段。片段（Fragment） 是渲染一个像素所需要的所有数据。

第五阶段，片段着色器。该阶段首先会对输入的片段进行 裁切（Clipping）。裁切会丢弃超出视图以外的所有像素，用来提升执行效率。

第六阶段，测试与混合。该阶段会检测片段的对应的深度值（z 坐标），判断这个像素位于其它物体的前面还是后面，决定是否应该丢弃。此外，该阶段还会检查 alpha 值（ alpha 值定义了一个物体的透明度），从而对物体进行混合。因此，即使在片段着色器中计算出来了一个像素输出的颜色，在渲染多个三角形的时候最后的像素颜色也可能完全不同。

关于混合，GPU 采用如下公式进行计算，并得出最后的颜色。

R = S + D * (1 - Sa)

关于公式的含义，假设有两个像素 S(source) 和 D(destination)，S 在 z 轴方向相对靠前（在上面），D 在 z 轴方向相对靠后（在下面），那么最终的颜色值就是 S（上面像素） 的颜色 + D（下面像素） 的颜色 * （1 - S（上面像素） 颜色的透明度）。

上述流水线以绘制一个三角形为进行介绍，可以为每个顶点添加颜色来增加图形的细节，从而创建图像。但是，如果让图形看上去更加真实，需要足够多的顶点和颜色，相应也会产生更大的开销。为了提高生产效率和执行效率，开发者经常会使用 纹理（Texture） 来表现细节。纹理是一个 2D 图片（甚至也有 1D 和 3D 的纹理）。纹理一般可以直接作为图形渲染流水线的第五阶段的输入。

最后，我们还需要知道上述阶段中的着色器事实上是一些程序，它们运行在 GPU 中成千上万的小处理器核中。这些着色器允许开发者进行配置，从而可以高效地控制图形渲染流水线中的特定部分。由于它们运行在 GPU 中，因此可以降低 CPU 的负荷。着色器可以使用多种语言编写，OpenGL 提供了 GLSL（OpenGL Shading Language） 着色器语言。

GPU 存储系统

早期的 GPU，不同的着色器对应有着不同的硬件单元。如今，GPU 流水线则使用一个统一的硬件来运行所有的着色器。此外，nVidia 还提出了 CUDA（Compute Unified Device Architecture） 编程模型，可以允许开发者通过编写 C 代码来访问 GPU 中所有的处理器核，从而深度挖掘 GPU 的并行计算能力。

下图所示为 GPU 内部的层级结构。最底层是计算机的系统内存，其次是 GPU 的内部存储，然后依次是两级 cache：L2 和 L1，每个 L1 cache 连接至一个 流处理器（SM，stream processor）。

SM L1 Cache 的存储容量大约为 16 至 64KB。

GPU L2 Cache 的存储容量大约为几百 KB。

GPU 的内存最大为 12GB。

GPU 上的各级存储系统与对应层级的计算机存储系统相比要小不少。

此外，GPU 内存并不具有一致性，也就意味着并不支持并发读取和并发写入。

GPU 流处理器

下图所示为 GPU 中每个流处理器的内部结构示意图。每个流处理器集成了一个 L1 Cache。顶部是处理器核共享的寄存器堆。

CPU-GPU 异构系统

至此，我们大致了解了 GPU 的工作原理和内部结构，那么实际应用中 CPU 和 GPU 又是如何协同工作的呢？

下图所示为两种常见的 CPU-GPU 异构架构。

左图是分离式的结构，CPU 和 GPU 拥有各自的存储系统，两者通过 PCI-e 总线进行连接。这种结构的缺点在于 PCI-e 相对于两者具有低带宽和高延迟，数据的传输成了其中的性能瓶颈。目前使用非常广泛，如PC、智能手机等。

右图是耦合式的结构，CPU 和 GPU 共享内存和缓存。AMD 的 APU 采用的就是这种结构，目前主要使用在游戏主机中，如 PS4。

注意，目前很多 SoC 都是集成了CPU 和 GPU，事实上这仅仅是在物理上进行了集成，并不意味着它们使用的就是耦合式结构，大多数采用的还是分离式结构。耦合式结构是在系统上进行了集成。

在存储管理方面，分离式结构中 CPU 和 GPU 各自拥有独立的内存，两者共享一套虚拟地址空间，必要时会进行内存拷贝。对于耦合式结构，GPU 没有独立的内存，与 GPU 共享系统内存，由 MMU 进行存储管理。

图形应用程序调用 OpenGL 或 Direct3D API 功能，将 GPU 作为协处理器使用。API 通过面向特殊 GPU 优化的图形设备驱动向 GPU 发送命令、程序、数据。

GPU 资源管理模型

下图所示为分离式异构系统中 GPU 的资源管理模型示意图。

MMIO（Memory-Mapped I/O）

CPU 通过 MMIO 访问 GPU 的寄存器状态。
通过 MMIO 传送数据块传输命令，支持 DMA 的硬件可以实现块数据传输。

GPU Context

上下文表示 GPU 的计算状态，在 GPU 中占据部分虚拟地址空间。多个活跃态下的上下文可以在 GPU 中并存。

CPU Channel

来自 CPU 操作 GPU 的命令存储在内存中，并提交至 GPU channel 硬件单元。
每个 GPU 上下文可拥有多个 GPU Channel。每个 GPU 上下文都包含 GPU channel 描述符（GPU 内存中的内存对象）。
每个 GPU Channel 描述符存储了channel 的配置，如：其所在的页表。
每个 GPU Channel 都有一个专用的命令缓冲区，该缓冲区分配在 GPU 内存中，通过 MMIO 对 CPU 可见。

GPU 页表

GPU 上下文使用 GPU 页表进行分配，该表将虚拟地址空间与其他地址空间隔离开来。
GPU 页表与 CPU 页表分离，其驻留在 GPU 内存中，物理地址位于 GPU 通道描述符中。
通过 GPU channel 提交的所有命令和程序都在对应的 GPU 虚拟地址空间中执行。
GPU 页表将 GPU 虚拟地址不仅转换为 GPU 设备物理地址，还转换为主机物理地址。这使得 GPU 页面表能够将 GPU 存储器和主存储器统一到统一的 GPU 虚拟地址空间中，从而构成一个完成的虚拟地址空间。

PFIFO Engine

PFIFO 是一个提交 GPU 命令的特殊引擎。
PFIFO 维护多个独立的命令队列，即 channel。
命令队列是带有 put 和 get 指针的环形缓冲器。
PFIFO 引擎会拦截多有对通道控制区域的访问以供执行。
GPU 驱动使用一个通道描述符来存储关联通道的设置。

BO

缓冲对象（Buffer Object）。一块内存，可以用来存储纹理，渲染对象，着色器代码等等。

CPU-GPU 工作流

下图所示为 CPU-GPU 异构系统的工作流，当 CPU 遇到图像处理的需求时，会调用 GPU 进行处理，主要流程可以分为以下四步：

1.将主存的处理数据复制到显存中

2.CPU 指令驱动 GPU

3.GPU 中的每个运算单元并行处理

4.GPU 将显存结果传回主存

屏幕图像显示原理

介绍屏幕图像显示的原理，需要先从 CRT 显示器原理说起，如下图所示。CRT 的电子枪从上到下逐行扫描，扫描完成后显示器就呈现一帧画面。然后电子枪回到初始位置进行下一次扫描。为了同步显示器的显示过程和系统的视频控制器，显示器会用硬件时钟产生一系列的定时信号。当电子枪换行进行扫描时，显示器会发出一个水平同步信号（horizonal synchronization），简称 HSync；而当一帧画面绘制完成后，电子枪回复到原位，准备画下一帧前，显示器会发出一个垂直同步信号（vertical synchronization），简称 VSync。显示器通常以固定频率进行刷新，这个刷新率就是 VSync 信号产生的频率。虽然现在的显示器基本都是液晶显示屏了，但其原理基本一致。

下图所示为常见的 CPU、GPU、显示器工作方式。CPU 计算好显示内容提交至 GPU，GPU 渲染完成后将渲染结果存入帧缓冲区，视频控制器会按照 VSync 信号逐帧读取帧缓冲区的数据，经过数据转换后最终由显示器进行显示。

最简单的情况下，帧缓冲区只有一个。此时，帧缓冲区的读取和刷新都都会有比较大的效率问题。为了解决效率问题，GPU 通常会引入两个缓冲区，即 双缓冲机制。在这种情况下，GPU 会预先渲染一帧放入一个缓冲区中，用于视频控制器的读取。当下一帧渲染完毕后，GPU 会直接把视频控制器的指针指向第二个缓冲器。

双缓冲虽然能解决效率问题，但会引入一个新的问题。当视频控制器还未读取完成时，即屏幕内容刚显示一半时，GPU 将新的一帧内容提交到帧缓冲区并把两个缓冲区进行交换后，视频控制器就会把新的一帧数据的下半段显示到屏幕上，造成画面撕裂现象，如下图：

为了解决这个问题，GPU 通常有一个机制叫做垂直同步（简写也是 V-Sync），当开启垂直同步后，GPU 会等待显示器的 VSync 信号发出后，才进行新的一帧渲染和缓冲区更新。这样能解决画面撕裂现象，也增加了画面流畅度，但需要消费更多的计算资源，也会带来部分延迟。

摘自：http://chuquan.me/2018/08/26/graphics-rending-principle-gpu

emoji在社交类APP很常用,比如发动态,圈子,还有回复评论,还有会话

后台在处理emoji的态度,直接就是不处理,所以我们需要对emoji包括中文,数字,还有特殊字符进行编码还有解码

//编码

NSString *uniStr = [NSString stringWithUTF8String:[_barrageText.text UTF8String]];
NSData *uniData = [uniStr dataUsingEncoding:NSNonLossyASCIIStringEncoding];
NSString *goodStr = [[NSString alloc] initWithData:uniData encoding:NSUTF8StringEncoding] ;
NSLog(@"---编码--->[%@]",goodStr);

//解码

const char *jsonString = [goodStr UTF8String];   // goodStr 服务器返回的 json
NSData *jsonData = [NSData dataWithBytes:jsonString length:strlen(jsonString)];
NSString *goodMsg1 = [[NSString alloc] initWithData:jsonData encoding:NSNonLossyASCIIStringEncoding];
NSLog(@"---解码--->[%@]",goodMsg1);

2017-05-15 10:16:17.858 DFRomwe[650:153981] ---编码--->[hello\ud83d\ude18\ud83d\ude18world\u4e16\u754chaha\ud83d\ude17]
2017-05-15 10:16:17.859 DFRomwe[650:153981] ---解码--->[hello😘😘world世界haha😗]

总想着事情就能这么轻松解决!!!
可是,然后,呵呵呵,你不去了解一下东西,还是不行的
果然,后台不作处理的情况下,如果返回JSON这就不行了,因为会默认带有转义字符: *** "\" *** 会导致下面这个情况:

//在这里以😀表情为例,😀的Unicode编码为U+1F604,UTF-16编码为:\ud83d\ude04
NSString * emojiUnicode = @"\U0001F604";
NSLog(@"emojiUnicode:%@",emojiUnicode);
//如果直接输入\ud83d\ude04会报错，加了转义后不会报错，但是会输出字符串\ud83d\ude04,而不是😀
NSString * emojiUTF16 = @"\\ud83d\\ude04";
NSLog(@"emojiUTF16:%@",emojiUTF16);
//转换
emojiUTF16 = [NSString stringWithCString:[emojiUTF16 cStringUsingEncoding:NSUTF8StringEncoding] encoding:NSNonLossyASCIIStringEncoding];
NSLog(@"emojiUnicode2:%@",emojiUTF16);

输出：

emojiUnicode:😄
emojiUnicode1:\ud83d\ude04
emojiUnicode2:😄

果断百度另外的方法

//解码
- (NSString *)decodeEmoji{
NSString *tepStr1 ;
if ([self containsString:@"\\u"]) {
tepStr1 = [self stringByReplacingOccurrencesOfString:@"\\u"withString:@"\U"];
}else{
tepStr1 = [self stringByReplacingOccurrencesOfString:@"\u"withString:@"\U"];
}
NSString *tepStr2 = [tepStr1 stringByReplacingOccurrencesOfString:@"""withString:@"\""];
NSString *tepStr3 = [[@""" stringByAppendingString:tepStr2]stringByAppendingString:@"""];
NSData *tepData = [tepStr3 dataUsingEncoding:NSUTF8StringEncoding];
NSString *axiba = [NSPropertyListSerialization propertyListWithData:tepData options:NSPropertyListMutableContainers format:NULL error:NULL];
return [axiba stringByReplacingOccurrencesOfString:@"\r\n"withString:@"\n"];
}

//编码
- (NSString *)encodeEmoji{

NSUInteger length = [self length];
    NSMutableString *s = [NSMutableString stringWithCapacity:0];
    
    for (int i = 0;i < length; i++){
        unichar _char = [self characterAtIndex:i];
        //判断是否为英文和数字
        if (_char <= '9' && _char >='0'){
            [s appendFormat:@"%@",[self substringWithRange:NSMakeRange(i,1)]];
        }else if(_char >='a' && _char <= 'z'){
            [s appendFormat:@"%@",[self substringWithRange:NSMakeRange(i,1)]];
        }else if(_char >='A' && _char <= 'Z')
        {
            [s appendFormat:@"%@",[self substringWithRange:NSMakeRange(i,1)]];
        }else{
            [s appendFormat:@"\\"];

            [s appendFormat:@"\\u%x",[self characterAtIndex:i]];
        }
    }
    return s;
    
}

这是从JSON解码与编码,其实原理也很简单:

A :就是把多余的转义斜杠扔掉,

B :然后Unicode转utf-8;

C :然后utf-8转Unicode;

这里我写了一个NSString的一个分类:#import "NSString+Emoji.h"

还添加了一些方法:

//判断是否存在emoji表情:因为emoji表情室友Unicode编码区间的

+ (BOOL)stringContainsEmoji:(NSString *)string
{
__block BOOL returnValue = NO;
[string enumerateSubstringsInRange:NSMakeRange(0, [string length])
options:NSStringEnumerationByComposedCharacterSequences
usingBlock:^(NSString *substring, NSRange substringRange, NSRange enclosingRange, BOOL *stop) {
const unichar hs = [substring characterAtIndex:0];
if (0xd800 <= hs && hs <= 0xdbff) {
if (substring.length > 1) {
const unichar ls = [substring characterAtIndex:1];
const int uc = ((hs - 0xd800) * 0x400) + (ls - 0xdc00) + 0x10000;
if (0x1d000 <= uc && uc <= 0x1f77f) {
returnValue = YES;
}
}
} else if (substring.length > 1) {
const unichar ls = [substring characterAtIndex:1];
if (ls == 0x20e3) {
returnValue = YES;
}
} else {
if (0x2100 <= hs && hs <= 0x27ff) {
returnValue = YES;
} else if (0x2B05 <= hs && hs <= 0x2b07) {

returnValue = YES;
                                    } else if (0x2934 <= hs && hs <= 0x2935) {
                                        returnValue = YES;
                                    } else if (0x3297 <= hs && hs <= 0x3299) {
                                        returnValue = YES;
                                    } else if (hs == 0xa9 || hs == 0xae || hs == 0x303d || hs == 0x3030 || hs == 0x2b55 || hs == 0x2b1c || hs == 0x2b1b || hs == 0x2b50) {
                                        returnValue = YES;
                                    }
                                }
                                
                            }];
    return returnValue;
}

//判断是否存在中文
//因为要保证之前的utf-8的数据也能显示
- (BOOL)includeChinese
{
for(int i=0; i< [self length];i++)
{
int a =[self characterAtIndex:i];
if( a >0x4e00&& a <0x9fff){
return YES;
}
}
return NO;
}

//判断是否以中文开头

- (BOOL)JudgeChineseFirst{
    //是否以中文开头(unicode中文编码范围是0x4e00~0x9fa5)
    int utfCode = 0;
    void *buffer = &utfCode;
    NSRange range = NSMakeRange(0, 1);
    //判断是不是中文开头的,buffer->获取字符的字节数据 maxLength->buffer的最大长度 usedLength->实际写入的长度，不需要的话可以传递NULL encoding->字符编码常数，不同编码方式转换后的字节长是不一样的，这里我用了UTF16 Little-Endian，maxLength为2字节，如果使用Unicode，则需要4字节 options->编码转换的选项，有两个值，分别是NSStringEncodingConversionAllowLossy和NSStringEncodingConversionExternalRepresentation range->获取的字符串中的字符范围,这里设置的第一个字符 remainingRange->建议获取的范围，可以传递NULL
    BOOL b = [self getBytes:buffer maxLength:2 usedLength:NULL encoding:NSUTF16LittleEndianStringEncoding options:NSStringEncodingConversionExternalRepresentation range:range remainingRange:NULL];
    if (b && (utfCode >= 0x4e00 && utfCode <= 0x9fa5))
        return YES;
    else
        return NO;
}

静态库打包的流程：

.a打包

将提前准备的项目文件及项目资源导入到SDK制作工程中

添加New Header Phase

将制作静态库需要的.h文件添加到Project中，将静态库调用的头文件添加到Public中

静态库打包bundle文件>由于演示制作的静态库包含图片和xib文件，因此为了规范，我们需要把图片和xib文件添加到bundle中，如图添加给静态库添加bundle资源包

创建好之后，将图片和xib文件添加到Copy Bundle Resources中

由于.bundle文件属于macOX类型，所以我们需要改一些配置来适配iOS,如图所示
TARGETS ->选择bundle -> Build Settings ->Base SDK ->选择Latest iOS (iOS 11.2)

设置Build Setting 中的COMBINE_HIDPI_IMAEGS 为NO,否则Bundle中的图片就是tiff格式了。

作为资源包，仅仅需要编译就好，无需安装相关配置，设置Skip Install为YES,同样需要删除安装路径Installation Dirctory的值

到此为止bundle文件的设置完成

找到源文件路径，如下图所示，到此静态库制作完成，将.libStaticSDK.a和source.bundle和头文件StaticSDK.h导入到项目中即可使用

找到源文件路径

3、合并静态库真机和模拟器文件

lipo -create XXX/模拟器.a路径 XXX/真机.a路径 -output 合并后的文件名称.a

4、注意点，由于资源文件在Bundle文件中因此在使用时需注意，以下我举两个例子，一个是加载图片，一个是加载xib文件

对于使用了Cocoapod导入第三方的xcode工程来讲 需要在Podfile中 做如下修改 之后 pod install
需要同时对住工程target 和Framework的target 配置pod环境

2.build Setting 设置

选择工程文件>target第一项>Build Setting>搜索linking，然后几个需要设置的选项都显现出来，首先是Dead Code Stripping设置为NO，网上对此项的解释如下，大致意思是如果开启此项就会对代码中的”dead”、”unreachable”的代码过滤，不过这个开关是否关闭，似乎没有多大影响，不过为了完整还原framework中的代码，将此项关闭也未曾不可。

The resulting executable will not include any “dead” or unreachable code

然后将Link With Standard Libraries关闭，我想可能是为了避免重复链接

最后将Mach-O Type设为Static Library，framework可以是动态库也可以是静态库，对于系统的framework是动态库，而用户制作的framework只能是静态库。

开始将下图中的build Active Architecture only选项设为YES，导致其编译时只生成当前机器的框架，将其设置为NO后，发现用模拟器编译后生成的framework同时包含x86_64和i386架构。不过这个无所谓，我们之后会使用编译脚本，脚本会将所有的架构全包含

分别编译

show in finder 如下

Debug-iphoneos 为Debug模式下真机使用的
Debug-iphonesimulator 为Debug模式下模拟器使用的
Release -iphoneos 为Release模式下真机使用的
Release-iphonesimulator 为Release模式下模拟器使用的

下面的合并和.a一样操作

下面介绍自动shell脚本合并

1:生成脚本target

2.target设置

Target Dependencies 选中需要打包的framework + 选择New Run Script Phase 出现 Run Scirpt

2.设置脚本路径

可以在命令行里设置
也可以直接将脚本粘贴在这里

# 取得项目名字（get project name）
FMK_NAME=${PROJECT_NAME}
# 取得生成的静态库文件路径  （get framework path）
INSTALL_DIR=${SRCROOT}/Products/${FMK_NAME}.framework
# 设置真机和模拟器生成的静态库路径 （set devcie framework and simulator framework path）
WRK_DIR=build
DEVICE_DIR=${WRK_DIR}/Release-iphoneos/${FMK_NAME}.framework
SIMULATOR_DIR=${WRK_DIR}/Release-iphonesimulator/${FMK_NAME}.framework
# 模拟器和真机编译 （device and simulator build）
xcodebuild -configuration "Release" -target "${FMK_NAME}" -sdk iphoneos clean build
xcodebuild -configuration "Release" -target "${FMK_NAME}" -sdk iphonesimulator clean build
# 删除临时文件 （delete temp file）
if [ -d "${INSTALL_DIR}" ]
then
rm -rf "${INSTALL_DIR}"
fi
mkdir -p "${INSTALL_DIR}"
# 拷贝真机framework文件到生成路径下 （copy device file to product path）
cp -R "${DEVICE_DIR}/" "${INSTALL_DIR}/"
# 合并生成，替换真机framework里面的二进制文件，并且打开 （merger and open）
lipo -create "${DEVICE_DIR}/${FMK_NAME}" "${SIMULATOR_DIR}/${FMK_NAME}" -output "${INSTALL_DIR}/${FMK_NAME}"
echo "${DEVICE_DIR}/${FMK_NAME}"
echo "${SIMULATOR_DIR}/${FMK_NAME}"
rm -rf "${WRK_DIR}"
open "${INSTALL_DIR}"