手游经常崩溃”闪退”？ 从门径上找原因

行动玩家，当游戏crash的时代是什么神志，淌若这个游戏玩起来还可以的话，那我可能还会开放第二次，淌若这个游戏一般的话我可能平直怒删了。当屡次出现闪退crash的时代，这种恶运的体验很容易让用户流失，变成很大的亏空。然则行动测试东说念主员，面临如斯辣手的事情，最初要作念的是协助开导组解决问题。没错，第一件要作念的事情即是去定位crash发生的代码逻辑，到底是哪个文献的哪一段函数逻辑导致了这个crash问题。因此，咱们需要去尽量重现crash场景，网罗贯通crash日记，以此定位到具体到游戏代码逻辑中寻找导致crash的原因，改善项贪图质地和体验。本文叙述在App crash产生的旨趣，网罗妥协析过程，旨在教授积聚，与全球共享。

一．crash产生的原因

当iOS/Android建设上的App诈欺闪退时，操作系统会生成一个crash日记，保存在建设上。crash日记上有好多有用的信息，比如每个正在实行线程的好意思满堆栈追踪信息和内存映像，这么就简略通过贯通这些信息进而定位crash发生时的代码逻辑，从而找到App闪退的原因。浅显来说，crash产生起头于两种问题：违抗iOS系统法规导致的crash和App代码逻辑BUG导致的crash，底下分辩对他们进行分析。

1.1违抗iOS系统法规包括三种类型：

(1) 内存报警闪退

当iOS检测到内存过低时，它的VM系统会发出低内存警告见知，尝试回收一些内存；淌若情况莫得获得充足的改善，iOS会间隔后台诈欺以回收更多内存；终末，淌若内存照旧不足，那么正在运行的诈欺可能会被间隔掉。在Debug模式下，可以主动将客户端实行的动作逻辑写入一个log文献中，这么门径童鞋可以将内存预警的逻辑写入该log文献，当发生如下截图中的内存报警时，即是辅导现时客户端性能内存吃紧，可以通过Instruments器具中的Allocations 和 Leaks模块库来发现内存分派问题和内存泄漏问题。

(2) 反应超时

当诈欺门径对一些特定的事件（比如启动、挂起、收复、收尾）反应不足时，苹果的Watchdog机制会把诈欺门径干掉，并生成一份相应的crash日记。这些事件与下列UIApplicationDelegate治安相对应，当遭受Watchdog日记时，可以检查上图中的几个治安是否有比拟重的羁系UI的动作。

application:didFinishLaunchingWithOptions:

applicationWillResignActive:

applicationDidEnterBackground:

applicationWillEnterForeground:

applicationDidBecomeActive:

applicationWillTerminate:

(3) 用户强制退出

一看到“用户强制退出”，最初可能思到的双击Home键，然后关闭诈欺门径。不外这种场景一般是不会产生crash日记的，因为双击Home键后，所有这个词的诈欺门径都处于后台景色，而iOS随时都有可能关闭后台进度，当诈欺羁系界面并罢手反应时这种场景才会产生crash日记。

这里指的“用户强制退出”场景，是略微比拟复杂点的操作：先按住电源键，直到出现“滑动关机”的界面时，再按住Home键，这时代现时诈欺门径会被间隔掉，何况产生一份相应事件的crash日记。

1.2诈欺逻辑的Bug

大大批闪退崩溃日记的产生都是因为诈欺中的Bug，这种Bug的造作种类有好多，比如

SEGV：（Segmentation Violation，段违例），无效内存地址，比如空指针，未首先化指针，栈溢出等；

SIGABRT：收到Abort信号，可能本人调用abort()或者收到外部发送过来的信号；

SIGBUS：总线造作。与SIGSEGV不同的是，SIGSEGV捕快的是无效地址（比如虚存映射不到物理内存），而SIGBUS捕快的是灵验地址，但总线捕快十分（比如地址对都问题）；

SIGILL：尝试实行犯科的指示，可能不被识别或者莫得权限；

