适配swift3

Any vs AnyObject

将项目里的 AnyObject 转成 Any 可能是大家遇到的第一件适配大事。如何解释这个变化呢?在 Swift 3 之前,我们可以写完一个项目都只用 AnyObject 来代表大多数实例,好像不用与 Any 类型打交道。但事实上,Any 和 AnyObject 是有明显区别的,因为 Any 可以代表 struct、class、func 等等几乎所有类型,而 AnyObject 只能代表 class 生成的实例。

那为什么之前我们在 Swift 2 里可以用 [AnyObject] 声明数组,并且在里面放 Int、String 等 struct 类型呢?这是因为 Swift 2 中,会针对这些 Int、String 等 struct 进行一个 Implicit Bridging Conversions,在 Array 里插入他们时,编译器会自动将其 bridge 到 Objective-C 的 NSNumber、NSString 等类型,这就是为什么我们声明的 [AnyObject] 里可以放 struct 的原因。

但在 Swift 3 当中,为了达成一个门真正的跨平台语言,相关提案将 Implicit Bridging Conversions 给去掉了。所以如果你要把 String 这个 struct 放进一个 [AnyObject] 里,一定要 as NSString,这些转换都需要显示的进行了——毕竟 Linux 平台默认没有 Objective-C runtime。

@discardableResult 的使用

在 Swift 3 编译器下,如果一个 func 返回了一个对象,而你没有使用它时,会有一个 WARNING。对于追求项目洁癖(不想看到 1 个 WARNING 和 1 个 ERROR)的人来说这是不能忍的,尽管你可能是故意不去使用它的。

这里有两种方法可以解决这个 WARNING。

第一种:在 func 定义的前面,加上 @discardableResult 的修饰符,代表可以不使用返回值,这样编译器就不会有警告了。在我们自己定义的 func 上基本上都可以这么做。

但是还会有一种情况,用了第三方库或者系统库返回的对象怎么办?那只能用第二种办法:

_ = navigationController?.popViewController(animated: true)

像这样通过 _ 来省略掉了。虽然比较难看,考虑到 Swift 是一门严格的语言,就忍忍吧。

Protocol 实现一定要在对应的 extension 里

以前写代码时会有不注意的地方,比如 UITableViewDelegate 和 UITableViewDataSource,我分别用 extension 来实现,但是在具体的实现中没注意,把 delegate 的一个方法放进了 dataSource 的 extension 去实现,项目也能完全正常运作。

但是在 Swift 3.0 下,如果你在一个 extension 里实现一个 protocol,那么这个 protocol 的方法一定要在这个 extension 里面能找到,而不能在另外一个 extension 里或者主 class 或 struct 里面。不然会有类似这样的警告:

Objective-C method ‘tableView:canEditRowAt:‘ provided by method ‘tableView(_:canEditRowAt:)‘ does not match the requirement‘s selector (‘tableView:canEditRowAtIndexPath:‘)

这也是 Swift 3 编译变得更严格的一个表现。

Implicitly Unwrapped Optionals 的坑

在 Swift 2 的项目中,我们可能存在这样不是特别安全的代码:

var greetings: String!
greetings = "Hello"
print("\(greetings) 图拉鼎")

这里会输出:

Hello 图拉鼎

没有任何问题。但是在 Swift 3 中,因为 Optional 的安全机制起作用了,会变成:

Optional("Hello") 图拉鼎

这个结果不是我们想要的。从这点也可以看到,Swift 3 的 IUO 行为变得更安全了,默认会把 IUO 变成 Optional。如果想要达到和 Swift 2 一样的效果,就得用:

print("\(greetings!) 图拉鼎")

这时你也注意到了,Swift 始终在用 ! 提醒你用 IUO 不那么安全。

Alamofire 最低支持iOS9

虽然说我使用的三方库都在第一时间将库升级到了 Swift 3 ,但是期中 Alamofire 库最低适配只支持到了 iOS 9。

参考:https://zhuanlan.zhihu.com/p/22584349

时间: 2024-11-07 07:02:44

适配swift3的相关文章

Swift2.3适配Swift3.0时出现的各种问题

昨晚上一波手贱把我的小5s升到iOS10.如此配套的话,Xcode7.3升级Xcode8.1看来也是势在必行了.公司程序是Swift2.3的,出于对苹果的恐惧迟迟不敢升级.但丑媳妇儿总要见公婆,借这个机会,也趁双休时间,做一下适配好了. 首先,强调一点.做好备份!做好备份!做好备份!重要的事情说三遍. 1.关于使用的Swift代码库的问题 这是我最心力交瘁的一个问题. 项目中使用了Swift的几个开源框架,SwiftHTTP.SwiftyJSON.KingFisher等等.我的项目并没有使用Co

