一个未能重现 Bug 的修复过程（未完）

一个线上bug ，一直没法重现，但是崩溃率不低，这就问题了有点头疼啦

bug 的堆栈信息

上述就是具体的崩溃信息，原本以为定位这么仔细就可以立马找出原因，然而并没有。
这边用了 DZNEmptyDataSet 和 CHTCollectionViewWaterfallLayout ，崩溃的点也是在此处出现的。。。

目前没法重现这一个 Bug， 只能通过图中返回的情况，定位到代码中：

- (CGSize)collectionViewContentSize {
  NSInteger numberOfSections = [self.collectionView numberOfSections];
  if (numberOfSections == 0) {
    return CGSizeZero;
  }
  CGSize contentSize = self.collectionView.bounds.size;
  contentSize.height = [self.columnHeights[0] floatValue];
  return contentSize;
}

- (BOOL)dzn_canDisplay {
    if (self.emptyDataSetSource && [self.emptyDataSetSource conformsToProtocol:@protocol(DZNEmptyDataSetSource)]) {
        if ([self isKindOfClass:[UITableView class]] || [self isKindOfClass:[UICollectionView class]] || [self isKindOfClass:[UIScrollView class]]) {
            return YES;
        }
    }
    return NO;
}

可以确定是 崩在 dzn_canDisplay 这里，但是尝试好多遍都不知道问题在哪里...

一、 猜

猜测，是否调用 [self.collectionView numberOfSections] 的时候， self.collectionView 的时候已经被提前释放或者说已经被干掉啦。

首先可以肯定的是，当 self.collectionView 被干掉此处肯定会崩，但是此种情况基本不存在，在 CHTCollectionViewWaterfallLayout 中它是不可被修改的，而外部的collectionView 又是在生命周期中，不会被干掉，所以此处排除。。。
另外，如果是 self.collectionView 的问题，那么 上述图中只会截止崩在该位置，不会继续走 dzn_canDisplay等方法。

二、理一下常见的 Carsh

再判断，可以肯定的是什么造成啦 collectionViewContentSize 和 dzn_canDisplay方法有问题，而又没有头绪...

回过头来，先看看分析iOS Crash文件：符号化iOS Crash文件的3种方法，需要使用Xcode符号化 crash log，我们需要下面所列的3个文件：

1. crash报告（.crash文件）
2. 符号文件 (.dsymb文件)
3. 应用程序文件 (appName.app文件，把IPA文件后缀改为zip，然后解压，Payload目录下的appName.app文件), 这里的appName是我们的应用程序的名称。

现在关键问题，这bug 根本一直不能在重现，可以单纯的看到堆栈信息的崩溃日志，再想想一般是什么原因会造成崩溃，回顾下 常见的Crash类型:

• 2-1、看门狗

看门狗也就是 Watchdog 机制，它是iOS为了保持用户界面的响应引入的一种机制， 。如果我们的应用未能及时的响应一些用户界面事件，如启动、暂停、恢复和终止，Watchdog就会杀死程序并生成一个Watchdog超时崩溃报告。Watchdog超时时间并没有明文规定，但通常会少于网络超时。（5秒不一定正确）

场景：

• 主线程执行同步的网络请求，而且请求时间特别长。
• 主线程死锁。
• 长时间读写本地文件
  ...

// 放在 AppDelegate didFinishLaunchingWithOptions
dispatch_sync(dispatch_get_main_queue(), ^{
     NSLog(@"永远不会调用");
});
NSLog(@"永远不会 run");

崩了

• 2-2、用户强制退出

类似强制关机的情况。

• 2-3、内存不够

在我们App运行的过程中，系统内存紧张时通常会先发警告，同时把后台挂起的程序终止掉，最终如果还是内存不够的话就会终止掉当前前台的进程。
也提醒我们要及时的杀掉不用的内存，否则内存占用越来越高，一旦超过系统限制就会被系统杀死，然后就Carsh 啦。

• 2-4、自己产生的 bug

最常见的数组越界，或者其他五花八门的，反正就是自己产生的问题，像上述遇到的问题。。。

来自 常见的Crash类型。

此处提醒，去看看 DZNEmptyDataSet 和 CHTCollectionViewWaterfallLayout 中的 issues， 是不是里面的问题，到它们的 github 上的 issues 转了一大圈，也没有类似的问题...

三、尽量让其重现

线上的崩溃率不低，但是为什么我们自己测试不出来啦，暂时还是只能去分析具体崩溃的位置, 在又一次认真的看堆栈崩溃信息发现， crash 在 objc_msgSend()，而发生这种情况的原因可能是：

• 向一个已经释放的对象发送消息，野指针之类的
• 接收者的内存错误。

