京东APP订单业务Swift优化总结

413次阅读  |  发布于3年以前

随着Swift ABI稳定，开发者对Swift的关注也持续升温，一些开源框架甚至已经不再提供ObjC版本了，部分苹果新出的系统库也是Swift Only。

在这样的背景下，京东商城订单业务在不同场景下尝试更多的使用Swift开发，比如:

在改造过程中，Swift的高效安全与便捷和一些优秀特性给团队留下了深刻的印象。有很多特性是开发者在写ObjC时不会太多考虑的。比如，Swift的静态派发方式、值类型的使用、静态多态、Errors+Throws、柯里化与函数合成以及丰富高阶函数等等，而且相对于OOP，Swift也能更好的支持面向协议编程、泛型编程以及更抽象函数式编程，解决了很多ObjC时代开发者面临的痛点问题。

结合Swift和ObjC的异同点，我们从Swift优势出发，重新审视和优化了项目的功能代码，优化点包括但不限于如下几个方面。

将部分方法动态派发替换为静态派发

Swift运行速度比ObjC快的原因之一就是其派发方式：静态派发(值类型)和函数表派发(引用类型)。使用静态派发ARM架构可直接用bl指令跳转到对应函数地址，调用效率最高并且有利于编译器的内联优化。值类型无法继承父类，编译时期能确定类型，满足静态派发的条件。对于引用类型，不同编译器的设置也会对派发方式有影响。比如WMO全模块编译下，系统会自动填用隐式final等关键字来修饰没有被子类继承的类，从而尽可能多的使用静态派发。

在我们的项目中，针对所有使用Class的类做了整体检查。除非必要应完全避免继承NSObject，少用NSObject的子类。对于不需要考虑继承或者多态的场景，尽可能的使用final 或者 private等关键字修饰。

另外需要关注的是，ObjC也引入了方法的静态派发。在Xcode12中集成的最新LLVM已经支持 ObjC 通过对方法指定__attribute__((objc_direct)) 的方式，来将原本的动态消息派发改为静态派发。

检查所有Class 尽可能替换为结构体或者枚举

Swift中的结构体和枚举是值类型，Class是引用类型。在Swift中使用值类型还是引用类型是开发者需要思考和评估的。

在我们开发的京东物流小组件和基于SwiftUI开发的macOS应用中，我们目前更多的使用了结构体和枚举。先对比下值类型与引用类型的区别，值类型(Struct Enum等等):

引用类型(Class Function Closure等等):

由此可见，Swift提供了更强大的值类型试图来解决ObjC时代OOP的子类与父类的紧耦合、对象隐式数据共享、非线程安全、引用计数等典型痛点。翻看Swift 标准库会发现其主要由值类型组成，基本类型集合如 Int，Double，Float，String，Array，Dictionary，Set，Tuple也都是结构体。当然，虽然值类型有众多优点，但也不是说要完全抛弃Class，还是要根据实际情况分析，实际的Swift开发中更多的是一个种结合的方式，完全不使用OOP也是不现实的。

优化结构体内存

和使用C语言结构体一样，Swift结构体的大小就是内部属性内存对齐后的大小。结构体中属性放置在不同的顺序会影响最后的内存大小。可使用系统提供的 MemoryLayout查看相应结构体占用内存大小。

我们从一些细节层面做了review，比如对于Int32完全满足的场景没有必要使用Int，不要使用String或者Int代替应该使用Bool的场景，内存小的属性尽量放在后面等等。

struct GameBoard {
  var p1Score: Int32
  var p2Score: Int32
  var gameOver: Bool 
}
struct GameBoard2 {
  var p1Score: Int32
  var gameOver: Bool 
  var p2Score: Int32
}
//基于CPU寻址效率考虑，GameBoard2字节对齐后占用空间更多
MemoryLayout<GameBoard>.self.size  //4 + 4 + 1 = 9(bytes)
MemoryLayout<GameBoard2>.self.size //4 + 4 + 4 = 12(bytes)

使用静态多态替换动态多态

上面提到值类型的时候，我们有提到静态多态，静态多态是指编译器能在编译时期确定类型的多态。这样编译器可以类型降级，在编译时可产生特定类型的方法。

