安卓10源碼tmpfs

1. 如何編譯android userdata.img

1、android文件系統的結構
android源碼編譯後得到system.img,ramdisk.img,userdata.img映像文件。其中， ramdisk.img是emulator的文件系統，system.img包括了主要的包、庫等文件，userdata.img包括了一些用戶數據，emulator載入這3個映像文件後，會把 system和 userdata分別載入到 ramdisk文件系統中的system和 userdata目錄下。因此，可以把ramdisk.img里的所有文件復制出來，system.img和userdata.img分別解壓到 ramdisk文件系統中的system和 userdata目錄下。

2、分離android文件系統出來
system.img,ramdisk.img,userdata.img映像文件是採用cpio打包、gzip壓縮的，可以通過file命令驗證：
file ramdisk.img，輸出：
ramdisk.img: gzip compressed data, from Unix, last modified: Wed Mar 18 17:16:10 2009
Android源碼編譯後除了生成system.img，userdata.img之外還生成system和 userdata文件夾，因此不需要解壓它們。Android源碼編譯後還生成root文件夾，其實root下的文件與 ramdisk.img 里的文件是一樣的，不過這里還是介紹怎樣把 ramdisk.img解壓出來:
將ramdisk.img復制一份到任何其他目錄下，將其名稱改為ramdisk.img.gz，並使用命令
gunzip ramdisk.img.gz
然後新建一個文件夾，叫ramdisk吧，進入，輸入命令
cpio -i -F ../ramdisk.img
這下，就能看見並操作ramdisk裡面的內容了。
然後把Android源碼編譯後生成的system和 userdata里的文件復制到 ramdisk/system和 ramdisk/userdata下。這樣就得到一個文件系統了。

3、使用網路文件系統方式掛載android文件系統
因此，需要建立/nfsroot目錄，再建立/nfsroot/androidfs目錄，把剛才的android文件系統改名為androidfs，並鏈接到/nfsroot/androidfs

4、android內核引導文件系統
android內核掛載/nfsroot/androidfs之後，根據init.rc,init.goldfish.rc來初始化並裝載系統庫、程序等直到開機完成。init.rc腳本包括了文件系統初始化、裝載的許多過程。init.rc的工作主要是：
1）設置一些環境變數
2）創建system、sdcard、data、cache等目錄
3）把一些文件系統mount到一些目錄去，如，mount tmpfs tmpfs /sqlite_stmt_journals
4）設置一些文件的用戶群組、許可權
5）設置一些線程參數
6）設置TCP緩存大小

2. 如何加快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,因對終端設備(慢速設備)的阻塞寫操作也會拖慢速度。推薦內存文件，這樣發生錯誤時，能夠查看。

3. 如何針對特定機型，編譯cwm recovery

*1 准備Ubuntu作為您的操作系統，筆者的版本是12.04_amd64。

*2 准備 Android 源碼的編譯環境，主要是安裝一些編譯用到的lib庫，以及同步源碼的一些工具，如GIT，CURL，REPO等。具體可參考：http://source.android.com/source/index.html[source.android.com]

*3 在確保環境已准備妥當之後，接下來開始下載 Android 源碼，此文以cm 10.1 源碼為例。

1).創建一個用於存放源碼的目錄，如：jellybean/system

mkdir –p jellybean/system

2).切換到該目錄

cd jellybean/system

3).初始化cm-10.1的分支

repo init -u git://github.com/CyanogenMod/android.git -b cm-10.1

4).同步源碼

repo sync –j30

*4 適配你的Vendor

1).前提條件

* 已root;

* 有boot.img或者recovery.img

2).手動建立Vendor文件夾：device/ZTE/N881F，規則為「device/device_manufacturer_name/device_name」，這里 「device_manufacturer_name」 指的是你要編譯的設備的廠商，「device_name」 指的是你的設備名稱。

mkdir –p device/ZTE/N881F

3).獲取boot.img

adb連接手機狀態下，輸入

adb shell

進入shell模式，保證手機已root，輸入 su，轉入root許可權，輸入

cat /proc/mtd

查看有recovery（和/或）boot路徑，如果存在，分別執行

dd if=/your_boot_partition of=/your_sdcard_if_exists/boot.img
dd if=/your_recovery_partition of=/your_sdcard_if_exists/recovery.img

your_boot_partition 是mtd文件中記載的boot的路徑，your_sdcard_if_exists 是你的sdcard路徑，recovery同理，完成後退出shell,在終端或命令行下執行

adb pull /your_sdcard_if_exists/boot.img d:\boot.img
adb pull /your_sdcard_if_exists/recovery.img d:\recovery.img

這樣就獲取了boot.img和recovery.img文件

