最近有客戶反饋，使用平臺的SDK，進行掃碼時，使用幾個小時後，內存就變佔滿了，然後呢，系統就重啓了。
於是，給客戶腳本，ps之類拷機，定位，發現是system_server出現內存泄漏。這個大傢伙，有java,有native.
通過的抓取2分鐘時間內dumpsys meminfo差異 ：
主要在Native Heap增加。
好吧，確認是Native Heap出現內存泄漏無疑。
Native Heap的泄漏，主要還是通過開啓 libc debug 來分析。
1.設置屬性：
setprop libc.debug.malloc 1
setprop libc.debug.malloc.options backtrace
stop;start
注意不是重啓，不然這些屬性就失效了。另外，開啓這個屬性後，系統的運行速度會嚴重變慢。所以不同的測試場景，需要考慮系統負載。
2.抓取操作前後dumpheap 差異：
ps 獲取下system_server的進程號，比如 520
am dumpheap -n 520 /sdcard/0.txt
am dumpheap -n 520 /sdcard/1.txt
可以多個。
3.解析上述dumpheap:
放在android工程根目錄執行：
python native_heapdump_viewer.py 0.txt > 00.txt
python native_heapdump_viewer.py 1.txt > 11.txt
注意native_heapdump_viewer.py 可用相關參數。我這邊沒有使用。
4.然後對比00.txt,11.txt,重點關注排前面的數據:
這邊列出的，是按調用流程，從上到下。比如下面的代碼，可以方便在工程中找到。
88432 25.39% 100.00% 20808 e8c29312 /system/lib/libc.so __pthread_start(void*) /proc/self/cwd/bionic/libc/bionic/pthread_create.cpp:198 (discriminator 1)
4436088 23.52% 92.64% 17960 e71c5f28 /system/lib/libandroid_runtime.so android::AndroidRuntime::javaThreadShell(void*) frameworks/base/core/jni/AndroidRuntime.cpp:1174
3736560 19.81% 84.23% 15327 e8cc53a2 /system/lib/libutils.so android::Thread::_threadLoop(void*) /proc/self/cwd/system/core/libutils/Threads.cpp:754
2922464 15.50% 78.21% 15159 e89a880c /system/lib/libinputflinger.so android::InputReaderThread::threadLoop() /proc/self/cwd/frameworks/native/services/inputflinger/InputReader.cpp:949 (discriminator 1)
2912784 15.45% 99.67% 15029 e89a6d38 /system/lib/libinputflinger.so android::InputReader::loopOnce() /proc/self/cwd/frameworks/native/services/inputflinger/InputReader.cpp:314
這樣，一行行跟進去，終於發現在
InputReader.cpp:2277 ，每進來一個操作事件，被修改的代碼，就new一個字符數組來獲取某個屬性，但並沒有釋放，醉了。
知道原因後，就改了這個屬性的獲取方式。然後測試，OK。