我正在使用Xcode 6 Beta 6。這已經(jīng)困擾了我一段時間，但是現(xiàn)在已經(jīng)到了幾乎無法使用的地步。我的項(xiàng)目已經(jīng)開始有一個體面的65個斯威夫特文件的大小和幾個橋接Objective-C的文件（這是真的不是問題的原因）。似乎對任何Swift文件進(jìn)行任何微小的修改（例如在應(yīng)用中幾乎未使用的類中添加簡單的空白）都會導(dǎo)致重新編譯指定目標(biāo)的整個Swift文件。經(jīng)過更深入的研究后，我發(fā)現(xiàn)CompileSwiftXcode在swiftc目標(biāo)的所有Swift文件上運(yùn)行命令的階段占了編譯器時間的幾乎100％。我做了進(jìn)一步的調(diào)查，如果僅使用默認(rèn)控制器保留應(yīng)用程序委托，則編譯速度非?？欤请S著我添加越來越多的項(xiàng)目文件，編譯時間開始變得很慢。現(xiàn)在只有65個源文件，每次編譯大約需要8/10秒。一點(diǎn)也不快。我還沒有看到任何帖子談到這個問題，除了這一個，但所以我想知道如果我在這種情況下，只有一個，這是一個舊版本的Xcode 6。我已經(jīng)在GitHub上檢查了一些Swift項(xiàng)目，例如Alamofire，Euler和CryptoSwift，但是它們都沒有足夠的Swift文件可以進(jìn)行實(shí)際比較。我發(fā)現(xiàn)唯一一個啟動時大小合適的項(xiàng)目是SwiftHN，即使它只有十幾個源文件，我仍然能夠驗(yàn)證同一件事，一個簡單的空間，整個項(xiàng)目需要重新編譯，這開始需要一個很少的時間（2/3秒）。與分析器和編譯都快速發(fā)展的Objective-C代碼相比，這確實(shí)讓Swift永遠(yuǎn)無法處理大型項(xiàng)目，但是請告訴我我錯了。Xcode 6 Beta 7更新仍然沒有任何改善。這開始變得荒謬。由于缺少#importSwift，我真的看不到蘋果將如何進(jìn)行優(yōu)化。不要像我那樣高興得太快。他們用來使構(gòu)建增量的圖形求解器尚未得到很好的優(yōu)化。的確，首先，它并不關(guān)注函數(shù)簽名的更改，因此，如果在一個方法的塊中添加空格，則將重新編譯所有依賴該類的文件?，F(xiàn)在，如果您進(jìn)行修改FileA，則編譯器顯然會標(biāo)記FileA為要重新編譯。它還將重新編譯FileB（根據(jù)對的更改，這將是可以的FileA），而且還FileC因?yàn)镕ileB重新編譯了，這很糟糕，因?yàn)樵诖薋ileC從未使用FileA過。因此，我希望他們能改進(jìn)依賴關(guān)系樹求解器...我已經(jīng)用此示例代碼打開了雷達(dá)。Xcode 7 beta 5和Swift 2.0更新昨天，Apple發(fā)布了Beta 5，在發(fā)布說明中我們可以看到：Swift語言和編譯器?增量構(gòu)建：僅更改函數(shù)的主體將不再導(dǎo)致依賴文件的重建。（15352929）我已經(jīng)嘗試過了，我必須說它現(xiàn)在真的（真的！）運(yùn)行良好。他們迅速優(yōu)化了增量構(gòu)建。我烈建議您創(chuàng)建一個swift2.0分支，并使用XCode 7 beta 5使代碼保持最新。您會對編譯器的增強(qiáng)功能感到滿意（但是我會說XCode 7的全局狀態(tài)仍然很慢且有錯誤）。Xcode 8.2更新自從我最近一次更新此問題以來已經(jīng)有一段時間了?，F(xiàn)在，我們的應(yīng)用程序大約有2萬行代碼，幾乎都是Swift代碼，雖然不錯，但并不出色。它經(jīng)歷了迅速的2遷移，而不是迅速的3遷移。在2014年中的Macbook pro（2.5 GHz Intel Core i7）上進(jìn)行編譯大約需要5 / 6m，這在干凈的版本上還可以。但是，盡管蘋果聲稱：增量構(gòu)建仍然是一個笑話：僅發(fā)生很小的更改時，Xcode不會重建整個目標(biāo)。（28892475）顯然，我認(rèn)為我們很多人在檢查了這個廢話之后就笑了（向我項(xiàng)目的任何文件添加一個私有（私有?。傩远紩匦戮幾g整個過程……）我想指出你們在Apple開發(fā)人員論壇上的這個線程，該線程上有關(guān)于此問題的更多信息（以及不時地對此事的Apple開發(fā)人員的交流）基本上人們想出了一些方法來嘗試改進(jìn)增量構(gòu)建：將HEADER_MAP_USES_VFS項(xiàng)目設(shè)置添加到true禁用Find implicit dependencies您的方案創(chuàng)建一個新項(xiàng)目，然后將文件層次結(jié)構(gòu)移至新項(xiàng)目。我將嘗試解決方案3，但解決方案1/2不適用于我們。具有諷刺意味的是，在整個情況下，有趣的是，當(dāng)我們遇到第一個編譯緩慢問題時，盡管我們從Apple那里獲得了實(shí)際的改進(jìn)，但在第一篇文章中，我們使用的是Xcode 6和Swift 1或Swift 1.1代碼。這種情況與Xcode 6一樣糟糕。實(shí)際上，我真的很后悔為我們的項(xiàng)目選擇Swift而不是Obj / C，因?yàn)樗刻於紩钊司趩省＃ㄎ沂仓粮挠肁ppCode，但這是另一個故事）無論如何，截至撰寫本文時，我看到這則SO帖子具有32k +的視圖和143個ups，所以我想我不是唯一的一個。盡管對這種情況感到悲觀，但還是呆在那兒，隧道盡頭可能有些亮光。