wv-y

注释掉 **AntiAntiDebug.m**中的 `rebind_symbols((struct rebinding[1]){{"dlsym", my_dlsym, (void*)&orig_dlsym}},1);` 就不会报错了，具体原因和其他解决方案未知

> demo无法体现 可以看下log输出，每出现一个cell，myhook_collectionView:willDisplayCell:方法执行了两次； 在这里的截图有所体现 https://github.com/tigerAndBull/TABAnimated/issues/204#issue-1334000130

> 看起来没有问题，去TABCollectionAnimated中的sizeForItemAtIndexPath方法里，打个断点调试一下 感谢回复，我再调试看看，请问怎么加微信群，二维码过期了，有问题可以方便交流😂

@tigerAndBull 作者大佬，你好 使用以下写法，在第一次进入页面时骨架屏没有cell1的视图，后续再进入则都可以正常展示，不会再复现这个问题，打出来的包在真机运行也是一样的问题。 两个cell的init方法中我都有添加试图。 真机是iPhone 12， IOS14.7 ``` NSArray *cellClassArray = @[[Cell1 class], [Cell2 class]]; NSArray *sizeArray = @[@(CGSizeMake(Screen_Width, 200)), @(CGSizeMake(Screen_Width, 90))]; TABCollectionAnimated *tabAnimated = [TABCollectionAnimated animatedWithCellClassArray:cellClassArray cellSizeArray:sizeArray animatedCountArray:@[@(1),@(1)]]; tabAnimated.superAnimationType...

> > > 看起来没有问题，去TABCollectionAnimated中的sizeForItemAtIndexPath方法里，打个断点调试一下 > > > > > > 感谢回复，我再调试看看，请问怎么加微信群，二维码过期了，有问题可以方便交流😂 > > 用2.6.2试试，不行加wx: _tigerAndBull 感谢回复，经过排查发现，这些问题是因为，项目中collectionView的layout是复写UICollectionViewFlowLayout的子类，2.6.0和2.6.2表现一致，直接使用UICollectionViewFlowLayout是没有问题的。

> cellSize和cellHeight都有两种形态，一种是属性，一种是通过代理获取。 > > > > 感谢回复，经过排查发现，这些问题是因为，项目中collectionView的layout是复写UICollectionViewFlowLayout的子类，2.6.0和2.6.2表现一致，直接使用UICollectionViewFlowLayout是没有问题的。 > > 重写的目的是什么，可能是重写后某些生命周期变化了，如果要继续追踪的话，需要提供重写了什么 重写是为了实现多列瀑布流，采用的layout是这个 https://www.jianshu.com/p/ca806664c58a 除了加了些容错，核心的东西是一样的

老哥们，这个问题有啥好的解决办法吗？我这是把boost升级到4.0.4之后出现的问题，用的flutter版本是3.7.12 _cxa_throw + 6704335372284639784 -[FBFlutterContainerManager removeContainerByUniqueId:] (FBFlutterContainerManager.m:60-61) -[FlutterBoostPlugin containerWillAppear:] (FlutterBoostPlugin.m:0) -[FBFlutterViewContainer viewWillAppear:] (FBFlutterViewContainer.m:272) -[UIViewController _setViewAppearState:isAnimating:] + 664

可以看下JXCategoryTitleView中计算cell宽度的方法，看下计算结果；也可以自己计算宽度，不使用默认的；或者是不是TitleView 的高度设置的不对

> 需要服务端处理去重逻辑， 去重判断业务可以加唯一id来区分。 因为网络传输是不稳定的，端上是在服务端确认收到数据后才删除掉本地数据。 但是如果在这个传输过程中出现网络问题，或者端上杀进程。 为了保证数据不丢失， 端上都不会删除数据，端上会在服务端明确收到数据后，才删除本地数据，否则，下一次启动会上报上一次没有确认收到的数据。 所以解决这个重复的问题方案就需要 业务的服务端进行数据去重处理。 服务端去重逻辑确实是有的； 这个库也集成到项目里好久了，但是线上发现有用户上报的日志还是半年之前的，占比能达到10%～20%，这个比例不正常；同时logid重复的情况很多，生成ID的api，iOS这边使用的[[NSUUID UUID] UUIDString]; 几乎不会重复的。 我这边用demo测试了下，怀疑有调用uploadSuccess时没有成功删除的情况； 以下是测试逻辑： 1、push200条日志； 2、上传日志时，记录下来上传记录（key和日志内容）； 3、上传一部分后将上传记录写入本地，并杀死app； 4、然后再启动app可以看到又从0开始上传 如果等这200条日志全部上传完成再杀死app后重启则不会有重复上报现象。 大佬能帮忙分析下吗？ 下面是部分逻辑代码 ## MyViewController ``` // // DataReporterManager.m //...

可以看到日志内容是重复的，但是两次返回的int64_t key不同，这个key的生成逻辑是什么样的呀？