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