++wythern++

1. • adb shell setprop libc.debug.malloc 1
   • adb shell ps mediaserver
   • adb shell kill <mediaserver_pid>
2. Call dumpMemoryAddresses(). (in MemoryLeakTrackUtil.cpp).
   
3. $ adb pull /proc/<mediaserver_pid>/maps
   
4. get the diff file of memory allocations
   
   • $ adb pull /data/000 .
   • $ adb pull /data/111 .
   • $ diff 000 111 >diff_0_1
     
5. $ ./addr2func.py --root-dir=../ --maps-file=./maps diff_0_1

MediaScanner用法總結

轉自這里以及這里

-   掃描全部

Java代碼  

1. public void systemScan(){  
2.         sendBroadcast(new Intent(Intent.ACTION_MEDIA_MOUNTED, Uri.parse("file://"  
3.                 + Environment.getExternalStorageDirectory())));  
4.     }  

-  掃描某個文件  參數：填入該文件的路徑

Java代碼  

1. public void fileScan(String file){  
2.         Uri data = Uri.parse("file://"+file);  
3.           
4.         sendBroadcast(new Intent(Intent.ACTION_MEDIA_SCANNER_SCAN_FILE, data));  
5.     }  

- 掃描文件夾 參數：填入該文件夾路徑

Java代碼  

1. public void fileScan(String file){  
2.         Uri data = Uri.parse("file://"+file);  
3.           
4.         sendBroadcast(new Intent(Intent.ACTION_MEDIA_SCANNER_SCAN_FILE, data));  
5.     }  
6.       
7.     public void folderScan(String path){  
8.         File file = new File(path);  
9.           
10.         if(file.isDirectory()){  
11.             File[] array = file.listFiles();  
12.               
13.             for(int i=0;i<array.length;i++){  
14.                 File f = array[i];  
15.                   
16.                 if(f.isFile()){//FILE TYPE  
17.                     String name = f.getName();  
18.                       
19.                     if(name.contains(".mp3")){  
20.                         fileScan(f.getAbsolutePath());  
21.                     }  
22.                 }  
23.                 else {//FOLDER TYPE  
24.                     folderScan(f.getAbsolutePath());  
25.                 }  
26.             }  
27.         }  
28.     }  

Android 調試技術

一、JAVA層單步調試

參見“用eclipse單步調試Laucher”
參見“用eclipse編譯調試adnroid的Browser”

二、Native層單步調試

參見“使用GDB 單步調試Android本地代碼”

三、JAVA層堆棧打印

1. 在指定的函數內打印相關java調用

Log.d(TAG,Log.getStackTraceString(new Throwable()));

2. 普通JAVA進程堆棧

ActivityManagerService.dumpStackTraces

保存在系統設置dalvik.vm.stack-trace-file指定的文件data/anr/traces.txt中。可以包含多個進程堆棧信息。

3. 內核進程堆棧

dumpKernelStackTraces，該函數為私有函數，不可調用。
代碼在frameworks/base/services/java/com/android/server/Watchdog.java
保存在系統設置dalvik.vm.stack-trace-file指定的文件data/anr/traces.txt中。

4. 出異常時打印當前堆棧

Exception::printStackTrace()

try {  ... } catch (RemoteException e) {   e.printStackTrace();   ... }

5. 輸出指定進程的堆棧

Process.sendSignal(pid, Process.SIGNAL_QUIT)

保存在data/anr/traces.txt。
這個只對java進程有效，由dalvikvm的SignalCatcher.c處理。

四、Native層堆棧打印

1. CallStack

使用方式:

#include <utils/CallStack.h> ... CallStack stack; stack.update(); stack.dump("");  // the parameter is prefix of dump

在使用之前需要修改system/core/include/arch/linux-arm/AndroidConfig.h

#define HAVE_DLADDR 1 #define HAVE_CXXABI 1

并在文件frameworks/base/libs/utils/Android.mk中大約105行（LOCAL_SHARED_LIBRARIES）后添加

