最近公司的 iOS 工程师吵架差不多要打起来了,一边支持主要 Frame 布局,一边支持主要 AutoLayout (Masonry) 布局。
Frame 支持的观点是: AutoLayout 最终也是通过 frame,而且项目只需要兼容 iPhone,机型不多情况下使用 Frame 编程效率比较高。
AutoLayout 支持的观点是: Frame 布局,一连串数字加起来可读性有点差,维护麻烦。
我是 iOS 新人,请问大大主要使用哪种比较靠谱,避免少踩坑?
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 来简化 ViewController 页面代码。 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? 蛤?
|