将泛型定义为遵守某个协议的约束可以避免直接把协议直接当做类来传参使用，否则编译器会报错，相当于接口支持多态，但调用时要用特定的类型调用，从而达到了静态多态的目的。对于静态多态，编译器会充分利用其静态特性做优化，同时在设置了WMO全模块优化(Whole Module Optimization)的情况下会尽量控制由此可能产生的代码增长。

简而言之，开发者要尽可能多考虑静态多态。比如在使用协议作为函数的参数时，可以引入泛型。WWDC中有很经典的讨论:

protocol Drawable {
    func draw()
}
struct Line: Drawable {
    var x: Double = 0
    func draw() {
    }
}
func drawACopy<T: Drawable>(local: T) {//指定T必须遵守Drawable
    local.draw()
}


let line = Line()
drawACopy(local: line)//Success (传入具体的实现了Drawable的结构体，编译器可推断其类型)
let line2: Drawable = Line()
drawACopy(local: line2)//Error，编译器不允许直接使用Drawable协议作为入参

面向协议为协议提供扩展默认实现

对于类的继承父类和遵守协议，Swift更愿意选择后者。ObjC中OOP的形式，在Swift里基本都可以使用 Structs/Enums + Protocols + Protocol extensions + Generics 来实现逻辑抽象。

我们尽量减少了项目中使用OOP的场景，尽可能的只用值类型面向协议和利用泛型，这样编译器能做更多的静态优化，更能降低OOP超类带来的紧耦合。

同时，Protocol extension能够为protocol提供一个默认实现，这也是区别于ObjC协议的很重要的优化。

使用时要注意，应该用具体的类型去调用Protocol extension中的方法，而不是用通过类型推断得到的Protocol来调用。使用Protocol调用时，如果该方法没有在Protocol中定义，Protocol extension中的默认实现将被调用，即使具体的类型中有实现对应方法。因为此时编译器此时只能找到默认实现。

优化错误处理

相对于ObjC, Swift 中对 Error 和 Throw 的处理更加完善，这样显而易见的好处是API更友好，提高可读性，利用编辑器检测降低出错概率。ObjC时代大家往往不会考虑抛出异常的操作，这个也是习惯ObjC编码的程序员在封装底层API时需要注意的。常见的是使用继承Error协议的Enum。

enum CustomError: Error {
   case error1
   case error2
}

产生Error后也可以抛出让外部处理，支持throw的方法后编译器会做强检测是否有处理throw。要注意 () throws -> Void 和 () -> Void 是不同的 Function Type。

//(Int)->Void可以赋值给(Int)throws->Void
let a: (Int) throws -> Void = { n in
}
//反之类型不匹配 编译报错
let b: (Int) -> Void = { n throws in
}

rethrows:如果一个函数入参是一个支持throw的函数，那么通过rethrows可以标识该函数同样可以抛出Error。这样在使用该函数时，编译器会检测是否需要try-catch。

这是我们在封装基础功能时需要考虑的，系统中友好的示例很多，比如map函数在系统中的定义：

public func map<T>(_ transform: (Element) throws -> T) rethrows -> [T]
let a = [1, 2, 3]
enum CustomError: Error {
  case error1
  case error2
}
do {
  let _ = try a.map { n -> Int in
    guard n >= 0 else {
      //如果map接受的closure内部有抛出throw，编译器会强制检测外部是否有try-catch
      throw CustomError.error1
    }
    return n * n
  }
} catch CustomError.error1 {
} catch {
}

用Guard减少if嵌套

关键性检测可以使用 Guard，其优势是可以增强可读性，较少过多的if嵌套。使用Guard时，一般else里面会是 return、 throw、continue、 break等。

//if嵌套过多，难以阅读，增加后期维护成本
if (xxx){
  if (xxx) {
    if (xxx) {
    }
  }
}
//使用Guard，整体更清晰，便于后期维护
let dict : Dictionary = ["key": "0"]
guard let value1 = dict["key"], value == "0" else {
  return
}
guard let value2 = dict["key2"], value == "0" else {
  return
}
print("\(value1) \(value2)")

利用Defer

被defer修饰的closure会在当前作用域退出的时候调用，主要用来避免重复添加返回前需要执行的代码，提高可读性。

比如在我们macOS应用中有对文件读写的操作，这时候使用defer可以确保不会忘记关闭文件。

func write() throws {
  //...
  guard let file = FileHandle(forUpdatingAtPath: filepath) else {
    throw WriteError.notFound
  }
  defer {
    try? file.close()
  }
  //...
}