UICollectionView在Swift3.0中的用法

UICollectionView在Swift3.0中的用法 UICollectionView的初始化跟OC中是相似的,创建 GameView 集成自 UICollectionView .注意不同于UITableView的用法,他需要用 UICollectionViewFlowLayout 来指定一些需要设置的属性,或者可以通过遵守 UICollectionViewDelegateFlowLayout 这个代理来实现.下面我用设置属性的方式来实现的,比较方便. //布局 layout.scroll

前端页面适配的rem换算

为什么要使用rem 之前有些适配做法,是通过js动态计算viewport的缩放值(initial-scale). 例如以屏幕320像素为基准,设置1,那屏幕375像素就是375/320=1.18以此类推. 但直接这样强制页面缩放过于粗暴,会导致页面图片文字失真模糊. Px是相对固定单位,字号大小直接被定死,所以用户无法根据自己设置的浏览器字号而缩放,em和rem虽然都是相对单位,但em是相对于它的父元素的font-size,页面层级越深,em的换算就越复杂,而rem是直接相对于根元素,这就避开了

登录界面、AutoUtils 屏幕适配、自定义Edittext(显示密码可见和一键清空)和 TextInputLayout的使用。

登录界面: AutoUtils自动屏幕适配: AutoUtils屏幕适配使用的方法 : 1.将AutoUtils类复制到要适配的项目中: 2.在程序的入口(清单文件filter):super.onCreate(savedInstanceState);//屏幕适配,这里是以720*1280分辨率为基准的适配AutoUtils.setSize(this, false, 720, 1280); * 这里我们UI是以1920*1280分辨率做图的,并且是横屏显示:AutoUtils.setSize(th

Android 屏幕适配问题分析

一.屏幕分辨率.大小及相关单位介绍 Android categorizes device screens using two general properties: size and density.There are four generalized sizes: small, normal, large, xlarge:And four generalized densities: low (ldpi 0.75), medium (mdpi 1.0 baseline), high (hdpi

适配iOS10以及Xcode8-b

现在在苹果的官网上,我们已经可以下载到Xcode8的GM版本了,加上9.14日凌晨,苹果就要正式推出iOS10系统的推送了,在此之际,iOS10的适配已经迫在眉睫啦,不知道Xcode8 beat版本,童鞋们有木有下载过来试试呢?就我的使用来说,总体觉得苹果还是坑不断,但是也在一直进步的啦.下面我就来说说,iOS10的适配以及Xcode8使用上的一些注意点. 一.证书管理 用Xcode8打开工程后,比较明显的就是下图了,这个是苹果的新特性,可以帮助我们自动管理证书.建议大家勾选这个Automati

移动端适配方案研究

初次接触移动端的时候,以为终于可以不用像pc那样考虑令人头疼的ie浏览器兼容问题,有强大的css3的帮助,可以随心所欲..可是后来才发现原来移动端各种层次不齐的终端更会让人抓耳挠腮,同样的页面在不同的手机上显示的完全不一样的效果,于是抛开功能,页面适配性也成了一个大的课题. 说到移动端,下面这一行代码大家一定不陌生: <meta name="viewport" content="width=device-width, initial-scale=1, maximum-s

升级Xcode7之后的适配问题(插件、ATS等)

一.插件失效 1. 首先查看 Xcode 的 UUID,在终端执行 defaults read /Applications/Xcode.app/Contents/Info DVTPlugInCompatibilityUUID 会得到一串 UUID 码 2. 找到 Xcode 插件所在的目录 ~/Library/Application Support/Developer/Shared/Xcode/Plug-ins 选择已安装的插件如:VVDocumenter-Xcode,右键显示包内容,找到 in

操作系统: 最佳适配算法和邻近适配算法的模拟实现(内存分配算法)

实现动态分区的分配算法. (1) 最佳适配算法:选择内存空闲块中最适合进程大小的块分配. (2) 邻近适配算法:从上一次分配的地址开始查找符合要求的块,所查找到的第一个满足要求的空闲块就分配给进程. 模拟添加进程的时候,假定内存是一块完整的空闲区,对于算法(1)来说,分配的时候遍历所有的空闲内存块,找出其中最适合的一块,注意此时内存分区的总块数可能已经发生了变化: 对于算法(2)来说,则需要从上次分配的内存块(使用变量记录即可)接着向下找到第一个满足条件的块即可,内存分区的总块可能也已经发生了变