安卓編譯時長

Ⅰ ubuntu12.04編譯android源碼要多久

這個關鍵是要看你的電腦配置情況，以及代碼的附加情況，有的平台軟體會附加很多東西上去，編譯就比較慢了。
我們這邊使用的是四核八線程的電腦，32GB內存，
原生代碼 4.4 八線程編譯40分鍾左右，5.1，一個半小時左右，6.0的大約一個小時，以上是原生代碼編譯模擬器的時間。

高通代碼6.0編譯一般需要兩個小時左右，mtk的也是兩個小時左右，

Ⅱ 9700k or 3700x+32GB ddr4,初次編譯完整安卓8源碼需要多長時間

純粹玩游戲是9700K略強，但3700X以比9700K低500多的價格卻能有9700K大約95%的游戲性能，且多線程性能戰平目前Intel的消費級旗艦9900K，且3700X還首發支持了PCI-E 4.0技術，能提供更多的帶寬用於顯卡和高端固態硬碟如果是我，我肯定選3700X，如果你純粹追求幀率，買9700K也是可以的，畢竟絕大多數游戲9700K幀率的確比3700X更好看，總體的游戲體驗也稍好一些，首發評測已經出來了

追問：

那要是玩游戲的情況下，超線程有用嗎？現在9700k加Z390中端的板子大概3800左右，3700x加中端X570也是3800左右。在一個聽說3700x有迷之卡頓，是真的嗎？
追答：

超線程對大部分游戲沒有幫助，但也不會有負面影響，超線程對核心硬體資源的分配是動態的，並不會將一個物理核心均分為二，在需要單線程運算時核心會完全讓出全部的硬體資源給這一線程，另一個線程僅僅只是佔位符，不實際擁有資源，運行多線程密集型任務時每個核心才是基本兩個線程各擁有一半的核心資源，但游戲並不屬於這種類型
三代銳龍剛剛上市，還沒有大規模發售，目前只有小部分人入手，具體情況還不好說，銳龍前兩代的確有卡頓現象，原因是CPU中的內存控制器到內存間的傳輸延遲過高，而游戲恰恰又是延遲敏感型應用，三代銳龍正好改進了這一問題，雖然延遲還達不到Intel高端酷睿的水準，但相比前兩代理論上會有明顯好轉

Ⅲ 整體編譯Android系統，大家用了多少時間

我自己實際編譯ICS4.0.4源碼情況：acer台式機，3.2Ghz cpu，4核，8GB/1600hz內存，整體編譯（含u-boot、kernel、boot.img和system.img）需要1小時10分鍾。編譯時，使用make -j8（因為硬體cpu是4線程的，故使用2倍線程數）。之後的增量編譯，一般需要5~10分鍾即可。

Ⅳ Android源碼編譯是干什麼

編譯Android系統。

Ⅳ 用ubuntu虛擬機編譯android5.1要多久

