当产品由团队开发时,每个人的零件设计思想尺有所短寸有所长,因此非设计者使用时极有可能出现遗漏。
问题
有团队同事反馈,在“智勇三张”游戏玩久了后,页面切换非常卡顿,几乎必现,问题优先级高。页面过场如图所示:
初步分析
根据先前的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很多的时候,越多越卡。
至此,问题解决!解决过程再次说明第一步开发人员自己稳定复现问题的必要性。