QMUINavigationBarScrollingAnimator 在 scrollView 所在的 viewController 已经被推出 UINavigationController 时，滚动器依然能对 UINavigationBar 产生影响

[WOHANGO]

Bug 表现
QDNavigationBarScrollingAnimatorViewController.m中，当 tableView.contentSize.height 小于 self.view.frame.size.height 时，页面上滑几遍后手势返回，NavigationBar的样式有误。暂未想到解决方法

截图
https://user-images.githubusercontent.com/20496270/146634904-dcb318c8-6af1-445f-a841-26bb98eca485.mp4

其他信息

• 设备: iPhone
• iOS 版本: [iOS 15.0.2]
• Xcode 版本: [Xcode 13.1]
• QMUI 版本: [4.4.1]

[MoLice]

以 QDNavigationBarScrollingAnimatorViewController 为例：

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
    return 2;// 使其不满一屏，所以往上滚动后松手会继续滚动，最终回到原点
}

- (void)scrollViewDidEndDragging:(UIScrollView *)scrollView willDecelerate:(BOOL)decelerate {
    if (decelerate) {
        [self.navigationController popViewControllerAnimated:YES];// 当松手时立马 pop，此时可以制造一个“vc 已经被 pop 时，vc 内的 scrollAnimator 依然在修改 navigationBar 样式”的场景
    }
}

在 QMUI Demo 里运行以上示例代码即可发现，往上拖拽列表，松手时界面会立马被 pop 掉，前一个界面预期是恢复蓝色的导航栏，但由于 pop 后 scrollAnimator 还在继续运作，导致导航栏的样式又被设置为列表处于顶部时的样式（也即背景透明）。

当一个 QMUINavigationBarScrollingAnimator 的 navigationBar 属性被手动指定时，暗示着业务有义务在某些恰当的时机（例如 vc 被 pop）清空 navigationBar 属性。但如果业务没主动设置 navigationBar 属性，依赖 QMUINavigationBarScrollingAnimator 内部自动寻找，则 QMUINavigationBarScrollingAnimator 内部是有义务在 vc 被 pop 时移除掉对 navigationBar 的关联。

对于后者，自动寻找的情况，下个版本 QMUI 会优化这里的表现，使被 pop 掉的 vc 不会再影响导航栏的样式，在此之前你可以用这个文件替换本地的 QMUI 以临时修复该问题。QMUINavigationBarScrollingAnimator.m.zip

对于前者，QMUI 不会处理，需要业务自行检查。

[MoLice]

已发布 4.4.2 修复该问题。