vmware workstation 10
ubuntu-10.04.4-desktop-amd64.iso
1
ubuntu的安裝,打開vmware workstation 10，點創建新的虛擬機
2
點下一步
3
選擇下載的UBANTU光碟ISO文件，點下一步
4
設置Ubantu名稱及登錄用戶名及密碼，點下一步
5
設置虛擬機文件名稱及保存在磁碟上的位置，點下一步
6
設置虛擬機使用磁碟大小，若要編譯ANDROID，至少設置40GB,這里設置200GB保證足夠夠用
7
至此主要的設置都完成了，直接點擊完成即可。也可點擊自定義硬體進行詳細的設置，我們點自定義硬體，來設置內存
8
把虛擬機內存設置成實體機內存的一般大小，以保證安裝Ubantu的時候，速度不會卡，這里我設置成4GB，其它保持默認即可。設置完後點擊關閉。這個我們可以在任何時候配置硬體，甚至可以在UBANTU安裝完成之後再重新編輯硬體設置，只需點下圖的編輯虛擬機設置
9
配置完成，下面才是真正開始安裝，點擊開啟此虛擬機UBANTU即開始自動安裝，全程自動，無人值守
10
初始化安裝
11
安裝中 ，5%
12
安裝中 ，50%
13
安裝中 ，79%
14
安裝中 ，100%
15
安裝完成就開始自動安裝VMware Tools,這VMware Tools不屬於Ubantu操作系統，只是VMware公司方便主操作系統與客戶操作系統交互而提供的一個工具軟體
16
安裝完成，自動重啟，顯示登陸界面，點擊輸入前面設置的密碼登錄
17
登陸完成，安裝成功！！！
END
1
下面對UBANTU進行一些設置，以符合我們的工作習慣
修改默認顯示解析度，選擇System--->Preference--->monitors，修改顯示解析度為1280x800
2
修改待機屏幕保護及鎖屏時間，選擇System--->Preference--->screensaver，，去掉屏幕保護程序激活時鎖屏，免得安裝軟體時或編譯時總要輸入密碼才能登入系統
3
編輯虛擬機硬體設置，修改客戶機時間與主機時間同步
4
調出我的電腦、網上鄰居、我的文檔、回收站等圖標
按鍵盤的Alt 和 F2，打開 Run Application程序，輸入gconf-editor，然後Run打開Configuration Editor，選擇apps--->nautilus--->desktop，如圖所示框選相應選項即可
5
將終端放置在桌面和上面板上，以方便我們點擊調用，如圖所示
6
安裝右鍵調用終端工具，通常點擊右鍵，右鍵菜單沒有open in terminal右鍵打開終端工具
輸入sudo apt-get install nautilus-open-terminal命令，安裝右鍵打開終端工具
7
修改操作系統界面為中文，選擇System--->admininstration--->langunge support，如圖設置安裝中文語言包，經試驗安裝中文語言包極其緩慢，需要更新源，下一節會講到
8
設置虛擬機系統與主機系統共享文件夾，方法很多，
1.主機讀取虛擬客戶機共享出來的文件夾
2.虛擬客戶機讀取主機共享出來的文件夾
後面我會花時間專門一節講解虛擬機系統與主機文件夾共享的各種方法
END
本經驗是由本人親自測試編寫，圖片文字全部為原創，網路經驗首發，未經許可，謝絕轉載！
如果覺得本人的經驗對你有幫助，請點擊支持，謝謝！
換一批相關經驗
android4.4源碼編譯環境搭建72014.06.26
android開發環境之虛擬機搭建72014.04.30
Ubuntu10.04搭建MTK android編譯環境02014.04.06
android學習1-虛擬機的搭建02015.01.15
android學習2-虛擬機設置成漢語02015.01.16
相關標簽 android 虛擬機
©2015Bai 使用網路前必讀 網路經驗協議 作者創作作品協議

Ⅵ Android Studio編譯慢、卡死和狂佔內存怎麼破

在2020年，仍然使用2g內存的電腦，你可以改變職業。沒有合適的設備，什麼都沒用。Android Studio是內存，設備爛卡死不可避免，要解決卡的問題，一定要升級硬體設備。另一些人則說，對修辭學的回答相當有力，在一定程度上，加快編譯的速度，卻不能解決卡死的問題，沒有人能解釋為什麼會加快編譯的速度。

至於加快編譯，有一種方法，我認為一些主要適用性的答案並不強，實際上應該從gradle開始，什麼不是正確的地方，也請輕噴，有什麼問題可以留個信息。

我談到了下面的所有步驟，建議在最後進行。在終端編譯中有很多好處:

能觀察整個編譯過程，幫助理解層次構建過程;

可以看出哪些任務在編譯過程中耗費時間，可以較慢地編寫出適合的補救方案;

可以終止編譯，如果在某個階段被卡住，CTRL + c終止編譯，Android也會終止在Studio中編譯，但基本上九次會失敗;

因為它最終會對Android Studio產生影響，基本不會導致Android Studio caton;不滿足Android工作室的各種bug ?

最後，為什麼要減少設置中模塊的數量。Gradle實際上可以加速編譯，但是有很多限制?

首先,我們認為編譯過程,首先解析gradle配置,設置任務依賴於有向圖,然後執行每個任務的模塊,如果我們通過maven的依賴關系,使用模塊的aar(單android庫),如果我們想要改變文件在這個模塊,不要再次修改上傳下載,每次都是很好,但是有一個致命的問題:不修改版本號,快照通常不是做的想法。這可能導致一些不會生效的變化，並且需要時間來解決這個問題。但是，有一種方法可以在一定程度上解決這個問題，並添加以下腳本:

