案件還原：

        修改Android 4.0原始碼中的Setting，新增一項功能之後，在eng模式下編譯，一切正常，遂提交程式碼到伺服器。第二天，傳來噩耗，Setting上新新增的功能無法使用，一點選則報錯。

案件分析：

        上傳程式碼之前，已經在本地編譯測試過，咋會有錯呢？？！！管它三七二十一，操起adb logcat抓取log進行分析。不看不知道，一看嚇一跳，log中顯示的錯誤資訊竟然是ClassNotFound，也就是找不到相應的類，難道我上傳的時候遺漏了嗎(有這種可能)？馬上檢視提交記錄，逐個檢查提交的檔案，全部提交了啊！咋會出現ClassNotFound呢？這時候咋辦呢？冷靜下來分析後可以知道，本地測試一般是在eng模式下編譯的，而這次報錯的是伺服器在usr模式下編譯處出來的。難道eng編譯和usr編譯出來的結果不一致？？！！

案件進一步分析：

        在本地選擇usr編譯模式，編譯程式碼進行測試，果然出現了與伺服器一樣的錯誤，即ClassNotFound。

        1.既然eng模式編譯的程式碼能夠正常執行，證明程式碼邏輯以及功能都是OK的。

        2.usr編譯出來出現ClassNotFound的問題，證明usr和eng編譯模式不同導致編譯結果差異。

        3.比較eng模式和usr模式編譯出來的Settings.apk，發現大小竟然不一致，用apktool反解後對比發現，usr模式下編譯的Settings.apk中的確少了一個類(後文用lostClass.java代替)。

案件調查：

假設一：

        難道是編譯過程中沒有將lostClass.java編譯進去？

驗證一：

        檢視編譯過程中是否有對lostClass.java進行編譯。

1.第一種檢視方法。

        開啟原始碼中Settings資料夾下的Android.mk檔案我們可以發現以下程式碼：

        LOCAL_SRC_FILES := $(call all-java-files-under, src)

        我們在這句程式碼後新增以下內容：

        $(warning SevenTest LOCAL_SRC_FILES : $(LOCAL_SRC_FILES))

        儲存後終端中執行編譯，我們可以看到src檔案資訊輸出在終端上。複製到檔案中查詢lostClass.java，可以找到，因此可以推翻4的假設。

2.第二種檢視方法。

        檢視APK的編譯打包流程，如圖1：

        根據以上流程，我們可以找到每一步對應的mk檔案，這裡我們找到AndroidSouceCode/build/core/definitons.mk中註釋以下程式碼：

