Android生存指南之:解Bug策略與思路問題的詳解
2020-04-11 12:23:06
供稿：網友
現在維護和定制Android的需求越來越多，做的人也越來越多，而Google直接Release出來的源碼中又有很多Bug和不合理的地方，特別是原生的應用，如Mms，Browser, Email, Contacts等。定制或做Android解決方案第一步就是要修復原生的Bug以得到一個穩定的系統。
1. 仔細觀察Bug的特性
了解Bug所涉及的流程和模塊有哪些，以及是什么樣的Bug，Exception？功能上的？還是UI/UE設計問題。針對不同的問題，可能要采取不同的手段，對于Exception就要先分析Log文件，以確定產生Exception的原因；對于功能上的問題，可能要先嘗試復現； 對于UI/UE的問題可能有要先找UI設計師確認是否需要修改。
2. 找出決定因素，排除次要和無關因素
分析，推敲和嘗試復現以排除次要的，無關的因素和操作步驟。如果跟某些特定的數據有關，就要把數據進行拆解，以把無影響的部分去掉，直到找到引起問題的特殊數據。
3. 對比
跟正常的流程進行對比，跟沒有問題的版本進行對比，跟同一系列的產品進行對比，看有哪些異常和不一致的地方。
4. 單一變量原則
每次改動一個變化的東西，這樣你才能清楚是因為什么產生了問題或是解決了問題。如果同時的改動有二個就很難分的清是哪一個產生了作用。
5. 分而治之
通過分治的方法逐步縮小范圍，先在一個模塊分析，確定有問題或沒問題，然后再轉到其模塊，先在其中一個邏輯或文件中分析，然后再到其他的，以避免盲目的亂找。
6. 模擬場景
用特殊的數據，或者修改代碼來模擬Bug發生時的場景。這對復現非必現Bug時特別有用，對線程問題也很有用。
7. 定位問題的方法：經驗＋Log＋Debugging工具
經驗是要靠積累才能得來的，通常情況下對代碼和流程熟悉的人定位起來就快速的多； Log是指日志文件和打印這種簡單粗暴的方式；調試工具是指像Eclipse和GDB等斷點單步工具。通常用經驗和Log來進行大范圍的定位，當對流程有了一定的了解后，且已經定位到稍小的范圍，如一個函數內或一個文件內時就可以用工具進行斷點和單步調試以精確定位。當范圍很大時，如用調試工具會很慢，很難找到有效的斷點，單步的話又太煩瑣，很容易讓人混亂和丟失思路。
8. 逆向推理和洞察力
在調試解Bug過程中逆向推理力十分的重要，因為你得到的是一個結果（Bug），而要去找到它的原因，就需要推理和猜測問題可能是出在哪里。另外一個非常重要的能力就是洞察力，觀察Log，操作等，注意一些細微的差異，發現一些隱藏的線索等。當然，這與經驗不同，不是那么容易就能培養出來的！
9. 具體的方法和工具
a. 編譯
很顯然，要想用日志等方法，就要修改源碼，添加日志，就要編譯。整體編譯Android可以用make，整體編譯過一次后就可以局部編譯，進入到某個帶有Android.mk文件的目錄運行mm就可以把此目錄重新編譯成apk, jar或so
b. 運行
編譯好后，就要把新編譯出來的Apk或jar或so運行起來以看到不同。可以直接把apk,jar和so通過adb push 到手機中（apk到/system/app, jar到/system/framework, so到/system/lib)。或者用mm snod命令重新生成system.img，然后再使用（模擬器可以這樣做）。
c. 調試工具
Apk用Eclipse就可以直接調，前提要能編譯過
jar也要用Eclipse來調試
so因為都是Native C/C++代碼，所以要用GDB來調試。手機中運行gdbserver，PC上用gdb調試編譯出來的symbols/下面的庫，gdb和gdbserver用過手機中指定的端口來通信。
