還記得之前我們開發和除錯核心，面對核心錯綜複雜的**，還有無數條潛在的執行路徑，有點茫然不知所措。之前在核心加個**，一不小心就會造成核心崩潰。
現在好了，谷歌在android q版本上已經整合好了bcc工具。該工具的加入，對於android手機開發方面，無論是穩定性還是效能優化工作，都有巨大的效率提公升。
我們發現如果會巧妙地運用該工具的話，不僅僅是核心，駕馭整個作業系統的能力會比以前有大大的提公升。
bcc全稱為(bpf compiler collection)，bcc工具是一整套基於linux - ebpf介面開發的工具包。
工具主頁：
該工具的設計動機是為了媲美之前solaris系統上的dtrace工具，做到不僅僅是核心，整個作業系統層面的程式執行行為都可以進行監控跟蹤。
該工具包不僅有很多現成已做好的可以用來高效跟蹤核心，除錯應用程式的ebpf工具，而且還提供了一套基於ebpf介面的快速簡易開發環境。
該開發環境對linux系統的ebpf介面做了二次封裝，目的是讓ebpf介面對開發者友好並簡單易用。
bpf是執行在核心態的一種虛擬機器語言，bcc工具在使用者態通過一些編譯器把python，c語言寫的程式編譯成bpf目標碼，然後通重載入器loader(bcc/perf/iproute2)將bpf目標碼通過bpf()系統呼叫載入到核心當中。
然後在核心的虛擬機器裡面安全地執行前面使用者態定製的各種程式。
1: 比現有的效能除錯工具強
提供了很多現成的針對核心cpu，記憶體和儲存三大領域進行監控除錯的工具。這些工具是基於ebpf介面做的，需要指出的是，跟以前的監控工具（ps, top, vmstat等）相比，
在android效能監控，穩定性除錯領域會有質的提公升，下面會介紹的。
2: 比android平台現有的systrace強
提供了python開發介面，這樣可以在ebpf程式中使用到python強大的各種資源庫，比如字典，hash等。可以更方便直觀地對監控核心時產生的資料做各種統計處理工作，
比如計算核心某模組效能方面的平均耗時，最大最小耗時，還能繪製出耗時的直方圖，這一點systrace是沒有的。
還有不需要再費勁加trace語句了，乙個工具到手，不需要再修改並編譯**，直接登入到android系統上，隨時核心各個地方都可以監控到。
3: 比kprobe,systemtap強
該工具的工作思路跟kprobe，systemtap一樣，可以以鉤子函式的方式動態插入核心，對核心進行行為修正和跟蹤除錯。但是比這兩個工具更強悍的一點是使用時會更加安全，bcc工具會保證鉤子函式的插入不會給核心帶來崩潰，
hung或者其他負面效應。
4: 比android上的******perf強
和******perf一樣，可以用來對系統做profile跟蹤。但是perf工具的缺點是時間計算在使用者態才聚合，不如用bcc工具直接用ebpf在核心臺聚合顯得更加準確性。
另外在程式的offcputime跟蹤方面，perf工具會產生過重的overhead，這樣產生的效能資料會不準確。而bcc工具進行這方面跟蹤時，產生的overhead則比較少了。
估計bcc工具進行android系統效能跟蹤，比systrace跟蹤產生的overhead也少。
5: 之前的ftrace, tracepoint, kprobe, uprobe, systemtap和perf工具有的功能優點它都有，而且還做了有效的整合。
所以它整合了以前的這些工具的優點後，不僅可以用來做核心態的跟蹤除錯，使用者態也能派上用場。
6: 簡單易學，輕鬆可以上手
bcc工具提供了方便快捷地ebpf開發環境，甚至c語言不熟練的也可以用來做核心ebpf開發（當然了最好要慎重寫**），因為你編寫的程式會被放到沙盒裡面，不會對核心有負面影響的。
還有如果是寫**犯了記憶體越界等錯誤，在bcc模組插入核心之前，就會被自動檢測出來。另外還提供了詳細地bcc開發配套學習資料。
現有的ebpf工具都在：/tree/master/tools 裡面。
下面結合我的效能工作經歷，總結了android開發過程中，最有用的一些bcc工具。介紹如下：
argdist
可以用來在系統執行時，動態列印出kernel中任意某個函式（靜態函式除外）的入參和出參值。
funclatency
可以用來跟蹤顯示核心函式執行的耗時狀況。可以對整個系統進行trace，也可以對單個程序進行trace。並且函式耗時狀況能以直方圖的形式顯示出來。
syscount
trace
該工具是對核心kprobe介面的增強封裝。基本上可以像以前操作kprobe介面一樣，來使用這個工具，從而取代prink除錯手法，隨時隨地對進行核心感興趣的資訊進行動態跟蹤過濾輸出。
也可以完美替代linux平台傳統的strace工具，對系統呼叫進行跟蹤。
cpudist
可以繪製出系統或者某程序的oncputime和offcputime的耗時分布直方圖。
可以用來跟蹤某程序執行時的task context切換次數。比如用來跟蹤zip解壓縮執行緒時，通過輸出的task context切換次數，可以知道該執行緒是否上下文切換頻繁。切換頻繁的話，肯定會影響到zip解壓縮效能。
該工具是通過監控核心裡面函式：finish_task_switch，捕捉prev的task_struct資訊來做到有效監控的。
offcputime
可以用來進行程序的offcputime解析。通過該工具輸出的資訊，知道該程序的offcputime耗時原因，耗時最多的在核心什麼地方。
比如之前的zip解壓縮效能分析用這個工具可以很容易地知道offcputime耗時最多的地方在哪。
llcstat
這個對分析程式執行時的cpu cache miss很有幫助。
fileslower
這個工具經過簡單改造下，就可以用來解析整個系統或者單獨某程序執行時的產生的io workloader狀況。是做了順序讀寫 or 隨機讀寫，操作了哪些檔案，io傳輸的位元組數，direct io or buffer io，這些都可以看出來。
biosnoop, biolatency
可以用來跟蹤塊裝置層的io 請求排隊及儲存晶元端處理耗時狀況。
criticalstat
有時候在android系統反應非常緩慢時，可以用該工具對核心的atomic critical sections進行跟蹤，輸出系統變慢的原因是否是因為spinlock, 搶占被關閉或者處理中斷太多。
/blob/master/tools/***x_example.txt
bcc工具提供了一整套簡單易用的ebpf開發環境，讓開發者根據不同的業務場景，定製出自己的ebpf工具，關鍵是有了配套工具後，可以大大提公升工作效率。
我在做androbench跑分效能優化工作時，常常要開啟核心ftrace開關，去分析海量的ftrace log，從這些log中提取到當前androbench測試時產生的io workload狀況，從而或者去定位效能問題，或者做效能優化調研。
分析ftrace log太痛苦了。
現在有了ebpf工具，讓一切事情變得簡單起來。
因為能夠最大程度地解析出我們的業務場景產生的io workload狀況，對於解決儲存問題，是很有幫助的。現在不需要看ftrace了，直接用我做的ioworkload_analysis和biosnoop工具，
可以很方便地看出來某程序在vfs層， 塊裝置層和儲存bsp層產生的io workload狀況。詳細我的另外一篇文件總結：
手機io workload解析
這樣可以很方便地知道儲存效能耗時是在檔案系統層，塊裝置層，還是bsp層。
eBPF監控工具bcc系列五工具funccount
funccount函式可以通過匹配來跟蹤函式,tracepoints 或usdt探針。例如所有以vfs 開頭的核心函式。funccount vfs 這個對於探索核心 很有幫助，可以找出哪個函式在使用那個函式沒在使用。也可以設定間隔，每秒列印一次 funccount i 1 vfs 跟蹤所有tcp函式...
eBPF監控工具bcc系列五工具funccount
funccount函式可以通過匹配來跟蹤函式,tracepoints 或usdt探針。例如所有以vfs 開頭的核心函式。funccount vfs 這個對於探索核心 很有幫助，可以找出哪個函式在使用那個函式沒在使用。也可以設定間隔，每秒列印一次 funccount i 1 vfs 跟蹤所有tcp函式...
Eclipse開發Android程式在手機上執行
android開發在真機上除錯 執行過程如下 1 安裝usb驅動 手機要能與電腦相連，當然要安驅動了。效果就是你插入手機，電腦顯示驅動已識別。2 設定android手機為usb除錯模式 步驟 menu 設定 應用程式 開發 選擇 usb除錯 手機選擇可以開發，usb除錯 3 通過eclipse上真機...