- 浏览: 888231 次
- 性别:
- 来自: 上海
文章分类
- 全部博客 (466)
- iPhone, iOS , Objective-c (155)
- 数据库 (20)
- 设计模式 (5)
- 第三方包管理,cocoapod (2)
- 版本管理, SVN, Subversion, Git (1)
- Google, Android, Java (14)
- Wordpress (1)
- 职业素养 (3)
- 版本管理,git (3)
- 前端小技巧 (2)
- flash (1)
- javascript (5)
- Ruby (0)
- 编程语言 (1)
- 网络常识 (1)
- 找到生活好感觉 (5)
- 产品经理 (1)
- markdown (1)
- 云服务器 (1)
- iPhone (116)
- iOS (116)
- Objective-c (116)
- 学习技巧 (2)
- Google (5)
- Android (6)
- Java (21)
- python (1)
- sqlite (3)
- node.js (2)
- mongodb (2)
- 学习技巧,阅读 (2)
- 软件测试 (3)
- 架构设计 (2)
- 设计 (1)
- Spring framework (3)
- junit (1)
- Linux (2)
- 软件 (1)
- Struts2 (1)
- 版本管理 (3)
- SVN (3)
- Subversion (3)
- Git (3)
- mysql (5)
- quartz (1)
- 无关技术 (1)
- 前端 (1)
- Redis (1)
- 产品管理 (0)
- 计算机常识 (1)
- 计算机科学 (0)
- swift (1)
- 服务器 (2)
- 搜索 (1)
- Scala (1)
- J2EE (1)
- maven (1)
- 前端css (1)
- 英语 (1)
- 消息队列 (1)
- kafka (0)
- apache kafka (4)
- netbeans (1)
- IDE (2)
- 歌词 (1)
- 过滤器实现 (1)
- linux vim vi (1)
- jmeter (1)
- springcloud (1)
最新评论
-
hujingnemo:
不知道为什么打不开
CHM如何改编字体大小 -
weiboyuan:
求答案 weiboyuanios@163.com
iOS软件工程师面试题(高级) -
xueji5368:
这个现在已经广泛使用了嘛!
RoboGuice入门 -
Yao__Shun__Yu:
...
CHM如何改编字体大小 -
353144886:
非常之详细 美女求认识
sqlite数据类型 datetime处理
1.In your UITableViewCell subclass, add constraints so that the subviews of the content view have their edges pinned to the edges of the content view (most importantly to the top AND bottom edges). Let the intrinsic content size of these subviews drive the height of the table view cell's content view by making sure the content compression resistance and content hugging constraints in the vertical dimension for each subview are not being overridden by higher-priority constraints you have added.
Remember the idea is to have the subviews connected vertically to the cell's content view so that they can "exert pressure" and make the content view expand to fit them.
If you're adding constraints in code, you should do this once after init in the updateConstraints method.
2.For every unique set of constraints in the cell, use a unique cell reuse identifier. In other words, if your cells have more than one unique layout, each unique layout should receive its own reuse identifier.
For example, if you were displaying an email message in each cell, you might have 4 unique layouts: messages with just a subject, messages with a subject and a body, messages with a subject and a photo attachment, and messages with a subject, body, and photo attachment. Each layout has completely different constraints required to achieve it, so once the cell is initialized and the constraints are added for one of these layouts, the cell should get a unique reuse identifier specific to that layout. This means when you dequeue a cell for reuse, the constraints have already been added and are ready to go for that layout.
Note that due to differences in intrinsic content size, cells with the same constraints (layout) may still have varying heights! Don't confuse fundamentally different layouts (different constraints) with different calculated view frames (solved from identical constraints) due to different sizes of content.
Do not add cells with completely different sets of constraints to the same reuse pool (i.e. use the same reuse identifier) and then attempt to remove the old constraints and set up new constraints from scratch after each dequeue. The internal Auto Layout engine is not designed to handle large scale changes in constraints, and you will see massive performance issues.
After configuring the cell with the content it will hold, force the cell to immediately layout its subviews, and then use the systemLayoutFittingSize: method on the UITableViewCell's contentView to find out what the required height of the cell is. Use UILayoutFittingCompressedSize to get the smallest size required to fit all the contents of the cell. The height can then be returned by the tableView:heightForRowAtIndexPath: delegate method.
If your table view has more than a couple dozen rows in it, you will find that doing the Auto Layout constraint solving can quickly bog down the main thread when first loading the table view, as tableView:heightForRowAtIndexPath: is called on each and every row upon first load (in order to calculate the size of the scroll indicator).
As of iOS 7, you can and absolutely should use the estimatedRowHeight property on the table view, or implement the delegate method tableView:estimatedHeightForRowAtIndexPath:. What this does is allow you to return a guess for the cell height using minimal or no computation, which is used to get a temporary estimate/placeholder for the row height of cells that are not onscreen. Then, when these cells are about to scroll onscreen, the real row height will be calculated and the estimated height updated with the actual one.
Generally speaking, the estimate you provide doesn't have to be very accurate - it's only used to correctly size the scroll indicator in the table view, and the table view does a good job of adjusting it when you scroll and it finds that your estimates were wrong. I would just suggest adding enough logic to make sure your estimated heights are within an order of magnitude of the actual heights.
If you've done all the above and are still finding that performance is unacceptably slow (when doing the constraint solving for the row height calculations), you'll unfortunately need to implement some caching for cell heights. The general idea is to let the Auto Layout engine solve the constraints the first time, then cache the calculated height for that cell and use the cached value for all future requests for that cell's height. The trick of course is to make sure you clear the cached height for a cell when anything happens that could cause the cell's height to change -- primarily, this would be when that cell's content changes or when other important events occur (like the user adjusting the Dynamic Type text size slider).
Remember the idea is to have the subviews connected vertically to the cell's content view so that they can "exert pressure" and make the content view expand to fit them.
If you're adding constraints in code, you should do this once after init in the updateConstraints method.
2.For every unique set of constraints in the cell, use a unique cell reuse identifier. In other words, if your cells have more than one unique layout, each unique layout should receive its own reuse identifier.
For example, if you were displaying an email message in each cell, you might have 4 unique layouts: messages with just a subject, messages with a subject and a body, messages with a subject and a photo attachment, and messages with a subject, body, and photo attachment. Each layout has completely different constraints required to achieve it, so once the cell is initialized and the constraints are added for one of these layouts, the cell should get a unique reuse identifier specific to that layout. This means when you dequeue a cell for reuse, the constraints have already been added and are ready to go for that layout.
Note that due to differences in intrinsic content size, cells with the same constraints (layout) may still have varying heights! Don't confuse fundamentally different layouts (different constraints) with different calculated view frames (solved from identical constraints) due to different sizes of content.
Do not add cells with completely different sets of constraints to the same reuse pool (i.e. use the same reuse identifier) and then attempt to remove the old constraints and set up new constraints from scratch after each dequeue. The internal Auto Layout engine is not designed to handle large scale changes in constraints, and you will see massive performance issues.
After configuring the cell with the content it will hold, force the cell to immediately layout its subviews, and then use the systemLayoutFittingSize: method on the UITableViewCell's contentView to find out what the required height of the cell is. Use UILayoutFittingCompressedSize to get the smallest size required to fit all the contents of the cell. The height can then be returned by the tableView:heightForRowAtIndexPath: delegate method.
If your table view has more than a couple dozen rows in it, you will find that doing the Auto Layout constraint solving can quickly bog down the main thread when first loading the table view, as tableView:heightForRowAtIndexPath: is called on each and every row upon first load (in order to calculate the size of the scroll indicator).
As of iOS 7, you can and absolutely should use the estimatedRowHeight property on the table view, or implement the delegate method tableView:estimatedHeightForRowAtIndexPath:. What this does is allow you to return a guess for the cell height using minimal or no computation, which is used to get a temporary estimate/placeholder for the row height of cells that are not onscreen. Then, when these cells are about to scroll onscreen, the real row height will be calculated and the estimated height updated with the actual one.
Generally speaking, the estimate you provide doesn't have to be very accurate - it's only used to correctly size the scroll indicator in the table view, and the table view does a good job of adjusting it when you scroll and it finds that your estimates were wrong. I would just suggest adding enough logic to make sure your estimated heights are within an order of magnitude of the actual heights.
If you've done all the above and are still finding that performance is unacceptably slow (when doing the constraint solving for the row height calculations), you'll unfortunately need to implement some caching for cell heights. The general idea is to let the Auto Layout engine solve the constraints the first time, then cache the calculated height for that cell and use the cached value for all future requests for that cell's height. The trick of course is to make sure you clear the cached height for a cell when anything happens that could cause the cell's height to change -- primarily, this would be when that cell's content changes or when other important events occur (like the user adjusting the Dynamic Type text size slider).
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath { // Dequeue a cell for the particular layout required (you will likely need to substitute // the reuse identifier dynamically at runtime, instead of a static string as below). // Note that this method will init and return a new cell if there isn't one available in the reuse pool, // so either way after this line of code you will have a cell with the correct constraints ready to go. UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:@"UniqueCellIdentifierForThisUniqueCellLayout"]; // Configure the cell with content for the given indexPath, for example: // cell.textLabel.text = someTextForThisCell; // ... [cell.contentView setNeedsLayout]; [cell.contentView layoutIfNeeded]; CGFloat height = [cell.contentView systemLayoutSizeFittingSize:UILayoutFittingCompressedSize].height; return height; } - (CGFloat)tableView:(UITableView *)tableView estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath { // Return a fixed constant if possible, or do some minimal calculations if needed to be able to return an // estimated row height that's at least within an order of magnitude of the actual height. // For example: if ([self isLargeTypeForCellAtIndexPath:indexPath]) { return 150.0f; } else { return 60.0f; } }
发表评论
-
UIImage变为NSData并进行压缩
2014-05-19 20:23 1877//sdk中提供了方法可以直接调用 UIImage *im ... -
update cocapods
2014-05-17 22:27 770早上更新cocoapod依赖库,发现更新到32.1版本,早先的 ... -
iOS发送短信息代码实例
2014-05-16 18:15 2634#import <MessageUI/Message ... -
DISPATCH TIMER
2014-05-14 16:12 679/* __block void (^callback) ... -
UITextField左边显示图片
2014-05-13 18:08 1111The overlay view displayed on t ... -
iOS调用系统打电话,发短信功能
2014-05-11 15:48 2058先介绍一种最简单的方法: 调用打电话功能 [[UIAppl ... -
iOS面试题
2014-05-09 16:10 10471.写一下UIButton与UITableView的层级结构 ... -
socket二进制报文
2014-05-09 15:18 1251里面有帧头 字符串UTF-8 中间用0隔开 又一个字符串 ... -
将网站添加到桌面的方法
2014-05-08 14:25 1629<link href="http://www. ... -
iPhone通讯录联系人操作大全
2014-05-07 10:29 14081.需要引入AddressBook.framework框架 2 ... -
sqlite获取最新插入的rowid
2014-05-07 09:59 1483除了 last_insert_rowid select max ... -
号码归属地查询,拨打电话
2014-05-06 15:07 800在程序内调用拨打电话的方法,[[UIApplication s ... -
iOS时间合并
2014-04-28 17:55 1023合并同一时间的课程,同一时间可能有多个课程,比如13:30-1 ... -
vCard通讯录格式说明
2014-04-28 16:47 2449原帖:http://freesoftman.iteye.com ... -
UISearchBar背景色全套解决方案
2014-04-25 09:36 7396os系统升级到7.1后,原来在7.0下显示正常的UISearc ... -
升级XCode5.1.1遇到的奇葩问题NSString,NSObjectRuntime.h报错,Foundation找不到
2014-04-24 11:19 861升级XCode5.1.1遇到的奇葩问题NSString,NSO ... -
将NSString转为NSArray
2014-04-22 16:52 6232// Your JSON data: NSString *c ... -
另外一种NSData转为NSString的方法
2014-04-22 15:40 1169If the data is not null-termina ... -
HTTP,Socket,WebSocket异同
2014-04-18 16:54 1794参考文章: http://abbshr.g ... -
push隐藏UINavigtaionBar和UITabbar
2014-04-17 15:20 1049[self.navigationController setN ...
相关推荐
可滑动的UITableViewCell受流行的启发,该在实现。 预习 退出模式 .exit模式是邮箱应用程序中已知的原始行为。 切换模式 .toggle是另一种行为,其中单元格在滑动后会反弹。 安装 Swift软件包管理器(推荐) 是苹果...
示例项目演示了iOS 8中的自调整表格视图单元格大小,使用UITableViewCell中的“自动布局”来实现具有可变行高的动态布局。 该项目是一个通用应用程序,将在iPhone和iPad上运行。 此实现仅与iOS 8及更高版本兼容。 ...
做一个微博客户端的第三方是自学的第一个实践的项目,自从从事iOS工作之后,就把这个项目给搁置了。趁现在过年回来有些空闲时间,再次修改(总觉得项目就是不停地修改)。并且记录一点东西,以后可再回头看看从前...
源码TableViewCellWithAutoLayoutiOS8,示例演示了在iOS 8中自动调整table view表格尺寸的功能,在UITableViewCell中使用Auto Layout来获得可变行高的动态布局。 该项目适用于iPhone和iPad,仅兼容iOS 8及以上系统...
案例4:动态高度UITableViewCell,附加简单的高度缓存 Case5:topLayoutGuide和bottomLayoutGuide使用案例 案例6:自定义基准线效果 Case7:给UITableView加简单的视差视差效果标题 案例8:实时更改UITableViewCell...
自定义列表 cell (UITableViewCell)的选中颜色(可增添渐变颜色),以及自定义cell和cell之间的分割线(separator)。 仅支持ARC模式。如果你的项目使用非ARC,则必须在编译模式中给此类库的所有代码加上:-...
· 加入了“高级评论”的示例代码,根据数据源数组来显示评论列表,个数不确定、评论内容长度不确定(即cell高度不确定),可在工程中搜索 高级评论 查看相关代码。 · 加入了cell上按钮触发事件绑定的示例代码,...
提供的HostCell泛型使向UITableViewCell添加FunctionalTableData支持变得容易。 值得注意的功能 :hundred_points: 维护表状态的功能方法 :construction_worker: 可重用的视图和状态 :white_heavy_check_mark...
因此,我编写了ObjectForm,以使构建表单和绑定模型类变得非常简单。 ObjectForm不需要您编写UIKit代码。 通过设计,很容易理解和扩展。 如果仔细遵循示例项目,您会发现很容易将其放入Swift项目。 该项目不依赖...
8.7.2 深层可变副本 169 8.7.3 更新控制器头文件 170 8.7.4 修改视图 171 8.7.5 修改控制器实现 173 8.8 小结 183 第9章 导航控制器和表视图 184 9.1 导航控制器 184 9.1.1 栈的性质 184 9.1.2 控制器栈 185 9.2 由...