您好,歡迎來電子發(fā)燒友網(wǎng)! ,新用戶?[免費(fèi)注冊(cè)]

您的位置:電子發(fā)燒友網(wǎng)>源碼下載>通訊/手機(jī)編程>

提高 Xcode 在讀寫上的速度的實(shí)現(xiàn)方法

大?。?/span>0.3 MB 人氣: 2017-09-25 需要積分:1

  上個(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)圖。

  提高 Xcode 在讀寫上的速度的實(shí)現(xià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%

      發(fā)表評(píng)論

      用戶評(píng)論
      評(píng)價(jià):好評(píng)中評(píng)差評(píng)

      發(fā)表評(píng)論,獲取積分! 請(qǐng)遵守相關(guān)規(guī)定!

      ?