Question

基督复活（复活节盛宴的喜悦）！
在小型应用程序重构后测试应用程序时，我收到了一个＆＃34; Crashlytics＆＃34;崩溃日志。试图通过将所有下一次调用（从第二次调用开始）发送到专用串行队列来尝试更改模型以避免双同步方法调用（同时）。我添加了以下代码：

@interface SynchronizationModel ()

@property (nonatomic) dispatch_queue_t synchronizationQueue;

@end

@implementation SynchronizationModel

BOOL isSynchronizationNotCalled = YES;

#pragma mark - Synchronization

+ (dispatch_queue_t)synchronizationQueue {
    static dispatch_queue_t queue;
    static dispatch_once_t onceToken;
    const char *queueID = "com.app.synchronizationModel.queue";

    dispatch_once(&onceToken, ^{
        queue = dispatch_queue_create(queueID, DISPATCH_QUEUE_SERIAL);

    });

    return queue;
}

+ (void)sychronizeOfflineObjects {
    if (isSynchronizationNotCalled) {
        NSLog(@"%d synchronization without a queue, flag notCalled =", isSynchronizationNotCalled);
        isSynchronizationNotCalled = NO;
        [self synchronizeOfflineObjectsNonAsynchronous];
    } else {
        NSLog(@"%d synchronization inside of a queue, flag notCalled =", isSynchronizationNotCalled);
        isSynchronizationNotCalled = NO;
        __weak typeof(self)weakSelf = self;
        dispatch_async(self.synchronizationQueue, ^{
            __strong typeof(weakSelf)strongSelf = weakSelf;
            [strongSelf synchronizeOfflineObjectsNonAsynchronous];
        });
    }
//  [self sychronizeOfflineObjects]; - uncomment for recursive test
    isSynchronizationNotCalled = YES;
    }

如您所见，使用递归调用对其进行测试。它确实有效。但有机会尝试亲自在设备上运行该应用程序。
在极少数地方调用此方法。主要是在一个明显的控制器中：

- (IBAction)buttonWasTapped:(id)sender {
    if(self.buttonImage.layer.animationKeys.count == 0){
        [self synchronizationMethod];
    }
}

- (void)synchronizationMethod {
    NSLog(@"startWorkWithServer - originally here is some code but it works perfect");
        [SynchronzationModel sychronizeOfflineObjects];
    } else {
        [self startAnimation];
        [self performSelector:@selector(delayStop) withObject:nil afterDelay:2.0];
        if([webConnectionAllowed isEqualToString:@"NotAllowed"]){ 
            [self showAlertWithTitle:nil message:NSLocalizedString(@"Connection is allowed", nil)];
        }
    }
}

已将应用程序发送给我的团队主管以进行结帐。他已经在一个设备上启动了一个应用程序但是在一瞬间（猜测它已经工作了一段时间）它被拒绝了SIGABRT错误消息。

Crashlytics报告返回：

#0. Crashed: com.twitter.crashlytics.ios.exception
0  App                            0x18751d CLSProcessRecordAllThreads + 820509
1  App                            0x18751d CLSProcessRecordAllThreads + 820509
2  App                            0x187415 CLSProcessRecordAllThreads + 820245
3  App                            0x17b34f CLSHandler + 770895
4  App                            0x185dfb __CLSExceptionRecord_block_invoke + 814587
5  libdispatch.dylib              0x1c942083 _dispatch_client_callout + 22
6  libdispatch.dylib              0x1c94e33b _dispatch_barrier_sync_f_invoke + 50
7  App                            0x1857fd CLSExceptionRecord + 813053
8  App                            0x185625 CLSExceptionRecordNSException + 812581
9  App                            0x18513b CLSTerminateHandler() + 811323
10 libc++abi.dylib                0x1c4f393f std::__terminate(void (*)()) + 78
11 libc++abi.dylib                0x1c4f3443 __cxa_rethrow + 90
12 libobjc.A.dylib                0x1c4ff1bb objc_exception_rethrow + 42
13 CoreFoundation                 0x1d1a55a1 CFRunLoopRunSpecific + 596
14 CoreFoundation                 0x1d1a5341 CFRunLoopRunInMode + 104
15 GraphicsServices               0x1e97cbfd GSEventRunModal + 156
16 UIKit                          0x223b3e27 -[UIApplication _run] + 574
17 UIKit                          0x223ae551 UIApplicationMain + 150
18 App                            0x148daf main (main.m:14)
19 libdispatch.dylib              0x1c96f50b (Missing)

但至少我没有dSYM文件（只有Crashlytics的.txt），我没有明显的方法来表示崩溃日志或了解导致问题的原因。要在我的设备上测试它，但不确定它是否会崩溃。

看起来线程发生了什么，但我不确定究竟是什么线索。有人可以建议如何找出造成问题的地方。

还有一个补充：有一些人正在处理一个项目（我对它很新）我甚至不确定上面的代码是否已经打开错误（但很可能）或者它是甚至在我的变化发生之前。我刚刚给出了一个小方法，通常是第一次调用方法，并且所有其余的调用同时发送到专用串行队列。由于它是递归工作的，这是一个非常小的变化，只使用一个额外的私有串行队列，它让我感到困惑，对于真正的崩溃来说似乎有点小（在报告中有线程问题）。

非常感谢任何建议。

Answer 1

似乎我应该在这里使用正确的修饰符。添加＆＃34; strong＆＃34;到synchronizationQueue属性解决了这个问题。

这篇文章有助于找到解决方案。

What property should I use for a Dispatch Queue after ARC?

在ARC之前，队列过去被视为非对象类型，因此＆＃34;分配＆＃34;走了很长的路。将它留空将会有效，因为它是非对象类型的默认修饰符。

在引入ARC之后，队列被视为和Objective-c对象一样，我们应该使用＆＃34; strong＆＃34;跟他们。值得一提的是，＆＃34;强大的＆＃34; now是Objective-c对象的默认属性属性，仍然不确定为什么它在上面给出的情况下没有解决。

如何找出导致IOS设备错误崩溃报告的原因？

1 个答案: