7040人阅读
iOS开发（97）
一：给大家介绍一款简单高效的应用崩溃收集方法：腾讯Bugly
腾讯 Bugly，是腾讯公司为移动开发者开放的服务之一，面向移动开发者提供专业的 Crash 监控、崩溃分析等质量跟踪服务。Bugly 能帮助移动互联网开发者更及时地发现掌控异常，更全面的了解定位异常，更高效的修复解决异常。
针对移动应用，腾讯 Bugly 提供了专业的 Crash、Android ANR ( application not response)、iOS 卡顿监控和解决方案。移动开发者 ( Android / iOS ) 可以通过监控，快速发现用户在使用过程中出现的 Crash (崩溃)、Android ANR 和 iOS 卡顿，并根据上报的信息快速定位和解决问题。
移动互联网时代，由于设备的碎片化，客服人员每天要接到很多用户反馈在各种不同机型上的崩溃问题，又没有办法提供具体的 Crash 日志给开发人员。测试人员每天需要对用户的反馈进行 Bug 复现，然后抓取log 日志，人力成本，手机终端成本非常高，造成很多资源浪费。
腾讯无线研发部发现该问题后，开始开发这套 Crash 监控上报体系。经过了四年多的开发与打磨，目前腾讯的所有产品都已经接入了Bugly质量监控平台，开发同学只要登陆 Bugly 网站，就可以清晰的看到每天自己的产品有多少 Crash，影响了多少用户的使用，并可以根据 Bugly 提供的 Crash 日志进行问题修复，极大的提高了工作效率。
2011年初- 2014年10月 Bugly 服务于腾讯内部所有项目，如QQ邮箱、浏览器、手机QQ、腾讯视频等。
2014年10月起，腾讯 Bugly 对外开放给更多的开发者使用，帮助开发人员更准确高效的定位解决问题。
对产生的问题进行24小时的监控，把握崩溃前后的各个时间节点。Bugly 目前支持 iOS 和 Android 两大主流平台的崩溃分析上报，包括iOS的不同开发语言（Object-C 以及 Swift）, 并支持 Android 操作系统的 java 层和 NDK 层全面的崩溃上报。符号还原功能可以帮助开发者定位到具体错误的代码，帮助开发者快速定位问题，修改问题。
Bugly 还支持了不同游戏引擎的脚本层错误上报，对于使用 Cocos 以及 Unity 引擎进行开发的游戏，Bugly的代码还原可以帮助开发这定位到引擎脚本的堆栈，包括 Cocos 的 Lua 脚本，C++ 脚本，以及 Unity 的 C# 脚本。
Android / iOS 游戏
支持 Untily 游戏引擎的脚本错误上报、支持 Cocos 游戏引擎的Lua脚本错误上报、Android NDK 错误上报、Android 和 iOS 64 位系统支持、Android全架构支持、Android 系统的 ANR 以及 iOS 系统的卡顿上报、实时上报问题、适配最新官方系统、精准问题定位、自定义 log 上报、监控、统计功能、智能合并分析。
Android&应用
NDK 支持、全架构 / 64位系统支持、应用 ANR 上报、实时上报问题、自定义 log 上报、精准问题定位、适配最新官方系统监控、统计功能、智能合并分析。
语言支持 Swift & Object-C、支持 iOS 手表、支持 64位系统、应用卡顿上报、适配最新官方系统、精准问题定位以及全面的问题上报、自定义 log 上报、实时上报问题、监控、统计功能、进行智能合并分析。
Bugly 经过腾讯内部4年打磨，目前腾讯所有产品都在使用，其适配性基本覆盖了中国市场的移动设备以及网络环境，可靠性有保证。使用 Bugly，就等于使用了和手机 QQ、QQ 空间、手机管家相同的质量保障途径，Bugly 会持续对产品进行优化打磨，帮助更多的开发者打造更有品质的产品。
二：iOS集成
（1）iOS集成先把Bugly的SDK导入工程中，可以使用QQ帐号登录Bugly官网下载解压手动导入，也可以使用CocoPods命令导入。
（2）使用QQ帐号登录Bugly官网注册应用
(3)获得Appid，这个Appid是上一步注册应用时Bugly官方自动生成的，所有使用Bugly的应用中每个应用的Appid唯一。点击帐号信息------&点击我的App-------&点击注册的应用名称，即可看到该应用的Appid。
（3）在AppDelegate.m中导入#import&&Bugly/Bugly.h&，在启动完成方法中初始化Bugly，Appid就是上一步我们得到的Appid。
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
// Override point for customization after application launch.
//Bugly初始化方法
[Bugly startWithAppId:@&&];
return YES;
三 ：此时便可以对应用崩溃日志进行搜集，崩溃日志会上传到Bugly官网服务器，我们使用QQ号登录Bugly官网就可以查看。
我做了两个崩溃测试，一个是数组越界，一个是按钮绑定方法没有实现，代码如下：
ViewController.m
Created by fe on 16/7/13.
Copyright © 2016年 fe. All rights reserved.
#import &ViewController.h&
@interface ViewController ()
@implementation ViewController
- (void)viewDidLoad {
[super viewDidLoad];
//数组越界的错误测试
[self arryTest];
//定义方法没有实现的错误测试
[self methodTest];
//数组越界的错误测试
-(void)arryTest
NSArray *testArry = @[@&1&,@&2&,@&3&];
NSString *testStr = testArry[3];
NSLog(@&%@&,testStr);
//定义方法没有实现的错误测试
-(void)methodTest
UIButton *testButton = [UIButton buttonWithType:UIButtonTypeContactAdd];
testButton.center = self.view.
[testButton addTarget:self action:@selector(buttonClick) forControlEvents:UIControlEventTouchUpInside];
[self.view addSubview:testButton];
收集到的日志信息如下：
总结：总体来说Bugly还是很方便，很实用，很高效的，可以有效的搜集崩溃日志，优化应用。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：74197次
积分：1791
积分：1791
排名：千里之外
原创：97篇
转载：69篇
(1)(1)(4)(1)(1)(10)(19)(24)(7)(10)(4)(11)(14)(3)(6)(1)(20)(11)(11)(7)
(window.slotbydup = window.slotbydup || []).push({
id: '4740887',
container: s,
size: '250,250',
display: 'inlay-fix'漫谈iOS Crash收集框架
招聘信息：
本文由作者
授权转载。为了能够第一时间发现程序问题，应用程序需要实现自己的崩溃日志收集服务，成熟的开源项目很多，如 ，， 等。追求方便省心，对于保密性要求不高的程序来说，也可以选择各种一条龙Crash统计产品，如 ， ，， 等等。是否集成越多的Crash日志收集服务就越保险？自己收集的Crash日志和系统生成的Crash日志有分歧，应该相信谁？为什么有大量Crash日志显示崩在main函数里,但函数栈中却没有一行自己的代码？野指针类的Crash难定位，有何妙招来应对？想解释清这些问题，必须从Mach异常说起。Mach异常与Unix信号iOS系统自带的 Apple’s Crash Reporter 记录在设备中的Crash日志，Exception Type项通常会包含两个元素： Mach异常 和 Unix信号。Exception&Type:&&&&&&&&&EXC_BAD_ACCESS&(SIGSEGV)&&&&
Exception&Subtype:&&&&&&KERN_INVALID_ADDRESS&at&0x041a6f3Mach异常是什么？它又是如何与Unix信号建立联系的？Mach是一个XNU的微内核核心，Mach异常是指最底层的内核级异常，被定义在下 。每个thread，task，host都有一个异常端口数组，Mach的部分API暴露给了用户态，用户态的开发者可以直接通过Mach API设置thread，task，host的异常端口，来捕获Mach异常，抓取Crash事件。所有Mach异常都在host层被ux_exception转换为相应的Unix信号，并通过threadsignal将信号投递到出错的线程。iOS中的 POSIX API 就是通过 Mach 之上的 BSD 层实现的。因此，EXC_BAD_ACCESS (SIGSEGV)表示的意思是：Mach层的EXC_BAD_ACCESS异常，在host层被转换成SIGSEGV信号投递到出错的线程。既然最终以信号的方式投递到出错的线程，那么就可以通过注册signalHandler来捕获信号:signal(SIGSEGV,signalHandler);捕获Mach异常或者Unix信号都可以抓到crash事件，这两种方式哪个更好呢？&优选Mach异常，因为Mach异常处理会先于Unix信号处理发生，如果Mach异常的handler让程序exit了，那么Unix信号就永远不会到达这个进程了。转换Unix信号是为了兼容更为流行的POSIX标准(SUS规范)，这样不必了解Mach内核也可以通过Unix信号的方式来兼容开发。小贴士:因为硬件产生的信号(通过CPU陷阱)被Mach层捕获，然后才转换为对应的Unix信号；苹果为了统一机制，于是操作系统和用户产生的信号(通过调用kill和pthread_kill)也首先沉下来被转换为Mach异常，再转换为Unix信号。Crash收集的实现思路正如上述所说，可以通过捕获Mach异常、或Unix信号两种方式来抓取crash事件，于是总结起来实现方案就一共有3种。1）Mach异常方式2）Unix信号方式signal(SIGSEGV,signalHandler);3）Mach异常+Unix信号方式Github上多数开源项目都采用的这种方式，即使在优选捕获Mach异常的情况下，也放弃捕获EXC_CRASH异常，而选择捕获与之对应的SIGABRT信号。著名开源项目在代码注释中给出了详细的解释：We&still&need&to&use&signal&handlers&to&catch&SIGABRT&in-process.&The&kernel&sends&an&EXC_CRASH&mach&exception&to&denote&SIGABRT&termination.&In&that&case,&catching&the&Mach&exception&in-process&leads&to&process&deadlock&in&an&uninterruptable&wait.&Thus,&we&fall&back&on&BSD&signal&handlers&for&SIGABRT,&and&do&not&register&for&EXC_CRASH.另外，需要重点说明的是：对于应用级异常NSException，还需要特殊处理。你是否见过崩溃在main函数的crash日志，但是函数栈里面没有你的代码：Thread&0&Crashed:
0&&&&&&&libsystem_kernel.dylib&&&&&&&&&&0x3a61757c&&&__semwait_signal_nocancel&+&0x18
1&&&&&&&libsystem_c.dylib&&&&&&&&&&&&&&&0x3a592a7c&&&nanosleep$NOCANCEL&+&0xa0
2&&&&&&&libsystem_c.dylib&&&&&&&&&&&&&&&0x3a5adede&&&usleep$NOCANCEL&+&0x2e
3&&&&&&&libsystem_c.dylib&&&&&&&&&&&&&&&0x3a5c7fe0&&&abort&+&0x50
4&&&&&&&libc++abi.dylib&&&&&&&&&&&&&&&&&0x398f6cd2&&&abort_message&+&0x46
5&&&&&&&libc++abi.dylib&&&&&&&&&&&&&&&&&0x&&&default_terminate_handler()&+&0xf8
6&&&&&&&libobjc.A.dylib&&&&&&&&&&&&&&&&&0x3a054f62&&&_objc_terminate()&+&0xbe
7&&&&&&&libc++abi.dylib&&&&&&&&&&&&&&&&&0x&&&std::__terminate(void&(*)())&+&0x4c
8&&&&&&&libc++abi.dylib&&&&&&&&&&&&&&&&&0x3990cd28&&&__cxa_rethrow&+&0x60
9&&&&&&&libobjc.A.dylib&&&&&&&&&&&&&&&&&0x3a054e12&&&objc_exception_rethrow&+&0x26
10&&&&&&CoreFoundation&&&&&&&&&&&&&&&&&&0x2f7d7f30&&&CFRunLoopRunSpecific&+&0x27c
11&&&&&&CoreFoundation&&&&&&&&&&&&&&&&&&0x2f7d7c9e&&&CFRunLoopRunInMode&+&0x66
12&&&&&&GraphicsServices&&&&&&&&&&&&&&&&0x346dd65e&&&GSEventRunModal&+&0x86
13&&&&&&UIKit&&&&&&&&&&&&&&&&&&&&&&&&&&&0x&&&UIApplicationMain&+&0x46c
14&&&&&&XXXXXX&&&&&&&&&&&&&&&&&&&&&&&&&&0x&&&main&+&0x1f2
15&&&&&&libdyld.dylib&&&&&&&&&&&&&&&&&&&0x3a561ab4&&&start&+&0x0可以看出是因为某个NSException导致程序Crash的，只有拿到这个NSException，获取它的reason，name，callStackSymbols信息才能确定出问题的程序位置。/*&NSException&Class&Reference&*/
@property(readonly,&copy)&NSString&*&&
@property(readonly,&copy)&NSString&*
@property(readonly,&copy)&NSArray&*callStackS
@property(readonly,&copy)&NSArray&*callStackReturnA方法很简单，可通过注册NSUncaughtExceptionHandler捕获异常信息:static&void&my_uncaught_exception_handler&(NSException&*exception)&{
&&&&//这里可以取到&NSException&信息
NSSetUncaughtExceptionHandler(&my_uncaught_exception_handler);将拿到的NSException细节写入Crash日志，精准的定位出错程序位置：Application&Specific&Information:
***&Terminating&app&due&to&uncaught&exception&'NSUnknownKeyException',&reason:&'[&setValue:forUndefinedKey:]:&this&class&is&not&key&value&coding-compliant&for&the&key&key.'
Last&Exception&Backtrace:
0&CoreFoundation&0x2f8a3f7e&&&&&__exceptionPreprocess&+&0x7e
1&libobjc.A.dylib&0x3a054cc&&&&&objc_exception_throw&+&0x22
2&CoreFoundation&0x2f8a3c94&&&&&-[NSException&raise]&+&0x4
3&Foundation&0x301e8f1e&&&&&&&&&-[NSObject(NSKeyValueCoding)&setValue:forKey:]&+&0xc6
4&DemoCrash&0x&&&&&&&&&&-[ViewController&crashMethod]&+&0x6e
5&DemoCrash&0x00084ecc&&&&&&&&&&main&+&0x1cc
6&DemoCrash&0x00084cf8&&&&&&&&&&start&+&0x24那么，是不是收到了大量crash在main函数却没有NSException信息的日志，就代表自己集成的Crash日志收集服务没有注册NSUncaughtExceptionHandler呢？不一定，还有另外一种可能，就是被同时存在的其他Crash日志收集服务给坑了。多个Crash日志收集服务共存的坑是的，在自己的程序里集成多个Crash日志收集服务实在不是明智之举。通常情况下，第三方功能性SDK都会集成一个Crash收集服务，以及时发现自己SDK的问题。当各家的服务都以保证自己的Crash统计正确完整为目的时，难免出现时序手脚，强行覆盖等等的恶意竞争，总会有人默默被坑。1）拒绝传递 UncaughtExceptionHandler如果同时有多方通过NSSetUncaughtExceptionHandler注册异常处理程序，和平的作法是：后注册者通过NSGetUncaughtExceptionHandler将先前别人注册的handler取出并备份，在自己handler处理完后自觉把别人的handler注册回去，规规矩矩的传递。不传递强行覆盖的后果是，在其之前注册过的日志收集服务写出的Crash日志就会因为取不到NSException而丢失Last Exception Backtrace等信息。（P.S. iOS系统自带的Crash Reporter不受影响）在开发测试阶段，可以利用
框架去hookNSSetUncaughtExceptionHandler方法，这样就可以清晰的看到handler的传递流程断在哪里，快速定位污染环境者。不推荐利用调试器添加符号断点来检查，原因是一些Crash收集框架在调试状态下是不工作的。检测代码示例：static&NSUncaughtExceptionHandler&*g_vaildUncaughtExceptionH
static&void&(*ori_NSSetUncaughtExceptionHandler)(&NSUncaughtExceptionHandler&*&);
void&my_NSSetUncaughtExceptionHandler(&NSUncaughtExceptionHandler&*&handler)
&&&&g_vaildUncaughtExceptionHandler&=&NSGetUncaughtExceptionHandler();
&&&&if&(g_vaildUncaughtExceptionHandler&!=&NULL)&{
&&&&&&&&NSLog(@"UncaughtExceptionHandler=%p",g_vaildUncaughtExceptionHandler);
&&&&ori_NSSetUncaughtExceptionHandler(handler);
&&&&NSLog(@"%@",[NSThread&callStackSymbols]);
&&&&g_vaildUncaughtExceptionHandler&=&NSGetUncaughtExceptionHandler();
&&&&NSLog(@"UncaughtExceptionHandler=%p",g_vaildUncaughtExceptionHandler);
}对于越狱插件注入应用进程内部，恶意覆盖NSSetUncaughtExceptionHandler的情况，应用程序本身处理起来比较弱势，因为越狱环境下操作时序的玩法比较多权利比较大。2）Mach异常端口换出+信号处理Handler覆盖和NSSetUncaughtExceptionHandler的情况类似，设置过的Mach异常端口和信号处理程序也有可能被干掉，导致无法捕获Crash事件。3）影响系统崩溃日志准确性应用层参与收集Crash日志的服务方越多，越有可能影响iOS系统自带的Crash Reporter。由于进程内线程数组的变动，可能会导致系统日志中线程的Crashed 标签标记错位，可以搜索abort()等关键字来复查系统日志的准确性。若程序因NSException而Crash，系统日志中的Last Exception Backtrace信息是完整准确的，不会受应用层的胡来而影响，可作为排查问题的参考线索。ObjC野指针类的Crash收集Crash日志这个步骤没有问题的情况下，还是有很多全系统栈的日志的情况，没有自己一行代码，分析起来十分棘手，ObjC野指针类的Crash正是如此，这里推荐几篇好文章：除此之外，在Crash日志中补充记录一些额外信息可以辅助定位，如切面标记线程出处、队列出处，记录用户操作轨迹等等……版权申明：本文在微信公众平台的发表权，已「独家代理」给 iOS 开发（iOSDevTips）微信公共帐号。
微信扫一扫
订阅每日移动开发及APP推广热点资讯公众号：CocoaChina
您还没有登录！请或
点击量4857点击量4718点击量4558点击量4394点击量3665点击量3567点击量3523点击量3324点击量3261
&2016 Chukong Technologies,Inc.
京公网安备89和其他开发者一起互动，更多惊喜等着你！
当前位置：
企业(个人)名称：
平台模式：
平台支持：
授权方式：
开发语言：
更新时间：
Bugly是腾讯内部产品质量监控平台的外发版本，其主要功能是App发布以后，对用户侧发生的crash以及卡顿现象进行监控并上报，让开发同学可以第一时间了解到app的质量情况，及时机型修改。目前腾讯内部所有的产品，均在使用其进行线上产品的崩溃监控。
1、全平台支持：目前支持iOS和Android两大主流平台的崩溃分析上报，包括iOS的不同开发语言（OC以及Swift）,&并支持Android操作系统的java层和NDK层全面的崩溃上报。同时，我们还对rm64-v8a、armeabi、armeabi-v7a、x86、x86_64等不同的架构进行了适配，不管用户的手机是什么架构，都可以完整的上报crash信息，并进行代码还原。2、游戏深度支持：对于使用Cocos以及U3D引擎进行开发的游戏，我们的代码还原可以帮助开发这定位到引擎脚本的堆栈，包括Cocos的lua脚本，C++脚本，以及U3D的C#脚本。3、实时、准确、完整的数据：依托腾讯强大的IDC，无论App的使用用户在国内还是海外，可以在用户发生Crash后，实时上报到系统平台，并提供完成的Crash堆栈数据和发生问题的机型详细数据：有哪些机型发生了这个问题，机型的sdk版本号分布，内存以及硬盘剩余占比，是否root以及发生问题时其他线程的日志和系统Logcat的日志信息。开发者可以实时查看应用的质量情况，尤其是在刚上线的前半个小时，快速了解应用质量。4、监控、统计功能：用户可以根据自身业务的需求设置告警阀值，当单位时间内Crash数量超过阀值后，用户可以第一时间收到微信告警。同时，日报以及周报会把影响用户数量最多的问题Highlight出来，方便开发者对主要的问题进行快速修改。5、智能合并分析：通过对腾讯现有产品的海量Crash数据进行分析，完成精准的合并算法，帮助开发者把同一根因引起的crash进行合并，开发同学不需要重复分析同一根因引起的Crash。Bugly经过腾讯内部4年打磨，目前腾讯所有产品都在使用，其适配性基本覆盖了中国市场的移动设备以及网络环境，可靠性有保证。使用Bugly，就等于您使用了和手机QQ、QQ空间、手机管家相同的质量保障途径，Bugly会持续对产品进行优化打磨，帮助更多的开发者打造更有品质的产品。
Copyright @ 2005- 京ICP证060544号 版权所有 未经许可 请勿转载登录以解锁更多InfoQ新功能
获取更新并接收通知
给您喜爱的内容点赞
关注您喜爱的编辑与同行
966,690 九月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
iOS开发工具——统计Crash的工具Crashlytics
iOS开发工具——统计Crash的工具Crashlytics
5&他的粉丝
日. 估计阅读时间:
硅谷人工智能、机器学习、互联网金融、未来移动技术架构 ，
相关厂商内容
相关赞助商
1、Crashlytics不会漏掉任何应用崩溃信息。拿我的应用举例来说，在iTunes Connect的后台查看不到任何崩溃信息。但是用户确实会通过微博或者客服电话反馈应用崩溃的情况。而这些在Crashlytics中都可以统计到。如下截图分别显示了我的某应用在苹果iTunes Connect后台和Crashlytics中的差别：
2、Crashlytics可以象Bug管理工具那样，管理这些崩溃日志。例如：Crashlytics会根据每种类型的Crash的出现频率以及影响的用户量来自动设置优先级。对于每种类型的Crash，Crashlytics除了会像一般的工具提供Call Stack外，还会显示更多相关的有助于诊断的信息，例如：设备是否越狱，当时的内存量，当时的iOS版本等。对于修复掉的Crash日志，可以在Crashlytics的后台将其关掉。下图所示的是一个我的早期应用的崩溃记录，在我修复后，我将其更新为已修复状态。
3、Crashlytics可以每天和每周将崩溃信息汇总发到你的邮箱，所有信息一目了然。
下面我就给大家介绍如何使用Crashlytics。
Crashlytics的服务是免费提供的，但是并不能直接注册使用，需要先申请，打开 ，输入自己的邮箱申请使用。如下图所示：
提交完邮箱之后，你的申请会放在Crashlytics的申请队列中，网页跳转到如下界面。在这个界面的右侧，你可以提供更多有效信息来让Crashlytics优先处理你的申请，建议大家都填上更多自己的信息。
如果顺利，通常1-2天左右，你就会收到Crashlytics发来的申请通过邮件，如下图所示，通过邮件链接跳转到注册界面，填写密码即可完成注册。
在使用Crashlytics前需要对原有的XCode工程进行配置，在这一点上，Crashlytics做得比其它任何我见过的SDK提供商都体贴。因为Crashlytics专门做了一个Mac端的App来帮助你进行配置，所以，在配置前你先需要去下载该应用。
应用下载后，运行该应用并登录帐号。然后选择应用中的&New App&按钮，然后选择自己要增加Crashlytics的工程，然后Crashlytics的应用会提示你为工程增加一个Run Script，如果你不知道如何添加，这里有一个。添加好之后的工程截图如下所示
接着，Crashlytics的本地应用会提示你将Crashlytics相关的framework拖到工程中。如下所示：
按照提示做完之后，就到了最后一步了，在AppDelegate的didFinishLaunchingWithOptions方法中加入如下代码：
#import &Crashlytics/Crashlytics.h&
- (BOOL)application:(UIApplication *)application
didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
[Crashlytics startWithAPIKey:@&your identify code&];
之后，运行一下程序，Crashlytics就会检测到你设置成功。如果你感兴趣，可以自己手工触发一个崩溃记录，看Crashlytics能否帮你收集到。使用如下代码即可
[[Crashlytics sharedInstance] crash];
如果你想测试一个Exception导致的崩溃，可以使用如下代码：
[NSObject doesNotRecognizeSelector];
[arrayWithOnlyTwoElements objectAtIndex:3];
应用对外发布后，就可以在Crashlytics后台查看和修改相关的记录。另外，Crashlytics还支持将数据导入到其它项目管理工具（例如Redmine或Jira）如下所示，配置都非常简单。
实现原理和使用体会
在原理上，Crashlytics的通过以下2步完成崩溃日志的上传和分析：
提供应用SDK，你需要在应用启动时调用其SDK来设置你的应用。SDK会集成到你的应用中，完成Crash信息的收集和上传。
修改工程的编译配置，加入一段代码，在你每次工程编译完成后，上传该工程对应的dSYM文件。研究过手工分析Crash日志的同学应该知道，只有通过该文件，才能将Crash日志还原成可读的Call Stack信息。
为了更加方便开发者设置相应的工程，Crashlytics提供了mac端的应用程序，帮助你检测相关工程是否正确设置并且提供相应的帮助信息。后来我还发现，该程序还会自动帮你升级Crashlytics的SDK文件。虽然这一点很体贴，但是我个人觉得还是不太友好。因为毕竟修改SDK会影响应用编译后的内部逻辑，在没有任何通知的情况下升级，我都无法确定Crashlytics有没有干坏事。不过国外的服务，特别是象Twitter这种相对较大知名度公司提供的服务要有节操得多，所以在这一点上我还是比较放心的。
使用Crashlytics可以让你摆脱管理应用崩溃记录的烦恼。并且帮助你找出应用的一些重大隐藏性Bug。例如我之前写的一个应用就过一个缓存过期的问题，只有当缓存过期时才会触发这个Bug，这样的问题在测试人员那边很难触发，因为他们不可能了解你的应用内部实现细节。通过Crashlytics，使我清楚了解到应用Crash的数量和位置，结合自己的开发经验，就很容易找到问题所在了。
值得一提的是，Crashlytics本身的也非常健全，如果你在使用中遇到任何问题，也可以上去查看详细的文档。
愿Crashlytics能让大家的应用都更加健壮～
感谢对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至。也欢迎大家通过新浪微博（）或者腾讯微博（）关注我们，并与我们的编辑和其他读者朋友交流。
Author Contacted
语言 & 开发
25 他的粉丝
架构 & 设计
176 他的粉丝
0 他的粉丝
61 他的粉丝
0 他的粉丝
12 他的粉丝
Crashlytics
0 他的粉丝
告诉我们您的想法
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
赞助商链接
InfoQ每周精要
订阅InfoQ每周精要，加入拥有25万多名资深开发者的庞大技术社区。
架构 & 设计
文化 & 方法
<及所有内容，版权所有 &#169;
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
找回密码....
InfoQ账号使用的E-mail
关注你最喜爱的话题和作者
快速浏览网站内你所感兴趣话题的精选内容。
内容自由定制
选择想要阅读的主题和喜爱的作者定制自己的新闻源。
设置通知机制以获取内容更新对您而言是否重要
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?
我们发现您在使用ad blocker。
我们理解您使用ad blocker的初衷，但为了保证InfoQ能够继续以免费方式为您服务，我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单，感谢您的理解与支持。