在iOS中苹果提供了NSURLConnection、NSURLSession等优秀的网路接口供我们来调用，开源社区也有很多的开源库，如之前的ASIHttpRequest 现在的AFNetworking和Alamofire，我们接下来介绍的NSURLProtocol，都可以监控到这些开源库的网络请求。
NSURLProtocol是iOS网络加载系统中很强的一部分，它其实是一个抽象类，我们可以通过继承子类化来拦截APP中的网络请求。
举几个例子：
等等，都可以用到 NSURLProtocol是一个抽象类，我们需要子类化才能实现网络请求拦截。
FPS（Frames Per Second）是指画面每秒传输的帧数。每秒帧数越多，所显示的动画就越流畅，一般只要保持 FPS 在 50-60，App 就会有流畅的体验，反之会感觉到卡顿。
CADisplayLink 是一个能让我们以和屏幕刷新率相同的频率将内容画到屏幕上的定时器。
一旦 CADisplayLink 以特定的模式注册到 runloop 之后，每当屏幕需要刷新时，runloop 就会调用 CADisplayLink 绑定的 target 上的 selector，此时 target 可以读取到 CADisplayLink 的每次调用的时间戳，用来准备下一帧显示需要的数据。如：一个视频应用使用时间戳来计算下一帧要显示的视频数据。
现阶段，常用的 FPS 监控几乎都是基于 CADisplayLink 实现的。
我们可以联想：内存使用情况是否也可以通过类似CPU的方式获取到呢？答案是肯定的。
内存是有限且系统共享的资源，一个程序占用越多，系统和其他程序所能用的就越少。程序启动前都需要先加载到内存中，并且在程序运行过程中的数据操作也会占用一定的内存资源。减少内存占用也能同时减少其对 CPU 时间维度上的消耗，从而使不仅使 App 以及整个系统也都能表现的更好。
MacOS 和 iOS 都采用了虚拟内存技术来突破物理内存的大小限制，每个进程都有一段由多个大小相同的页（Page）所构成的逻辑地址空间。处理器和内存管理单元（MMU，Memory Management Unit）维护着由逻辑地址到物理地址的 页面映射表（简称 页表），当程序访问逻辑内存地址时，由 MMU 根据页表将逻辑地址转换为真实的物理地址。在早期的苹果设备中，每个页的大小为 4KB；基于 A7 和 A8 处理器的系统为 64 位程序提供了 16KB 的虚拟内存分页和 4KB 的物理内存分页；在 A9 之后，虚拟内存和物理内存的分页大小都达到了 16KB。
虚拟内存分页（Virtual Page，VP）有两种类型：
CPU 占用率的采集原理其实很简单：App 作为进程运行时会有多个线程，每个线程对 CPU 的使用率不同。各个线程对 CPU 使用率的总和，就是当前 App 对 CPU 的占用率。
wiki上比较全的iPhone CPU信息 : Apple-designed_processors)
iOS 是基于 Apple Darwin 内核，由 kernel、XNU 和 Runtime 组成，XNU（X is not UNIX） 是 Darwin 的内核，一个混合内核，由 Mach 微内核和 BSD 组成。Mach 内核是轻量级的平台，只能完成操作系统最基本的职责，如：进程和线程、虚拟内存管理、任务调度、进程通信和消息传递机制。其他的工作，如文件操作和设备访问，都是由 BSD 层实现。
事实上，Mach 并不能识别 UNIX 中的所有进程，而是采用一种稍微不同的方式，使用了比进程更轻量级的概念：任务（Task）。经典的 UNIX 采用了自上而下的方式：最基本的对象是进程，然后进一步划分为一个或多个线程；Mach 则采用了自底向上的方式：最基本的单元是线程，一个或多个线程包含在一个任务中。
介绍下常见的几种对图片的像素级操作
1.修改颜色 2. 颜色空间变化 3.lsb 隐藏信息 4. 颜色混合 5. 马赛克
在 iOS图片-位图信息与图片解码 中介绍了位图信息中像素 颜色空间等概念。这次来实践一下如何对图片的像素进行操作。位图又被叫做点阵图像，也就是说位图包含了一大堆的像素点信息，这些像素点就是该图片中的点，有了图片中每个像素点的信息，我们就知道如何对图片进行像素级操作了。
由于在iOS开发中使用的位图大部分是32位RGBA模式，所以我们先说下这种模式的简单图像处理。
首先我们需要知道什么是32位RGBA模式的位图。32位就表示一个这种模式位图的一个像素所占内存为32位，也就是4个字节的长度。R、G、B、A分别代表red，green，blue和alpha，也就是颜色组成的三原色与透明度值。RGBA每一个占用一个字节的内存。
知道了上面这些，我们就有了思路：通过改变每一个像素中的RGBA值来进行一些位图图像的处理了。
介绍下几种iOS中位图信息 与相关解压缩
ref 谈谈 iOS 中图片的解压缩
ref Quartz 2D Programming Guide
我们从网络下载或者从本地磁盘加载一张图片到屏幕上显示，要经过图片的解码过程，为什么呢？因为我们一般的图片格式例如 JPEG，PNG都是经过压缩后的图片，而显示在屏幕上的图片叫做位图(bitmap)，所谓的解码就是把压缩后的图片变成位图。
为什么非要解码成位图才能显示呢？因为位图又被叫做点阵图像，也就是说位图包含了一大堆的像素点信息，这些像素点就是该图片中的点，有了图片中每个像素点的信息，就可以在屏幕上渲染整张图片了。
那我们为什么还需要不同格式的各种图片呢？直接全部用位图不就好了？那不就不需要每次解码了？那些JPEG以及PNG等其实都是图像的压缩格式，我们都知道压缩的意思就是减小空间，所以我们可以想到，使用这些格式的原因就是位图实在太大了。
介绍下 wwdc 2018 Image and Graphics Best Practices 中图片处理解压相关知识点
ref: Image and Graphics Best Practices
一张图片从磁盘中显示到屏幕上过程大致如下：从磁盘加载原始压缩的图片信息、解码二进制图片数据为位图、渲染图片最终绘制到屏幕上。
在实际的渲染过程中，UIImage负责解压Data Buffer内容并申请buffer（Image Buffer）存储解压后的图片信息，然后UIImageView负责将Image Buffer 拷贝至 framebuffer，用于给显示硬件提供颜色信息。
解压过程是一个大量占用CPU资源的工作，因此UIImage 会retain存储解压后信息的Image Buffer以便给重复的渲染工作提供信息，Image Buffer与图片的实际尺寸有关（理论值为height * width * 4 bytes），与图片文件大小无关。若是在TableView等列表中连续加载多张图片，便会引发连续的大块内存分配，这将对Memory和CPU带来沉重的负担。
介绍下iOS中ImageIO的概览与应用
Image I/O Programming Guide
ImageIO框架提供了读取与写入图片数据的基本方法，使用它可以直接获取到图片文件的内容数据，ImageIO具有很多特性 Mac平台上最快的图像解码器和编码器 逐步加载图像的能力``支持图像元数据 有效缓存 ImageIO框架中包含6个头文件:
介绍下在iOS中的多种图片缩略方式
ref https://nshipster.com/image-resizing/
在UIKit CoreGraphics ImageIO CoreImage vImage多种缩略方法中 Core Image表现最差。Core Graphics 和 Image I/O最好。
实际上，在苹果官方在 Performance Best Practices section of the Core Image Programming Guide 部分中特别推荐使用Core Graphics或Image I / O功能预先裁剪或缩小图像。
上一篇 Mach-O应用 fishhook动态修改C函数 了解了fishhook的原理，现在来看一下它的代码，看它是如何一步一步替换原有函数实现的。