如果cat /proc/mtd 提示 No such file or directory，請在adb shell的root許可權下執行

mount

在輸出中查找 system,userdata,cache的路徑，通常情況下,boot,recovery路徑會和他們保持一致，一個可能的輸出是

root@edison:/ # mount
mount
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/system /system ext3 ro,relatime,barrier=1,data=ordered 0 0
/dev/block/pds /pds ext3 rw,nosuid,nodev,noatime,nodiratime,errors=continue,barrier=1,data=ordered 0 0
/dev/block/preinstall /preinstall ext3 rw,nosuid,nodev,noatime,nodiratime,barrier=1,data=ordered 0 0
/dev/block/userdata /data ext3 rw,relatime,errors=continue,barrier=0,data=ordered 0 0
/dev/block/cache /cache ext3 rw,nosuid,nodev,noatime,nodiratime,errors=continue,barrier=1,data=ordered 0 0
/dev/fuse /mnt/sdcard fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
/dev/block/vold/179:97 /mnt/external1 vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0

分析內容發現，沒有boot，沒有Recovery分區。。。不急，咱們找規律。
/dev/block/cache，/dev/block/userdata，/dev/block/system。。。這樣是不是boot和recovery分區路徑為/dev/block/boot和/dev/block/recovery？

此時查看 /dev/block 目錄

root@edison:/ # ls /dev/block
ls /dev/block
boot
cache
cdrom
cid
...
recovery
...

真有，那麼 boot 和 recovery 即是我們要尋找的文件，接下來，同樣使用 dd 命令導出它們到sdcard，再使用adb pull命令導出到本地磁碟

4).生成vendor

source build/envsetup.sh
make -j4 otatools
build/tools/device/mkvendor.sh device_manufacturer_name device_name /your/path/to/the/boot.img

實際命令如下：

source build/envsetup.sh
make -j4 otatools
build/tools/device/mkvendor.sh ZTE N881F boot.img

上述命令假設你的boot.img存放於源碼目錄下。

5).提取recovery.fstab。經過第4)步驟後，會生成一份默認的recovery.fstab到你的N881F目錄下，這時我們需要獲取一份屬於你機器的掛載點，這時候有兩種辦法：

* 直接查看手機里的「/cache/recovery/last_log」，如果該文件存在，則查找如下內容：

recovery filesystem table

=========================

如果有上述內容，那就將它拷貝粘貼至recovery.fstab。

* 解包recovery.img，解壓後的etc目錄下有此文件，直接拷過來用。文件內容：

mount point fstype device [device2]
/boot emmc /dev/block/mmcblk0p8
/cache ext4 /dev/block/mmcblk0p15
/data ext4 /dev/block/mmcblk0p13
/misc emmc /dev/block/mmcblk0p17
/recovery mtd /dev/block/mmcblk0p16
/sdcard vfat /dev/block/mmcblk1p1 /dev/block/mmcblk1
/system ext4 /dev/block/mmcblk0p12
/sdcard2 vfat /dev/block/mmcblk0p20

6).准備 recovery.rc

import /init.recovery.${ro.hardware}.rc
on early-init
start ueventd
on init
export PATH /sbin
export ANDROID_ROOT /system
export ANDROID_DATA /data
export EXTERNAL_STORAGE /sdcard
symlink /system/etc /etc
mkdir /boot
mkdir /recovery
mkdir /sdcard
mkdir /internal_sd
mkdir /external_sd
mkdir /sd-ext
mkdir /datadata
mkdir /emmc
mkdir /system
mkdir /data
mkdir /cache
mount /tmp /tmp tmpfs
chown root shell /tmp
chmod 0775 /tmp
write /sys/class/android_usb/android0/enable 0

#可能會修改的地方
write /sys/class/android_usb/android0/idVendor 19d2
write /sys/class/android_usb/android0/idProct 1361
write /sys/class/android_usb/android0/functions mass_storage,adb

write /sys/class/android_usb/android0/iManufacturer ${ro.proct.manufacturer}
write /sys/class/android_usb/android0/iProct ${ro.proct.model}
write /sys/class/android_usb/android0/iSerial ${ro.serialno}
on boot
ifup lo
hostname localhost
domainname localdomain
class_start default
service ueventd /sbin/ueventd
critical
service recovery /sbin/recovery
service adbd /sbin/adbd recovery
disabled
# Always start adbd on userdebug and eng builds
on property:ro.debuggable=1
write /sys/class/android_usb/android0/enable 1
start adbd
setprop service.adb.root 1
# Restart adbd so it can run as root
on property:service.adb.root=1
write /sys/class/android_usb/android0/enable 0
restart adbd
write /sys/class/android_usb/android0/enable 1

