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