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）從而優化啓動速度，這就是二進制重排。