這篇做為穩定性分析的開篇，但我不知道下篇什麼時候寫。因為前幾天突然想到這些就記錄下來。我覺得這裡記錄的會比具體的分析方法更有用，分析方法總能在網上找到的。
什麼是穩定性問題
分析android問題時，經常會遇到一些穩定性問題。什麼是穩定性問題呢，我歸結有以下特點，
非必現問題，或沒有找到復現路徑的問題。其實沒有非必現問題，只有找不到復現方法。系統越複雜這類問題越多，因為軟體路徑太多了。
應用的宕機重啟。這類問題不能簡單的歸結為應用問題，畢竟應用是跑在系統上的。當應用開發人員無法分析出問題時，可能就會認為是穩定性問題。
系統宕機重啟。android開發還是偏重應用的，這樣導致系統開發人員較少。很多時候碰到這類問題就找不到分析方法，也就歸到穩定性上。起始這類問題與linux系統上的分析方法並沒有太大卻別，只不過深入底層的人越來越少了。
原生**的問題。android原生**也是有bug的，因為這部分**沒人動，也就很少有人研究。最後又歸到穩定性上。
效能問題。有時效能問題也會歸到穩定性上，例如正常情況下某應用啟動很快，在某種情況下啟動很慢，這很可能就是效能導致的。我認為效能問題和穩定性問題不能混為一談，二者的分析方法有很大差別。
沒人願意深入研究的問題。各模組都不承認是自己的問題，相互扯皮。因為沒有人從系統角度上來分析問題，也不進行深入研究，覺得還是歸到穩定性好些。
簡單來說就是其他模組解決不了的或不願意解決的就是穩定性問題。有真正的穩定性問題嗎？我覺得嚴格來說時沒有的，問題最終的根本原因總會落在乙個模組上，也就是有主的。但是，android系統真的是乙個非常複雜的系統，不能要求每個開發人員都能了解整個系統。所以這類複雜的系統性問題還是交給一些資深的開發人員解決更好些。這也就對分析穩定性問題的人員要求較高，需要對系統有整體的概念，並且對許多模組有深入研究。我認為將穩定性問題改為系統問題會更加準確，解決穩定性問題的開發人員也應該是系統工程師。
曾有人問過是否有簡單的方法來分析穩定性問題，我必須說沒有。android系統還沒有優秀到完全避免各模組關聯的干擾，其他系統我也沒見過。在debug方面，android系統已經做得很優秀了。但在分析穩定性問題時，這些debug手段也僅能分析一部分問題，而且還不是很容易的找到根本原因。我理解很多人對於穩定性問題的急迫心情，因為這類問題通常後果很嚴重。但這類問題真不是急就能解決的，對待這類問題沒有捷徑，就需要一點點認真去分析。穩定性問題就像是醫學上的疑難雜症和罕見病例，你不能期望它想發燒感冒一樣通過乙個化驗就確定**。解決這種病需要很長的時間，做各種化驗，必須找專家來看，可能還需要會診。如果乙個初級醫師來看這種病，很可能會因為誤診導致更嚴重的後果，解決穩定性問題也一樣。
成為一名android系統工程師
我建議分析穩定性問題最好由資深工程師或系統工程師來進行，成為乙個合格的android系統工程師需要掌握以下知識點，
linux kernel基本的工作機制，如程序排程，程序空間，記憶體管理，檔案系統等等。
linux應用開發，如系統呼叫，ipc通訊，多執行緒開發，常用的庫等等。
linux kernel常用的除錯手段，如crash，ftrace，kmemleak，kprobe，kgdb，trace32，perf，procfs，sysfs，debugfs等等
linux應用常用的除錯手段，如gdb，strace，ltrace，valgrind，gprof，mtrace，iperf，blktrace，fio等等。
輔助系統的工作原理，如bootloader，recovery，dtb，busybox等等。
android框架和基本原理。
android framework中主要模組的工作機制，包括activity，window，package，input，storage，audio，media，su***ce等等。
android ipc通訊（binder）的原理和實現。
android中日誌收集手段的原理，包括logcat，anr，tombstones，watchdog，gc等等。
android中常用的除錯手段，如bionic的記憶體檢測，lmk機制，asan，systrace，oatdump，dumpsys，dumpstate等等。
android studio中常用的除錯工具，如profiler，systrace，traceview，heap viewer，allocation tracker，memory monitor，layout inspector，mat等等。
了解編譯相關的工具，如llvm，makefiel，android make，soong，gradle，工具鏈，映象製作，ota打包等等。
上面這麼多，我感覺還沒有好多沒提到，目前只能想到這些。不需要全部精通，那是神人要做的。凡人要做到都有基本的了解，精通其中幾個模組，否則給人一知半解的感覺，但做到這樣也是不容易。掌握了上述的知識（這個要求有點高），就可以成為一名android系統工程師了。但這離優秀的系統工程師還差很遠，要想成為優秀必須有以下的品質。
三心：細心，耐心，恆心。複雜問題可能需要很長時間才能解決，要耐得住寂寞，並且不放過任何乙個線索。
敢於挑戰困難。複雜的問題一定經過了許多人的分析還沒有結論，害怕了就一步也邁不出去。
快速的學習能力。穩定性問題遍布整個系統，可能經常會分析到陌生的模組，學習能力差就會影響問題解決。要不有一張快速的嘴到處問問，也不失為一種方法。
較強的邏輯思維。很多問題都是繞來繞去，很容易暈菜。
不走尋常路。遇到困難時，跳出來，換一種方法也許就解決了。
運氣。這東西在**都很重要，有些問題就是碰出解決方案的，實際上並不不是完全的運氣，但運氣真的很重要。
寫完這些，我想很少人想成為android系統工程師了，我也想找乙個三板斧就能混個高薪水的工作。
穩定性問題分析方法
穩定性問題千奇百怪，而且大部分都很難定位。我這裡試圖去總結一下各類問題的分析流程，這些不是標準，只是我的經驗。先根據問題的表現分下類，
有穩定復現路徑的問題。
偶現問題，且debug資訊足夠。
偶現問題，且debug資訊不足。
不能復現的問題。
關於debug資訊，一部分是標準android帶有的logcat輸出，anr日誌，tombstone日誌，watchdog日誌等。另一部分是系統開發商附加的。好的系統開發商能提供豐富的debug資訊，在問題發生時一同抓取上報。這些資訊可能包括kernel log，dumpsys中的部分資訊，binder資訊，詳細的cpu記憶體資訊，io資訊，排程資訊，corefile，vmcore等等。廠商的不同，這些資訊也會不同。下面根據問題的不同分別講述一下。
有穩定復現路徑的問題：
如果乙個問題能有穩定的復現路徑，解決問題就變得容易很多。
這類問題不論debug資訊的多少，都能找根本原因。因為能復現，就可以不斷的增加debug資訊。
嚴格來說這類問題不能稱為穩定性問題，但依然佔據穩定性問題的多數。
偶現問題，且debug資訊足夠：
僅使用android標準的debug資訊就可以定位問題時，都比較容易解決，也不會太複雜。對系統有很好的理解，並且會分析棧資訊可能就夠用了。但可能需要分析原始碼來確定根本原因。
需要借助廠商附加的debug資訊定位問題時，問題會相對複雜。
面對複雜問題時，可能需要仔細分析不同的debug資訊，在它們之間找到關聯。盡可能的搜尋相關線索，這樣才能找到根本原因。
有時可能能根據debug資訊定位到**段，但真正的根本原因還需要分析**邏輯才能確定。不要輕易下手修改**，尤其是原生**。
定位到原生**出問題時，先在網上找一下是否有人給出patch，相信你不可能是第乙個碰到這種問題的人。
編寫測試**來驗證你的解決方案。
偶現問題，且debug資訊不足：
debug資訊不夠用時就麻煩了，這也是我認為最難解決的問題。
試圖尋找復現路徑，讓問題變為有穩定復現路徑的問題。
在懷疑點增加debug資訊，等待下一次復現。
根據懷疑點分析**邏輯，試圖使用測試**來復現該問題。
根據core檔案中的記憶體映象來獲取更多的有用資訊。
仔細分析現有的debug資訊，往往一小句話就有很大的驚喜。
注意cpu，memory，io的狀態對系統的影響。
懷疑記憶體問題時可以使用記憶體檢測工具來檢查一遍當前系統隱含的記憶體問題。
有時**檢查工具也能規避很多問題，提交前沒有檢查的最好檢查一下。
問題很可能不是第一現場，先解決系統之前的錯誤，後面的錯誤可能就跟隨解決。
同樣的，在網上搜尋是否有類似問題的解決方案。
總體來說，這類問題就是嘗試各種方法來解決目前無法解決的問題。
不能復現的問題：
此類問題既然無法復現，也就不重要了。
如果可以根據debug資訊解決固然很好，不能解決時可以先降低優先順序。
等待該問題變成偶先問題時，就可以根據上述方法分析了。
問題的解決方法說起來很簡單，實際解決時要困難的多，只能祝好運。
Android內建系統apk問題
平台 rockchip android版本 7.1 個人部落格 檢視logcat 下面是關鍵log 03 12 10 48 50.247 1381 1381 e androidruntime process com.android.settings,pid 1381setting apk找不到32位...
android 常用系統資訊獲取總結
最近在幫客戶做技術實施方案，需要獲取系統這塊的內容，今天專程用了兩個小時從網上蒐集的資料做了個總結 所有的裝置都可以返回乙個telephonymanager.getdeviceid 如果是gsm網路，返回imei 如果是cdma網路，返回meid 手機的唯一標識，像gsm手機的 imei 和 cdm...
android系統開機流程歸納總結
一，首先我們要正確的抓取ylog日誌 對ylog ap current 時間節點 android資料夾下的python檔案進行解壓。得到0000日誌。二，然後我們可通過下面日誌中的關鍵字來過濾出關鍵日誌 event log recorded boot progress start 616 20433...