反正就是接收者的问题，而我上面图中的那就是 self.emptyDataSetSource 啦，此时在想难道是它被提前释放掉了，但是下面这个 view ,无论如何都是在是会返回的啊

- (UIView *)customViewForEmptyDataSet:(UIScrollView *)scrollView 

而且对于 CollectionView 或者 viewModel 都是强引用啊，在生命周期内不会自己释放掉啊。

PS一个点：编译优化会使调用堆栈中指向第二段的调用点(call site)可能并不是真正导致崩溃的调用。

此时突然想到了我们的崩溃轨迹，有着大量的 KVO痕迹

1、1秒前 DiscoveryViewController viewDidAppear:(,)
2、1秒前 HomeViewController viewDidAppear:(,)
3、2秒前 NSKVONotifying_UICollectionView handlePan:(UIScrollViewPanGestureRecognizer,)
4、2秒前 NSKVONotifying_UICollectionView handlePan:(UIScrollViewPanGestureRecognizer,)

是否和 KVO 有关？？？然而此处是没有用 KVO的啊，而且用了地方都是处理过的，此时我们只能先再了解下KVO一个点：

• NSKVONotifying_UICollectionView 的由来
  当某个类的实例对象的key第一次被观察时，系统就会在运行期动态地创建该类的一个派生类NSKVONotifying_类名，在这个派生类中重写该类中被观察的属性的 setter 方法。

@property(nonatomic, readonly) UIPanGestureRecognizer *panGestureRecognizer NS_AVAILABLE_IOS(5_0);
@property(nonatomic) CGPoint contentOffset;  

在添加KVO观察后，我们在 ObserveValueForKeyPath 打上断点，看一下Object 。

在ObserveValueForKeyPath 时方法的Object 的显示
此时isa指针被系统动态的指向了派生类NSKVONotifying_UICollectionView
注意：KVO的本质就是监听对象的属性进行赋值的时候有没有调用setter方法。

本页面没有用到，那只能再次猜测：是不是其他页面（有用到空页面，瀑布流）返回过来的，并且用来了KVO 而没提前释放 —— 一般是没有的，临走前就算没有释放，也不会调用dzn_canDisplay 方法的。

所以，此处稳妥一点让Bug重现的方法就是 找到一个操作，会涉及方法
- (BOOL)dzn_canDisplay,
- (CGSize)collectionViewContentSize
而且又历经 HomeViewController，DiscoveryViewController，暂时符合该系列行为的就是：

• 启动 app 的操作。

KVO 那块可以理解是 contentOffset 的改变。接下来是重点测试这块啦，但是一直还是无法重现该崩溃。

四、伪解决它

测试了一整天，就没有崩溃一次，从来没有想到过有一天居然想让自己的项目崩掉。。。
回顾一下，我们之前版本 和 这一版本在启动中做的改变，然后我更懵啦，最后觉的一种可能是 这边 self.viewModel 被提前释放掉了，但我这是强引用啊！。。。（项目中用的 是MVVM）

暂时的做法： 增加更多的防空处理。。。
😭！同时我们这个项目被暂停下来啦，暂时都不会重新发版本啦，更不知道去如何解决它啦。。。

PS更新：再次看听云，这几天这个 Bug 居然不重现了，让我更懵啦，只是出现一个类似这个bug的，就是具体崩溃轨迹有点不同，真的懵了......

PS: 最有可能的原因

[self.collectionView performBatchUpdates:^{
      [self.collectionView insertItemsAtIndexPaths:indexPaths];
                    } completion:NULL];

根据崩溃信息，后来一朋友立马想到是这个问题，就是UICollectionView插入 insertItemsAtIndexPaths的时候必须用一个方法，用到这个 performBatchUpdates 的方法。

performBatchUpdates

- (void)performBatchUpdates:(void (^ __nullable)(void))updates completion:(void (^ __nullable)(BOOL finished))completion; // allows multiple insert/delete/reload/move calls to be animated simultaneously. Nestable.

allows multiple insert/delete/reload/move calls to be animated simultaneously. Nestable.

毕竟这个是苹果推荐的，之前没有用，还是不对的。虽说无法证实，无法重现，但看后面那个注释以及崩溃信息，感觉还是比较可靠的。

五、 总结

暂时这个问题没有解决它，没法重现，但是还是先理一下这个过程的问题和收获。

• 解决 bug 的思路历程，需要再优化；
• 进一步了解 Carsh 文件，以及常见原因；
• 对 KVO 的实现，有了新的认识。

同时，如有朋友知道上述类似问题的解决方案，欢迎告之。

PS： 个人再次遇到这个BUG，有了些新理解。