SIGFPE：Floating Point Error，数学计较干系问题（可能不限于浮点计较），比如除零操作；

SIGPIPE：管说念另一端莫得进度接办数据；

常见的崩溃原因基本都是代码逻辑问题或资源问题，比如数组越界，捕快野指针或者好意思术资源不存在，或好意思术资源大小写造作等，这种问题的类型有好多，不再详备先容。

二．crash的网罗

上文提到crash日记是操作系统层产生并保存在建设上的，那淌若我的一台建设在运行某App的时代crash了，可以通过什么阵势拿到crash日记呢。淌若是在windows上你可以通过itools或pp助手等扶直器具检察系统产生的历史crash日记，然后再凭证app来检察。淌若是在Mac 系统上，只需要开放xcode->windows->organizer->devices，选拔device logs进行检察，

以上这些是针对简略拿到真机建设的情况下能力网罗crash日记的。淌若是针对玩家的话，当App在玩家的建设上crash的时代怎样网罗呢。先来看下商场上已有的交易软件提供crash网罗干事，他们这些软件基本都提供了日记存储，日记象征化贯通和干事端可视化管制等干事。

开导者也可以使用Keymob等器具来扶直崩溃日记的网罗和分析，它提供了日记检察、性能监控和文献管制等功能，匡助简化调试经由。

除了上述所说的这些交易软件外，还有一些开源的软件也可以拿来网罗crash日记，比如Razor,QuincyKit（git蚁合）等，这些软件网罗crash的旨趣其实大同小异，都是凭证系统产生的crash日记进行了一次索要或封装，然后将封装后的crash文献上传到对应的干事端进行贯通处理。好多交易软件都罗致了Plcrashreporter这个开源器具来上传妥协析crash，比如HockeyApp,Flurry和crittercism等，

通过这种阵势就可以很好的撑执开导东说念主员网罗crash日记的需求，进而定位妥协决App居品存在的问题。淌若有需要或者感酷爱酷爱的可以深远的调研一下。

然则有个很迫切的问题即是这种阵势只可网罗游戏引擎层（c++或object c代码）的逻辑，淌若是剧本逻辑问题产生的crash就窝囊无力了。而当今手游表情基本都是引擎（cocos2dx或Neox)+剧本（lua或javascript)的开导模式，的确所有这个词的业务逻辑都在剧本层，游戏App经常发生的crash的确都是由剧本逻辑bug导致的，这该若那处理呢？平时在开导阶段，门径童鞋在Debug模式下通达了客户端运行日记功能，当出现crash或者traceback等问题的时代平直去检察log文献的输出即可知说念原因了，然则在Release模式下一切log输出均被屏蔽，逻辑运行的log音尘输出也就无法检察了。这种情况该又该如那处理呢？治安总比问题多，iOS/Android系统提供了十分发生时的处理API，只需要在门径启动的方位加入对应的处理逻辑，当十分发生时就可以触发对应的回调函数将必要的信息进行处理上传，当令地反馈给开导组。

三．crash日记的贯通

淌若是剧本层逻辑导致的crash，如上所述，这种情况是可以平直凭证网罗的日记骨子来定位导致crash的逻辑的。淌若是引擎层发生了问题，该怎样定位贯通呢。

1)crash绚丽是诈欺进度产生crash时的一些绚丽信息，它描写了该crash的唯独绚丽（E838FEFB-ECF6-498C-8B35-D40F0F9FEAE4），所发生的硬件建设类型（iphone3,1代表iphone4），以及App进度干系的信息等；

2）基本信息描写的是crash发生的时代和系统版块；

3）十分类型描写的是crash发生时抛出的十分类型和造作码；

4）线程回溯描写了crash发生时所有这个词线程的回溯信息，每个线程在每一帧对应的函数调用信息（这里由于空间限制莫得沿途列出）；