項目。配置。所有(新操作<配置> ({@ Overridevoidexecute(配置文件){文件)。ResolutionStrategy。TimeUnit CacheDynamicVersionsFor(5。分鍾)

文件。ResolutionStrategy。TimeUnit CacheChangingMolesFor(0。秒)} })

有人會問，插件，每個人都要開發一個模塊，對於每個模塊的維護都要打包到maven，每次我修改，甚至很小的改動，也要做一個上傳，就會遇到快照不做同樣的問題。嘿，嘿，這個問題，我們公司有一個等級插件，已經解決了，至於解決方案，是公司機密，我不會說。

一件事,我相信大多數開發人員共同發展是單一模塊,該模塊的情況並不多,所以最基本的也是依賴aar或罐子里,並不存在所謂的圖書館aar上傳,所以一些答案的耶和華說並不意味著什麼,這就是為什麼我說影響編譯速度的情況主要集中在它的生命周期的第三階段,第三階段的優化,看到我的答案。

Ⅶ 如何加快linux android 的編譯速度

項目越來越大，每次需要重新編譯整個項目都是一件很浪費時間的事情。Research了一下，找到以下可以幫助提高速度的方法，總結一下。
1. 使用tmpfs來代替部分IO讀寫
2.ccache，可以將ccache的緩存文件設置在tmpfs上，但是這樣的話，每次開機後，ccache的緩存文件會丟失
3.distcc,多機器編譯
4.將屏幕輸出列印到內存文件或者/dev/null中，避免終端設備（慢速設備）拖慢速度。

tmpfs
有人說在Windows下用了RAMDisk把一個項目編譯時間從4.5小時減少到了5分鍾，也許這個數字是有點誇張了，不過粗想想，把文件放到內存上做編譯應該是比在磁碟上快多了吧，尤其如果編譯器需要生成很多臨時文件的話。
這個做法的實現成本最低，在Linux中，直接mount一個tmpfs就可以了。而且對所編譯的工程沒有任何要求，也不用改動編譯環境。
mount -t tmpfs tmpfs ~/build -o size=1G
用2.6.32.2的Linux Kernel來測試一下編譯速度：
用物理磁碟：40分16秒
用tmpfs：39分56秒
呃……沒什麼變化。看來編譯慢很大程度上瓶頸並不在IO上面。但對於一個實際項目來說，編譯過程中可能還會有打包等IO密集的操作，所以只要可能，用tmpfs是有益無害的。當然對於大項目來說，你需要有足夠的內存才能負擔得起這個tmpfs的開銷。
make -j
既然IO不是瓶頸，那CPU就應該是一個影響編譯速度的重要因素了。
用make -j帶一個參數，可以把項目在進行並行編譯，比如在一台雙核的機器上，完全可以用make -j4，讓make最多允許4個編譯命令同時執行，這樣可以更有效的利用CPU資源。
還是用Kernel來測試：
用make： 40分16秒
用make -j4：23分16秒
用make -j8：22分59秒
由此看來，在多核CPU上，適當的進行並行編譯還是可以明顯提高編譯速度的。但並行的任務不宜太多，一般是以CPU的核心數目的兩倍為宜。
不過這個方案不是完全沒有cost的，如果項目的Makefile不規范，沒有正確的設置好依賴關系，並行編譯的結果就是編譯不能正常進行。如果依賴關系設置過於保守，則可能本身編譯的可並行度就下降了，也不能取得最佳的效果。
ccache
ccache工作原理：
ccache也是一個編譯器驅動器。第一趟編譯時ccache緩存了GCC的「-E」輸出、編譯選項以及.o文件到$HOME/.ccache。第二次編譯時盡量利用緩存，必要時更新緩存。所以即使"make clean; make"也能從中獲得好處。ccache是經過仔細編寫的，確保了與直接使用GCC獲得完全相同的輸出。

