UITableView优化笔记(一)

推荐:http://code4app.com/ios/VVeboTableView/565d75a3594b90bf268b49ff

1: heightForRowAtIndexPath方法小做文章

原因:tableview继承自scrollview,当tableview加载时需要将contentSize计算出来。所以第一次加载时会频繁调用此方法,如:table有100行,则此方法调用100次,将每次得出的结果相加得到contentSize。就像每次使用scrollview滚动时都要设置contentSize这个属性一样。

小做文章1:如果table每一个cell的高度固定,使用_tableView.rowHeight = 200;

小做文章2:如果cell高度可变,不要在heightForRowAtIndexPath中调用cellForRowAtIndexPath来计算。取而代之的是,cell的工厂方法。如:

小做文章3:在获取数据的时候就将高度计算好并存储到数据中,heightForRowAtIndexPath方法则直接使用该数据。如:

总结:尽可能使用第三种方法,分析如下

第二种方法时间分析如下:

第三种方法时间分析如下:

两种方法本质上都是遍历数据获取相应高度,计算高度的代码完全相同。但是第二种方法中heightForRowAtIndexPath的运行时间占比很大,并且随着table滚动而不断增加,证明每次用户滚动table时,计算高度的方法都执行一次,如果计算高度的方法用时比较多,如我当前用的

每次计算的时间都在330个单位上下,那么如果数据量大,滚动很快时,这简直就是灾难。

第三种方法计算高度的代码则是在获取数据后,table加载之前执行,并且只执行一次。210ms的时间不随着table的滚动儿增加。而我们的heightForRowAtIndexPath的方法,执行时间已经降到了1ms,几乎可以忽略不计了。

当然,在一个只有table的demo中,这点优化基本看不出有什么作用。

2:添加不如画:cellForRowAtIndexPath方法大费周折

平时使用cellForRowAtIndexPath时最常用的方法就是在cell的init方法中addSubview如

这个是添加子视图的方法将数据灌在cell中。

画的方法则是在最开始推荐的demo中的方法,感谢作者。

像这样:

画的代码很多,基本属于CoreGraphics框架的东东,说大费周折,基本都在这了。

添加子视图的方法时间分析如下:

画的方法时间分析如下:

实话实说呀,这画的方法代码执行的时间真心是吓了我一跳了,画cell的线程真心是-_-#

但是呢,用户滚动table是感觉不到地,因为所有画的线程都是子线程,而主线程占比只有区区的2%,就是setimage的方法。

反过来,添加子视图的方法cellForRowAtIndexPath则几乎全部都在主线程执行,子线程只有查找缓存图片的方法。这个办法真心卡卡卡的呀。

真机跑一下,明显感觉画的方法要比添加子视图的方法顺畅的多。

ps:只分析代码执行时间,不分析内存占用量。

时间: 2024-10-05 05:41:27

UITableView优化笔记(一)的相关文章

UITableView优化技巧

最近在微博上看到一个很好的开源项目VVeboTableViewDemo,是关于如何优化UITableView的.加上正好最近也在优化项目中的类似朋友圈功能这块,思考了很多关于UITableView的优化技巧,相信这块是难点也是痛点,所以决定详细的整理下我对优化UITableView的理解. UITableView作为iOS开发中最重要的控件之一,其中的实现原理很是考究.Apple在这块的优化水平直接决定了iOS的体验能甩安卓几条街,哈哈,扯淡扯多了...好了,废话不多说,直接进入主题.首先来谈谈

UITableView 优化总结

最近在微博上看到一个很好的开源项目VVeboTableViewDemo,是关于如何优化UITableView的.加上正好最近也在优化项目中的类似朋友圈功能这块,思考了很多关于UITableView的优化技巧,相信这块是难点也是痛点,所以决定详细的整理下我对优化UITableView的理解. UITableView作为iOS开发中最重要的控件之一,其中的实现原理很是考究.Apple在这块的优化水平直接决定了iOS的体验能甩安卓几条街,哈哈,扯淡扯多了...好了,废话不多说,直接进入主题.首先来谈谈

详细整理:UITableView优化技巧

