> 
 > 
 > 
Autolayout在UITableView中的坑
摘要：iOS发展到现在,iOS5的占有率已经很低了(估计多数还在使用iOS5系统的用户活跃度也不高吧),因此兼容最低版本iOS6.0也不会损失太多用户。同时,下一代大屏iPhone已经发售了,Autolayout绝对是其中一个重要的界面兼容手段。为了能尽快做好适配好新设备的工作,我相信学习Autolayout这门技术也是必不可少。我作为一个使用了Autolayout大约一周左右的初学者,就在这里记录一下一些要点吧。一、Autolayout的简要背景Autolayout这个东西是从i
iOS发展到现在,iOS5的占有率已经很低了(估计多数还在使用iOS5系统的用户活跃度也不高吧),因此兼容最低版本iOS6.0也不会损失太多用户。同时,下一代大屏iPhone已经发售了,Autolayout绝对是其中一个重要的界面兼容手段。为了能尽快做好适配好新设备的工作,我相信学习Autolayout这门技术也是必不可少。我作为一个使用了Autolayout大约一周左右的初学者,就在这里记录一下一些要点吧。
一、Autolayout的简要背景Autolayout这个东西是从iOS6开始才出现的,在没有Autolayout的远古年代,大家是用Autoresizing做一些简单的界面拉伸的。这里先说一下Autoresizing,这个东西支持width和height的四方向拉伸,也可以对x和y做一些简单的四方向对齐。当然,Autoresizing还是基于绝对坐标的,所以界面上的元素还是需要设置好对应的坐标。支持ib和代码设置,如下图
1self.view.autoresizingMask = UIViewAutoresizingFlexibleWidth|UIViewAutoresizingFlexibleH
可以看到代码其实就是设置UIViewAutoresizing枚举变量,代码也是比较简单的。利用Autoresizing就已经能很好适配了搭载iOS6的iPhone5(有部分界面还是需要多个containerview或者写代码手动调节的,不过并不复杂),那为何Apple还要多此一举推出Autolayout呢?从实用性来看,应对iPhone5之流,Autoresizing足矣,且有兼容性的优势。但是现在时代变了,Android满地开花的大屏手机(5吋以上才能称作大屏),Apple为了保持自有优势,我认为大屏设备和界面的大一统将会是未来战略(iPhone可以使用原来iPad的专用控件)。这必然导致界面的适配问题,最起码Autoresizing已经显得无力了,同时对于部分需要有横向界面的应用会有更复杂的调整工作。如果不使用Autolayout,改用代码手工适配的话,工作量也不算少,同时会需要大量的魔术数来定位坐标。这完全不是现代界面该有的开发方式,实在太原始了。随着iOS8的到来,Autoresizing的兼容性优势会逐渐消失,事实上要同时兼容4个大版本的iOS,这难度的确不小。因此,现在开始学习并使用Autolayout是一个不错的时机。除了上述因素,从开发工具来看,对于Autolayout的支持已经比Xcode5之前好了不少。其次,针对Autolayout的开源工具库也已经相对成熟,前人踩过的坑大多都可以找到对应解决方法。所以,我实在想不出一个拒绝Autolayout的理由。
二、Autolayout的基础知识如果大家对Android有所了解,应该知道他们是通过dp的相对坐标和一些布局来定位控件的(好吧,可能我用词不太正确)。但iOS的Autolayout思路和Android的布局思路,还是有很大的差异。Autolayout的本质是约束,通过设定足够多的约束条件,来得出每一个控件的最终坐标。约束条件之间不能相互矛盾,否则会出错抛出异常。条件之间的矛盾还是比较难描述的,这个我在下面的内容再举例说明。约束的条件有几种类别:1、大小(Width、Height、WidthEqually等)2、间隔(HorizontalSpacing等)3、对齐(TopEdges、HorizontalCenters等)在使用Autolayout的界面里,如果控件不添加任何约束的话,还是可以使用绝对坐标定位的。但是,Autoresizing和Autolayout在同一个界面层级是不能共存的,只能选择其一。不过实际操作上,Autolayout要实现某些Autoresizing的功能是完全可以的,但是步骤不一定比以前简单。对于一个控件来说,从前的定位是通过设置frame的4个变量来控制的。但在Autolayout的世界里,这些绝对的数值已经不那么重要了。Autolayout在运行时计算出这些数值也是需要最少2个约束,大多数情况还需要4个以上。2个约束的例子:系统的UIActivityView是固定大小的,所以只需要添加x和y的约束。3个约束的例子:UILabel类控件,其长度可以由系统计算文字数量和大小得出,所以width或者height的约束可以省去一个。其余两个约束就是x和y的约束,具体表现为HorizontalSpacing等。4个约束的例子实际上就是多了上述例子一个width或者height约束。从这些例子,可以得出一个结论,对于一个控件而言,x和y是不可能避免的约束,所以使用Autolayout的控件最少需要2个约束。当然,大多数情况是4个约束起步,同时还需要控件间的各种约束来构建一个完整的界面。同时在Autolayout的光环下,基本不再需要手动设置frame。使用Autolayout的控件,frame只是表示这个控件当前的坐标。只有相关的约束有变化或约束的控件发生变化,随之这frame也会变化。这些在InterfaceBuilder中可以很容易体现出来,你可以立即看到控件在任意情况下的变化。三、Autolayout实践应用这里的实践以ib为主,我在这里解释一下,设置Autolayout实际上有3种方法,分别是:ib、可视语言和传统代码。我分别说说这些方法的特点:1、ib直观简单,所见即所得,实时控制界面变化。系统还会提醒冲突和缺少约束,并给出修改建议(建议通常不是最好)。对于约束相对静态的界面,开发效率高。但在复杂页面中,常常是100+的约束,不是很友好。同时,对界面内的控件复用比较麻烦,造成大量相类似约束。某些控件不能直接往其添加子控件,如UILabel添加一个UIImageView到其中。2、可视语言需要编写代码,同时要求对Autolayout的体系比较熟悉。由于其语言样式可以比较容易看出控件间的约束关系,所以还是比传统代码直观,但还是无法预想运行时的变化。一次可以添加多个约束,并在运行时改变约束,但是不能完整实现所有约束功能。同时可视语言也有一些学习成本,没有对应的代码建议,所以需要额外的检查来保证语法正确。3、传统代码其实就是调用普通的API,参数比较多,但是可以实现Autolayout的所有功能。从代码量来看,要比可视语言多。这种方法更偏向于类似传统code界面,对于一个100+约束的界面,我想还是挺吃力的。不过,在复用性方面有一定的优势,和可视语言一样,可以在运行时改变约束。此外,使用PureLayout开源库可以在一定程度上简化代码。作为新手而言,通过ib来学习Autolayout是最友好的,可以很直观地观察界面的变化。刚开始时,最容易出现的问题就是遗漏了添加一些必要约束,造成期望与实际不符。ib能检查出约束是否完整,并给予建议,让新手迅速适应Autolayout的开发。
ib会提示警告和错误,警告一般不会在运行时产生异常,但错误是务必要解决的,因为运行时是一定会有异常的。
出现警告的原因一般是frame没有更新,这个可以直接update一下。
而出现错误的原因则是缺少必要约束或者是约束冲突。前者的解决方法是补全约束,后者的情况有点复杂。所谓的约束冲突就是没有办法同时满足所有约束,从而产生冲突。一般是通过删除一些约束,使所有约束都可以满足,个人不建议通过修改约束的优先级来解决。如非特殊情况,一般都是添加越少约束越好,这样思路越清晰,同时对于运行效率都有一定帮助。从目前经验来看,一般的界面开发,的确是用不到优先级的(楼主目前的经验)。可以看到这些建议不是唯一的,是选择其中一个来补全约束的。新手可以选择系统的建议,看看补充了什么约束,但长远来说,不建议直接使用系统建议补充的约束。个人认为ib的这些警告和错误对于开发界面来说,是极其高效的,但建议却不是非常智能。特别是补充约束的建议,通常和你心中期望的界面是差距很大的。对于单个控件,可以直接通过菜单或者右下角来添加约束,
右下角的按钮还能一下添加多个约束
对于控件间的约束则需要按住Command+点击,选中多个控件再添加约束。
约束其实也是对象,因此会出现在坐标的列表
同时,约束也支持outlet约束为什么也需要outlet?显然是为了调用某些方法,而降低了遍历约束难度。在ib上拉几个控件,就可以完成了上面的简单实践了。但是,光这些是不足以完成适配不同屏幕的开发。四、Autolayout的复杂约束Autolayout中的UILabel类控件大小是自适应的,因此一般不需要指定width和height。而且,固定width和height的这类约束要尽量少用(UIImageView这类还是不反对使用),这类约束一般会限制你的思维。如何多个UILabel并排在同一行,但是行宽有限,同时每个UILabel都有较多的字数。那么应该如何控制某个UILabel可以优先完整显示?这时就要利用抗拉伸和抗压缩的优先级了
还有一个相对特别的属性是比例,支持输入类似“16:9”这类有无穷小数的值。具体应用如下,
这个约束可以使控件跟随父视图的大小按比例变化,有类似于之前Autoresizing的效果。既然约束也是对象,运行动态改变约束的值,则可以达到更多复杂的控制。为了操作方便,我们可以为一些约束创建outlet。同时在运行时,根据需要动态改变约束的数值或者移除添加约束等,这时,为了操作方便,我使用了一个开源库PureLayout。利用PureLayout就可以很方便地,对约束进行操作,其API要比系统的友好不少。github地址:https://github.com/smileyborg/PureLayout。暂时发现的坑:1、在tableView的tableHeaderView使用Autolayout时务必要注意,不要使用严格的约束来限制了整个view的大小,否则运行时十有八九会出错。还有,改变tableView大小时,也有一些错位的情况,暂时无解。tableFooterView的情况未测试,估计应该一样。2、在iOS6上约束的容错性更差,更容易报异常,例如有两个相同约束,iOS6上会有异常断点,但不会崩溃;iOS7上无任何异常出错。当然存在多个相同约束是不规范的行为,编写约束时应尽量做到用最少的约束去达到最佳的效果。3、Autolayout也是有性能问题的,目前我在iOS6的iPod Touch4上测试100个左右约束的界面。在刷新tableView和添加视图等操作时,能明显感觉到延迟。经过一系列操作,甚至会出现1分钟以上的延迟,这时无法接受的。可以得出一个结论,Autolayout在约束较多的时候,在低端机器上也是会造成性能瓶颈的。不过,幸运的是,我在iOS7上的4s运行同样的界面,就几乎没有延迟。随着低端设备被淘汰,这个问题会得到缓解的。最后的一个建议是,不要过早地使用Autolayout优化,因为实际上有些界面使用Autoresizing也是能很好地完成适配工作的。同时,对于tableView这类控件使用Autolayout,需要多加留心。
以上是的内容，更多
的内容，请您使用右上方搜索功能获取相关信息。
若你要投稿、删除文章请联系邮箱：zixun-group@service.aliyun.com,工作人员会在五个工作日内给你回复。
云服务器 ECS
可弹性伸缩、安全稳定、简单易用
&40.8元/月起
预测未发生的攻击
&24元/月起
为您提供0门槛上云实践机会
你可能还喜欢
你可能感兴趣
阿里云教程中心为您免费提供
Autolayout在UITableView中的坑相关信息，包括
的信息，所有Autolayout在UITableView中的坑相关内容均不代表阿里云的意见！投稿删除文章请联系邮箱：zixun-group@service.aliyun.com，工作人员会在五个工作日内答复
售前咨询热线
支持与服务
资源和社区
关注阿里云
International摘自：http://codingobjc.com/blog//shi-yong-autolayoutshi-xian- uitableviewde-celldong-tai-bu-ju-he-ke-bian-xing-gao/index.html
附：真心感激衔接国际技术的同行们。
本文翻译自：
有人在上问了一个问题：
如何在UITableViewCell中使用Autolayout来实现Cell的内容和子视图自动计算行高，并且能够保持平滑滚动的？
这 个问题得到了300+的支持和450+的收藏，答案得到了730+的支持，很详细的说明了如何在iOS7和iOS8上实现UITableView的动态行 高功能，并且这个答案对实现UICollectionView的动态行高也具有参考意义。所以在这里将这个答案翻译了一下，希望对大家有所帮助。以下是答 案的全文翻译：
答案略长，如果你不喜欢细读，可以直接看这两个示例的代码：
&- iOS8以上才支持
不管你是在哪个iOS版本上做开发，以下步骤中的前两个步骤都是必须的：
1、设置好布局约束条件
在UITableViewCell子类中，添加布局约束，使得cell子视图的边缘固定(pin)到cell的contentView的边缘（最重要的是要有顶部和底部的边距约束条件）。注意：不要将子视图的边距约束固定到cell本身上了，只能固定到cell的contentView上！&确 保每个子视图垂直方向上的内容压缩阻力(compression resistance)和吸附性约束(hugging constraints)没有被你添加的更高优先级的约束条件覆盖，让这些子视图的固有内容尺寸(intrinsic content size)来驱动contentView的高度。（）
记住，要点是让cell的子视图与contentView之间产生垂直的连结，让它们能够对contentView&施加压力&，使contentView扩展以适合它们的尺寸。下面用一个cell和一些子视图作为示例，展示了你的一些(不是全部！)布局约束应该看起来是什么样的：
可以设想，随着更多的文本被添加到上例中&Multi-line body&那个label上，它需要垂直地增高以适合文本，这将有效地迫使cell的高度增加。（当然，你需要正确地设置约束条件，以使其正常的工作！）
如何设置正确的约束条件，绝对是使用Autolayout实现动态行高时最难最重要的 部分。如果弄错了，它就可能无法正常工作&&所以，不要着急，慢慢来！我建议你用代码来设置布局约束，这样你就完全知道每个布局约束被加到了什么地方，出 问题时也更容易调试。特别如果使用一些优秀开源库，可以让用代码设置约束和用Interface Builder设置约束一样简单直观，并且功能还更强大。这里也有一个由我设计和维护的专用库：
如果你用代码来设置布局约束，你应该在UITableViewCell子类的updateConstraints方法里面一次性完成。注意，updateConstraints可能不止被调用一次，因此要避免重复添加相同的布局约束。在updateConstraints中，可以将添加布局约束的代码包在一个if条件语句中(比如用一个叫didSetupConstraints的布尔属性，运行一次添加布局约束的代码后就将其设置为YES)，以确保不重复添加相同的布局约束。另外，更新已有布局约束的代码（比如调整布局约束的constant属性），也应该将它们放置在updateConstraints&中，但是要在didSetupConstraints条件语句的外面，这样才可以确保每次调用的时候都会被执行。
2. Cell使用具有唯一性的重用标示符
在 cell里面，为每一组特定的约束条件，使用一个特定的cell重用标示符。换句话说，如果cell有多种不同的布局，每一种布局应当有其对应的重用标示 符。（当cell有多种不同数量的子视图的时候，或者子视图以一种独特的方式布局的时候，这些情况下你就需要使用一个新的重用标示符。）
例 如，要在一个cell中显示一条email消息，可能会有4种独特的布局：第一种，只有主题的消息；第二种，带主题和正文的消息；第三种，带主题和图片附 件的消息；第四种，带主题、正文和图片附件的消息。每一种布局都需要完全不同的布局约束才能实现。因此，一旦cell被初始化并且布局约束被加到其中任意 一种类型的cell上后，cell应当得到一个唯一的重用标示符来指定该cell类型。这就意味着，当你dequeue重用一个cell的时候，该类型 cell的布局约束已经添加好了，可以直接使用。
注意，由于固有内容尺寸的不同，具有相同布局约束的cell仍然可能具有不同的高度！不要混淆了布局（不同的约束）和由不同内容尺寸而计算出（通过相同的布局约束来计算）的不同视图frame这两个概念，它们根本是完全不同的两个东西。
不要将拥有不同布局约束条件的cell丢到同一个重用池当中（也就是使用相同的重用标示符），然后又在每次dequeue过后将旧的约束移除，又从头开始重新添加约束。自动布局引擎内部并没有被设计来可以处理大规模的约束更改，你会看到大量的性能问题。
iOS8 - Self-Sizing Cells
3. 启用估算行高
在iOS8上，苹果将许多在iOS8之前比较难实现的东西都内置实现了。为了让cell实现self-sizing的机制，必须先将tableView的rowHeight属性设置为常量UITableViewAutomaticDimension。然后，只需将tableView的estimatedRowHeight属性设置为非零值即可开启行高估算功能，例如：
self.tableView.rowHeight = UITableViewAutomaticDimension;
self.tableView.estimatedRowHeight = 44.0; // 设置为一个接近&平均&行高的值
这 样做就为tableView上还没有显示在屏幕上的cell提供了一个临时的估算的行高。然后，当cell即将滚入屏幕范围内的时候，会计算出实际的高 度。为了确定每一行的实际高度，tableView会自动让每个cell基于其contentView的已知固定宽度（tableView的宽度，减去其 他额外的，像section index或accessoryView这些宽度）和被加到contentView及其子视图上的自动布局约束规则来计算contentView的高度。一旦真正的行高被计算出来后，旧的估算的行高会被更新为这个真实的行高（并且其他任何需要对tableView的contentSize或contentOffset的更改都自动替你完成了）。
一般来说，行高估算值不需要太精确&&它只是被用来修正tableView中滚动条的大小的，当你在屏幕上滑动cell的时候，即便估算值不准确，tableView还是能很好地调节滚动条。将tableView的estimatedRowHeight属性设置成（在viewDidLoad或类似的方法中）一个接近于&平均&行高的常量值即可。只有行高变化很极端的时候（比如相差一个数量级），才会在滚动时产生滚动条&跳跃&的现象。这个时候，你才应当实现tableView:estimatedHeightForRowAtIndexPath:方法，为每一行返回一个更精确的估算值。
iOS7支持（需要自己实现cell尺寸自适应功能）
3. 完成一个完整的布局过程 & 计算cell的高度
首 先，为每一个cell都初始化一个离屏(offscreen)实例，为每个重用标示符实例化一个与之对应的cell实例，这些cell完全用于高度计算。 （离屏表示cell的引用被存储在view controller的一个属性或实例变量之中，并且这个cell绝对不会被用作tableView:cellForRowAtIndexPath:方法的返回值以实际呈现在屏幕上。）接着，这个cell的内容（例如，文本、图片等等）还必须和会被显示在table view中的内容完全一致。
然后，强制cell立即更新子视图的布局，再用cell的contentView调用systemLayoutSizeFittingSize:方法计算出cell所需的高度是多少。使用UILayoutFittingCompressedSize参数可以得到适合cell中所有内容所需的最小尺寸。然后其高度就可以作为tableView:heightForRowAtIndexPath:方法的返回值。
4. 使用估算的行高
如果你的table view超过了几十行，你会发现自动布局约束的解决方式在第一次加载table view的时候会迅速地卡住主线程。因为，在第一次加载过程中，每一行都会调用tableView:heightForRowAtIndexPath:方法（为了计算滚动条的尺寸）。
iOS7中，你可以（也绝对应该）使用table view的estimatedRowHeight属性。这样会为还不在屏幕范围内的cell提供一个临时估算的行高值。然后，当这些cell即将要滚入屏幕范围内的时候，真实的行高值会被计算出来（通过tableView:heightForRowAtIndexPath:方法），估算的行高就会被替换掉。
一般来说，行高估算值不需要太精确&&它只是被用来修正tableView中滚动条的大小的，当你在屏幕上滑动cell的时候，即便估算值不准确，tableView还是能很好地调节滚动条。将tableView的estimatedRowHeight属性设置成（在viewDidLoad或类似的方法中）一个接近于&平均&行高的常量值即可。只有行高变化很极端的时候（比如相差一个数量级），才会在滚动时产生滚动条&跳跃&的现象。这个时候，你才应当实现tableView:estimatedHeightForRowAtIndexPath:方法，为每一行返回一个更精确的估算值。
5. 缓存行高（如果需要）
如果上面提到的你都做了，但是tableView:heightForRowAtIndexPath:的 性能仍然慢的不可接受。非常不幸，你需要给行高做一些缓存（这是苹果的工程师们给出的改进建议）。大体的思路是，第一次计算时让自动布局引擎解析约束条 件，然后将计算出的行高缓存起来，以后所有对该cell的高度的请求都返回缓存值。当然，关键还要确保任何会导致cell高度变化的情况发生时你都清除了 缓存的行高&&这通常发生在cell的内容变化时或其他重大事件发生时（比如用户调节了动态类型文本大小(Dynamic Type text size)的滑动条）。
iOS7示例代码（包含详细的注释）
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
// 判断indexPath对应cell的重用标示符，
// 取决于特定的布局需求（可能只有一个，也或者有多个）
NSString *reuseIdentifier = ...;
// 取出重用标示符对应的cell。
// 注意，如果重用池(reuse pool)里面没有可用的cell，这个方法会初始化并返回一个全新的cell，
// 因此不管怎样，此行代码过后，你会可以得到一个布局约束已经完全准备好，可以直接使用的cell。
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:reuseIdentifier];
// 用indexPath对应的数据内容来配置cell，例如：
// cell.textLabel.text = someTextForThisC
// 确保cell的布局约束被设置好了，因为它可能刚刚才被创建好。
// 使用下面两行代码，前提是假设你已经在cell的updateConstraints方法中设置好了约束：
[cell setNeedsUpdateConstraints];
[cell updateConstraintsIfNeeded];
// 如果你使用的是多行的UILabel，不要忘了，preferredMaxLayoutWidth需要设置正确。
// 如果你没有在cell的-[layoutSubviews]方法中设置，就在这里设置。
// cell.multiLineLabel.preferredMaxLayoutWidth = CGRectGetWidth(tableView.bounds);
return cell;
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath
// 判断indexPath对应cell的重用标示符，
NSString *reuseIdentifier = ...;
// 从cell字典中取出重用标示符对应的cell。如果没有，就创建一个新的然后存储在字典里面。
// 警告：不要调用table view的dequeueReusableCellWithIdentifier:方法，因为这会导致cell被创建了但是又未曾被tableView:cellForRowAtIndexPath:方法返回，会造成内存泄露！
UITableViewCell *cell = [self.offscreenCells objectForKey:reuseIdentifier];
if (!cell) {
cell = [[YourTableViewCellClass alloc] init];
[self.offscreenCells setObject:cell forKey:reuseIdentifier];
// 用indexPath对应的数据内容来配置cell，例如：
// cell.textLabel.text = someTextForThisC
// 确保cell的布局约束被设置好了，因为它可能刚刚才被创建好。
// 使用下面两行代码，前提是假设你已经在cell的updateConstraints方法中设置好了约束：
[cell setNeedsUpdateConstraints];
[cell updateConstraintsIfNeeded];
// 将cell的宽度设置为和tableView的宽度一样宽。
// 这点很重要。
// 如果cell的高度取决于table view的宽度（例如，多行的UILabel通过单词换行等方式），
&- iOS8以上才支持
阅读(...) 评论()开发UITableViewCell的autolayout遇到的坑 - 简书
开发UITableViewCell的autolayout遇到的坑
首先把 cell xib中的控件 autolayout设置好后，保证xcode看起来没有错误。小白的我以为这样就没问题了 点击运行。 发现后台打印了很多警告信息，仔细一看貌似多约束。
看看了模拟器的界面貌似没什么问题。 出于强迫症和好奇心。
我对xib的文件进行了 N次修改。 期间出了很多次页面错乱。 并且我一直保持xib的布局没有警告信息。
最后我排查下 完成了布局和autolayout 后台也不打印警告了。这里总结下我发现的两个问题。
1、UIIabel 不能设置宽度，因为系统会随着label的内容大小自动调节 label的宽度，如果你再设置宽度的话。就会发生优先级的冲突。
2、imageView 是布局在cell的垂直居中的。 并且top和bottom都有space。但我怕图片变形又设置了固定高度。这样运行起来会导致后台报警告。 表示系统重新修复了 imageView的高度。我降低了 imageView的高度优先级。我猜想是 在iphone6的情况下（我的模拟器设备）imageView的高度会生效。 但是在别的设备，imageView 会优先满足top和bottom的space 约束从来 拉伸或缩小 图片。
自己自学阶段都是自己在谷歌搜索理解的不知道对不对。 懵懵懂懂。 明天买本autolayout的书 好好恶补下。
下一级段着手优化 iOS对图片的处理。 app 常常会因为cell中图片的加载 接到内存溢出的警告，而且肉眼感觉图片的分辨率怪怪的。
一个程序员
用到的组件1、通过CocoaPods安装项目名称项目信息AFNetworking网络请求组件FMDB本地数据库组件SDWebImage多个缩略图缓存组件UICKeyChainStore存放用户账号密码组件Reachability监测网络状态DateTools友好化时间MBP...
发现 关注 消息 iOS 第三方库、插件、知名博客总结 作者大灰狼的小绵羊哥哥关注
09:45字数 61697阅读 3316评论 2喜欢 85 用到的组件 1、通过CocoaPods安装 项目名称 项目信息 AFNetworking 网络请求组件 FM...
用到的组件1、通过CocoaPods安装项目名称项目信息 AFNetworking网络请求组件 FMDB本地数据库组件 SDWebImage多个缩略图缓存组件 UICKeyChainStore存放用户账号密码组件 Reachability监测网络状态 DateTools友好...
原文地址：https://www.raywenderlich.com/129059/self-sizing-table-view-cells转载地址：http://www.rockerhx.com//-Self-sizing-Tabl...
UI下拉刷新EGOTableViewPullRefresh- 最早的下拉刷新控件。SVPullToRefresh- 下拉刷新控件。MJRefresh- 仅需一行代码就可以为UITableView或者CollectionView加上下拉刷新或者上拉刷新功能。可以自定义上下拉刷...
平面设计：3个工作日 概算报价：1个工作日 图纸深化：7个工作日 预算报价：1个工作日 消防报审：10个工作日 建委报审：7个工作日 物业审批：3个工作日 施工期间：45日 消防验收：3个工作日 物业验收：1个工作日
厨房翻新10大注意事项 二手房翻新或者老屋改造的时候，厨房肯定是重点改造区域，因为作为油烟重灾区，厨房的使用时间一长，就容易变得黑漆漆的，刚好可以趁着房屋翻新这个机会，让它“改头换面”一次。但是在开工前，先跟着三联小编一起来了解下厨房翻新的十大注意事项，掌握一些厨房墙面翻新...
什么是拆书帮&拆书家 1． 拆书帮是一群美的人他们在一起成长，他们热爱蜕变的感觉。一起释放学习促进者的能量。他们分享，传播，给予，付出。 2． 拆书帮的拆书家们会像1927年麦肯锡提出的咨询师的概念一样，以后会有一个新的职业叫做拆书家。 3． 拆书帮是一个公益性的自组织，我...
每个人都想从事与自己兴趣爱好相关的职业，如果你擅长计算机你有没有想过让它成为你的职业方向呢？如果你擅长与人沟通，你有没有想过成为一名出色的公关呢？如果你擅长于设计，你有没有想过成为一名优秀的设计师呢？江苏慧库天下软件科技有限公司将会是你不二之选，他为不一样的你展示不一样的平...
午加餐：麦片晚水果：葡萄 参考目标： 1份豆2份肉3份“新鲜”水果4份谷物/薯5份蔬菜，深绿色叶菜最好6杯水 今日总结： 食物种类：26 - 挺丰富的！ 量的配比：123456 - 都满足