ifeq ($(TARGET_OS),linux) LOCAL_SHARED_LIBRARIES += libdl endif

重新編譯，push生成的libutils.so到/system/lib/目錄下，重啟設備。

五、JAVA異常分析

這個android會輸出信息到logcat。容易分析。

六、Natvie異常分析

native進程異常會導致
debuggerd會輸出信息到logcat并保存到/data/tombstones。
可以修改system/core/debuggerd/debuggerd.c中dump_stack_and_code的代碼滿足更深的調試信息需求。

七、日志Log系統

在java中使用

import android.util.Log; ... Log.d(TAG,"log info");

在Native代碼中使用

#define LOG_TAG "YOUR_LOGTAG" ... #include <utils/Log.h> #define LOG_NDEBUG 0 ... LOGD("log info");

或者

Log.d(LOG_TAG,“log info”);

使用adb logcat時可以只顯示特定類別的LOG，還可以通過參數 -v threadtime 顯示線程號及時間信息。
普通標準輸出轉為Logcat

#system/bin/logwrapper 進程名

八、其他調試手段（命令行）

1. 打印指定JAVA進程的堆棧到文件中

#kill -3 pid

這里的3就是3.5節的Process.SIGNAL_QUIT。
輸出在data/anr/traces.txt文件中。
這個只對java進程有效，由dalvikvm處理。

2. 打印指定進程的堆棧到Logcat

#kill -11 pid 或者 #kill -7 pid

這個有時有效。其原理是利用了（六）節的機制。
可以用adb logcat看堆棧調用輸出。

3. 打印指定進程的系統調用

#strace -f -p pid -o output

主要輸出文件、SOCKET、鎖等系統操作的信息。
-f表示跟蹤所有子進程.
-o輸出log到指定文件，可不用。

Surface的創建過程

我們先看看Android如何創建一個Surface，下面的序列圖展示了整個創建過程。

                                                              圖一   Surface的創建過程

創建Surface的過程基本上分為兩步：

1. 建立SurfaceSession

第一步通常只執行一次，目的是創建一個SurfaceComposerClient的實例，JAVA層通過JNI調用本地代碼，本地代碼創建一個 SurfaceComposerClient的實例，SurfaceComposerClient通過ISurfaceComposer接口調用 SurfaceFlinger的createConnection，SurfaceFlinger返回一個ISurfaceFlingerClient接 口給SurfaceComposerClient，在createConnection的過程中，SurfaceFlinger創建了用于管理緩沖區切換 的SharedClient，關于SharedClient我們下面再介紹，最后，本地層把SurfaceComposerClient的實例返回給 JAVA層，完成SurfaceSession的建立。

2. 利用SurfaceSession創建Surface

JAVA層通過JNI調用本地代碼Surface_Init()，本地代碼首先取得第一步創建的SurfaceComposerClient實例， 通過SurfaceComposerClient，調用ISurfaceFlingerClient接口的createSurface方法，進入 SurfaceFlinger，SurfaceFlinger根據參數，創建不同類型的Layer，然后調用Layer的setBuffers()方法， 為該Layer創建了兩個緩沖區，然后返回該Layer的ISurface接口，SurfaceComposerClient使用這個ISurface接 口創建一個SurfaceControl實例，并把這個SurfaceControl返回給JAVA層。

由此得到以下結果：

• JAVA層的Surface實際上對應于本地層的SurfaceControl對象，以后本地代碼可以使用JAVA傳入的SurfaceControl對象，通過SurfaceControl的getSurface方法，獲得本地Surface對象；
• Android為每個Surface分配了兩個圖形緩沖區，以便實現Page-Flip的動作；
• 建立SurfaceSession時，SurfaceFlinger創建了用于管理兩個圖形緩沖區切換的SharedClient對 象，SurfaceComposerClient可以通過ISurfaceFlingerClient接口的getControlBlock()方法獲得 這個SharedClient對象，查看SurfaceComposerClient的成員函數_init:

獲得Surface對應的顯示緩沖區