1. define compile-java  
2. $(hide) rm -f [email protected]  
3. $(hide) rm -rf $(PRIVATE_CLASS_INTERMEDIATES_DIR)  
4. $(hide) mkdir -p $(dir [email protected])  
5. $(hide) mkdir -p $(PRIVATE_CLASS_INTERMEDIATES_DIR)  
6. $(call unzip-jar-files,$(PRIVATE_STATIC_JAVA_LIBRARIES),$(PRIVATE_CLASS_INTERMEDIATES_DIR))  
7. $(call dump-words-to-file,$(PRIVATE_JAVA_SOURCES),$(PRIVATE_CLASS_INTERMEDIATES_DIR)/java-source-list)  
8. $(hide) if [ -d "$(PRIVATE_SOURCE_INTERMEDIATES_DIR)" ]; then \  
9.         find $(PRIVATE_SOURCE_INTERMEDIATES_DIR) -name '*.java' >> $(PRIVATE_CLASS_INTERMEDIATES_DIR)/java-source-list; \  
10. fi  
11. $(hide) tr ' ' '\n' < $(PRIVATE_CLASS_INTERMEDIATES_DIR)/java-source-list \  
12.     | sort -u > $(PRIVATE_CLASS_INTERMEDIATES_DIR)/java-source-list-uniq  
13. $(hide) $(1) -encoding UTF-8 \  
14.     $(strip $(PRIVATE_JAVAC_DEBUG_FLAGS)) \  
15.     $(if $(findstring true,$(LOCAL_WARNINGS_ENABLE)),$(xlint_unchecked),) \  
16.     $(2) \  
17.     $(addprefix -classpath ,$(strip \  
18.         $(call normalize-path-list,$(PRIVATE_ALL_JAVA_LIBRARIES)))) \  
19.     $(if $(findstring true,$(LOCAL_WARNINGS_ENABLE)),$(xlint_unchecked),) \  
20.     -extdirs "" -d $(PRIVATE_CLASS_INTERMEDIATES_DIR) \  
21.     $(PRIVATE_JAVACFLAGS) \  
22.     \@$(PRIVATE_CLASS_INTERMEDIATES_DIR)/java-source-list-uniq \  
23.     || ( rm -rf $(PRIVATE_CLASS_INTERMEDIATES_DIR) ; exit 41 )  
24. #Seven註釋  
25. #$(hide) rm -f $(PRIVATE_CLASS_INTERMEDIATES_DIR)/java-source-list  
26. #$(hide) rm -f $(PRIVATE_CLASS_INTERMEDIATES_DIR)/java-source-list-uniq  
27. $(hide) jar $(if $(strip $(PRIVATE_JAR_MANIFEST)),-cfm,-cf) \  
28.     [email protected] $(PRIVATE_JAR_MANIFEST) -C $(PRIVATE_CLASS_INTERMEDIATES_DIR) .  
29. endef  
30. define transform-java-to-classes.jar  
31. @echo "target Java: $(PRIVATE_MODULE) ($(PRIVATE_CLASS_INTERMEDIATES_DIR))"  
32. $(call compile-java,$(TARGET_JAVAC),$(PRIVATE_BOOTCLASSPATH))  
33. #Seven註釋  
34. #$(hide) rm -rf $(PRIVATE_CLASS_INTERMEDIATES_DIR)  
35. endef  

        這樣我們在終端中執行編譯命令後，可以在路徑：AndroidSourceCode/out/target/common/obj/APPS/Settings_intermediates/classes找到以下兩個檔案：

        java-source-list和java-source-list-uniq，在其中搜索lostClass.java即可以找到。

        通過以上檢視可以知道，lostClass.java在是被編譯了的，最後為了驗證，我們可以通過jd-gui這個工具來檢視AndroidSourceCode/out/target/common/obj/APPS/Settings_intermediates/classes.jar，通過檢視該jar檔案中包含了lostClass.java，從而假設一排除。

假設二：

        Settings.apk在打包的時候出現異常。

驗證二：

        對比eng模式以及usr模式下編譯的輸出資訊後發現，二者copy的dex檔案不同。如下：

usr模式：

Copying: out/target/common/obj/APPS/Settings_intermediates/proguard.classes.dex

eng模式：

Copying: out/target/common/obj/APPS/Settings_intermediates/noproguard.classes.dex

        通過比較可以知道：proguard.classes.dex比noproguard.classes.dex小，這裡的proguard就是混淆。也就是說usr模式對程式碼進行了混淆，從而使得usr模式編譯出的Settings.apk與eng模式編譯出的大小不同。是否會是usr模式對程式碼進行ProGuard導致問題的呢？這裡暫時不知道假設二正確與否。

假設三：

        usr模式下編譯系統對程式碼進行ProGuard時出現異常。

驗證三：

        先了解一下ProGuard這個工具；

ProGuard簡介：

        ProGuard是一個免費的java類檔案壓縮，優化，混淆器。它探測並刪除沒有使用的類，欄位，方法和屬性。它刪除沒有用的說明並使用位元組碼得到最大優化。它使用無意義的名字來重新命名類,欄位和方法。 

