为美好的世界献上祝福

之前介绍了一下 iOS中的编译过程 iOS编译过程 。 现在来对整体编译时间做一个优化。

编译耗时分析

xcode完整的build详细的步骤如下：

• 创建Product.app的文件夹
• 把Entitlements.plist写入到DerivedData里，处理打包的时候需要的信息（比如application-identifier）。
• 创建一些辅助文件，比如各种.hmap，这是headermap文件，具体作用下文会讲解。
• 执行CocoaPods的编译前脚本：检查Manifest.lock文件。
• 编译.m文件，生成.o文件。
• 链接动态库，o文件，生成一个mach o格式的可执行文件。
• 编译assets，编译storyboard，链接storyboard
• 拷贝动态库Logger.framework，并且对其签名
• 执行CocoaPods编译后脚本：拷贝CocoaPods Target生成的Framework
• 对Demo.App签名，并验证（validate）
• 生成Product.app

主要介绍一下 https://github.com/sunyanyan/ipaAnalyze 里的脚本。
该脚本输入ipa文件以及对应linkmap文件，输入该ipa各类资源的大小、以及各个模块的大小。

优化指标

itunes connect上有两种包大小显示：“Download Size”，“Install Size”。“Download Size”即下载包大小，超过150M需要使用无线网下载的限制就是这个大小（现在已经放宽到200M）；“Install Size”即安装后占用的磁盘空间大小，在appstore上显示的也是这个大小，用户往往会误认为这是下载安装包消耗的流量大小。所以一开始我们就将“Install Size”作为了优化指标。“Install Size”减小后，“Download Size”自然也会减小。

启动过程

iOS应用的启动可分为pre-main阶段和main()阶段，pre-main阶段为main函数执行之前所做的操作，main阶段为main函数到首页展示阶段。其中系统做的事情为：

• premain
  • 加载所有依赖的Mach-O文件（递归调用Mach-O加载的方法）
  • 加载动态链接库加载器dyld（dynamic loader）
  • 定位内部、外部指针引用，例如字符串、函数等
  • 加载类扩展（Category）中的方法
  • C++静态对象加载、调用ObjC的 +load 函数
  • 执行声明为__attribute__((constructor))的C函数
• main
  • 调用main()
  • 调用UIApplicationMain()
  • 调用applicationWillFinishLaunching

iOS 原生代码的编译调试，都是通过一遍又一遍地编译重启 APP来进行的。所以项目代码量越大，编译时间就越长。虽然我们可以将部分代码先编译成二进制集成到工程里，来避免每次都全量编译来加快编译速度，但即使这样，每次编译都还是需要重启App，需要再走一遍调试流程。

幸运的是，John Holdsworth 开发了一个叫做 InjectionIII 的工具可以动态地将 Swift 或 Objective-C 的代码在已运行的程序中执行，以加快调试速度，同时保证程序不用重启。

在iOS中苹果提供了NSURLConnection、NSURLSession等优秀的网路接口供我们来调用，开源社区也有很多的开源库，如之前的ASIHttpRequest 现在的AFNetworking和Alamofire，我们接下来介绍的NSURLProtocol，都可以监控到这些开源库的网络请求。

NSURLProtocol

NSURLProtocol是iOS网络加载系统中很强的一部分，它其实是一个抽象类，我们可以通过继承子类化来拦截APP中的网络请求。

举几个例子：

• 我们的APP内的所有请求都需要增加公共的头，像这种我们就可以直接通过NSURLProtocol来实现，当然实现的方式有很多种
• 我们需要将APP某个API进行一些访问的统计
• 我们需要统计APP内的网络请求失败率

等等，都可以用到 NSURLProtocol是一个抽象类，我们需要子类化才能实现网络请求拦截。

FPS

FPS（Frames Per Second）是指画面每秒传输的帧数。每秒帧数越多，所显示的动画就越流畅，一般只要保持 FPS 在 50-60，App 就会有流畅的体验，反之会感觉到卡顿。

相关系统原理

CADisplayLink 是一个能让我们以和屏幕刷新率相同的频率将内容画到屏幕上的定时器。

一旦 CADisplayLink 以特定的模式注册到 runloop 之后，每当屏幕需要刷新时，runloop 就会调用 CADisplayLink 绑定的 target 上的 selector，此时 target 可以读取到 CADisplayLink 的每次调用的时间戳，用来准备下一帧显示需要的数据。如：一个视频应用使用时间戳来计算下一帧要显示的视频数据。

代码实现

现阶段，常用的 FPS 监控几乎都是基于 CADisplayLink 实现的。

Memory

我们可以联想：内存使用情况是否也可以通过类似CPU的方式获取到呢？答案是肯定的。

相关系统原理

内存是有限且系统共享的资源，一个程序占用越多，系统和其他程序所能用的就越少。程序启动前都需要先加载到内存中，并且在程序运行过程中的数据操作也会占用一定的内存资源。减少内存占用也能同时减少其对 CPU 时间维度上的消耗，从而使不仅使 App 以及整个系统也都能表现的更好。

MacOS 和 iOS 都采用了虚拟内存技术来突破物理内存的大小限制，每个进程都有一段由多个大小相同的页（Page）所构成的逻辑地址空间。处理器和内存管理单元（MMU，Memory Management Unit）维护着由逻辑地址到物理地址的 页面映射表（简称 页表），当程序访问逻辑内存地址时，由 MMU 根据页表将逻辑地址转换为真实的物理地址。在早期的苹果设备中，每个页的大小为 4KB；基于 A7 和 A8 处理器的系统为 64 位程序提供了 16KB 的虚拟内存分页和 4KB 的物理内存分页；在 A9 之后，虚拟内存和物理内存的分页大小都达到了 16KB。

虚拟内存分页（Virtual Page，VP）有两种类型：

• Clean：指能够被系统清理出内存且在需要时能重新加载的数据，包括：
  • 内存映射文件
  • Frameworks 中的 __DATA_CONST 部分
  • 应用的二进制可执行文件
• Dirty：指不能被系统回收的内存占用，包括：
  • 所有堆上的对象
  • 图片解码缓冲数据
  • Framework 中的 DATA 和 DATA_DIRTY 部分

CPU

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 则采用了自底向上的方式：最基本的单元是线程，一个或多个线程包含在一个任务中。

• 线程
  • 线程定义了 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值来进行一些位图图像的处理了。