这是一个创建于 2380 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近公司的 iOS 工程师吵架差不多要打起来了，一边支持主要 Frame 布局，一边支持主要 AutoLayout (Masonry) 布局。
Frame 支持的观点是： AutoLayout 最终也是通过 frame，而且项目只需要兼容 iPhone，机型不情况下使用 Frame 编程效率比较高。
AutoLayout 支持的观点是： Frame 布局，一连串数字加起来可读性有点差，维护麻烦。
我是 iOS 新人，请问大大主要使用哪种比较靠谱，避免少踩坑？
57 条回复 2019-06-24 16:28:45 +08:00
 | 1 kera0a 2019-06-21 11:40:13 +08:00 via iPhone 最终都是 Frame，那为啥不用 Masonry 呀？ 开发效率，易用性，功能，可读性都完爆 Frame 了吧。 Frame 在特定场景下有用，通常情况还是用 Masonry 吧 第一个人适合用机器码写 iOS 程序，反正最后 objc 都是机器码 |
 | 2 nigulasida 2019-06-21 11:43:28 +08:00 AutoLayout |
 | 4 CommandZi 2019-06-21 11:46:10 +08:00 当然是 AutoLayout，后面还会转向 SwiftUI，Frame 真的 out 了 |
 | 5 Heavytiger 2019-06-21 11:47:35 +08:00 都用 |
 | 6 ai277014717 2019-06-21 12:04:47 +08:00 跟团队的大方向走。autolayout 也可以写的很烂。frame 一般来说都要根据屏幕宽度动态计算。autolayout 却不用。autolayout 滥用会导致性能问题。详细可以看看 wwdc 高性能 autolayout |
 | 7 zenghaojim33 2019-06-21 12:12:12 +08:00 这确定不是 2014 年的帖子吗... |
 | 8 MrStark 2019-06-21 12:14:34 +08:00 现在居然还有 iOS 新人，也是不容易了。话说，现在入手 iOS 不应该是从 Swift 入手的么，ObjC 已经是二等公民了。  |
 | 10 loveuqian 2019-06-21 12:17:51 +08:00 via iPhone 能做到任意列表点击状态栏滚到顶部保持 fps55 以上，都不算影响效率 |
 | 11 Paryace 2019-06-21 12:33:03 +08:00 仿佛回到了五年前....现在还有讨论这个的？ 现在的设备 99%的情况下抠不出来这点性能区别。开发效率优先，真的要优化也是出现性能瓶颈时优化。 |
 | 12 faimin 2019-06-21 12:47:30 +08:00 via iPhone 一起用呗，干嘛定那么死。简单页面 autolayout,复杂的用 frame. 做复杂动画的用 frame |
 | 14 SeanChense 2019-06-21 13:00:05 +08:00 frame > AutoLayout 支持的观点是：Frame 布局，一连串数字加起来可读性有点差，维护麻烦。 这个观点太逞强了 |
