冲动的惩罚
自从有那段使用beta版本的Mac OSX系统,导致机器时常开机卡死的经历之后,就尽量不敢在第一时间使用苹果的beta版系统。但是,由于自己是名iOS开发者,当Xcode出了beta版本无疑是需要第一时间体验一下的,即使Xcode beta版本可以不体验,但是出了第一个Release版本却是不得不更新。接下来讲的就是在使用Xcode8.0所遇到的坑。
坑与填平坑
Storyboard
对于Storyboard相信大家对它都不陌生,自从iOS5之后就开始支持了,是一种可视化开发组件。本人使用过Android、Windows Phone以及iOS的可视化组件,可以说Storyboard是这三个平台中最流畅、最好用的可视化开发组件,采用StoryBoard虽然会比纯代码写UI效率上会有那么一点损耗,但对于一般的应用,在开发之初它确实可以大大的提高开发效率、也易于维护(可以想想当年那些不采用Storyboard编写的代码,即使更改一个坐标位置都是极其痛苦的),可以说是利大于弊。但是就在最近升级到Xcode8之后,发现StoryBoard有如下几点变动(坑)。
所有UI控件的宽高设定了同一个初始值:1000。
在Xcode7的时候,StoryBoard生成的UI控件的默认宽高都是3.5英寸的宽高。采用自动布局时,在load完Storyboard之后,读取到UI控件的宽虽然不正确,但是大部分情况下高却是我们想要的,并且由于宽是320,是小于等于任何尺寸的宽,所以在UI渲染上并没有可见性的问题。
但是对于Xcode8则不同,只要是通过Storyboard生成的UI都是统一给定一个固定值:1000。在load完Storyboard之后,自动布局计算完高度之前,读出来的宽高都是1000。这就导致原先所有依赖于bounds计算位置宽高,没有任何问题的UI展示逻辑,采用Xcode8一编译就乱套了,比如会看到:图片无故拉长后再恢复原状,原先好好的布局出现了UI重叠在一起,有的UI甚至刷新不出来等。解决的办法主要有两个:
- 将Storyboar的打开方式选择xcode7.x(在右侧Show the file inspector->interface Builder Document->open in)。但这么做的缺点是:当你再次打开Storyboard,Xcode又帮你自动选中打开方式为Xcode8.0。而且为了以后着想,还是采用下面这种方式吧。
- 在代码要使用UI宽高做些计算之前,调用一下layoutIfNeeded。这样就能获得在Storyboard设计的宽高(当使用4.0英寸来设计获得就是在4.0英寸下的宽高,采用的是3.0英寸来设计获得的就是3.0英寸的宽高)。
cornerRadius
本人在开发过程中还遇到了这么一个问题:明明之前显示得好好的控件,为什么采用Xcode8编译之后,就消失不见了呢?并且采用Capture view Hierarchy工具查看又能看见这个控件,但是在模拟器或者真机上就是死活渲染不出来。经过各种调试最后发现是因为cornerRadius设置了一个比自己宽高还大的值(类似bounds.size.width / 2这样的逻辑,由于默认宽高为1000,因此计算出来的cornerRadius就是500了,比我的控件的宽高都大),导致了控件渲染不出来。这种情况采用上面的第二种方法,在使用bounds之前layoutIfNeeded一下,就基本跟以前一样了。
TableView static cells
当采用Taleview的的静态cell之后,如果header的高度是动态变化的,不管你如何reload data,底下的cell的frame都不会发生改变,除非你自己手动设置目标cell的frame。
不支持iOS7,却可以提交iOS7应用
Xcode8之后就不支持iOS7设备的调试了,但是Apptore却可以提交iOS7系统的应用。当在iOS7设备上遇到bug的时候,调试就成了困难。你不得不再下载一个xcode7来进行iOS7的调试,并且前提是你没有升级macOS为10.12,否则你连xcode7都打不开,更谈不上调试了。虽然现在确实iOS7的用户量很少,可对于一个步入正轨的app,只能是慢慢的放弃。开发工具虽不支持调试,但却可以提交Appstore,这对于开发者来说,对老板,用户都不好交代。既然想要放弃iOS7,为啥不干脆整个入口都封死呢?
卡卡卡
最后一点就是卡顿啊,特别是与macOS10.12配合一起,一编译,好几次机器几乎就变成了单进程应用了,其他的应用瞬间失灵。大好心情转瞬即逝啊!
最后
这次的Xcode8的升级之旅太不愉快了。经过这几年的iOS开发,一路走来感觉苹果的产品bug越来越多,也越来越不稳定,真为自己担忧啊。不知道看到这篇吐槽的iOS开发者们,你们是否也遇到了一些Xcode8的坑?