Xcode 10 使用的心塞之路

说心塞之路，一点也不为过，这两天体会到了类似服务端开发的压力。以下为事件的始末。

自从苹果 9 月发布会之后，Xcode 10 陆续开始了推送，为了一瞻苹果暗黑模式，我在 十一 期间也更新了最新系统，安装了Xcode 10，而且使用没有明显的bug，暗黑模式也是挺装逼的。

十一 之后，开始了我们 app 3.5.7 版本的提交审核，准确来说是 10.9 。但是直到两周也没有审核，一直维持着正在等待审核的状态。期间，我们又进行了新功能的研发，想着反正还是要发布一个版本，索性 3.5.7 就不再管了。

当 10.23 提交了 3.5.8 之后，第二天就审核通过了，顿时觉得很开心。接下来用户也没有反馈出什么问题。由于 app 在 AppStore 更新数据不及时，可能有些人还没有安装最新版。但是，晚上已经陆续有人开始反应会有闪退了，而且系统主要集中在 iOS 9。当时觉得可能是某个地方不兼容，所以就花费了2个小时下载了 iOS 9 的模拟器运行测试，也不会出现问题。接下来会有偶尔的用户反馈 iOS 11 、iOS 12 也会崩溃。关键这些闪退，大部分是 app 启动就闪退。在下载模拟器的同时我还查看了友盟、itunes 上的崩溃日志，发现没有关于这种的日志。然后就没辙了，只能等到明天继续打这场硬仗了。

第二天，也就是 10.25 ，一大早就收到好多客服反馈说好多人闪退(其实最后拉到一个群组里面也就 28 个人左右)，大部分还是启动就闪退，很少用户是点击个人中心清除缓存闪退。由于系统版本的分散，所以也不是系统兼容的问题，查看友盟、itunes 仍然没有相应的崩溃日志。

10.25 中午，在群里看到有个用户还在说问题，这个时候，突然想到 让用户添加我，获取他们设备上的崩溃日志，进行分析查看。这个过程大概持续了三个小时，获取到了他们设备的信息，通过命令行解析了崩溃日志如下：

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x000000010004cad0
Triggered by Thread: 0

Filtered syslog:
None found

Global Trace Buffer (reverse chronological seconds):
6148914687.014364 CFNetwork 0x0000000182e69928 TCP Conn 0x15fa75d50 starting SSL negotiation
6148914687.014932 CFNetwork 0x0000000182f0ba30 TCP Conn 0x15fa75d50 complete. fd: 9, err: 0
6148914687.016414 CFNetwork 0x0000000182f0cf5c TCP Conn 0x15fa75d50 event 1. err: 0
6148914687.075758 CFNetwork 0x0000000182f0d034 TCP Conn 0x15fa75d50 started
6148914689.682108 CFNetwork 0x0000000182e69a18 TCP Conn 0x15e7a27e0 SSL Handshake DONE
6148914689.687297 CFNetwork 0x0000000182f0ba30 TCP Conn 0x15f897720 complete. fd: 9, err: 0
6148914689.687758 CFNetwork 0x0000000182f0cf5c TCP Conn 0x15f897720 event 1. err: 0
6148914689.716092 CFNetwork 0x0000000182f0d034 TCP Conn 0x15f897720 started
6148914689.728427 CFNetwork 0x0000000182f0ba30 TCP Conn 0x15fa62e00 complete. fd: 21, err: 0
6148914689.728559 CFNetwork 0x0000000182f0cf5c TCP Conn 0x15fa62e00 event 1. err: 0
6148914689.741988 CFNetwork 0x0000000182e69a18 TCP Conn 0x15e7bc4b0 SSL Handshake DONE
6148914689.745552 CFNetwork 0x0000000182f0ba30 TCP Conn 0x15f897720 complete. fd: 35, err: 0
6148914689.745862 CFNetwork 0x0000000182f0cf5c TCP Conn 0x15f897720 event 1. err: 0
6148914689.749554 CFNetwork 0x0000000182f0ba30 TCP Conn 0x15e7d66e0 complete. fd: 34, err: 0
6148914689.749744 CFNetwork 0x0000000182f0cf5c TCP Conn 0x15e7d66e0 event 1. err: 0
6148914689.751110 CFNetwork 0x0000000182f0ba30 TCP Conn 0x15f8b60b0 complete. fd: 15, err: 0
6148914689.751278 CFNetwork 0x0000000182f0cf5c TCP Conn 0x15f8b60b0 event 1. err: 0
6148914689.754748 CFNetwork 0x0000000182f0d034 TCP Conn 0x15fa62e00 started
6148914689.773936 CFNetwork 0x0000000182f0d034 TCP Conn 0x15f897720 started
6148914689.773936 CFNetwork 0x0000000182f0d034 TCP Conn 0x15f8b60b0 started
6148914689.783995 CFNetwork 0x0000000182e69a18 TCP Conn 0x15f942ef0 SSL Handshake DONE
6148914689.786436 CFNetwork 0x0000000182e69928 TCP Conn 0x15e7a27e0 starting SSL negotiation
6148914689.786681 CFNetwork 0x0000000182f0ba30 TCP Conn 0x15e7a27e0 complete. fd: 13, err: 0
6148914689.786936 CFNetwork 0x0000000182f0cf5c TCP Conn 0x15e7a27e0 event 1. err: 0
6148914689.794683 CFNetwork 0x0000000182e69a18 TCP Conn 0x15fa41c60 SSL Handshake DONE
6148914689.805450 CFNetwork 0x0000000182f0ba30 TCP Conn 0x15fa265b0 complete. fd: 39, err: 0
6148914689.805680 CFNetwork 0x0000000182f0cf5c TCP Conn 0x15fa265b0 event 1. err: 0
6148914689.805878 CFNetwork 0x0000000182f0ba30 TCP Conn 0x15fa53ec0 complete. fd: 21, err: 0
6148914689.807784 CFNetwork 0x0000000182f0cf5c TCP Conn 0x15fa53ec0 event 1. err: 0