ccache用於把編譯的中間結果進行緩存，以便在再次編譯的時候可以節省時間。這對於玩Kernel來說實在是再好不過了，因為經常需要修改一些Kernel的代碼，然後再重新編譯，而這兩次編譯大部分東西可能都沒有發生變化。對於平時開發項目來說，也是一樣。為什麼不是直接用make所支持的增量編譯呢？還是因為現實中，因為Makefile的不規范，很可能這種「聰明」的方案根本不能正常工作，只有每次make clean再make才行。
安裝完ccache後，可以在/usr/local/bin下建立gcc，g++，c++，cc的symbolic link，鏈到/usr/bin/ccache上。總之確認系統在調用gcc等命令時會調用到ccache就可以了（通常情況下/usr/local /bin會在PATH中排在/usr/bin前面）。
安裝的另外一種方法：
vi ~/.bash_profile
把/usr/lib/ccache/bin路徑加到PATH下
PATH=/usr/lib/ccache/bin:$PATH:$HOME/bin
這樣每次啟動g++的時候都會啟動/usr/lib/ccache/bin/g++，而不會啟動/usr/bin/g++
效果跟使用命令行ccache g++效果一樣
這樣每次用戶登錄時，使用g++編譯器時會自動啟動ccache
繼續測試：
用ccache的第一次編譯(make -j4)：23分38秒
用ccache的第二次編譯(make -j4)：8分48秒
用ccache的第三次編譯(修改若干配置，make -j4)：23分48秒

看來修改配置（我改了CPU類型...）對ccache的影響是很大的，因為基本頭文件發生變化後，就導致所有緩存數據都無效了，必須重頭來做。但如果只是修改一些.c文件的代碼，ccache的效果還是相當明顯的。而且使用ccache對項目沒有特別的依賴，布署成本很低，這在日常工作中很實用。
可以用ccache -s來查看cache的使用和命中情況：
cache directory /home/lifanxi/.ccachecache hit 7165cache miss 14283called for link 71not a C/C++ file 120no input file 3045files in cache 28566cache size 81.7 Mbytesmax cache size 976.6 Mbytes
可以看到，顯然只有第二編次譯時cache命中了，cache miss是第一次和第三次編譯帶來的。兩次cache佔用了81.7M的磁碟，還是完全可以接受的。
distcc
一台機器的能力有限，可以聯合多台電腦一起來編譯。這在公司的日常開發中也是可行的，因為可能每個開發人員都有自己的開發編譯環境，它們的編譯器版本一般是一致的，公司的網路也通常具有較好的性能。這時就是distcc大顯身手的時候了。
使用distcc，並不像想像中那樣要求每台電腦都具有完全一致的環境，它只要求源代碼可以用make -j並行編譯，並且參與分布式編譯的電腦系統中具有相同的編譯器。因為它的原理只是把預處理好的源文件分發到多台計算機上，預處理、編譯後的目標文件的鏈接和其它除編譯以外的工作仍然是在發起編譯的主控電腦上完成，所以只要求發起編譯的那台機器具備一套完整的編譯環境就可以了。
distcc安裝後，可以啟動一下它的服務：
/usr/bin/distccd --daemon --allow 10.64.0.0/16
默認的3632埠允許來自同一個網路的distcc連接。
然後設置一下DISTCC_HOSTS環境變數，設置可以參與編譯的機器列表。通常localhost也參與編譯，但如果可以參與編譯的機器很多，則可以把localhost從這個列表中去掉，這樣本機就完全只是進行預處理、分發和鏈接了，編譯都在別的機器上完成。因為機器很多時，localhost的處理負擔很重，所以它就不再「兼職」編譯了。
export DISTCC_HOSTS="localhost 10.64.25.1 10.64.25.2 10.64.25.3"
然後與ccache類似把g++，gcc等常用的命令鏈接到/usr/bin/distcc上就可以了。
在make的時候，也必須用-j參數，一般是參數可以用所有參用編譯的計算機CPU內核總數的兩倍做為並行的任務數。
同樣測試一下：
一台雙核計算機，make -j4：23分16秒
兩台雙核計算機，make -j4：16分40秒
兩台雙核計算機，make -j8：15分49秒
跟最開始用一台雙核時的23分鍾相比，還是快了不少的。如果有更多的計算機加入，也可以得到更好的效果。
在編譯過程中可以用distccmon-text來查看編譯任務的分配情況。distcc也可以與ccache同時使用，通過設置一個環境變數就可以做到，非常方便。
總結一下：
tmpfs： 解決IO瓶頸，充分利用本機內存資源
make -j： 充分利用本機計算資源
distcc： 利用多台計算機資源
ccache： 減少重復編譯相同代碼的時間
這些工具的好處都在於布署的成本相對較低，綜合利用這些工具，就可以輕輕鬆鬆的節省相當可觀的時間。上面介紹的都是這些工具最基本的用法，更多的用法可以參考它們各自的man page。
5.還有提速方法是把屏幕輸出重定向到內存文件或/dev/null,因對終端設備(慢速設備)的阻塞寫操作也會拖慢速度。推薦內存文件，這樣發生錯誤時，能夠查看。

