快捷搜索:
来自 计算机编程 2019-06-22 21:38 的文章
当前位置: 67677新澳门手机版 > 计算机编程 > 正文

67677新澳门手机版迁移工作总结,新特性和迁移详

代码量(4万行)

  • 首先,我是今年年初才开始入手 Swift 的。加上 Swift 的 ABI 和 API 一直不稳定,所以没有在项目中大范围的使用,所以这次迁移的代码量不多,大概在4万行左右。

知识储备升级

先了解了一下Swift 2 到 Swift 3 的变动,及变动的原因。(看完心中一万头草泥马飞过,但是其实是越来越好了)

  • Swift官博:
  • swift-evolution:
  • Swift 3 新特性一览:

然后把语法文档快速的重温了一遍。

  • Swift Programming Language:
  • 中文版:

迁移时间(一天左右)

  • 迁移时间上的话,大概是花了1天左右。两个混编项目,一个 Swift 为主的项目。期中 Swift 为主的项目 花了大概大半天时间,两个混编代码量差不多,但是一个花了小半天,还有一个差不多只花了半个小时(原因先留个悬念~)。

总结

  • 总的说来这次迁移没有想象中的那么痛苦,虽然提案的改动很大,但是得益于 Xcode 8 的迁移工具,这次迁移花费时间不多,当然也有可能和我的代码量有关系~
  • 在迁移完之后,再看代码,会发现 Swift 更加的优雅了,至少相比于 2 来说好了很多,至于好在哪里?你自己写写不就知道了咯。
  • 最后,终于可以把 Xocde 7 卸载,再也不用担心两个一起开无脑闪退了!!!
  • 最后对于明年的 Swift 4 只想说 快来吧~分分钟把你解决!
  • 其实适配之路才刚刚开始,因为 Xcode 8 自动转的代码并没有很好的 Swift 3 化。目前只是说在 Swift 3 可以编译通过了而已~

Alamofire 等三方库支持 iOS8

  • 虽然说我使用的三方库都在第一时间将库升级到了 Swift 3 ,但是期中 Alamofire 和 Snap 两个库最低适配只支持到了 iOS 9,为了避免和产品撕逼,不得不想办法解决这个适配问题。下面以 Alamofire  为例

  • 其实三方库么,不一定只用 Cocoapods 的。所以打算下载代码然后直接撸源码。

  • Alamofire的 Xcode 修改为最低适配 8.0,然后编译查找不通过的函数,并删除。(其实这些函数都是 iOS 9 新加的函数,所以删除不影响什么。)

  • 大概花了 半个小时左右就可以删完了,然后直接拖到项目中就可以了~

  • Snap 其实只要拖进去就好了,暂时不需要修改什么。

// 其实都是 !os(watchOS) 这个宏下面的
#if !os(watchOS)

@discardableResult
public func stream(withHostName hostName: String, port: Int) -> StreamRequest {
    return SessionManager.default.stream(withHostName: hostName, port: port)
}

@discardableResult
public func stream(with netService: NetService) -> StreamRequest {
    return SessionManager.default.stream(with: netService)
}

#endif

迁移中的问题

准备

在开发最初开发选择 Swift 的时候的很多决策也让我这次少了很多工作量。

更多

工作之余,写了点笔记,如果需要可以在我的GitHub看。

本文作者:Damonwong 文章链接:

@escaping

  • 这个是我在适配中最蛋疼的坑

  • 首先在看swift-evolution只是了解到@escaping 必须显示声明。但是不知道@escaping的闭包,在函数体内无法再修改。

let pedonmeter:CMPedometer = CMPedometer()

    func getPedometerDataFromDate(_ datet:Date?, withHandler handler: @escaping (CMPedometerData?, Error?) -> ()){


        // 编译错误
        pedonmeter.queryPedometerDataFromDate(startTime, toDate:endTime, withHandler: { (pedometerData:CMPedometerData?, error:NSError?) -> Void in

            guard let pedometerData = pedometerData else { return }
            handler(pedometerData, error)

            // 做一些事情

        })
        // 最后逼不得已只能不修改了,函数外面就做一些事情了
        pedonmeter.queryPedometerData(from: startTime, to: endTime, withHandler:  handler as! CMPedometerHandler)

    }

背景

界面用 xib 而不用纯代码

  • 阴差阳错的,和 Swift 相关的大部分界面都是用xib 画的。而这个 xib 在这次迁移中得到了很大的优势,xib 和 SB 的代码不适配 Swift 3。想当初要是使用代码写的 UI 的话,这次迁移改动估计会多很多吧。

代码量(4万行)

  • 首先,我是今年年初才开始入手 Swift 的。加上 Swift 的 ABI 和 API 一直不稳定,所以没有在项目中大范围的使用,所以这次迁移的代码量不多,大概在4万行左右。

背景

迁移时间

  • 迁移时间上的话,大概是花了1天左右。两个混编项目,一个 Swift 为主的项目。期中 Swift 为主的项目 花了大概大半天时间,两个混编代码量差不多,但是一个花了小半天,还有一个差不多只花了半个小时。

Result of call to 'funtion' is unused

  • 这其实不是一个 编译错误,但是这个警告最开始让我有点懵逼.返回值不用难道要我都修改一下?

  • 最开始其实我是这么修改的 let _ = funtion(),但是后面在看SE-0047的时候发现@discardableResult也是可以达到这个效果的。

准备

在开发最初开发选择 Swift 的时候的很多决策也让我这次少了很多工作量。

界面用 xib 而不用纯代码

  • 阴差阳错的,和 Swift 相关的大部分界面都是用xib 画的。而这个 xib 在这次迁移中得到了很大的优势,xib 和 SB 的代码不适配 Swift 3。想当初要是使用代码写的 UI 的话,这次迁移改动估计会多很多吧。

关于第三方库的选择:

  • 对于一个项目来说,三方库似乎成了一道必选菜,但是如何去选择这道菜呢?
  • 对于三方库,当初的选择是,能用 OC 就尽量用 OC。 毕竟可以OC 可以无缝衔接到 Swift,而且还相对稳定。
  • 在选择 Swift 相关的三方库时,我尽量值选择使用者比较多的库,例如Alamofire、Snap、Kingfisher、Fabric 等,因为使用者比较多,开发者会更愿意去维护,而不至于跳票。所以不会存在现在许多小伙伴面临的问题,想迁移,但是有些库没有更新。至少对于我来说,当我想迁移的时候,所有和 Swift 相关的三方库都已经迁移到了 3.0 了。

得益于上面两点,在迁移过程中少了不少工作量。

本文由67677新澳门手机版发布于计算机编程,转载请注明出处:67677新澳门手机版迁移工作总结,新特性和迁移详

关键词: