iOS App启动优化（二）：物理内存和虚拟内存

内存管理

内存是分页管理的，映射表不能以字节为单位，是 以页为单位。优化

终端输入spa

pageSize
复制代码

返回的就是 4 * 1024 = 4096

早期的计算机不断启动应用，到达必定数量之后会报错，应用没法正常运行，必须先关闭前面的部分应用才能继续开启。操作系统

这是由于早期计算机没有虚拟地址，一旦加载都会 所有加载到内存中 。一旦物理内存不够了，那么应用就没法继续开启。翻译

应用在内存中的排序都是顺序排列的，这样进程只须要把本身的地址尾部日后偏移一点就能访问到别的进程中的内存地址，至关不安全。

用户使用时并不会使用到所有内存，若是 App 一启动就所有加载到内存中会浪费不少内存空间。 虚拟内存技术 的出现就是为了解决这个内存浪费问题。

App 启动后会认为本身已经获取到整个 App 运行所需的内存空间，但实际上并无在物理内存上为他申请那么大的空间，只是生成了一张 虚拟内存和物理内存关联的表 。

当 App 须要使用某一块虚拟内存的地址时，会经过这张表查询该虚拟地址是否已经在物理内存中申请了空间。

这个经过进程映射表映射到不一样的物理内存空间的操做叫 地址翻译 ，这个过程须要 CPU 和操做系统配合。

当数据未在物理内存会进行下列操做

上述行为就就是Page Fault

虽然解决了浪费问题，可是万一物理内存空间全都被申请了呢？仍是有可能产生内存不足的状况的，为保证当前App的正常使用，数据加载遵循如下原则：

空间问题已经解决了，可是安全问题是怎么解决的呢？

在dylib的加载过程当中系统为了安全考虑引入了ASLR（Address Space Layout Randomization）技术和代码签名。

ASLR技术：镜像Image、可执行文件、dylib、bundle在加载的时候会在其指向的地址（preferred_address）前面添加一个随机数误差（slide），防止应用内部地址被定位。

虚拟内存技术会产生缺页中断（Page Fault），这个过程是个耗时操做。

每页耗时也有很大差距，1微秒到0.8毫秒不等。

使用过程当中对这点耗时感受不明显，可是启动时加载大量数据，若是产生大量缺页中断（Page Fault），时间叠加后用户会有明显感知。

若是咱们把全部启动时候的代码都放在一页或者两页，这样就很大程度减小了启动时的缺页中断（Page Fault）从而优化启动速度，这就是二进制重排。