0x00
今天用Appium執(zhí)行UI自動化用例的時候，發(fā)現(xiàn)安裝蝸牛讀書的包之后apk無法啟動部念，啟動即掛掉，查log也無法查到有效的報錯日志。然后自己通過adb去安裝apk包的話家坎，apk可以順利啟動，正常運行吝梅。Appium安裝apk的過程中發(fā)生了什么---
0x01
我從蝸牛讀書的官網(wǎng)（https://du.163.com/）下載了最新版本apk虱疏，并將該apk拷貝到Appium UI自動化工程路徑下。此時兩個apk包是一摸一樣的憔涉。如下圖所示订框，左邊是下載路徑，右邊是UI自動化工程路徑兜叨。
然后執(zhí)行蝸牛讀書的UI自動化用例穿扳，該用例執(zhí)行前會做adb uninstall卸載蝸牛讀書app的操作，然后執(zhí)行的時候會先讓Appium執(zhí)行安裝蝸牛讀書app国旷，再進行其他UI自動化操作矛物。當執(zhí)行完UI自動化用例時，執(zhí)行報錯跪但，我們看到app啟動后馬上閃退掉履羞。工程報錯是無法找到相應(yīng)的元素。
為了更好的定位問題，我把appium執(zhí)行時要用的apk自己進行了手動adb install安裝忆首，發(fā)現(xiàn)會出現(xiàn)同樣的無法啟動的問題爱榔。然后我對比了此時apk的源文件和appium路徑下的apk文件，兩者有差異：
也就是說糙及，通過appium安裝的apk與原始apk不是一摸一樣了详幽。那么做了什么操作呢？
0x02
我們嘗試從appium的日志中找尋蛛絲馬跡浸锨。單獨的報錯日志意義一般唇聘，因為app未正常啟動，找不到指定元素也是必定的柱搜。我們查看下appium客戶端的實時日志迟郎，其中有關(guān)鍵的兩條操作：
如上圖所示，關(guān)鍵的兩條操作就是紅框中圈出所示聪蘸，分別進行了重簽名和對齊宪肖。重簽名使用的應(yīng)該是appium內(nèi)置的debug簽名，因為重簽名之前先做了debug簽名的校驗宇姚。
這樣看來就能夠解釋為什么經(jīng)過appium安裝后的apk大小發(fā)生了變化匈庭，appium對apk做了重簽名和對齊的操作。那么浑劳，為什么同樣的UI自動化設(shè)置阱持，大部分產(chǎn)品可以順利執(zhí)行，只有蝸牛讀書的apk無法正常啟動呢魔熏？
0x03
我們嘗試從蝸牛讀書apk本身入手衷咽，出問題的版本是最新版本，我們拿一個老的蝸牛讀書的版本來試蒜绽，發(fā)現(xiàn)同樣經(jīng)過appium重簽名和對齊之后的apk也能夠正常打開和操作镶骗。這個版本是有做過什么特殊處理么？
我們使用apk反編譯方法對apk進行簡單分析躲雅，發(fā)現(xiàn)新舊兩個版本的apk還是有著較大差異鼎姊。如下兩圖所示：
從上兩圖對比可以明顯的看到，雖然兩個版本都做了代碼混淆相赁，但是新版本在主包中只能看到MyApplication明顯是對apk做了加固的結(jié)果相寇。
與蝸牛讀書開發(fā)二次確認了下，確實在新版本中新增做了apk的加固钮科。經(jīng)過加固后的apk唤衫，如果被重簽名之后，外殼對簽名進行校驗通不過的話绵脯，不會正常啟動佳励。所以休里，問題的原因就比較清晰了：蝸牛讀書最新版本做了apk的加固，appium啟動apk時對apk進行了重簽名赃承，導(dǎo)致啟動時外殼校驗簽名不通過從而啟動失敗妙黍。
0x04
了解到原因后，如何解決呢瞧剖。
一種方式是不通過appium啟動apk废境。但是這種方式對于特殊的UI自動化場景是不適用的，比如想測試冷啟動的UI場景筒繁，就需要Appium進行啟動。
第二種方式是使用其他版本的apk巴元。但是這種方式治標不治本毡咏。
第三種方式是可以讓appium不進行apk的重簽名。通過添加設(shè)置capabilities.setCapability("noSign","true") 不讓appium對apk進行重簽名逮刨。沒添加這條設(shè)置的話呕缭，默認是開啟appium對apk的重簽名的。
結(jié)語
總結(jié)下Appium安裝apk后無法啟動的原因修己，是appium默認對安裝的apk都要進行重簽名恢总，而按照某種策略加固后的apk被appium重簽名后由于簽名校驗不通過從而無法啟動。解決方式則是對appium添加不進行重簽名的設(shè)置睬愤。
