https://www.cnblogs.com/fxwl/p/5961372.html
div区域
8、盒子模型的相关属性
- margin（外边距/边界）
- border（边框）
- padding（内边距/填充 ）
- space、gap间隙
- axis
http://www.cocoachina.com/ios/20141026/10045.html
https://www.jianshu.com/p/d8d29e30d2d4
layoutMargins和preservesSuperviewLayoutMargins
https://www.jianshu.com/p/4237bd89f521
UILayoutGuide的用法
https://www.tuicool.com/articles/nQ36naR
干什么？
- 替代之前视图之间的空视图
- 封装多个视图到一个模块
为什么要替代空视图？
先来举一个需求，在一行上面显示两个固定宽度的按钮，然后剩下的三个空间(左边按钮左边，两个按钮中间，右边按钮的右边)要宽度一样。想要实现这个需求，一般会想到加三个空的 UIView 放到那，然后让他们宽度相等，这样就可以实现这个需求了。
但是这样做的方法很笨，因为 UIView 是可以接受事件的，而我们这里用了它却只是用来占位置。而且这样做也会有性能消耗，代码可读性不太好。
http://www.cocoachina.com/ios/20141026/10045.html
setContentHuggingPriority
preferredContentSize
class HMPopOverViewC: UIViewController
extension UIView {
/* The size fitting most closely to targetSize in which the receiver's subtree can be laid out while optimally satisfying the constraints. If you want the smallest possible size, pass UILayoutFittingCompressedSize; for the largest possible size, pass UILayoutFittingExpandedSize.
Also see the comment for UILayoutPriorityFittingSizeLevel.
*/
@available(iOS 6.0, *)
open func systemLayoutSizeFitting(_ targetSize: CGSize) -> CGSize // Equivalent to sending -systemLayoutSizeFittingSize:withHorizontalFittingPriority:verticalFittingPriority: with UILayoutPriorityFittingSizeLevel for both priorities.
@available(iOS 8.0, *)
open func systemLayoutSizeFitting(_ targetSize: CGSize, withHorizontalFittingPriority horizontalFittingPriority: UILayoutPriority, verticalFittingPriority: UILayoutPriority) -> CGSize
}
symbolImageView.setContentHuggingPriority(.defaultLow, for: .horizontal)
titleLabel.setContentHuggingPriority(.defaultLow, for: .horizontal)
titleLabel.setContentCompressionResistancePriority(.defaultLow, for: .horizontal)
rightStackView.setContentHuggingPriority(.required, for: .horizontal)
stackView.setContentHuggingPriority(.required, for: .horizontal)
http://www.cocoachina.com/ios/20160229/15455.html
Auto Layout压缩阻力及内容吸附讲解
大致的意思就是我们自定义的视图在默认情况下，它的固有尺寸是返回(UIViewNoIntrinsicMetric，UIViewNoIntrinsicMetric)，也就是(-1,-1)，只有我们根据自定义视图本身的Content来重写该方法，我们自定义的视图才能明确的知道他在显示系统中该展示的大小。
UILabel和UIButton等这些控件，系统默认是根据他们的内容实现了固有尺寸，所以我们在使用的时候只需要确定origin或者Center它们就能正确的显示。
由此可见，固有尺寸是为了实现视图的 大小自适应 而存在的。
extension NSString {
@available(iOS 7.0, *)
open func size(withAttributes attrs: [NSAttributedStringKey : Any]? = nil) -> CGSize
@available(iOS 7.0, *)
open func draw(at point: CGPoint, withAttributes attrs: [NSAttributedStringKey : Any]? = nil)
@available(iOS 7.0, *)
open func draw(in rect: CGRect, withAttributes attrs: [NSAttributedStringKey : Any]? = nil)
}
@interface NSString (NSExtendedStringDrawing)
- (void)drawWithRect:(CGRect)rect options:(NSStringDrawingOptions)options attributes:(nullable NSDictionary<NSAttributedStringKey, id> *)attributes context:(nullable NSStringDrawingContext *)context NS_AVAILABLE(10_11, 7_0);
- (CGRect)boundingRectWithSize:(CGSize)size options:(NSStringDrawingOptions)options attributes:(nullable NSDictionary<NSAttributedStringKey, id> *)attributes context:(nullable NSStringDrawingContext *)context NS_AVAILABLE(10_11, 7_0);
@end
edgesForExtendedLayout
全屏布局
https://www.jianshu.com/p/879fe48b0eb7
var layoutGuide: UILayoutGuide {
if #available(iOS 11, *) {
return safeAreaLayoutGuide
} else {
return layoutMarginsGuide
}
}
|
var edgesForExtendedLayout: UIRectEdge { get set } |
|
|
Description |
The edges that you extend for your view controller. Instead of this property, use the safe area of your view to determine which parts of your interface are occluded by other content. For more information, see the safeAreaLayoutGuide and safeAreaInsets properties of UIView. |
UIViewController
@available(iOS 7.0, *)
open var edgesForExtendedLayout: UIRectEdge // Defaults to UIRectEdgeAll
@available(iOS 7.0, *)
open var extendedLayoutIncludesOpaqueBars: Bool // Defaults to NO, but bars are translucent by default on 7_0.
@available(iOS, introduced: 7.0, deprecated: 11.0, message: "Use UIScrollView's contentInsetAdjustmentBehavior instead")
open var automaticallyAdjustsScrollViewInsets: Bool // Defaults to YES
open var layoutMargins: UIEdgeInsets
self.view.layoutGuides
if #available(iOS 11.0, *){
self.table.contentInsetAdjustmentBehavior = .never
} else {
self.automaticallyAdjustsScrollViewInsets = false
}
// Called just before the view controller's view's layoutSubviews method is invoked. Subclasses can implement as necessary. The default is a nop.
- (void)viewWillLayoutSubviews
{
[super viewWillLayoutSubviews];
_codeReader.previewLayer.frame = self.view.bounds;
}
lable.preferredMaxLayoutWidth = KScreenWidth;
[footerView systemLayoutSizeFittingSize:UILayoutFittingCompressedSize].height;
因为iPhoneX的产生，原本的导航栏再也不是44了，那么会出现什么问题呢？在隐藏导航栏的页面，原本的高度要向上调整一个导航栏+状态栏的高度。那么iPhoneX的导航栏高度不是44了，我们需要手动获取，
有导航栏的，代码如下：
//获取状态栏的rect
CGRect statusRect = [[UIApplication sharedApplication] statusBarFrame];
//获取导航栏的rect
CGRect navRect = self.navigationController.navigationBar.frame;
那么导航栏+状态栏的高度
statusRect.size.height+navRect.size.height
-(float)mTabbarHeight{
//Tabbar高度
return self.tabBarController.tabBar.bounds.size.height;
}
extension UIViewController {
open var tabBarItem: UITabBarItem! // Automatically created lazily with the view controller's title if it's not set explicitly.
open var tabBarController: UITabBarController? { get } // If the view controller has a tab bar controller as its ancestor, return it. Returns nil otherwise.
}
https://www.cnblogs.com/jx66/p/6061641.html
adjustsFontSizeToFitWidth=YES.
// these next 3 properties allow the label to be autosized to fit a certain width by scaling the font size(s) by a scaling factor >= the minimum scaling factor
// and to specify how the text baseline moves when it needs to shrink the font.
open var adjustsFontSizeToFitWidth: Bool // default is NO
open var baselineAdjustment: UIBaselineAdjustment // default is UIBaselineAdjustmentAlignBaselines
@available(iOS 6.0, *)
open var minimumScaleFactor: CGFloat // default is 0.0
let size = label.text?.size(font: UIFont.boldSystemFont(ofSize: 15), maxWidth: 100)
extension String {
func size(font: UIFont, maxWidth: CGFloat = UIScreen.width) -> CGSize {
let label = UILabel()
label.text = self
label.font = font
label.numberOfLines = 0
return label.sizeThatFits(CGSize(width: maxWidth, height: CGFloat(Int.max)))
}
}
label.translatesAutoresizingMaskIntoConstraints = false
label.adjustsFontSizeToFitWidth = true
cell.layoutMargins = UIEdgeInsetsZero;
cell.separatorInset = UIEdgeInsetsZero;
CGSize size = [singleCell.contentView systemLayoutSizeFittingSize:UILayoutFittingCompressedSize];
UILayoutFittingExpandedSize
/* The size fitting most closely to targetSize in which the receiver's subtree can be laid out while optimally satisfying the constraints. If you want the smallest possible size, pass UILayoutFittingCompressedSize; for the largest possible size, pass UILayoutFittingExpandedSize.
Also see the comment for UILayoutPriorityFittingSizeLevel.
*/
@available(iOS 6.0, *)
open func systemLayoutSizeFitting(_ targetSize: CGSize) -> CGSize // Equivalent to sending -systemLayoutSizeFittingSize:withHorizontalFittingPriority:verticalFittingPriority: with UILayoutPriorityFittingSizeLevel for both priorities.
Return Value
The optimal size for the view based on the provided constraint priorities.
Discussion
Use this method when you want to prioritize the view's constraints when determining the best possible size of the view. This method does not actually change the size of the view.
self-sizing table view cell
https://*.com/questions/18746929/using-auto-layout-in-uitableview-for-dynamic-cell-layouts-variable-row-heights/18746930#18746930
Conceptual Description
The first 2 steps below are applicable regardless of which iOS versions you are developing for.
1. Set Up & Add Constraints
In your UITableViewCell subclass, add constraints so that the subviews of the cell have their edges pinned to the edges of the cell's contentView (most importantly to the top AND bottom edges). NOTE: don't pin subviews to the cell itself; only to the cell's contentView! 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. (Huh? Click here.)
Remember, the idea is to have the cell's subviews connected vertically to the cell's content view so that they can "exert pressure" and make the content view expand to fit them. Using an example cell with a few subviews, here is a visual illustration of what some (not all!) of your constraints would need to look like:
You can imagine that as more text is added to the multi-line body label in the example cell above, it will need to grow vertically to fit the text, which will effectively force the cell to grow in height. (Of course, you need to get the constraints right in order for this to work correctly!)
Getting your constraints right is definitely the hardest and most important part of getting dynamic cell heights working with Auto Layout. If you make a mistake here, it could prevent everything else from working -- so take your time! I recommend setting up your constraints in code because you know exactly which constraints are being added where, and it's a lot easier to debug when things go wrong. Adding constraints in code can be just as easy as and significantly more powerful than Interface Builder using layout anchors, or one of the fantastic open source APIs available on GitHub.
- If you're adding constraints in code, you should do this once from within the updateConstraints method of your UITableViewCell subclass. Note that updateConstraints may be called more than once, so to avoid adding the same constraints more than once, make sure to wrap your constraint-adding code within updateConstraints in a check for a boolean property such as didSetupConstraints (which you set to YES after you run your constraint-adding code once). On the other hand, if you have code that updates existing constraints (such as adjusting the constant property on some constraints), place this in updateConstraints but outside of the check for didSetupConstraints so it can run every time the method is called.
2. Determine Unique Table View Cell Reuse Identifiers
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. (A good hint that you need to use a new reuse identifier is when your cell variant has a different number of subviews, or the subviews are arranged in a distinct fashion.)
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 cell types, the cell should get a unique reuse identifier specific to that cell type. This means when you dequeue a cell for reuse, the constraints have already been added and are ready to go for that cell type.
Note that due to differences in intrinsic content size, cells with the same constraints (type) 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.