0x00
今天用Appium执行UI自动化用例的时候，发现安装蜗牛读书的包之后apk无法启动，启动即挂掉，查log也无法查到有效的报错日志。然后自己通过adb去安装apk包的话，apk可以顺利启动，正常运行。Appium安装apk的过程中发生了什么---
0x01
我从蜗牛读书的官网（https://du.163.com/）下载了最新版本apk，并将该apk拷贝到Appium UI自动化工程路径下。此时两个apk包是一摸一样的。如下图所示，左边是下载路径，右边是UI自动化工程路径。
然后执行蜗牛读书的UI自动化用例，该用例执行前会做adb uninstall卸载蜗牛读书app的操作，然后执行的时候会先让Appium执行安装蜗牛读书app，再进行其他UI自动化操作。当执行完UI自动化用例时，执行报错，我们看到app启动后马上闪退掉。工程报错是无法找到相应的元素。
为了更好的定位问题，我把appium执行时要用的apk自己进行了手动adb install安装，发现会出现同样的无法启动的问题。然后我对比了此时apk的源文件和appium路径下的apk文件，两者有差异：
也就是说，通过appium安装的apk与原始apk不是一摸一样了。那么做了什么操作呢？
0x02
我们尝试从appium的日志中找寻蛛丝马迹。单独的报错日志意义一般，因为app未正常启动，找不到指定元素也是必定的。我们查看下appium客户端的实时日志，其中有关键的两条操作：
如上图所示，关键的两条操作就是红框中圈出所示，分别进行了重签名和对齐。重签名使用的应该是appium内置的debug签名，因为重签名之前先做了debug签名的校验。
这样看来就能够解释为什么经过appium安装后的apk大小发生了变化，appium对apk做了重签名和对齐的操作。那么，为什么同样的UI自动化设置，大部分产品可以顺利执行，只有蜗牛读书的apk无法正常启动呢？
0x03
我们尝试从蜗牛读书apk本身入手，出问题的版本是最新版本，我们拿一个老的蜗牛读书的版本来试，发现同样经过appium重签名和对齐之后的apk也能够正常打开和操作。这个版本是有做过什么特殊处理么？
我们使用apk反编译方法对apk进行简单分析，发现新旧两个版本的apk还是有着较大差异。如下两图所示：
从上两图对比可以明显的看到，虽然两个版本都做了代码混淆，但是新版本在主包中只能看到MyApplication明显是对apk做了加固的结果。
与蜗牛读书开发二次确认了下，确实在新版本中新增做了apk的加固。经过加固后的apk，如果被重签名之后，外壳对签名进行校验通不过的话，不会正常启动。所以，问题的原因就比较清晰了：蜗牛读书最新版本做了apk的加固，appium启动apk时对apk进行了重签名，导致启动时外壳校验签名不通过从而启动失败。
0x04
了解到原因后，如何解决呢。
一种方式是不通过appium启动apk。但是这种方式对于特殊的UI自动化场景是不适用的，比如想测试冷启动的UI场景，就需要Appium进行启动。
第二种方式是使用其他版本的apk。但是这种方式治标不治本。
第三种方式是可以让appium不进行apk的重签名。通过添加设置capabilities.setCapability("noSign","true") 不让appium对apk进行重签名。没添加这条设置的话，默认是开启appium对apk的重签名的。
结语
总结下Appium安装apk后无法启动的原因，是appium默认对安装的apk都要进行重签名，而按照某种策略加固后的apk被appium重签名后由于签名校验不通过从而无法启动。解决方式则是对appium添加不进行重签名的设置。
