iOS 布局用 Frame 用 AutoLayout (Masonry)？

最终都是 Frame，那为啥不用 Masonry 呀？
开发效率，易用性，功能，可读性都完爆 Frame 了吧。
Frame 在特定场景下有用，通常情况还是用 Masonry 吧

第一个人适合用机器码写 iOS 程序，反正最后 objc 都是机器码

AutoLayout

@kera0a 那位工程师说中间过程会有运算的损耗，用 frame 最直接直观 :(

当然是 AutoLayout，后面还会转向 SwiftUI，Frame 真的 out 了

都用

跟团队的大方向走。autolayout 也可以写的很烂。frame 一般来说都要根据屏幕宽度动态计算。autolayout 却不用。autolayout 滥用会导致性能问题。详细可以看看 wwdc 高性能 autolayout

这确定不是 2014 年的帖子吗...

现在居然还有 iOS 新人，也是不容易了。话说，现在入手 iOS 不应该是从 Swift 入手的么，ObjC 已经是二等公民了。

@kera0a #1 无论用什么，反正最后都是 0 和 1，哈哈

能做到任意列表点击状态栏滚到顶部保持 fps55 以上，都不算影响效率

仿佛回到了五年前....现在还有讨论这个的？
现在的设备 99%的情况下抠不出来这点性能区别。开发效率优先，真的要优化也是出现性能瓶颈时优化。

一起用呗，干嘛定那么死。简单页面 autolayout,复杂的用 frame. 做复杂动画的用 frame

@MrStark T_T 公司项目用 OC，不用 Swift，他们说用了体积会变大，而且编译慢，生态也一般

frame

> AutoLayout 支持的观点是：Frame 布局，一连串数字加起来可读性有点差，维护麻烦。

这个观点太逞强了

逞强 --> 勉强

苹果一直在优化 autolayout 的性能，这里一般不会成为瓶颈的，用吧没事。或者用 stackview 取代一部分 autolayout

把他们都打一顿 然后上 SwiftUI (狗头

我建议你们公司 iOS 换一批人，9012 了，还不接受 autolayout、swift

建议使用机器码编程，运行效率高，而且反正 swift、objc 最终都会转换成机器码。

@353943780 Swift 生态一般？能用的库已经一大堆了

爱咋写咋写，互相先总结下好处不行么？

我支持 autolayout

不好意思，我只用 frame

布局约束本身可读性就不高，只要是写代码，你就是用 MAS 也没 Frame 让我看着舒服

楼上拿 SWIFTUI 来抵制 frame 的，真的是 50 步笑百步

@yeziahehe 不好意思，现在是 2019 年，

我完全接受 SWIFTUI，但绝不接受目前版本苹果提供的自动布局

@353943780 一些比较新的库已经 Swift Only 了，包括苹果推出的比如 Combine、RealityKit、SwiftUI。

可以我的 AutoLayout 助手 CTVFL，我得比有的都好用哈。不是 Swift 的

https://github.com/WeZZard/CTVFL

Masonry or Snapkit，只有在性能需要时使用 Frame
我觉得 Autolayout 可读性和开发效率更高

说用 frame 的 可能是没接触过其他平台的布局方案
说实话 我连 autolayout 都不满意

同样的方案 用 frame 实现要比 autolayout 慢的多 代码量也更多
iOS10 以后 autolayout 列表性能比之前强太多了
非列表页面 frame 更没有优势

非要说 AL 不好，用 Frame，还不如上 Flexlayout （ yoga ）
Frame 从效率层面屁都不是，动态 layout 更是被吊打，你只是随便弄个 View 放在上面当我没说

当真还有用 frame 的呀 真 iphone 4 时代的即视感

我用过最好用的是 TangramKit

主用 frame 页面控制比较灵活 我是不会相信苹果的 autolayout 的

AutoLayout 啊，这年代了，用 Frame 看代码脑瓜疼啊。

Masonry(Snapkit)多好用呀。

我用 flutter

SwiftUI 才是未来

我写 iOS 代码的时候，一直使用 Masonry 来写布局， 比较灵活。
大部分页面比较简单，直接使用 Masonry 灵活、快速。

缺点就是 :
1. 写复杂界面的时候，代码一坨一坨的。我选择将 Masonry 封装到具体的 View 来简化 ViewController 页面代码。
2. 列表页，尤其是非常复杂、由服务器动态控制布局的列表页，滑动起来比较卡顿。我选择使用 YYLabel 库，在很复杂的页面不使用 Masonry。

因为我是 Android 过去写 iOS 的 ， 写布局用 Masonry 很舒服。
最主要的是 iOS 只有我一个人会写，我想用啥就用啥，舒服的一批(当然最终的效果是符合产品经理和用户的预期的)。

这年代还用 frame 的确实有点不思进取了

请让坚持 Frame 的童鞋联系我，我想和他好好探讨下人生

@StubbornC 来吧，我

@matou ？？？？？ 不思进取？？？


你确定你用的来 frame ？？？？

页面布局部分 iOS 一直是很落后的 frame -> AutoLayout 是过度 还在使用 frame 布局的只能说你喜欢你继续

@MarginK 请问你们 frame 是怎么适配不同比例屏幕，以及横屏、可能存在的刘海屏上下颠倒的安全区问题？

请使用 ConstraintLayout

看来我真的老了，我不是很喜欢用 masonry，不是因为性能，就是习惯问题…估计楼主公司的人争论也就是个习惯问题，然后找个理由给自己的习惯背书…

可能不嫌累吧。像楼上所说，现在应该讨论 UIKit 和 SwiftUI 的问题，虽然 UIKIt 的玩意实现几个协议就能用了

纯代码:Frame->Masonry，Xib:Autoresize->Autolayout, 从纯代码计算，到所见即所得; 原因是设备配置高了，开发效率也要提高。

拥抱变化（狗头

挺有意思的，一个东西加点壳加点糖都能引起对立。。

@feikaras C 和 C++ 也对立

用 Flex Box 爽 一直用一直爽

什么年代了还争这个，SwiftUI，FlexLayou，Texture 了解一下

都什么年代了

iOS9 的 layoutAnchor 用起来还是可以的，不大喜欢用 masonr。

其实 frame 做屏幕适配也很方便啊，所有布局写在 LayoutSubview 里面就行了，能获得 view 的真实宽高，layoutGuide，自由度很高

单纯的就问题来说，frame 有些时候还是需要的，只不过大多数时候是 AutoLayout

@CSwater

1.不同屏幕？和 frame 关系不大
2.横屏？你是说屏幕方向改变刷新布局吧，size 部分按比例计算，XY 甚至都可以按比例写好，监听到页面变换，layoutsubviews 方法跑一次很简单不是吗？
3.刘海屏？很抱歉我没懂你是在问什么，SafeAreaInsets 和 frame 的使用在哪里存在冲突吗？老实说我对 X 以上机型的适配没花太多功夫，反而是最近的 dark mode 目前让我发现我要改的代码更多

pod 'Texture' 的我: frame? 蛤?