ProGuard作用：

        1.建立緊湊的程式碼，快速裝載和更小的記憶體佔用。

        2.增加程式和程式使用的庫被反編譯的難度。

        3.刪除來自原始檔中的沒有呼叫的程式碼 。

        在大致瞭解了ProGuard的作用之後，回過頭來看看lostClass.java，該類主要在Settings_heads.xml中呼叫，並沒有通過其他方式呼叫，難道這被ProGuard誤認為是沒有使用的程式碼而給優化掉了？

        開啟原始碼Settings下的Android.mk檔案，可以看到以下程式碼：

        LOCAL_PROGUARD_FLAG_FILES := proguard.flags

        繼續檢視當前路徑下的proguard.flags，程式碼如下：

1. # Keep all Fragments in this package, which are used by reflection.  
2. -keep class com.android.settings.*Fragment  
3. -keep class com.android.settings.*Picker  
4. -keep class com.android.settings.*Settings  
5. -keep class com.android.settings.wifi.*Settings  
6. -keep class com.android.settings.deviceinfo.*  
7. -keep class com.android.settings.bluetooth.*  
8. -keep class com.android.settings.applications.*  
9. -keep class com.android.settings.inputmethod.*  
10. -keep class com.android.settings.MasterClear  
11. -keep class com.android.settings.MasterClearConfirm  
12. -keep class com.android.settings.accounts.*  
13. -keep class com.android.settings.fuelgauge.*  

        稍稍檢視ProGuard的語法後知道，這樣表示哪些類不會完全被ProGuard處理。先在這裡加上一句程式碼：

        -keep class com.android.settings.xxxx.*

        這裡的xxxx表示lostClass.java的包名。

        再次進入終端，切換到usr模式下編譯程式碼，測試成功，但有幾個小的功能還是不能正常使用。通過以上至少證明假設三是正確的，即在ProGuard過程中產生的問題。

        這幾個不能使用的小功能，都有一個共同的特點，即點選Button後報錯，提示找不到對應的方法。這幾個Button是在xml檔案中新增onClick方法的，如：

1. <Button
2.     android:id="@+id/JumpButton"
3.     android:onClick="JumpFuction"
4.     android:layout_width="0dip"
5.     android:layout_height="wrap_content"
6.     android:layout_weight="1"/>

        通過檢視ProGuard官網的Example——A complete Android Application可以知道，還需要在proguard.flags中新增以下程式碼：

-keepclassmembers class * extends android.content.Context {
   public void *(android.view.View);
   public void *(android.view.MenuItem);
}

        官網給出的解釋是：We're also keeping possible onClick handlers in custom Context extensions, since they might be referenced from XML layout files.

        也就是說：有的onClick事件是在xml中定義的，所以在proguard.flags檔案中新增以上內容從而保證這些onClick觸發方法不會被ProGuard優化掉。加上以上程式碼，編譯，測試，通過！！

案件回顧：

        整個案件看似撲朔迷離，但背後隱藏的是APK整個編譯流程。一開始看似不可能的事情(usr模式和eng模式編譯結果不一致)，經過小白一步一步的跟蹤後竟然發現了背後的“驚天祕密”。ProGuard是一個免費的開源專案，用以壓縮、優化、混淆程式碼，Android 原始碼集成了proguard，預設會在usr以及usrdebug模式下開啟，這一點可以在AndroidSouceCode4.0/build/core/package.mk中找到：

ifndef LOCAL_PROGUARD_ENABLED
ifneq ($(filter user userdebug, $(TARGET_BUILD_VARIANT)),)
    # turn on Proguard by default for user & userdebug build
    LOCAL_PROGUARD_ENABLED :=full
endif
endif

        (PS：高通的原始碼與google原生的差不多，而MTK則註釋掉了這裡的LOCAL_PROGUARD_ENABLED :=full，即usr、usrdebug、eng模式編譯出來的結果都沒經過混淆。)

當然除了ProGuard還有一個DexGuard可以實現對Android應用的優化與保護，不過這貨是收費的(最便宜都要350 € 歐元啊。。。換算過來要將近3000快RMB。。。o(╯□╰)o)。

        最後在大人的明察秋毫下，真相終於大白。