5）二进制映像是指crash发生时已加载的二进制文献。以上即是一份crash日记包含的所有这个词信息，接下来就需要凭证这些信息去贯通定位导致crash发生的代码逻辑， 这就需要用到象征化贯通的过程（洋名叫：symbolication)。

象征化贯通过程有三种治安：

xcode可视化检察，

symbolicatecrash器具，

atos器具；然则这三种治安都需要用到构建app时生成的.app文献和.app.dsym这两个文献，第一种阵势还是在第二章节提到过，不再赘述，底下先容第二种和第三种贯通的阵势。

3.1 symbolicatecrash贯通

symbolicatecrash是xcode自带的一个号令行器具，在xcode5.0昔时的位置是/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/，xcode5.0以后旅途就变成了/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/

比如以上述提到的TestFlight App为例，将TestFlight .crash?TestFlight .app和TestFlight .app.dsym三个文献放在团结个目次下，然后运行 symbolicatecrash?TestFlight.crash TestFlight.app.dsym>?TestFlight .log，检察TestFlight.log文献的骨子

可以看出具体出现问题的逻辑代码是在阿谁文献的哪一转，这么就凭证贯通出来的指定函数来定位crash的发生原因。

3.2 atos治安

atos是一个BSD平台的通用指示，通过它可以将数字地址调遣为对应的二进制映像或者进度的象征，通过该指示进行象征化贯通的时代需要讲解极少的是唯独当.app文献、crash文献和.app.dsym文献三者的UUID都是一致的时代，该crash文献能力被正确贯通，不然贯通失败。（注：uuid是app诈欺在迁徙建设上的唯独绚丽）可以通过以下阵势来检察.app和.app.dsym文献的uuid

由此可见armv7架构下三者保执一致，都是4a42d422a466338aa56e88840b74de3d，那接下来首先进行象征化贯通。

从上文crash日记文献的线程回溯可以发现闪退时函数的回溯列内外阵势不是都备一致，比如下图中的阵势1和阵势2在第2列的抒发阵势上不太相通，阵势1是用的库函数名，阵势2则是一个基土产货址。其实这两种阵势都可以用一种通用的贯通阵势来贬责：

最初计较加载地址（load address):

以阵势1中的0x333d8049 UIApplicationMain + 1137 为例，这一帧对应的 load address=0x333d8049 -1137=0x333d7bd8

也即是UIApplicationMain的地址是0x333df12；阵势2的0x00068b19 0x36000 + 207641，通过上述阵势的计较即是load address=0x00068b19 -207641=0x36000 ，可以发现后果与第二列的值是调换的，也即是它的加载地址即是第二列的值0x36000? 然后用xcrun atos -arch armv7 -o TestFlight.app/TestFlight? 0x36000 0x00068b19 的指示来贯通crash日记线程0和线程3中带有TestFlight模块的地址，后果发现TestFlight门径的代码回溯过程

可以看出base

address(基地址）是4000，函数的回溯过程是main.m文献的第16行的某个函数出现问题，然后该函数在逻辑调用中会调用到AFURLConnnectionOperation.m文献的第162行的某个函数，这个逻辑的调用与第一种治安贯通的TestFlight.log文献作对比,crash的贯通都备一致，由此就可以定位到crash的原因所在，接下往还解决crash文献也就水到渠成了。

四．小结

以上是凭证我方的教授和清爽对iOS平台下的crash问题（包括旨趣、网罗妥协析过程）进行的一次瓦解，诚然苹果的沙盒系统对iOS平台的下的好多诈欺信息的索要有较多的限制，然则要肯定治安总比问题多。对于crash问题的清爽和网罗过程可以很好地扶直表情组来擢升项贪图质地，同期对于更深远地清爽iOS平台常识和crash旨趣有很好的匡助。天然，本文更多的波及iOS平台下的crash问题，对于Android平台的crash问题波及较少。诚然细节的达成上可能有各别开yun体育网，然则里面的旨趣逻辑应该是调换或者相似的，后续笔者还将链接怜惜对于Android平台干系问题的调研学习。