但是，主线程的日志不规律，有的是启动初始化 tab 报错，有的是刷新控件报错，有的是个人中心报错。但是前面部分的错误都是这样的：

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x000000010004cad0
Triggered by Thread: 0

这样子也解决不了问题呀。

刚好有用户添加我好友，我便在 AppDelegate 中添加了捕获异常的代码，并将异常信息通过打开邮箱发送给我，以便排查问题。当我将包通过蒲公英发送给他的时候，没有任何问题，也不会打开邮件 app 。这个情况让我很费解，随即把捕获异常的代码去掉，重新打包给他，还是没有问题。然后立马想到了可能是打包方式的问题。因为上传 AppStore 使用的是 fastlane 打包的。之后把测试包全部下发给加我的三个用户，全部正常了，然后让客服找了几个人测试了一下也是正常的。所以就断定了是打包方式的问题。接下来，就是使用 Xcode 10 打包上传，并申请加急，期待审核成功。

上传之后，差不多也到了下班时间了，但是，为了确定到底问题出在了哪里，我就把 AppStore 线上包下载下来，重签名发给用户安装，测试也是没有问题的。所以我就确定了是上传包后苹果签名的问题。也就是打包工具不一样导致的。剩下的只有等着明天审核通过，app 正常使用了。

其实，在回家的路上，自己心里还是很虚的，如果真的是我上传包工具不一样，那所有使用 fastlane 的开发者不都会出现这个问题吗？但是，这个就是唯一的答案，只能自己相信自己了。

10.26 一早，app 审核通过了，还没有发到市场上。我就先查看了一下 fastlane 使用什么命令上传包的，官方文档上说也是使用的官方工具 iTMSTransporter ，而且不论Organizer还是App Loader，都是通过iTMSTransporter来上传文件的。看到这里，我心里就虚了，也就是说上传过程不会有问题，真有问题，就是上传之后苹果签名的问题，如果签名有问题，所有 app 都会出现这个问题。这显然是不现实。接着，由于客服又开始催我上架 app ，就只能硬着头皮上架了。果然，闪退的用户更新完 app 还是闪退，而且有的用户安装后不闪退，但是 app 搜索弹出的键盘好多字母重合一块，而其他 app 弹出的键盘显示正常。怎么办呢？彻底没辙了。但是，办法总是想出来的。我又使用最新的项目打出一个测试包，让用户安装测试，还是没有任何问题。所以，结论就是渠道包的问题，打出的 AppStore 渠道的包就会有问题，而打出的 Adhoc 渠道包不会有问题。那又怎么样呢？把这个情况跟技术总监说了一下，技术总监说是不是项目中渠道配置问题，但是通常不会有这种配置问题，只有 Release Debug 之分。然后，想到前几天自己手动修改了一些配置，git 合并的时候也修改了一些配置，不确定是否有影响，只能通过 git 查看日志了。可是，git 里面有两个版本，到底是从 3.5.7 还是 3.5.8 开始的呢，又是一个问题？这么大的工作量也是不好找呀，无奈，只能中午吃饭去了。

