接触swift 已经有一年多的时间了，由最初的OC代码转为 swift 代码，然后从 swift 2.3 转为 swift 3。每次的转换都感觉是将项目整个的翻新了一遍，每次的转换代码都是一次改朝换代。
以下是在代码改朝换代的时候的一些心得：
在将 OC 代码转换为 swift 代码的时候，我当时使用的是 xcode7.3。xcode7.3在我的印象中，编写OC代码就是联想功能最差的一个。 所以：
- 一、在更新swift的时候，在swift文件中，几乎是不会联想的，动则就是整个屏幕中的代码全是白颜色，然后，类名，方法名，都是硬敲出来的。
- 二、既然是改写 swift 代码，那么就是对swift 不是太了解
- 三、针对一些第三方库，期望改为swift版。例如：Masnory -> SnapKit
- 四、cocoapod 推荐使用 useasframework 的方式集成
- 五、在 swift 2.3 转 swift 3.0 的时候，block（闭包）里面的参数都不要形参，所以参数的前面都是要加上 _ 来防止错误。并且 block 非option 的都要加上 @escaping 来修饰
- 六、在swift中，在iOS8 机型中，所有的控制器在使用 xib 的情况下，都要对初始化方法 init(nibName:nibBundle)这个方法重写，否则崩溃
- 七、增加桥接文件
以上几点都是在转码的时候耗费时间比较长、存在坑的。下面说几点在转码过程中总结的一些经验
- 一、项目中所使用的到工具类、工厂类、公共类、网络请求的封装等等，就是指一些公共模块。建议在转码初期，先将这些文件转为 swift。既然能称为工具类，那么一般都是解耦的，所以说，可以新建一个swift项目，将这些工具类转为swift文件。这样做的目的是： 一：工具类的使用量非常大，所以很有必要 swift2.0 / 3.0 化 二：在工具类使用如此频繁的情况下，如果你的xcode不会联想，这样将会使多么令人头疼的事情啊！在这点印象颇深
- 二、更新第三方库为 swift 版，因为虽说允许OC swift混编，但是在类型这个方面兼容性并不是太好。例如：OC中一些 NSArray 的地方，也许我们清楚里面存放的是字符串，但是如果没有显示指定 NSArray <NSString* > * 的话，那么在swift 中使用起来，你只能得到 Any 类型，使用的时候还要类型绑定，这个属于类型兼容性。再者一点就是 OC 的方法在联想方面差的要命
- 三、cocoapod 使用 useasframework，swift中比较注重 module 的概念，这个也是趋势，所以同样是混编，但是仍然要更改为包的形式
- 四、关于block 形参的问题，这个需要我们有耐心的一个一个更改
- 五、在 swift 3.0 中返回值没有使用那么会报一个警告，添加一个@discardresult 在方法的前面，放置警告
- 六、针对第三点中的 包 的概念，我们会发现，例如在使用 snapkit 的时候，只要使用 snp 的地方都要 import SnapKit （当然这个主要是针对swift2.3 -> swift 3.0 并且没有使用 useasframework ）。这个时候会发现每个文件都 import SnapKit 这样来一下，是多么痛苦的事情。 下面是我当时新建的 mac 工程整个项目添加 import SnapKit 的方法
func importSnapKit(path: String) {
let manager = FileManager.default
guard let subPaths = try? manager.subpathsOfDirectory(atPath: path) else {
return
}
for subPath in subPaths {
let realPath = path "/(subPath)"
var isDirectory: ObjCBool = true
if manager.fileExists(atPath: realPath, isDirectory: &isDirectory) {
if realPath.contains("SnapKit") { // 过滤自身
continue
}
if !isDirectory.boolValue {
alterSnapKitContent(path: realPath)
} else {
importSnapKit(path: realPath)
}
}
}
}
func alterSnapKitContent(path: String) {
guard !path.contains("SnapKit") else { // 过滤自身
return
}
guard path.contains(".swift") else {
return
}
guard var content = try? String.init(contentsOfFile: path) else {
print("can't get content at path: (path)")
return
}
guard content.contains("snp.") || content.contains("make.") else {
return
}
guard !content.contains("import SnapKit") else {
return
}
let containUIKit = content.contains("import UIKit")
let containFoundation = content.contains("import Foundation")
if containUIKit {
content = content.replacingOccurrences(of: "import UIKit", with: "import UIKitnnimport SnapKit")
_ = try? content.write(toFile: path, atomically: true, encoding: String.Encoding.utf8)
print("has add:nimport SnapKitnin file: (path)")
} else if containFoundation {
content = content.replacingOccurrences(of: "import Foundation", with: "import Foundationnnimport SnapKit")
_ = try? content.write(toFile: path, atomically: true, encoding: String.Encoding.utf8)
print("has add:nimport SnapKitnin file: (path)")
} else {
content = content.replacingOccurrences(of: "All rights reserved.n//", with: "All rights reserved.n//nnimport SnapKit")
_ = try? content.write(toFile: path, atomically: true, encoding: String.Encoding.utf8)
print("has replace all right reversed. ")
}
}
// importSnapKit(path: "/Users/*/Desktop/projectname")大致思路为： 1、读取项目中的每个文件，当然除了pod、snapkit 文件夹下面的 2、读取每个文件中的内容，判断是否包含snp. 这个字符串，如果存在，则需要导入 import SnapKit 。否则不需要 3、将 import SnapKit 放在 import UIKit 或 import Foundation 或 All rights reserved. 的下面一行 这样等待半分钟，将会自动在需要的文件中 import SnapKit
同样：针对所有的 module 都可以这样导入，只要将限制条件更改为合适的即可
转为Swift 后：
现在我们公司都是使用swift 编程，swift在代码编写方面确实是能够提高效率，尤其是swift 是面向协议编程，其灵活性不可言喻，并且在 swift 的强语言下，swift 项目是相当稳定的。目前 swift 项目唯一不足之处便是xcode 的编译速度问题，编译型语言。我们公司项目是比较大的，每次项目的编译时间在15分钟左右，接下来的任务就是如何降低编译时间。
总体来说推荐大家转为swift编程。