雖然在SurfaceFlinger在創建Layer時已經為每個Layer申請了兩個緩沖區，但是此時在JAVA層并看不到這兩個緩沖 區，JAVA層要想在Surface上進行畫圖操作，必須要先把其中的一個緩沖區綁定到Canvas中，然后所有對該Canvas的畫圖操作最后都會畫到 該緩沖區內。下圖展現了綁定緩沖區的過程：

                                                                            圖二  綁定緩沖區的過程

    開始在Surface畫圖前，Surface.java會先調用lockCanvas()來得到要進行畫圖操作的Canvas，lockCanvas會進 一步調用本地層的Surface_lockCanvas，本地代碼利用JAVA層傳入的SurfaceControl對象，通過getSurface() 取得本地層的Surface對象，接著調用該Surface對象的lock()方法，lock()返回了改Surface的信息，其中包括了可用緩沖區的 首地址vaddr，該vaddr在Android的2D圖形庫Skia中，創建了一個bitmap，然后通過Skia庫中Canvas的 API：Canvas.setBitmapDevice(bitmap)，把該bitmap綁定到Canvas中，最后把這個Canvas返回給JAVA 層，這樣JAVA層就可以在該Canvas上進行畫圖操作，而這些畫圖操作最終都會畫在以vaddr為首地址的緩沖區中。

    再看看在Surface的lock()方法中做了什么：

• dequeueBuffer(&backBuffer)獲取backBuffer
  • SharedBufferClient->dequeue()獲得當前空閑緩沖區的編號
  • 通過緩沖區編號獲得真正的GraphicBuffer:backBuffer
  • 如果還沒有對Layer中的buffer進行映射（Mapper），getBufferLocked通過ISurface接口重新重新映射
• 獲取frontBuffer
• 根據兩個Buffer的更新區域，把frontBuffer的內容拷貝到backBuffer中，這樣保證了兩個Buffer中顯示內容的同步
• backBuffer->lock() 獲得backBuffer緩沖區的首地址vaddr
• 通過info參數返回vaddr

釋放Surface對應的顯示緩沖區

畫圖完成后，要想把Surface的內容顯示到屏幕上，需要把Canvas中綁定的緩沖區釋放，并且把該緩沖區從變成可投遞（因為默認只有兩個 buffer，所以實際上就是變成了frontBuffer），SurfaceFlinger的工作線程會在適當的刷新時刻，把系統中所有的 frontBuffer混合在一起，然后通過OpenGL刷新到屏幕上。下圖展現了解除綁定緩沖區的過程：

                                                                 圖三  解除綁定緩沖區的過程

• JAVA層調用unlockCanvasAndPost
• 進入本地代碼：Surface_unlockCanvasAndPost
• 本地代碼利用JAVA層傳入的SurfaceControl對象，通過getSurface()取得本地層的Surface對象
• 綁定一個空的bitmap到Canvas中
• 調用Surface的unlockAndPost方法
  • 調用GraphicBuffer的unlock()，解鎖緩沖區
  • 在queueBuffer()調用了SharedBufferClient的queue()，把該緩沖區更新為可投遞狀態

SharedClient 和 SharedBufferStack

從前面的討論可以看到，Canvas綁定緩沖區時，要通過SharedBufferClient的dequeue方法取得空閑的緩沖區，而解除綁定 并提交緩沖區投遞時，最后也要調用SharedBufferClient的queue方法通知SurfaceFlinger的工作線程。實際上，在 SurfaceFlinger里，每個Layer也會關聯一個SharedBufferServer，SurfaceFlinger的工作線程通過 SharedBufferServer管理著Layer的緩沖區，在SurfaceComposerClient建立連接的階 段，SurfaceFlinger就已經為該連接創建了一個SharedClient 對象，SharedClient 對象中包含了一個SharedBufferStack數組，數組的大小是31，每當創建一個Surface，就會占用數組中的一個 SharedBufferStack，然后SurfaceComposerClient端的Surface會創建一個 SharedBufferClient和該SharedBufferStack關聯，而SurfaceFlinger端的Layer也會創建 SharedBufferServer和SharedBufferStack關聯，實際上每對 SharedBufferClient/SharedBufferServer是控制著同一個SharedBufferStack對象，通過 SharedBufferStack，保證了負責對Surface的畫圖操作的應用端和負責刷新屏幕的服務端（SurfaceFlinger）可以使用不 同的緩沖區，并且讓他們之間知道對方何時鎖定/釋放緩沖區。