另外比较常用的场景是释放锁的时候，以及非逃逸闭包回调等。

但是defer不要过度使用，使用时要注意closure捕获变量和作用域的问题。

比如如果在if语句中使用defer，则跳出if时，该defer就会被执行。

用可选绑定替换所有的强制拆包

对于可选值，要尽最大可能甚至完全避免强制拆包。大部分情况下如果遇到了需要使用 ! 的情况，很可能说明最初的设计是不合理的。包括downCasting时，由于类型转换本身就有可能失败，要避免使用 as! ，尽量使用as?，当然try!也要避免。

对于可选值，永远要使用可选绑定检测，确保可选变量具有真正的值存在，然后再进行操作:

var optString: String?
if let _ = optString {
}

多考虑懒加载

将项目中不需要必须创建的属性，改为懒加载。Swift的懒加载相对于ObjC来说可读性更好，也更容易实现，使用Lazy修饰就好。

lazy var aLabel: UILabel = {
    let label = UILabel()
    return label
}()

使用函数式编程 减少状态变量声明与维护

在类里面声明过多的状态变量是不利于后期维护的。Swift里函数可以作为函数参数、返回值以及变量，可以很好的支持函数式编程。利用函数式能有效减少全局变量或者状态变量。

命令式编程更关注解决问题的步骤。直接反应机器指令序列。有变量（对应存储单元），赋值语句（对应获取与存储指令），表达式（对应 指令算数计算），控制语句（对应跳转指令）。

函数式编程更关注数据的映射关系和数据的流向，即输入和输出。函数被当做变量，既可以作为其它函数的参数（输入值），也可以从函数中返回（输出值）。将计算描述为表达式求值，自变量的映射f(x)->y，给定x，会稳定映射为y。函数内尽量不访问函数作用域之外的变量，只依赖入参，减少状态变量的声明与维护。同时少用可变变量(对象)，多用不可变变量(结构体)。这样就不会有其他side effects干扰。

利用柯里化把接受多个参数的函数变换成接受一个单一参数的函数，将部分参数缓存到函数内部。同时利用函数合成增加可读性。比如做加法乘法计算，我们可以封装加法和乘法函数然后逐一调用:

func add(_ a: Int, _ b: Int) -> Int { a + b }
func multiple(_ a: Int, _ b: Int) -> Int { a * b }
let n = 3
multiple(add(n, 7), 6) //(n + 7) * 6 = 60

也可以使用函数式：

//柯里化add和multiple函数: 由两个入参改为一个并返回一个(Int)->Int类型函数
func add(_ a: Int) -> (Int) -> Int { { $0 + a} } 
func multiple(_ a: Int) -> (Int) -> Int { { $0 * a} } 
//函数合成 自定义中置运算符 > 增加可读性
infix operator > : AdditionPrecedence
func >(_ f1: @escaping (Int)->Int,
       _ f2: @escaping (Int)->Int) -> (Int) -> Int {
  {f2(f1($0))} 
}
//生成新的函数 newFn
let n = 3
let newFn = add(7) > multiple(6) // (Int)->Int
print( newFn(n) ) //(n + 7) * 6 = 60

可以看到，从使用multiple(add(n, 7), 6) 到 let newFn = add(7) > multiple(6), newFn(n)，整体更清晰了，尤其是在更复杂的场景下，其优势会更明显。

总结

Swift提供了丰富简便的语法糖以及强大的类型推断，这些都让Swift变得很容易上手入门。但是要从性能考虑或者是设计出更完美API的角度出发，还是需要投入更多的实践才行。订单团队正在iOS小组件、AppClips、京东工作站(macOS桌面应用)等场景下尝试尽可能多的使用Swift与SwiftUI开发，开发效率与项目稳定性都有不错的表现。目前京东集团内部对Swift的基础设施正在逐步完善中，我们相信也希望未来集团内有更多的同学参与到Swift的开发中进来。

参考链接：https://developer.apple.com/videos/play/wwdc2016/419/

https://developer.apple.com/videos/play/wwdc2016/416/

https://swift.org/blog/whole-module-optimizations/

https://docs.swift.org/swift-book/GuidedTour/GuidedTour.html#//apple_ref/doc/uid/TP40014097-CH2

Copyright© 2013-2020

All Rights Reserved 京ICP备2023019179号-8