最近在微博上看到一个很好的开源项目VVeboTableViewDemo,是关于如何优化UITableView的.加上正好最近也在优化项目中的类似朋友圈功能这块,思考了很多关于UITableView的优化技巧,相信这块是难点也是痛点,所以决定详细的整理下我对优化UITableView的理解. UITableView作为iOS开发中最重要的控件之一,其中的实现原理很是考究.Apple在这块的优化水平直接决定了iOS的体验能甩安卓几条街,哈哈,扯淡扯多了...好了,废话不多说,直接进入主题.首先来谈谈

千万级记录的Discuz论坛导致MySQL CPU 100%的优化笔记

千万级记录的Discuz论坛导致MySQL CPU 100%的优化笔记 2007年3月,我写过一篇文章<解决一个 MySQL 服务器进程 CPU 占用 100%的技术笔记>( http://www.xiaohui.com/weekly/20070307.htm ),谈到自己在解决一个拥有 60 万条记录的 MySQL 数据库访问时,导致 MySQL CPU 占用 100% 的经过.在解决问题完成优化(optimize)之后,我发现 Discuz 论坛也存在这个问题,当时稍微提了一下: 发现此主

java性能优化笔记(三)java程序优化

程序代码优化要点: 字符串优化:分析String源码,了解String常用方法,使用StringBuffer.StringBuilder. List.Map.Set优化:分析常用ArrayList.LinkedList.HashMap.TreeMap.LinkedHashMap.Set接口.集合常用方法优化. 使用NIO:Buffered.Channel操作和原理,使用零拷贝. 引用优化:强引用.弱引用.软引用.虚引用.WeekHashMap. 优化技巧:常用代码优化技巧.这里不一一罗列,请参考

UITableView优化那点事

forkingdog关于UITableView优化的框架其实已经能够应用在一般的场景,且有蛮多的知识点供我们借鉴,借此站在巨人的肩膀上来分析一把. 至于UITableView的瓶颈在哪里,我相信网上随便一搜就能了解的大概,我这里顺便提供下信息点: 1 //罪魁祸首 2 tableView:cellForRowAtIndexPath: 3 tableView:heightForRowAtIndexPath: 框架同样根据这两个痛点给出了解决方案: 高度计算 fd_heightForCellWith

SQL优化笔记—CPU优化

补充:常规服务器动态管理对象包括,下面有些资料可能会应用到 dm_db_*:数据库和数据库对象dm_exec_*:执行用户代码和关联的连接dm_os_*:内存.锁定和时间安排dm_tran_*:事务和隔离dm_io_*:网络和磁盘的输入/输出 优化性能的常用方法是检索速度最慢的查询构成您 SQL Server 实例上的正常. 每日工作负载的一部分,然后调整它们,一个接一个的"Top 10"列表. 跟踪会话. 请求 和 SQL Server 基础架构中的最耗费大量资源,查询和执行时间最长

CMU Convex Optimization(凸优化)笔记1--凸集和凸函数

CMU凸优化笔记--凸集和凸函数 结束了一段时间的学习任务,于是打算做个总结.主要内容都是基于CMU的Ryan Tibshirani开设的Convex Optimization课程做的笔记.这里只摘了部分内容做了笔记,很感谢Ryan Tibshirani在官网中所作的课程内容开源.也很感谢韩龙飞在CMU凸优化课程中的中文笔记,我在其基础上做了大量的内容参考.才疏学浅,忘不吝赐教. 1.凸集合 1.1 基本概念 定义:给定一个集合$C \subseteq \mathbb{R}^n $,满足下列条件

U3D开发性能优化笔记(待增加版本)

U3D开发性能优化笔记: .NGUI: Atlas优化; .poolmanager使用; .控制同屏drawcall次数; .SHADER优化顶点和运算; .合批与动态剔除; .逻辑部分优化;(如看到不到的物件不要做公告板位置运算,不要播放animation) .物理帧UPDATE降低; .关闭垂直同步,降低图片采样,声音预加载 方案 等等 ..; .模型骨骼不要超过32根; .贴图不要太大,建议512 *512 以下; .少用 CUTOFF和 aplha混合; .3D游戏效率基本原则就是费内存