android系統級增量編譯

① 如何加快android Studio 編譯app 的速度

以下幾個方法可以提高Android Studio的編譯速度：

• 使用Gradle 2.4。

1. Gradle 2.4對執行性能有很大的優化，要手動讓Android Studio使用Gradle 2.4，在項目根目錄下的 build.grade中加入。

   

   ② android系統編譯jar包給app使用

   最近在android O編譯系統jar包給應用使用遇到了點問題，網上也沒有找到解決方案，這里記錄下。
   
   編譯方法參考網上博客就可以， android源碼編譯jar包
   
   最終生成了javalib.jar，改名為 tvManager.jar即可。注意：如果沒有指定LACAL_JACK_ENABLED選項，則默認是enabled，將會生成classes.jack文件，不會產生classes.jar包！
   
   正常按照上面方案就可以編譯出jar包，導入到AS裡面就可以使用，下面說下我遇到的問題
   
   遇到classes.jar.toc被依賴， 但是怎麼編譯都沒有編譯出來，網上也沒有找到對應的方法，編譯錯誤如下:
   
   https://www.cnblogs.com/wangqiang9/p/9679466.html
   https://stackoverflow.com/questions/43471694/how-to-generate-classes-dex-toc-files

   ③ 整體編譯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系統編譯命令make

   在編譯Android系統時，需要先執行2條命令，來設置必要的環境變數。
   
   接下來就可以執行make系列命令，來完成不同的需要。
   
   make clean 用來清除編譯歷史，開始一個全新的編譯。
   make -j 或 make -j8 啟動編譯過程。 -j 後面的數字代表要使用的cpu thread的數目。
   
   在完成了全編譯後，才能執行生成OTA升級包的操作。
   
   注意事項：

   ⑤ 編譯調試Android系統原生App - 以Settings為例

   本文已過時，最新文章：向大家推薦《使用 AS 開發 System App》 https://xiaozhuanlan.com/system-app
   
   Android原生系統帶有許多原生的App，比如 瀏覽器、錄音機、計算器、設置 等，有些時候，我們需要用到一些系統的功能，或者是對已有的功能做二次開發，比如我上學時給一個公司做過一個Launcher和Wizard，就需要用到系統設置中的某些功能，比如Wifi、聲音、顯示等功能，於是就需要從Settings源碼中提取出需要的功能。
   
   特別是公司自己定製Android系統，需要在上面做一些 系統級的App 的時候，原生App已有的功能就可以通過編譯其源碼的方式直接拿過來改改就能用，而且可用度很高。
   
   這里有兩種情況，分為 原生 的和 公司定製 的系統。無論是原生的還是定製的，類似於Settings這樣需要使用到 系統級或隱藏API 的App，都需要系統簽名文件和編譯系統源碼後得到相應的jar包才可以在IDE中編譯，因為標准SDK根本沒有那些API可供調用。
   
   舉個栗子：
   
   需要額外的Jar就需要自己編譯系統源碼啦，這個是比較麻煩的，有興趣可以試試自己編譯定製自己的Android系統。
   
   ** 注意，既然是定製的，源碼、jar、簽名文件，還有系統都是一一對應的，你不能拿其他公司的系統簽名來給你公司的系統app簽名，這樣無法運行的。 **
   
   有了源碼，下一步當然是要跑起來啦。
   
   建議都使用Eclipse來編譯，不要使用AS，因為AS編譯大型的原生App能卡到你吐血，而且出錯提示也不友好。但是用過AS的人都不想再碰Eclipse了有沒有？？別急，可以先用Eclipse編譯過了，再貼到AS中，這樣好很多，也很節省時間。
   
   初始化：
   
   放入源碼：
   
   修正res錯誤：
   
   修正src錯誤：
   
   使用到系統級API的，或者AndroidManifest.xml文件中聲明了
   
   那麼沒有系統簽名，直接debug簽名運行是不行的，需要向底層工程師要系統的簽名文件，在源碼目錄
   build\target\proct\security
   下的 platform.pk8 和 platform.x509.pem ，如果你想看此次編譯Settings是否已成功了，可以適當的在入口加一下Log，然後導出未簽名的apk，使用系統簽名進行簽名後，放到 /system/app/ 下替換掉Settings.apk，然後重啟系統，打開設置，看看Logcat是否輸出里加入的Log。
   
   在不知道系統簽名可以轉換成debug簽名前，老實說我一直都是用Log的方式調試，太特么痛苦了。現在知道後整個人都懵逼了。
   
   我們都希望可以像調試普通app那樣調試系統app，以下是如何通過 openssl 將 platform.pk8 和 platform.x509.pem 轉換成 debug.keystore 文件：
   
   三個命令
   
   此方法來自： http://curlog.com/2016/08/30/android-pk2debug-keystore/
   
   Mac自帶openssl，linux和Win需要安裝。
   
   然後就可以使用得到的debug簽名配置到eclipse後愉快的調試啦，當然，得先把系統中已經存在的app先刪除掉。然後重啟系統，至於如何配置eclipse的debug簽名，請Google。
   
   使用過AS後，當然希望在AS中也可以調試系統App，抽空再寫篇相關編譯和調試的文章。如果這篇文章幫到你了，給個贊唄。

   ⑥ Android系統編譯指令make 、mmm、mm優缺點比較

   Android 系統提供了三種指令用於編譯，他們分別為make、mmm、mm，這三個指令編譯的優缺點如下：
   
   例如：make MediaProvider z這種模式對應於單個模塊的編譯。它的優點是：會把該模塊依賴的其他模塊一起跟著編譯。例如：make libmedia 就會把libmedia依賴庫全部編譯好。當然缺點也會很明顯，那就是它會搜索整個源碼來定位MediaProvider 模塊所使用的Android.mk文件。並且還要判斷該模塊依賴的其他模塊是否有修改。所以編譯時間比較長。
   
   注意：一般的編譯方式都會採用增量編譯，即只編譯發生變化的目標文件，但有時則需要重新編譯所有目標文件，那麼就可以使用make 命令行的-B選項。例如：mm -B 模塊名，或者mm -B、mmm -B。在mm 和 mmm內部也是調用make命令的，而make的-B選項將強制編譯所有的目標文件。

   ⑦ 如何在windows下編譯android系統

   目前官網不提供在windows下對android的支持，只提供對linux/mac(類UNIX)的支持，可參考 http://source.android.com/source/download.html
   
   android基於linux 內核，對其相關編譯和連接環境有依賴。建議在windows上安裝虛擬機，安裝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,因對終端設備(慢速設備)的阻塞寫操作也會拖慢速度。推薦內存文件，這樣發生錯誤時，能夠查看。