iOS 9后台定位崩溃问题

本文详细介绍了如何在iOS9及更高版本中实现后台定位功能,包括配置Info.plist文件、实例化定位管理器、设置代理、请求用户权限等关键步骤。

如果不适配iOS9,就不能偷偷在后台定位(不带蓝条,见图)!好消息:将允许出现这种场景:同一App中的多个location manager:一些只能在前台定位,另一些可在后台定位,并可随时开启或者关闭特定location manager的后台定位。


// 1. 实例化定位管理器
_locationManager = [[CLLocationManager alloc] init];
// 2. 设置代理
_locationManager.delegate = self;
// 3. 定位精度
[_locationManager setDesiredAccuracy:kCLLocationAccuracyBest];
// 4.请求用户权限:分为:?只在前台开启定位?在后台也可定位,
//注意:建议只请求?和?中的一个,如果两个权限都需要,只请求?即可,
//??这样的顺序,将导致bug:第一次启动程序后,系统将只请求?的权限,?的权限系统不会请求,只会在下一次启动应用时请求?
if ([[[UIDevice currentDevice] systemVersion] floatValue] >= 8) {
    //[_locationManager requestWhenInUseAuthorization];//?只在前台开启定位
    [_locationManager requestAlwaysAuthorization];//?在后台也可定位
}
// 5.iOS9新特性:将允许出现这种场景:同一app中多个location manager:一些只能在前台定位,另一些可在后台定位(并可随时禁止其后台定位)。
if ([[[UIDevice currentDevice] systemVersion] floatValue] >= 9) {
    _locationManager.allowsBackgroundLocationUpdates = YES;
}
// 6. 更新用户位置
[_locationManager startUpdatingLocation];


但是如果照着这种方式尝试,而没有配置Info.plist,100%你的程序会崩溃掉,并报错:

1
*** Assertion failure in -[CLLocationManager setAllowsBackgroundLocationUpdates:]


要将 Info.plist 配置如下:





<think>我们正在回答用户关于“如何使用Bugly在iOS平台上定位崩溃问题”的询问。根据用户提供的引用内容,我们需要整合信息并给出清晰的步骤。用户提供的引用[1]说明了如何触发一个Crash并查看Crashissue,引用[2]则详细说明了如何通过反向符号化来定位崩溃原因。因此,我们的回答应该包括两个主要部分:1.如何集成Bugly并触发Crash来上报崩溃信息(简要提及,因为用户可能已经完成集成,重点在定位)。2.如何通过Bugly上报的崩溃日志进行反向符号化以定位崩溃的源代码位置。注意:用户的问题集中在定位崩溃的方法和步骤,所以重点在第二部分。根据引用[2],反向符号化的步骤需要dSYM文件,并且需要执行终端命令。我们将详细描述这些步骤。另外,我们还需要生成相关问题,以帮助用户深入了解。回答结构:1.引言:简述Bugly在崩溃定位中的作用。2.步骤一:在Bugly控制台查看崩溃报告(包括堆栈信息)。3.步骤二:准备反向符号化所需的材料(dSYM文件、崩溃日志中的基地址和地址)。4.步骤三:使用atos命令进行反向符号化。5.步骤四:解释结果,定位代码行。6.注意事项:如dSYM文件的管理等。最后,生成相关问题。注意:由于用户提供的引用内容中已经包含了具体的命令和步骤,我们直接整理并清晰表述即可。</think>### iOS Bugly 定位崩溃的方法和步骤 在 iOS 平台使用 Bugly 定位崩溃问题主要分为两个阶段:**崩溃上报**和**符号化解析**。以下是详细操作流程: #### 一、崩溃上报阶段 1. **集成 Bugly SDK** 在 AppDelegate 中初始化 Bugly(需提前在 Bugly 官网创建应用获取 AppID): ```swift func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool { Bugly.start(withAppId: "YOUR_APP_ID") return true } ``` 2. **触发崩溃测试**(可选) 添加测试代码模拟崩溃(正式环境需移除): ```swift @IBAction func triggerCrash(_ sender: UIButton) { let array = [0] _ = array[1] // 故意触发数组越界崩溃 } ``` 崩溃后 10 秒内可在 [Bugly 控制台](https://bugly.qq.com/) 的「崩溃」页面查看原始报告[^1]。 --- #### 二、符号化解析阶段(关键步骤) 崩溃日志中的地址需要反向符号化才能定位到源代码,需准备: - **dSYM 文件**:Xcode 编译生成的调试符号文件(位于 `~/Library/Developer/Xcode/Archives`) - **崩溃日志中的关键信息**:内存基地址(Image Base Address)和崩溃地址(Crash Address) **操作流程**: 1. **获取崩溃地址信息** 在 Bugly 崩溃详情页的「堆栈跟踪」中找到类似: ``` 0 CoreFoundation 0x000000018d3e3d98 0x18d2c0000 + 0x123d98 ↑ 模块名 ↑ 崩溃地址 ↑ 内存基地址 ``` 2. **终端执行符号化命令** ```bash cd /Applications/Xcode.app/Contents/Developer ./usr/bin/atos -o [dSYM文件路径]/Contents/Resources/DWARF/[应用名] \ -l [内存基地址] [崩溃地址] ``` **示例**: ```bash ./usr/bin/atos -o ~/Desktop/YourApp.dSYM/Contents/Resources/DWARF/YourApp \ -l 0x18d2c0000 0x000000018d3e3d98 ``` 3. **解析结果** 成功执行后将输出源码位置: ``` -[ViewController triggerCrash:] (in YourApp) (ViewController.swift:25) ``` 表示崩溃发生在 `ViewController.swift` 第 25 行[^2]。 --- #### 注意事项 1. **dSYM 文件匹配** - 必须使用**对应版本编译生成的 dSYM**(UUID 需与崩溃日志一致) - 可在终端验证 UUID:`dwarfdump --uuid YourApp.dSYM` 2. **自动化方案** - 在 Bugly 控制台上传 dSYM 文件(「符号表管理」>「上传」),后续崩溃会自动符号化 - 或通过 CI 脚本自动上传: ```bash curl -k "https://api.bugly.qq.com/openapi/file/upload/symbol?app_key=KEY&app_id=ID" \ --form "api_version=1" \ --form "app_id=APP_ID" \ --form "symbolType=2" \ --form "bundleId=com.your.bundle" \ --form "fileName=your_app.dSYM.zip" \ --form "file=@your_app.dSYM.zip" ``` 3. **调试技巧** - 开发阶段开启 Xcode 的 **Exception Breakpoint** 实时捕获崩溃 - 真机测试时连接 Xcode → **Window → Devices and Simulators** 查看设备日志 > **关键原理**:dSYM 文件将机器码地址映射到源代码位置,反向符号化是定位崩溃的必要步骤[^2]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值