7).修改 recovery.rc

這份文件大致是通用的，可能需要修改的地方單獨指出來了，如若Recovery編譯完後USB大容量不能正常掛載，則可去手機里查看「/sys/class/android_usb/android0/idVendor」和「/sys/class/android_usb/android0/idProct」這兩個文件的內容，然後依次填入上述可修改處的值（如 idVendor 19d2，把「19d2「換成「/sys/class/android_usb/android0/idVendor」對應的值即可）。

在Ubuntu下還可以用lsusb命令查看這兩個值:

focus@ubuntu:/media/linux/jellybeanplus/system$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 003: ID 064e:d20c Suyin Corp.
Bus 002 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 003 Device 013: ID 19d2:1361 ZTE WCDMA Technologies MSM

最後一行的19d2和1361即為idVendor和idProct。

8).重寫按鍵對應的c文件 recovery_ui.c

9).提取設備的根文件系統的rc或sh文件，如init.qcom.usb.rc，init.qcom.usb.sh。（僅在根文件系統的目錄下有這些文件的情況下成立，如無則忽略）

10).查看內核基址，ramdisk文件的offset偏移量等

11).提取system.prop

adb pull /system/build.prop

從手機里pull過來build.prop後，拷貝到N881F目錄，打開文件，將文件內容拷貝至system.prop，然後將build.prop文件刪除。

*5 開始編譯

1).設置源碼環境變數

gedit ~/.bashrc

添加如下環境變數：

# Android environment
export TARGET_ARCH=arm
export ANDROID_SDK_TOOLS=<YOUR_ANDROID_SDK_DIR>/tools
export ANDROID_TOOLCHAIN=<YOUR_SOURCE_CODE_DIR>/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin
export PATH=${ANDROID_SDK_TOOLS}:${ANDROID_TOOLCHAIN}:$PATH

# java environment
JAVA_HOME=<YOUR_JAVA_SDK_DIR>
export JRE_HOME=$JAVA_HOME/jre
export CLASSPATH=.:$JAVA_HOME/lib:$JRE_HOME/lib:$CLASSPATH
export PATH=$JAVA_HOME/bin:$JRE_HOME/bin:$PATH

執行命令使環境變數生效：
source ~/.bashrc

2).編譯你的Vendor

cd <源碼目錄>
source build/envsetup.sh
lunch cm_N881F-eng
make -j4 recoveryimage

4. 如何編譯android userdata.img

1、android文件系統的結構
android源碼編譯後得到system.img,ramdisk.img,userdata.img映像文件。其中， ramdisk.img是emulator的文件系統，system.img包括了主要的包、庫等文件，userdata.img包括了一些用戶數據，emulator載入這3個映像文件後，會把 system和 userdata分別載入到 ramdisk文件系統中的system和 userdata目錄下。因此，我們可以把ramdisk.img里的所有文件復制出來，system.img和userdata.img分別解壓到 ramdisk文件系統中的system和 userdata目錄下。

2、分離android文件系統出來
system.img,ramdisk.img,userdata.img映像文件是採用cpio打包、gzip壓縮的，可以通過file命令驗證：
file ramdisk.img，輸出：
ramdisk.img: gzip compressed data, from Unix, last modified: Wed Mar 18 17:16:10 2009
Android源碼編譯後除了生成system.img，userdata.img之外還生成system和 userdata文件夾，因此不需要解壓它們。Android源碼編譯後還生成root文件夾，其實root下的文件與 ramdisk.img 里的文件是一樣的，不過這里還是介紹怎樣把 ramdisk.img解壓出來:
將ramdisk.img復制一份到任何其他目錄下，將其名稱改為ramdisk.img.gz，並使用命令
gunzip ramdisk.img.gz
然後新建一個文件夾，叫ramdisk吧，進入，輸入命令
cpio -i -F ../ramdisk.img
這下，你就能看見並操作ramdisk裡面的內容了。
然後把Android源碼編譯後生成的system和 userdata里的文件復制到 ramdisk/system和 ramdisk/userdata下。這樣就得到一個文件系統了。

3、使用網路文件系統方式掛載android文件系統
因此，我們需要建立/nfsroot目錄，再建立/nfsroot/androidfs目錄，把剛才的android文件系統改名為androidfs，並鏈接到/nfsroot/androidfs

4、android內核引導文件系統
android內核掛載/nfsroot/androidfs之後，根據init.rc,init.goldfish.rc來初始化並裝載系統庫、程序等直到開機完成。init.rc腳本包括了文件系統初始化、裝載的許多過程。init.rc的工作主要是：
1）設置一些環境變數
2）創建system、sdcard、data、cache等目錄
3）把一些文件系統mount到一些目錄去，如，mount tmpfs tmpfs /sqlite_stmt_journals
4）設置一些文件的用戶群組、許可權
5）設置一些線程參數
6）設置TCP緩存大小

