当产品由团队开发时，每个人的零件设计思想尺有所短寸有所长，因此非设计者使用时极有可能出现遗漏。
问题
有团队同事反馈，在“智勇三张”游戏玩久了后，页面切换非常卡顿，几乎必现，问题优先级高。页面过场如图所示：
初步分析
根据先前的bug解决方法论，改bug第一步是找到必现步骤。那么以同事反馈流程为切入点，玩了20分钟“智勇三张”，大家猜猜看结果怎么样？当然是不能必现-_-!，因为常规情况下，用户认为的必现和开发人员认为的必现，不是同一种概念。
进一步分析
功能正常但页面切换动画卡顿，这种情况以前从未碰到过，还真不好下手，于是想先看看网上其他同僚们是否有碰到此类问题，百度搜索"UINavigationController push 卡顿"。我的习惯是业务关联性较大、出现场景与具体功能有关的问题用百度，偏纯技术类的问题用Google，通常解决问题效率还不错。
一番浏览后，发现同僚们大致以下两种观点：
- 新push的UIViewController背景色不能为clearColor，否则易卡顿；（绝大多数）
- 新push的UIViewController做了太多的加载相关的逻辑。
针对第一种情况，其实不是卡顿，只是背景色透明时，让push过程的动画看起来不那么自然，先前在开发中有碰到过这个问题；至于第二种分析，如果在新VC中做了太多的加载工作，极有可能的效果是推送前卡顿，或推送后卡顿同时在几秒内不响应用户点击。页面结构是我自己搭建的，哪里有性能瓶颈自己清楚。我认为这两种都不符合我的思路切入点。
先前解决的那个推迟了3个月的问题，是在数据不断拉取不断重新刷新的过程中复现的，并且和眼下的问题在同一个大页面容器内，要不试试看用相同的方法重现下？于是停留在“大厅”tab的“娱乐场”，尝试反复将app做前后台切换触发拉取数据。
居然真的出现问题了。
对当前显示的View Hierarchy做Debug操作，得到如下结果。
由图，显而易见，页面上最大的问题在于叠了太多层顶部H5小游戏banner入口。好，那么开始查找代码。
定位并解决问题
浏览banner构造处代码，如下所示：
/**
构造麻将和赛猪入口
*/
private func constructEntertainmentTopView(gameListArray: [MediaInfo]) {
let gameCount = gameListArray.count
let margin = CGFloat(6.0)
let bannerWidth = (ScreenWidth - margin * (gameCount + 1)) / gameCount
let bannerHeight = 80 - margin * 2
//2x高度 750 x 160
entertainmentTopView = UIView(frame: CGRect(x: 0, y: 0, width: ScreenWidth, height: 80))
entertainmentTopView?.backgroundColor = ColorMainBg
addSubview(entertainmentTopView!)
rightTableView.contentInset = UIEdgeInsetsMake(80, 0, 0, 0)
for i in 0 ..< gameListArray.count {
let gameImageView = UIImageView(frame: CGRect(x: margin + (bannerWidth + margin) * i, y: margin, width: bannerWidth, height: bannerHeight))
entertainmentTopView?.addSubview(gameImageView)
gameImageView.isUserInteractionEnabled = true
gameImageView.setupCornerRadius(3, shouldRasterImage: false)
gameImageView.tag = i + 1
gameImageView.contentMode = .scaleAspectFill
gameImageView.sd_setImage(with: URL(string: gameListArray[i].imgurl))
gameImageView.addGestureRecognizer(UITapGestureRecognizer(target: self, action: #selector(tapGameImage(tap:))))
}
}
一看代码就明白了。页面结构是我写的，但是这个banner是另一个同事改过的，改动内容是把banner从静态入口改为拉取接口根据返回数据动态构造。当前的代码只有构造，没有移除。而如果每一次触发拉取数据操作都叠加一次banner的话，必定引发页面卡顿。解决方法就是在每次给entertainmentTopView赋值新的UIView构造对象前，先执行entertainmentTopView?.removeFromSuperview()即可。
这里还有一个问题。原先我一直以为，UINavigationController的动画本质是对当前rootViewController.view截图后做移动+透明度变化，按理说，这样的话顶多就截图时慢一些，并不应该影响动画流畅度的。除非它不是截图，而是直接对现有真实view做移动和变化透明度操作，嗯，只有这一种可能了。
在经过测试后，在下图所示的状况下，居然左右两个页面都还在刷新，验证了我的猜想。那就弄明白为什么卡了，因为在push和pop的动画播放同时，还要保持高帧率的页面刷新，尤其是在view hierarchy很多的时候，越多越卡。
至此，问题解决！解决过程再次说明第一步开发人员自己稳定复现问题的必要性。
