提高 Xcode 在讀寫上的速度的實現(xiàn)方法
上個月參加了一場西雅圖當?shù)氐木€下 iOS 開發(fā)者聚會。Jeff Szuhay 作為一個有20+年開發(fā)經(jīng)驗的資深程序員，跟我講了一套提高 iOS 開發(fā)效率的方法。相比于其他程序員在 App 啟動時間、架構優(yōu)化方面的經(jīng)驗，老爺子 Jeff 的優(yōu)化基于硬件層面，匠心獨運，極客風十足。以下是他的經(jīng)驗分享和我個人的實測。
問題來源
我們都知道 Xcode 在運行或編譯時，會有大量的讀寫操作。例如從硬盤中調(diào)用圖片，我們會這么操作：
let image = UIImage（named： “imageName”）
這時候 Xcode 就會去電腦的硬盤中去找到圖片，完成讀寫操作。類似的操作還有存取文件等等。如果這類讀取數(shù)量比較少，那么無傷大雅，但是一旦多起來，尤其是大項目在后期產(chǎn)生了大量的 DerivedData 存在硬盤上，Xcode 在編譯時就會花大量時間去硬盤（Disk）上完成讀寫這些數(shù)據(jù)的操作。更不幸的是有時候還會遇到硬盤故障等問題。
解決思路
正所謂“哪里需要優(yōu)化，哪里就需要程序員”，Jeff 在這個時候作為一名白衣騎士登場了。多年的計算機研究讓他對整個計算機架構非常熟悉。下圖是他展示的計算機結構簡圖。
計算機結構簡圖
此圖簡潔明了得說明了計算機的基本架構。左上角是計算機的大腦，CPU，負責核心計算和處理工作；右上角是內(nèi)存（RAM），用來運行程序并與 CPU 進行數(shù)據(jù)交流；中間的線是總線，負責各個模塊之間傳遞信息和信號；圖下側是基本的 System IO。
再回來看我們的問題：Xcode 現(xiàn)在是在 RAM 中運行，然后到 Storage 中讀寫數(shù)據(jù)，數(shù)據(jù)接著再傳回 RAM。這種方式有兩個瓶頸：
Storage 速度很慢。即使是最先進的 SSD，其速度也比 RAM 慢了400倍。也就是無論你怎么在軟件層優(yōu)化，其速度也無法突破 SSD 的瓶頸；
數(shù)據(jù)要不停的在各個模塊之間傳遞。傳遞過程中亦有延時和無謂的時間消耗。
針對以上兩個瓶頸，Jeff 認為，如果我們可以讓所有的讀寫操作都在內(nèi)存（RAM）中完成，那么必然能大幅提高 Xcode 的工作效率。問題是，怎么實現(xiàn)？
非常好我支持^.^
(0) 0%
不好我反對
(0) 0%