811
移動測試技術問答Q&A
1. INSTALL_PARSE_FAILED_INCONSISTENT_CERTIFICATES
由於APP簽名衝突造成。如果設備上已經安裝了其他簽名的相同包名APP，再安裝其他簽名的就會報出此類錯誤。
解決方法：a. 更換簽名文件，重新簽名 b. 更改應用的包名，避免衝突。
2. INSTALL_FAILED_DEXOPT
方法數超標所導致。dx打包時限製了單個dx文件的最大方法數為65535。同時Dalvik VM限製內存中加載的方法數（方法，類定義及構造函數）不能超過65535個。
解決方法：a. 檢查代碼，刪出無用jar包和代碼，尤其是自動生成的get/set，沒用的類。b. 將部分java代碼封裝到JNI中。
3. INSTALL_PARSE_FAILED_NO_CERTIFICATES
應用中沒有簽名信息。
解決方法：使用Eclipse或者Android Studio對項目重新編譯打包。
4. INSTALL_FAILED_MEDIA_UNAVAILABLE
Android應用安裝位置不可用。應用安裝位置有兩個：ROM、sdcard。如果嚴格指定安裝到sdcard，但是設備沒有sdcard時，就會報此類錯誤。
解決方法：AndroidManifest.xml中配置：
5. INSTALL_FAILED_OLDER_SDK
設備係統版本比應用的最低支持的係統版本低。
解決方法：AndoidManifest.xml中將係統版本降低。
6. INSTALL_FAILED_VERSION_DOWNGRADE
設備中已經安裝了此APP的更高版本，無法降級安裝。
解決方法：先卸載之前的版本，再安裝此版本。
7. INSTALL_PARSE_FAILED_UNEXPECTED_EXCEPTION
安裝APP時，Android係統會對APP先進行解析。解析過程出錯，就會報出此類錯誤，可能得原因很多。
解決方法：檢查AndroidManifest.xml各項配置是否符合規範。比如sdkVersion不能用string等等。
8. INSTALL_FAILED_UID_CHANGED
應用在上次卸載時，由於應用中的native程序未被殺死而占用/data/data/{packageName}目錄，導致/data/data/目錄下的APP相關內容未被刪除，多數情況下能在logcat中找到報錯：Installer: rm -rf failed， directory is not empty。再次安裝時無法覆蓋，導致報出此類問題。
解決方法：如果設備Root了，則直接刪除/data/data/目錄下的應用包名文件夾；如果沒有root，需要將手機恢複出廠設置。此外，開發者要額外注意容易出現此類問題的手機，對此類設備的用戶給出提示。用戶無需操心，阿裏移動測試平台會幫助解決。
9. INSTALL_FAILED_NO_MATCHING_ABIS
當安裝的APP包含native libraries（一般是so文件）的時候，如果沒有對應機器CPU架構的庫文件，就會出現這種問題。比如，你編譯了一個armv7平台的APP，但是想要裝在intel 架構的設備上，就會出現這個錯誤。
解決方法：在編譯APP時，先用NDK編譯出相應的CPU架構的庫文件。
10. INSTALL_FAILED_CANCELLED_BY_USER
部分機型在使用adb命令安裝應用時，設備會彈窗詢問用戶是否允許安裝，假如一段時間內（一般是30s），沒有點擊確認彈窗，那麼此類設備會阻止安裝，並提示用戶：INSTALL_FAILED_CANCELLED_BY_USER
解決方法：聯係MQC工作人員，旺旺群：335334143；QQ群：492028798
11. INSTALL_FAILED_VERICATION_TIMEOUT
原因及解決方法同：INSTALLED_FAILED_CANCELLED_BY_USER
12. OutOfMemory問題（OOM）解決方法
每個Android應用都有一個最大內存上限。超過這個上限，就會導致內存不足（OutOfMemory）。檢查內存上限的方法：
int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);
Log.d("TAG", "Max memory is " + maxMemory + "KB");
通常情況下，出現OOM，是由於應用中加載了大量的圖片導致。鑒於此，有以下幾種方式來減小應用對內存的使用：
a. 合理壓縮展示圖片，比如一個100x100的控件裏，如果加載一個1024x768的圖片，不會讓圖片的展示效果更好，反而會增加OOM的風險。所以，合理的對圖片進行壓縮非常重要。
b. 壓縮完圖片，但是應用裏包含了太多的圖，這種情況依然可能出現OOM。這種情況下，考慮使用內存緩存技術。根據每一屏要展示的圖片數量，以及每個圖片的大小，設定一個合理的緩存值，一般情況下不要超過1/8的最大內存值。如果圖片不在顯示區域，可以考慮將其進行回收，係統的垃圾回收器（GC）會認為這些內存不在被使用，從而對圖片進行GC操作。這樣會大大降低OOM的風險。
c. 更多的OOM討論，參見：https://blog.csdn.net/vshuang/article/details/39647167
13. iOS應用（ipa）安裝失敗可能的原因和解決方法
每個ipa包本質上是一個zip包，裏麵包含ios應用的資源和可執行文件。
a. 如果提示“應用重簽名失敗”，很可能的原因是ipa是直接從itunes市場下載的正式發布包，這樣的包經過蘋果的加密，無法安裝到任何沒有購買過這個應用的用戶手機上麵。
b. 如果部分的手機安裝失敗，請檢查一下你的應用支持的最低ios SDK的版本（可以很直觀的從包裏麵的Info.plist看到）。比如最低支持ios8.3，則ios8.2版本的手機就裝不上這個應用。
14. 啟動失敗如何進行Debug？
很多同學遇到啟動失敗的問題，很難進行debug，不知道該如何入手。啟動失敗其實也可以找到錯誤棧信息，並且通過這個錯誤棧信息，定位到具體的問題原因。如下圖：
這裏，我們可以看到啟動失敗的進程pid：26981。然後，我們需要下載日誌，這裏的日誌就是詳細的logcat日誌。
下載之後，我們需要通過這個PID找到真正引起crash的錯誤棧。這裏建議，使用支持正則匹配的編輯器打開logcat日誌（比如nodepad++、vim等等），打開之後，使用正則規則：“26981.* E .*” 進行匹配查找。可以找到如下信息：
這樣我們就能知道具體那行代碼導致的錯誤了。
15. 常見崩潰問題，NullPointerException: Attempt to invoke virtual method 'android.content.res.Resources android.content.Context.getResources()' on a null object reference**
該問題一般是由於資源加載時，引用初始化未完全的Context對象導致。
解決方法：通過增加非空檢查；創建View時，使用當前組件的Context（比如ActivityXXX.this），而不用getApplicationContext()等方式。
參考資料：https://stackoverflow.com/questions/28248232/what-am-i-doing-wrong-with-my-handling-of-contex-java-android
參考資料：https://stackoverflow.com/questions/25488208/java-nullpointerexception-getting-resources**
阿裏雲測移動質量中心（以下簡稱MQC）是為廣大企業客戶和移動開發者提供真機測試服務的雲平台，擁有大量熱門機型，提供7x24全天候服務。
我們致力於提供專業、穩定、全麵、高價值的自動化測試能力，以及簡單易用的使用流程、貼心的技術服務，並且幫助客戶以最低的成本、最高的效率發現APP中的各類隱患（APP崩潰、各類兼容性問題、功能性問題、性能問題等），減少用戶流失，提高APP質量和市場競爭力。
聯係我們：
網站地址：https://mqc.aliyun.com
開發者交流旺旺群：335334143
開發者交流QQ群：492028798
客服郵箱：mqc_group@service.alibaba.com；
更多精彩技術分享 歡迎關注 MQC公眾號
最後更新：2017-08-13 22:42:06