吃完饭之后，想了一下，为了找到从哪个版本出现的问题，只能通过 TestFlight 安装测试了。所以继续找用户通过 TestFlight 安装测试，这时，发现 TestFlight 新添加了一个生成共有链接的功能。不需要 AppleId 即可安装，所以就通过这种方式给用户生成一个 3.5.6 先临时使用。接着，找到加我的用户，询问邮箱，邀请、截图、点击、一步步操作，中间过程非常复杂，还是没有成功。没办法，只能兵行险招，给他们开通权限，这样就可以测试之前多个版本了。找到一个用户，给了权限，安装各个版本测试一下，发现从 3.5.7 版本就崩溃了。找到了问题，就只能去 git 翻看日志了。同时回想了一下，发现从 3.5.7 开始使用的 Xcode 10 发布的应用，所以，可能也跟 Xcode 版本有关。在找 log 的同时，重新下载 Xcode 9.4.1，同时询问以前公司的 iOS 开发目前使用的 Xcode 版本也是 10。心中又有了疑惑，难道是我 Xcode 坏了。没关系，不是有用户可以测试嘛。我重新打出包让以前同事上传上去了。同时，我查到一个日志，关于 release 下签名的配置改动，重新恢复成原来的，继续打包上传了。而此时，我的 Xcode 9.4.1 也下载好了，打开项目进行编译打包，同时联系用户帮我测试，发现这个用户暂时没有时间，只能找另一个用户重新添加权限测试了。他首先测试了前两个包，还是会出现闪退，接着测试第三个包，就一切正常了。哎哟，终于找到了问题了，还真的是 Xcode 版本的问题。当然，这次为了求稳，还是期待多个人同时测试的。目前来说，只能等第一个给权限的用户了。5 点左右的时候，这个人有时间了，并测试一波也是好了。现在稳了，可以提交版本了。

提交了新版本 3.6.0 ，并加急后，我决定明天即使通过(因为明天就是周六)，也不上架，先通过 TestFlight 让用户测试，真的没有问题，再进行上架（说实话，自己真蠢，为什么之前没有想到呢）。

10.27 ，3.6.0 成功审核通过，过了一会，TestFlight 也可以测试这个版本了，就分发给用户进行了测试，这次真的是稳了，没有什么问题。参与测试的用户达到了 107 个，但是为了求稳，还是想让没闪退的用户参与测试一下，奈何无人测试呀。

以上就是整个查找 bug 的过程，真的是心酸。虽然历时比较久，我不觉得有哪里耽误了时间。当然，如果有个这样的手机在身边，估计 2 个小时就搞定。

虽然说这个 bug 的解决过程没有可优化处，但是其他方面还是有待提高。比如找到了问题解决之后，如果要发包，可以去看看崩溃日志，顺道把已有的 bug 一起解决掉。

ps： 在用户测试 3.6.0 版本的时候，听到产品经理说同行多个 app 最近也是频繁更新，估计也是这个问题。

当然，还是会有总结的：

1. 用户的时间不是固定的，自己的时间是固定的，所以，不要把鸡蛋放到同一个篮子里，多找几个用户并行进行。
2. 方向很重要，先找问题的方向，然后再去具体找。假设当时直接去看日志，那不是翻死了，最后还是找不到问题，所以，通过用户测试找到从 3.5.7 开始的崩溃，进而联想到 Xcode 的问题。
3. 多考虑后续操作。因为最终还是要确定 App Store 包在用户手机上运行正常，所以必须要通过 TestFlight，所以在引导用户使用 TestFlight 的操作不是浪费时间，而是必要时间损耗。而且，通过 TestFlight 找到了整个方向。
4. 逆向思考。从崩溃日志解决不了问题，从结果来看，排除所有的不可能，剩下的唯一一个就是可能。
5. 平时多积累，日后必有用。如果不是之前使用过 TestFlight，也不会想到这个测试工具。同样，如果知道 fastlane 使用的上传包工具也是系统的，就不会再多浪费一个版本的发布。

到此，基本确定了就是 Xcode 10 上传 App Store 渠道包的问题了。

总之，一句话，Xcode 10 ，你可把我害惨了~