- 浏览: 910487 次
- 性别:
- 来自: 上海
-
文章分类
- 全部博客 (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 1953//sdk中提供了方法可以直接调用 UIImage *im ... -
update cocapods
2014-05-17 22:27 822早上更新cocoapod依赖库,发现更新到32.1版本,早先的 ... -
iOS发送短信息代码实例
2014-05-16 18:15 2701#import <MessageUI/Message ... -
DISPATCH TIMER
2014-05-14 16:12 742/* __block void (^callback) ... -
UITextField左边显示图片
2014-05-13 18:08 1186The overlay view displayed on t ... -
iOS调用系统打电话,发短信功能
2014-05-11 15:48 2095先介绍一种最简单的方法: 调用打电话功能 [[UIAppl ... -
iOS面试题
2014-05-09 16:10 10891.写一下UIButton与UITableView的层级结构 ... -
socket二进制报文
2014-05-09 15:18 1323里面有帧头 字符串UTF-8 中间用0隔开 又一个字符串 ... -
将网站添加到桌面的方法
2014-05-08 14:25 1672<link href="http://www. ... -
iPhone通讯录联系人操作大全
2014-05-07 10:29 14811.需要引入AddressBook.framework框架 2 ... -
sqlite获取最新插入的rowid
2014-05-07 09:59 1550除了 last_insert_rowid select max ... -
号码归属地查询,拨打电话
2014-05-06 15:07 865在程序内调用拨打电话的方法,[[UIApplication s ... -
iOS时间合并
2014-04-28 17:55 1119合并同一时间的课程,同一时间可能有多个课程,比如13:30-1 ... -
vCard通讯录格式说明
2014-04-28 16:47 2580原帖:http://freesoftman.iteye.com ... -
UISearchBar背景色全套解决方案
2014-04-25 09:36 7459os系统升级到7.1后,原来在7.0下显示正常的UISearc ... -
升级XCode5.1.1遇到的奇葩问题NSString,NSObjectRuntime.h报错,Foundation找不到
2014-04-24 11:19 913升级XCode5.1.1遇到的奇葩问题NSString,NSO ... -
将NSString转为NSArray
2014-04-22 16:52 6282// Your JSON data: NSString *c ... -
另外一种NSData转为NSString的方法
2014-04-22 15:40 1225If the data is not null-termina ... -
HTTP,Socket,WebSocket异同
2014-04-18 16:54 1849参考文章: http://abbshr.g ... -
push隐藏UINavigtaionBar和UITabbar
2014-04-17 15:20 1110[self.navigationController setN ...
相关推荐
在iOS 7中,苹果引入了一系列新的设计语言和API更新,使得自定义UITableViewCell变得更加灵活和直观。本教程将深入探讨如何在iOS 7环境中实现自定义UITableViewCell。 首先,你需要了解UITableViewCell的基本结构。...
如果使用AutoLayout,可以通过修改约束(constraints)来实现动态高度,例如设置按钮的heightAnchor与一个可变的Height约束相关联,然后根据需求改变Height约束的constant值。 为了响应滑动事件,我们需要在...
在iOS开发中,创建自适应的UITableViewCell高度是一项常见的需求,尤其在显示内容不固定或者内容长度可变的情况下。这个“ios-自适应cell高度.zip”文件提供的示例应该就是一个简单的教程,展示了如何通过纯代码实现...
在iOS开发中,`UITableViewCell`的高度自适应是一个关键的特性,它使得表格视图能够根据内容动态调整单元格的高度,从而提供更好的用户体验。这个话题主要涉及到`UITableView`和`UITableViewCell`的交互,以及Auto ...
当单元格的内容不固定,比如文本长度可变时,我们希望单元格的高度能够根据内容自动调整,以保证良好的用户体验。这就需要用到Auto Layout来实现动态高度的功能。本文将详细介绍如何在UITableViewCell中使用Auto ...
在iOS开发中,动态设置UITableViewCell的高度是一项常见的需求,特别是在处理包含可变内容的列表时,如用户点击城市后展示最近访问城市的列表。本教程通过"ios-动态设置cell高度.zip"压缩包中的XiaoDongDemo2项目,...
首先,我们要明白,一个单元格(UITableViewCell)的高度是由它的内容决定的,特别是当内容包含可变长度的文本时。在iOS中,我们可以利用AutoLayout或者老式的`sizeThatFits:`方法来计算文本的最适合大小,从而确定...
在UITableView中,每个Cell的高度是可变的,这取决于Cell的内容。通常,我们需要在`UITableViewDataSource`的`heightForRowAt`方法中返回Cell的高度。为了动态计算这个高度,我们需要根据Cell内部的布局和内容来...
例如,如果你的cell包含一个可变高度的UILabel,你可以这样做: ```swift func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat { let cell = tableView....
在实际应用中,我们经常需要动态调整UITableViewCell的高度,以便适应不同内容的显示需求,尤其是当单元格内部包含可变长度的文本时,如UILabel。`UITableViewCell自适应高度`就是指根据单元格内内容的大小自动调整...
在iOS开发中,实现`cell`的高度自适应是一项常见的需求,尤其在显示内容不固定或者内容长度可变的场景下。`cell`高度自适应可以让界面看起来更加灵活且美观。这里我们将深入探讨如何基于`Masonry`框架实现`...
在iOS应用中,当单元格内有可变内容,如多行文本、图像或者复杂的视图布局时,我们需要动态计算单元格的高度。传统的做法是重写`tableView(_:heightForRowAt:)`代理方法,根据数据源计算每个cell的高度。然而,这种...
在iOS应用开发中,滚动视图(如UITableView或UICollectionView)通常会显示一列可滚动的数据项,每个数据项通常有一个标题。在iOS 13.1中,开发者可以通过自定义滚动视图的标题来实现独特的用户体验。这可能涉及到...
同时,这种设计使得表格和控制器之间的依赖关系变得松散,提高了代码的可复用性和可维护性。 此外,代理模式还常用于实现回调,例如网络请求的完成通知。假设Demo中有网络请求任务,可能会有一个网络请求类(如...
它允许在单个视图中显示可变大小的单元格,因此特别适合创建如网格、瀑布流或照片墙这样的界面。UICollectionView的使用需要定义UICollectionViewCell和UICollectionViewFlowLayout,同样需要设置数据源和代理。 ...
6. **可变高度的UITableViewCell设计**: - 创建UILabel作为单元格的子视图。 - 在`heightForRowAtIndexPath:`方法中计算高度。 - 在`cellForRowAtIndexPath:`中设置UILabel的尺寸。 7. **UIView的圆角属性设置*...
标题提到的“ios 自定义复选按钮和单选按钮”是关于如何使用Objective-C(OC)编程语言来手写代码,创建一个可重用的控件,既能作为单选按钮也能作为复选按钮。这一话题涵盖了UI设计、自定义视图、状态管理等多个...
可滑动的UITableViewCell受流行的启发,该在实现。 预习 退出模式 .exit模式是邮箱应用程序中已知的原始行为。 切换模式 .toggle是另一种行为,其中单元格在滑动后会反弹。 安装 Swift软件包管理器(推荐) 是苹果...
为了显示带有箭头的可折叠效果,我们可能需要自定义UITableViewCell,添加一个扩展箭头的imageView,并在`tableView(_:cellForRowAt:)`中根据数据状态更新箭头的方向。 4. 展开与收起子列表: 在`tableView(_:...
它是由一个个单元格(UITableViewCell)组成的,每个单元格都可以单独定制。在描述中提到的“绘画时代理”实际上是指UITableViewDataSource和UITableViewDelegate这两个代理协议。通过遵循这些协议,开发者可以控制...