| 15 SeanChense 2019-06-21 13:00:23 +08:00 逞强 --> 勉强 |
 | 16 hstdt 2019-06-21 13:02:27 +08:00 via iPhone 苹果一直在优化 autolayout 的性能，这里一般不会成为瓶颈的，用吧没事。或者用 stackview 取代一部分 autolayout |
 | 17 xjbeta 2019-06-21 13:02:46 +08:00 把他们都打一顿 然后上 SwiftUI (狗头 |
 | 18 yeziahehe 2019-06-21 13:24:01 +08:00  2 我建议你们公司 iOS 换一批人，9012 了，还不接受 autolayout、swift |
 | 19 shawndev 2019-06-21 13:27:52 +08:00 建议使用机器码编程，运行效率高，而且反正 swift、objc 最终都会转换成机器码。 |
| 20 zenghaojim33 2019-06-21 13:30:22 +08:00 @353943780 Swift 生态一般？能用的库已经一大堆了 |
 | 21 Otho 2019-06-21 13:30:53 +08:00 爱咋写咋写，互相先总结下好处不行么？ |
 | 22 eric1202 2019-06-21 13:42:23 +08:00 我支持 autolayout |
 | 23 MarginK 2019-06-21 13:42:48 +08:00 不好意思，我只用 frame 布局约束本身可读性就不高，只要是写代码，你就是用 MAS 也没 Frame 让我看着舒服 楼上拿 SWIFTUI 来抵制 frame 的，真的是 50 步笑百步 |
| 25 CommandZi 2019-06-21 14:22:29 +08:00 @353943780 一些比较新的库已经 Swift Only 了，包括苹果推出的比如 Combine、RealityKit、SwiftUI。 |
 | 26 wezzard 2019-06-21 14:35:20 +08:00 via iPhone |
 | 27 daocheng 2019-06-21 14:42:34 +08:00 Masonry or Snapkit，只有在性能需要时使用 Frame 我觉得 Autolayout 可读性和开发效率更高 |
 | 28 wangyifei6817 2019-06-21 14:45:34 +08:00 说用 frame 的 可能是没接触过其他平台的布局方案 说实话 我连 autolayout 都不满意 同样的方案 用 frame 实现要比 autolayout 慢的多 代码量也更多 iOS10 以后 autolayout 列表性能比之前强太多了 非列表页面 frame 更没有优势 |
| 29 zenghaojim33 2019-06-21 14:56:45 +08:00 非要说 AL 不好，用 Frame，还不如上 Flexlayout （ yoga ） Frame 从效率层面屁都不是，动态 layout 更是被吊打，你只是随便弄个 View 放在上面当我没说 |
 | 30 damngood 2019-06-21 15:03:14 +08:00 via iPhone 当真还有用 frame 的呀 真 iphone 4 时代的即视感 |
 | 31 damngood 2019-06-21 15:08:22 +08:00 via iPhone autolayout 的性能没问题 除非你 某个 view 的 sub view 太多，比如有几百个这种情况在之前的实现上可能有性能问题. frame 根本就不应该是争论点 该争论的是 用 uikit 还是 swift ui |
 | 32 ostholz 2019-06-21 15:11:55 +08:00 我用过最好用的是 TangramKit |
 | 33 deyu 2019-06-21 15:13:39 +08:00 主用 frame 页面控制比较灵活 我是不会相信苹果的 autolayout 的 |
 | 34 q409195961 2019-06-21 15:16:58 +08:00 AutoLayout 啊，这年代了，用 Frame 看代码脑瓜疼啊。 Masonry(Snapkit)多好用呀。 |
 | 35 kkkkkrua 2019-06-21 15:43:07 +08:00 我用 flutter |
 | 36 superpeaser 2019-06-21 15:46:11 +08:00 SwiftUI 才是未来 |
 | 37 HarryQu 2019-06-21 16:06:12 +08:00 我写 iOS 代码的时候，一直使用 Masonry 来写布局， 比较灵活。 大部分页面比较简单，直接使用 Masonry 灵活、快速。 缺点就是 : 1. 写复杂界面的时候，代码一坨一坨的。我选择将 Masonry 封装到具体的 View 来简化 ViewControllr 页面代码。 2. 列表页，尤其是非常复杂、由服务器动态控制布局的列表页，滑动起来比较卡顿。我选择使用 YYLabel 库，在很复杂的页面不使用 Masonry。 因为我是 Android 过去写 iOS 的 ， 写布局用 Masonry 很舒服。 最主要的是 iOS 只有我一个人会写，我想用啥就用啥，舒服的一批(当然最终的效果是符合产品经理和用户的预期的)。 |
 | 38 matou 2019-06-21 16:12:02 +08:00 这年代还用 frame 的确实有点不思进取了 |
 | 39 StubbornC 2019-06-21 16:21:26 +08:00 请让坚持 Frame 的童鞋联系我，我想和他好好探讨下人生 |
 | 42 unruly 2019-06-21 17:58:02 +08:00 页面布局部分 iOS 一直是很落后的 frame -> AutoLayout 是过度 还在使用 frame 布局的只能说你喜欢你继续 |
 | 43 CSwater 2019-06-21 19:43:15 +08:00 via iPhone @MarginK 请问你们 frame 是怎么适配不同比例屏幕，以及横屏、可能存在的刘海屏上下颠倒的安全区问题？ |
 | 44 kx5d62Jn1J9MjoXP 2019-06-21 19:48:15 +08:00 请使用 ConstraintLayout |
 | 45 holydancer 2019-06-21 20:11:26 +08:00 via Android 看来我真的老了，我不是很喜欢用 masonry，不是因为性能，就是习惯问题…估计楼主公司的人争论也就是个习惯问题，然后找个理由给自己的习惯背书… |
 | 46 expkzb 2019-06-21 20:22:36 +08:00 可能不嫌累吧。像楼上所说，现在应该讨论 UIKit 和 SwiftUI 的问题，虽然 UIKIt 的玩意实现几个协议就能用了 |
 | 47 0xcb 2019-06-21 21:38:34 +08:00 via Android 纯代码:Frame->Masonry，Xib:Autoresize->Autolayout, 从纯代码计算，到所见即所得; 原因是设备配置高了，开发效率也要提高。 |
 | 48 acumen 2019-06-21 22:58:14 +08:00 拥抱变化（狗头 |
 | 49 feikaras 2019-06-22 05:53:00 +08:00 1 挺有意思的，一个东西加点壳加点糖都能引起对立。。 |
 | 51 Ixizi 2019-06-22 11:15:14 +08:00 用 Flex Box 爽 一直用一直爽 |
 | 52 conver 2019-06-22 12:43:55 +08:00 via iPhone 什么年代了还争这个，SwiftUI，FlexLayou，Texture 了解一下 |
 | 53 Deeer 2019-06-22 15:43:20 +08:00 都什么年代了 |
 | 54 rollpard 2019-06-22 19:05:01 +08:00 iOS9 的 layoutAnchor 用起来还是可以的，不大喜欢用 masonry。 其实 frame 做屏幕适配也很方便啊，所有布局写在 LayoutSubview 里面就行了，能获得 view 的真实宽高，layoutGuide，自由度很高 |
 | 55 ShuangFan 2019-06-24 09:28:39 +08:00 单纯的就问题来说，frame 有些时候还是需要的，只不过大多数时候是 AutoLayout |
| 56 MarginK 2019-06-24 14:13:26 +08:00 @CSwater 1.不同屏幕？和 frame 关系不大 2.横屏？你是说屏幕方向改变刷新布局吧，size 部分按比例计算，XY 甚至都可以按比例写好，监听到页面变换，layoutsubviews 方法跑一次很简单不是吗？ 3.刘海屏？很抱歉我没懂你是在问什么，SafeAreaInsets 和 frame 的使用在哪里存在冲突吗？老实说我对 X 以上机型的适配没花太多功夫，反而是最近的 dark mode 目前让我发现我要改的代码更多 |
 | 57 ruixingchen 2019-06-24 16:28:45 +08:00 pod 'Texture' 的我: frame? 蛤? |
Select Language