android列印呼叫棧的方法
文章1：
列印呼叫棧是android平臺問題定位的基本方法，如果需要知道誰在呼叫某個函式，可以在此函式中新增列印呼叫棧函式，弄清楚函式之間的呼叫關係。
1. Java層列印呼叫棧方法
RuntimeException here = new RuntimeException("here");
here.fillInStackTrace();
Log.w(TAG, "Called: " + this, here);
2. C++層列印呼叫棧方法
CallStack stack;
stack.update();
stack.dump();
備註：下面操作是可選操作，但加上去之後會有一些額外的功能
#define HAVE_DLADDR 1 ：可以從lib中自己轉成c++程式碼行，不需要手動反編譯
#define HAVE_CXXABI 1：將c++ 已被name mangling的函式名轉化為原始檔中定義的函式名。
並在檔案frameworks/base/libs/utils/Android.mk中大約105行（LOCAL_SHARED_LIBRARIES）後新增
ifeq ($(TARGET_OS),linux)
LOCAL_SHARED_LIBRARIES += libdl
endif重新編譯push生成的libutils.so到/system/lib/目錄下，重啟裝置。
此外，由於CallStack.dump中使用的LOGD進行的列印，因此需要將後臺的Log Level設定為D一下才能出來。
3. C函式列印呼叫棧
可以參考CallStack.cpp的實現，通過呼叫_Unwind_Backtrace完成。
4. Kernel層列印呼叫棧方法
dump_stack();函式
文章2：
寫程式的話，只要有思路，實現起來不會太難，而我們經常要做的是讀別人的程式，自己寫的程式如果沒有好的註釋的話，過一段時間以後，尚且不知道當時為什麼這麼寫，何況是別人寫的呢？在讀別人程式的時候，弄清楚程式的流程是很重要的，輸出程式的堆疊資訊，對弄清楚程式整個流程是非常有幫助的。
在java中，通過丟擲異常，比如在Android的 ActivityManagerService.java中的startActivity
06-15 17:33:55.899 W/System.err( 252): java.lang.Exception: print trace
06-15 17:33:55.899 W/System.err( 252): at com.android.server.am.ActivityManagerService.startActivity(ActivityManagerService.java:2493)
06-15 17:33:55.899 W/System.err( 252): at android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:131)
06-15 17:33:55.899 W/System.err( 252): at com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:1750)
06-15 17:33:55.899 W/System.err( 252): at android.os.Binder.execTransact(Binder.java:338)
06-15 17:33:55.899 W/System.err( 252): at dalvik.system.NativeStart.run(Native Method)把怎個呼叫流程弄清楚了，以前一直在想，為什麼別人可以再分析的時候，能夠知道程式跑哪去了，我想這在除錯java程式不失為一種好的方式。
對於C/C++的程式碼，可以通過在函式中新增如下程式碼：
#ifdef _ARM_
LOGW("print stack");
android::CallStack stack;
stack.update(1, 100);
stack.dump("");
#endif便可以得到堆疊資訊了。比如在InputReader.cpp中的dispatchTouches開始處新增如下程式碼，可以再LOG看到：
06-15 17:33:16.882 D/InputReader( 252): dump stack
06-15 17:33:16.882 D/CallStack( 252): #00 0x0x4c9557ea: <_ZN7android16TouchInputMapper15dispatchTouche***j>+0x0x4c955791
06-15 17:33:16.882 D/CallStack( 252): #01 0x0x4c95615c: <_ZN7android16TouchInputMapper4syncEx>+0x0x4c955ea5
06-15 17:33:16.882 D/CallStack( 252): #02 0x0x4c956214: <_ZN7android16TouchInputMapper7processEPKNS_8RawEventE>+0x0x4c9561e1
06-15 17:33:16.882 D/CallStack( 252): #03 0x0x4c956226: <_ZN7android21MultiTouchInputMapper7processEPKNS_8RawEventE>+0x0x4c956219
06-15 17:33:16.882 D/CallStack( 252): #04 0x0x4c958758: <_ZN7android11InputDevice7processEPKNS_8RawEventEj>+0x0x4c9586f1
06-15 17:33:16.882 D/CallStack( 252): #05 0x0x4c9587c0: <_ZN7android11InputReader28processEventsForDeviceLockedEiPKNS_8RawEventEj>+0x0x4c958779
06-15 17:33:16.882 D/CallStack( 252): #06 0x0x4c9593ec: <_ZN7android11InputReader19processEventsLockedEPKNS_8RawEventEj>+0x0x4c9593b1
06-15 17:33:16.882 D/CallStack( 252): #07 0x0x4c9595bc: <_ZN7android11InputReader8loopOnceEv>+0x0x4c959541
06-15 17:33:16.882 D/CallStack( 252): #08 0x0x4c94fd0a: <_ZN7android17InputReaderThread10threadLoopEv>+0x0x4c94fd01
06-15 17:33:16.883 D/CallStack( 252): #09 0x0x40151714: <_ZN7android6Thread11_threadLoopEPv>+0x0x401516a1
06-15 17:33:16.883 D/CallStack( 252): #10 0x0x401d2de2: <_ZN7android14AndroidRuntime15javaThreadShellEPv>+0x0x401d2d9d
06-15 17:33:16.883 D/CallStack( 252): #11 pc 00023d5a /system/lib/libutils.so
06-15 17:33:16.883 D/CallStack( 252): #12 0x0x400ee118: <__thread_entry>+0x0x400ee0e4
06-15 17:33:16.883 D/CallStack( 252): #13 0x0x400edc68: <pthread_create>+0x0x400edbb0我想如果瞭解過Android的JNI，我想打出上面的結果也就可想而知了。
對於核心的堆疊，只要呼叫dump_stack()，就能打出堆疊資訊了。
在Android中，如果瞭解Android的JNI，明白Linux的系統呼叫，知道java層怎麼到C/C++層，知道系統呼叫，那麼整個系統的呼叫流程也就明白了？想的太天真了，整個Android這麼大，就被這樣征服了，也太沒意思了，還折騰什麼？路還遠著，從Android的C/S架構來說，這只是明白了C跟S但方面的，真正複雜的，並不在這，而在相互之間的通訊，如果binder也弄明白了的話，那應該很容易把整個Android系統貫穿起來，may be，mey not？誰知道，反正我還沒有。