5. 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,因對終端設備(慢速設備)的阻塞寫操作也會拖慢速度。推薦內存文件，這樣發生錯誤時，能夠查看。

6. 安卓可以用tmpfs么

不可以。系統不一樣，內核也不一樣，所研發的軟體使用的要求就不一樣。 1.Android 的核心系統服務依賴於 Linux 2.6 內核，如安全性，內存管理，進程管理， 網路協議棧和驅動模型。 Linux 內核也同時作為硬體和軟體棧之間的抽象層。 2.IOS 就是基於 apple 的 OSX ，OSX 分兩部分，一部分是 NEXT 圖形環境，以及地底層的 darwin 。

7. android.xml哪個命令是獲取root許可權

Android的應用程序入口肯定是java程序。應用程序的啟動者是由系統臨時根據Androidmanifest.xml中定義的許可權而創建的臨時用戶。而不像linux那樣是使用登陸者的身份啟動，從而使得進程具有登陸者的所有許可權。這也是Android的安全機制之一。

新的許可權機制也帶來新的問題，Android給應用程序的許可權是按功能來分，java雖然可以訪問文件系統。但由於應用程序本身是臨時用戶啟動，這個臨時用戶許可權十分有限。因此誕生了<越獄/root機器>這樣的產物。

其實root機器不是真正能讓你的應用程序具有root許可權。它原理就跟linux下的像sudo這樣的命令。在系統的bin目錄下放個su程序並屬主是root並有suid許可權。則通過su執行的命令都具有Android root許可權。

Su的源代碼網上也有，有興趣的同學去google下。

當然使用臨時用戶許可權想把su拷貝的/system/bin目錄並改屬性並不是一件容易的事情。這里用到2個工具跟2個命令。工具就是busybox。不熟悉的同學可以去網上google下。這個太有名了我就不多說了。

把busybox拷貝到你有許可權訪問的目錄然後給他賦予4755許可權，你就可以用它做很多事了。

當然busybox只能不能提升許可權，真正提升許可權的是ratc這個程序，這個程序中一鍵root包裡面可以找到，作用是rooting在adb的shell。

網上介紹Ratc的文章不多，它是rage against the cage 的縮寫。是真正的提升許可權的破解程序。雖然我沒看過源代碼，但估計是利用adb源代碼部分內容來實現的，原理估計跟模擬器使用adb shell登陸可以獲得root shell差不多。（因為它運行需要adb連接才會成功）。

使用busybox前先運行ratc，這樣運行busybox的UID將是0，也就是root。

首先把system目錄改成可讀性的：busybox mount -o remount,rw /system，當然你還不能改下面的文件，因為system下文件的所有者都不是你，但你可以偷梁換柱把system下的目錄給換掉。

使用命令Busybox mount -t tmpfs none /system/xbin，呵呵這下xbin目錄你隨便寫了。

將su跟busybox弄過去cp /data/data/xxx/su /system/xbin。然後賦許可權chmod 4755 /system/xbin/su。然後使目錄生效busybox --install -s /system/xbin，別忘善後busybox mount -o remount,ro /system去掉system可寫。

這樣只是臨時的，只能用su跟busybox能執行一些原來系統沒有許可權執行的命令而已。當系統重啟後/system/xbin又變為原來的文件。真正要改系統的話需要自己寫內核代碼（相當於windows的驅動程序）。內核文件擁有所有許可權。使用busybox命令insmod /data/data/xxx/xxx.ko裝載內核文件，你想幹嘛就可以幹嘛了。

當然我們不是搞破解的沒必要去改別人的機器，我們只是想讓自己應用程序具有root許可權而已。所以臨時的su就可以了。我們用c++寫一個可執行文件。使用socket可以跟java的程序通訊。然後將需要使用root許可權才能執行的代碼放在c++程序里，然後java程序中創建新的su進程，將c++程序帶全路徑作為參數1。啟動後就可以通過socket調用c++函數去執行你想乾的事了。

最後程序執行完了別忘了善後busybox umount /system/xbin。

最後說說要注意的事情，如果機器已經擁有Android root許可權的話就不需要做這些事情了，但root過的機器都有裝有個許可權管理的程序。會彈出對話框。但這個程序管理能力有限，如果不想讓他彈出的話。也許可以通過改su文件名來解決。有興趣的同學不妨試試。

8. 求一個安卓十進制轉二進制源碼

私信你了。注意查看。兩分鍾寫的demo，你查看一下：

輸入為空的情況：