Ⅷ Android Studio編譯慢，卡死和狂佔內存怎麼破

已經使用AndroidStudio進行開發超過一年，隨著項目的增大，依賴庫的增多，構建速度越來越慢，現在最慢要6分鍾才能build一個release的安裝包，在網上查找資料，發現可以通過一些配置可以加快速度，這里跟大家分享一下。開啟gradle單獨的守護進程在下面的目錄下面創建gradle.properties文件：/home//.gradle/(Linux)/Users//.gradle/(Mac)C:\Users\\.gradle(Windows)並在文件中增加：org.gradle.daemon=true同時修改項目下的gradle.properties文件也可以優化：#Project-wideGradlesettings.#IDE(e.g.AndroidStudio)users:##configuredthroughtheIDE.###sec:configuration_on_demandorg.gradle.configureondemand=true同時上面的這些參數也可以配置到前面的用戶目錄下的gradle.properties文件里，那樣就不是針對一個項目生效，而是針對所有項目生效。上面的配置文件主要就是做，增大gradle運行的java虛擬機的大小，讓gradle在編譯的時候使用獨立進程，讓gradle可以平行的運行。修改androidstudio配置在androidstudio的配置中，開啟offline模式，以及修改配置。實際上的配置和上面的一大段一樣，主要是在這個地方配置的只會在ide構建的時候生效，命令行構建不會生效。命令行構建基於上面的配置，命令行構建時在命令後面加上這個參數即可--daemon--parallel--offline。引入依賴庫時使用aar使用網上第三方的依賴庫時盡量使用aar，可以在maven/android/2015/03/01/android-reference-local-aar/。

Ⅸ 我的手機上編譯時間是11月10日，安卓更新時間是10月1日，這是什麼意思

編譯時間是手機系統軟體版本編譯完成的時間，新手機的系統編譯時間通常會早於手機出廠和購買時間的。

Ⅹ 如何編譯android kernel

1.准備工作： （ubuntu1110 32位）
ubuntu等linuxOS，下載好eclipse，安裝好JDK， 安裝好android的SDK， 在eclipse中成功打開android 手機模擬器即OK。

2.初始化編譯環境 ：
關注該網頁上的「installing required packages」,其中有的軟體包因為版本問題而安裝不上，不用管它，之後遇到錯誤再單獨解決。

3.下載內核源碼：
android 2.3 內核 下載需要等待一段時間。

4.下載交叉編譯器：
該步驟有可能耗費大量時間，依據網速不同，幾個小時到幾天不等，或許可以嘗試git clone 後面的地址只下載prebuilt/linux-x86/toolchain

5.設置參數以及編譯：
$ export ARCH=arm
$ export SUBARCH=arm
$ export CROSS_COMPILE=arm-eabi-
$ cd goldfish // 進入下載的源代碼目錄
$ git checkout <commit_from_first_step> //這個步驟我沒有做，不知道幹嘛用的
$ make goldfish_defconfig
$ make

6.報錯信息：
若有報錯說找不到 （arm-eabi-gcc command not found）等等，嘗試使用http://blog.csdn.net/davidbeckham2901/article/details/7397447 中說到的解決方案即可（即採用另外一個交叉編譯器）。

7.測試：

最後，測試一下剛才編譯的內核：emulator -avd myavd -kernel ~/goldfish/arch/arm/boot/zImageemulator若系統找不到，可以去android SDK中某文件夾找到，加入系統PATH即可。 -avd後面的參數 myavd即為模擬器的名字，這個我是在eclipse中的模擬器管理中新建的一個模擬器，用那個模擬器的名字即可。 -kernel後面的參數就找到剛才編譯出的內核的路徑。
若啟動模擬器失敗，可嘗試關閉後再啟動。第一次啟動模擬器時可能需要等待比較長的時間，3分鍾到15分鍾不等。