文件編譯時間過長
1. Xcode 構建速度優化（一）衡量編譯時間
隨著項目不斷迭代，工程文件越來越多，引用的三方庫也越來越多，這些直接導致編譯時間的不斷增加，完整編譯一次項目動輒需要五分鍾以上時間，實在有些影響開發效率，是時候來一波提速了。
為編譯和構建提速，首先我們需要對速度有一個衡量標准：准確獲得構建用時
首先，我們需要定義要衡量和優化的內容。 有兩種選擇：
xcode默認情況下會跟蹤所有構建，我們可以通過更改xcode相關設置，來在活動查看器中顯示出構建時間，通過命令行：
每次編譯成功後，會在Successed之後顯示出所用時間:
Xcode Build Timing Summary是Xcode10中加入的用於查看獲取構建時間和發現用時瓶頸方面的最有利工具。 可以通過Proct->Perform Action->Build With Timing Summary來開啟：這樣在 Build Log 的末尾就會添加 Timing Summary Log。我們可以通過這個 log 看到哪個階段是耗時的，便於我們進行優化。
如上圖中: xib階段的編譯耗時明顯是比普通c文件要多的，意味著我們可以通過減少xib方式來優化提升速度
而c文件的編譯用時比總時間還要長，是因為c文件是並行編譯的
在命令行中同樣可以開啟這個功能：
常用的第三方工具有 BuildTimeAnalyzer 、 xcode-build-times-rendering 、 XCLogParser 。
BuildTimeAnalyzer可以統計可以得出某個文件的類型檢查時長，每個表達式的類型檢查時長。
xcode-build-times-rendering是一個Ruby編寫的第三方工具，可以方便地分別測量目標的構建時間並在圖表上顯示它們，使用gem安裝
接下來使用這個工具自帶命令配置項目
然後構建項目並生成報告：
這個工具使用上比較簡單，缺點是只能從宏觀上生成各個target編譯的整體圖標，無法詳細列出各個內部編譯明細
XCLogParser可以詳細列出各個Target和內部每個文件的編譯耗時，對我們分析編譯時間瓶頸非常有幫助，它的工作原理主要是做為解析器，通過解析xcode編譯生成的xcactivitylog日誌來記錄
安裝：
編譯項目後，進行安裝
安裝成功後通過命令：
會自動在當前目錄的 build/xclogparser/reports/ 路徑下生成報告，其中--project參數需要設置為待分析項目的名字，並注意當前在終端切換到希望寫入日誌的目錄。
報告截圖：
這個工具將作為我們後面分析提升編譯構建速度的主要使用工具。
經過我多次在不同時間段，不同電腦上不斷嘗試編譯，
我發現編譯耗時是一個比較玄的東西，及時在同一台電腦，同一個項目， 同一套環境配置下，編譯用時也會隨著電腦當前狀態（包括同時打開進程、散熱等等）上下大幅跳動，就像演算法時間復雜度一樣，有時候我們明明做了一些細微的優化，但是結果反而是編譯耗時增加了，這是很正常的事情
所以，衡量這個標准需要我們取多次試驗中的平均值作為參考。
2. C語言多充循環，運算次數多，編譯時間很長，又無法估計最終需要多久，怎麼辦
如果要減少時間 那麼優化代碼，或者直接改進演算法
如果要預測時間，那麼大致估計一下循環的次數，然後在固定的某個循環中加一個列印，通過列印頻率來估算總時間
3. Visual Studio編譯很慢，什麼原因
Visual Studio編譯很慢解決辦法：
打開vs2010的工具選項，環境>常規之下 查看」視覺體驗」配置，它默認選擇了」基於客戶端性能自動調整視覺體驗」並啟用硬體圖形加速，取消選擇這個選擇。
4. 一個C++工程中，許多個文件都include某一個類，當該類更新時，編譯速度太慢，怎麼辦
這是個好問題，雖然老生常談，但真正知道解決方案的人很少。《EffectiveC++》有介紹，同時推薦這本書給所有C++er。
一個組織有問題的大型項目中，影響編譯速度的最大問題就是頭文件形成龐大的依賴網路，其中一個頭文件修改就導致一大堆間接依賴的源代碼文件需要重新編譯。a.h包含b.h，b.h包含c.h，c.h又包含d.h，即使a.h和d.h似乎沒什麼關系，修改d.h的時候還是無可避免a.cc被重新編譯。
首先得知道C++一個特性，函數分為聲明和實現兩部分是人所皆知，但類也可以分為前置聲明和定義可能知道的人就比較少了，知道能怎麼用就更少了，其實就是可以用來解決編譯速度問題的。
5. 用Keil編譯程序時數據段過長怎麼辦
程序DATA區空間已超過指定單片機的DATA區空間，可以用keil C編譯的時候壓縮。
6. tomcat部署的應用將jsp頁面轉換為java文件後編譯該java文件成class文件耗時很長大概有3分鍾。求解！
不可能的事，tomcat做這些操作只需幾秒鍾
7. Android studio 編輯build.gradle文件時卡頓時間過長是什麼原因
方法1：
1、在C:\User\<用戶名>\.gradle 目錄下新建一個gradle.properties文件，並在裡面添加一行：org.gradle.daemon=true
2、打開AS，在Settings中設置Gradle的工作模式為offline，如下圖：
這樣就可以解決一直在running的問題了
方法2：
找到路徑C:\Users\admin\.gradle\wrapper\dists，在此文件夾下有一個gradle版本文件夾，打開後是一個名字很長的文件夾，
例如我的C:\Users\admin\.gradle\wrapper\dists\gradle-2.4-all\6r4uqcc6ovnq6ac6s0txzcpc0 然後下載對應版本的gradle，將下載的壓縮包直接放進名字很長的文件夾中即可，不需要解壓
方法3：
需要在android studio 中配置gradle的代理，當然是用goagent了。
打開setting->gradle->Gradle VM Options：
-Dhttp.proxyHost=127.0.0.1 -Dhttp.proxyPort=8087
設置生成功後，重啟androidstudio ，速度會非常快。
方法4：
1）進入剛安裝的Android Studio目錄下的bin目錄。找到idea.properties文件，用文本編輯器打開。
2）在idea.properties文件末尾添加一行： disable.android.first.run=true ，然後保存文件。
3）關閉Android Studio後重新啟動，便可進入界面。
方法:5：
可能是由於國內的某些殺毒軟體禁用了aapt.exe進程導致的。aapt即Android Asset Packaging Tool，在SDK的build-tools目錄下。該工具可以查看，創建， 更新ZIP格式的文檔附件(zip, jar, apk)。也可將資源文件編譯成二進制文件，盡管你可能沒有直接使用過aapt工具，但是build scripts和IDE插件會使用這個工具打包apk文件構成一個Android 應用程序。
解決辦法：
網上有個解決的方法，是通過延長aapt.exe的啟動時間來解決的，在系統變數中加上「SLAVE_AAPT_TIMEOUT」，並設置值為30，同時也要在用戶變數中加上"JAVA_HOME"的設置，不過相信只要是做java或者android開發的人都會設置好"JAVA_HOME"吧
8. keil4每次build target 都是全編譯是怎麼回事啊每次花很長時間啊，謝謝！！！
嘗試以下幾種解決方法：
方法1：project--option for target 'xxx' ---Listing---將C Preprocessor Listing:.\Listings*.I 的勾選去掉。
方法2：project--option
for target 'xxx' ---target---Code Generation-- 將Use Cross-Mole Optimization勾選去掉
方法3：project--option for target 'xxx' ---Output---將Create Batch File的勾選去掉。
我的是方法1解決的
9. keil4每次build target 都是全編譯是怎麼回事啊每次花很長時間啊，謝謝!!!
全編譯，顧名思義，就是把工程里所有的文件都編譯一遍，不管這個文件是否有過改動，所以時間很長，因為這個過程是編譯--鏈接---生成HEX文件，所以，如果你文件很多，代碼很多，時間就很長。
而半編譯是只對你改動過的文件進行重新的編譯，所以，過程是
編譯部分文件--重新鏈接--生成HEX.
如果你不是把Keil的優化等級調到了8級及以上，用半編譯完全沒問題。
10. myeclipse 編譯時間很長，項目很大，全編要2個小時。
方法1：將其他模塊打包，編譯自己所在的模塊；或自己寫個腳本變異這個路徑下的這個文件，因為最後生成的都是.Class類的可執行文件。
方法2：網上找個ant之類的腳本文件，直接修改路徑，變異這個文件