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