一个线上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个文件：
- crash报告（.crash文件）
- 符号文件 (.dsymb文件)
- 应用程序文件 (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，有了些新理解。
网友评论