位置: 编程技术 - 正文
推荐整理分享手游频繁崩溃”闪退”? 从程序上找原因(手游频繁崩溃怎么解决),希望有所帮助,仅作参考,欢迎阅读内容。
文章相关热门搜索词:手游频繁崩溃怎么回事,手游一直闪退什么原因,手游频繁崩溃怎么回事,手游频繁崩溃怎么解决,手游频繁崩溃怎么解决,手游频繁崩溃怎么回事,手游频繁崩溃怎么回事,手游频繁崩溃怎么办,内容如对您有帮助,希望把文章链接给更多的朋友!
(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文件都可以导出来,然后再单独对这个crash文件做处理分析。 以上这些是针对能够拿到真机设备的情况下才能收集crash日志的。如果是针对玩家的话,当App在玩家的设备上crash的时候如何收集呢。先来看下市场上已有的商业软件提供crash收集服务,他们这些软件基本都提供了日志存储,日志符号化解析和服务端可视化管理等服务: Crashlytics (www.crashlytics.com) Crittercism (www.crittercism.com) Bugsense (www.bugsense.com) TestFlight (www.testflightapp.com) HockeyApp (www.hockeyapp.net) Flurry(www.flurry.com) 具体这些商业软件有哪些优缺点,有人做了如下统计: 除了上述所说的这些商业软件外,还有一些开源的软件也可以拿来收集crash日志,比如Razor,QuincyKit(git链接)等,这些软件收集crash的原理其实大同小异,都是根据系统产生的crash日志进行了一次提取或封装,然后将封装后的crash文件上传到对应的服务端进行解析处理。很多商业软件都采用了Plcrashreporter这个开源工具来上传和解析crash,比如HockeyApp,Flurry和crittercism等,下图是笔者利用这一开源框架制作的一个收集crash的样例。 通过这种方式就可以很好的支持开发人员收集crash日志的需求,进而定位和解决App产品存在的问题。如果有需要或者感兴趣的可以深入的调研一下。 但是有个很重要的问题就是这种方式只能收集游戏引擎层(c或object c代码)的逻辑,如果是脚本逻辑问题产生的crash就无能无力了。而现在手游项目基本都是引擎(cocos2dx或Neox)脚本(lua或javascript)的开发模式,几乎所有的业务逻辑都在脚本层,游戏App时常发生的crash几乎都是由脚本逻辑bug导致的,这该怎么处理呢?平时在开发阶段,程序童鞋在Debug模式下开通了客户端运行日志功能,当出现crash或者traceback等问题的时候直接去查看log文件的输出即可知道原因了,但是在Release模式下一切log输出均被屏蔽,逻辑运行的log消息输出也就无法查看了。这种情况该又该如何处理呢?方法总比问题多,iOS/Android系统提供了异常发生时的处理API,只需要在程序启动的地方加入对应的处理逻辑,当异常发生时就可以触发对应的回调函数将必要的信息进行处理上传,适时地反馈给开发组。比如,下图是某项目组在iOS平台收集crash的一个截图: 其实,它具体的实现原理是这样的:首先,在游戏应用程序启动的地方需要开启异常处理逻辑的handler: 最后需要当crash发生时,需要调用的回调函数处理具体如下: 这样在当玩家在Release游戏版本中出现逻辑异常导致crash时,就会把对应的脚本层的异常(traceback或error等)以类dump文件的形式发送到指定的服务端,方便运营维护人员进行快速定位分析。这些脚本层异常日志收集后的显示效果如下: 以具体某一个异常日志文件为例,具体上传的内容如下图。这是一种直接可读的文本,里面记录着crash发生时代码逻辑的traceback,通过阅读代码逻辑就可以直接定位到或推断导致crash标签: 手游频繁崩溃怎么解决
本文链接地址:https://www.jiuchutong.com/biancheng/372809.html 转载请保留说明!友情链接: 武汉网站建设