SharedClient和SharedBufferStack的代碼和頭文件分別位于：

/frameworks/base/libs/surfaceflinger_client/SharedBufferStack.cpp

/frameworks/base/include/private/surfaceflinger/SharedBufferStack.h

                                                                       圖四    客戶端和服務端緩沖區管理

     繼續研究SharedClient、SharedBufferStack、SharedBufferClient、SharedBufferServer的誕生過程。

    1. SharedClient

•     在createConnection階段，SurfaceFlinger創建Client對象：

• 再進入Client的構造函數中，它分配了4K大小的共享內存，并在這塊內存上構建了SharedClient對象：

• 回到createConnection中，通過Client的getControlBlockMemory()方法獲得共享內存塊的 IMemoryHeap接口，接著創建ISurfaceFlingerClient的子類BClient，BClient的成員變量mCblk保存了 IMemoryHeap接口指針；
• 把BClient返回給SurfaceComposerClient，SurfaceComposerClient通過 ISurfaceFlingerClient接口的getControlBlock()方法獲得IMemoryHeap接口指針，同時保存在 SurfaceComposerClient的成員變量mControlMemory中；
• 繼續通過IMemoryHeap接口的getBase ()方法獲取共享內存的首地址，轉換為SharedClient指針后保存在SurfaceComposerClient的成員變量mControl中；
• 至此，SurfaceComposerClient的成員變量mControl和SurfaceFlinger::Client.ctrlblk指向了同一個內存塊，該內存塊上就是SharedClient對象。 

    2. SharedBufferStack、SharedBufferServer、SharedBufferClient

    SharedClient對象中有一個SharedBufferStack數組：

    SharedBufferStack surfaces[ NUM_LAYERS_MAX ];

    NUM_LAYERS_MAX 被定義為31，這樣保證了SharedClient對象的大小正好滿足4KB的要求。創建一個新的Surface時，進入SurfaceFlinger的 createSurface函數后，先取在createConnection階段創建的Client對象，通過Client在 0--NUM_LAYERS_MAX 之間取得一個尚未被使用的編號，這個編號實際上就是SharedBufferStack數組的索引：

 然后以Client對象和索引值以及其他參數，創建不同類型的Layer對象，一普通的Layer對象為例：

在createNormalSurfaceLocked中創建Layer對象：

構造Layer時會先構造的父類LayerBaseClient，LayerBaseClient中創建了SharedBufferServer對 象，SharedBufferStack 數組的索引值和SharedClient被傳入SharedBufferServer對象中。

    自此，Layer通過lcblk成員變量(SharedBufferServer)和SharedClient共享內存區建立了關聯，并且每個Layer對應于SharedBufferStack 數組中的一項。

    回到SurfaceFlinger的客戶端Surface.cpp中，Surface的構造函數如下：

SharedBufferClient構造參數mClient->mControl就是共享內存塊中的SharedClient對象，mToken就是SharedBufferStack 數組索引值。

到這里我們終于知道，Surface中的mSharedBufferClient成 員和Layer中的lcblk成員(SharedBufferServer)，通過SharedClient中的同一個 SharedBufferStack，共同管理著Surface（Layer）中的兩個緩沖區。

一并參考：

$ git commit --amend

［Source] 
http://zh-cn.w3support.net/index.php?db=so&id=613022

1. M-x replace-string ; \n   
   will replace ";" with 2 characters "\n".

2. M-x replace-regex ; \n 
   get a error msg: Invalid use of `\' in replacement text. 
   in this mode use C-q C-j to insert a RET into the string you current edited for replace/replaced.

The author also said that you could paste a RET into the string for instead the method above, but i have not tested that.