最详尽的 Swift 代码规范指南

1. 代码格式

  • 1.1 使用四个空格进行缩进。
  • 1.2 每行最多160个字符,这样可以避免一行过长。 (Xcode->Preferences->Text Editing->Page guide at column: 设置成160即可)
  • 1.3 确保每个文件结尾都有空白行。
  • 1.4 确保每行都不以空白字符作为结尾 (Xcode->Preferences->Text Editing->Automatically trim trailing whitespace + Including whitespace-only lines).
  • 1.5 左大括号不用另起一行。
class SomeClass {
    func someMethod() {
        if x == y {
            /* ... */
        } else if x == z {
            /* ... */
        } else {
            /* ... */
        }
    }

    /* ... */
}
  • 1.6 当在写一个变量类型,一个字典里的主键,一个函数的参数,遵从一个协议,或一个父类,不用在分号前添加空格。
// 指定类型
let pirateViewController: PirateViewController

// 字典语法(注意这里是向左对齐而不是分号对齐)
let ninjaDictionary: [String: AnyObject] = [
    "fightLikeDairyFarmer": false,
    "disgusting": true
]

// 声明函数
func myFunction<T, U: SomeProtocol where T.RelatedType == U>(firstArgument: U, secondArgument: T) {
    /* ... */
}

// 调用函数
someFunction(someArgument: "Kitten")

// 父类
class PirateViewController: UIViewController {
    /* ... */
}

// 协议
extension PirateViewController: UITableViewDataSource {
    /* ... */
}
  • 1.7 基本来说,要在逗号后面加空格。
let myArray = [1, 2, 3, 4, 5]
  • 1.8 二元运算符(+, ==, 或->)的前后都需要添加空格,左小括号后面和右小括号前面不需要空格。
let myValue = 20 + (30 / 2) * 3
if 1 + 1 == 3 {
    fatalError("The universe is broken.")
}
func pancake() -> Pancake {
    /* ... */
}
  • 1.9  遵守Xcode内置的缩进格式( 如果已经遵守,按下CTRL-i 组合键文件格式没有变化)。当声明的一个函数需要跨多行时,推荐使用Xcode默认的格式,目前Xcode 版本是 7.3。
// Xcode针对跨多行函数声明缩进
func myFunctionWithManyParameters(parameterOne: String,
                                  parameterTwo: String,
                                  parameterThree: String) {
    // Xcode会自动缩进
    print("\(parameterOne) \(parameterTwo) \(parameterThree)")
}

// Xcode针对多行 if 语句的缩进
if myFirstVariable > (mySecondVariable + myThirdVariable)
    && myFourthVariable == .SomeEnumValue {

    // Xcode会自动缩进
    print("Hello, World!")
}
  • 1.10 当调用的函数有多个参数时,每一个参数另起一行,并比函数名多一个缩进。
someFunctionWithManyArguments(
    firstArgument: "Hello, I am a string",
    secondArgument: resultFromSomeFunction()
    thirdArgument: someOtherLocalVariable)
  • 1.11 当遇到需要处理的数组或字典内容较多需要多行显示时,需把 [ 和 ] 类似于方法体里的括号, 方法体里的闭包也要做类似处理。
someFunctionWithABunchOfArguments(
    someStringArgument: "hello I am a string",
    someArrayArgument: [
        "dadada daaaa daaaa dadada daaaa daaaa dadada daaaa daaaa",
        "string one is crazy - what is it thinking?"
    ],
    someDictionaryArgument: [
        "dictionary key 1": "some value 1, but also some more text here",
        "dictionary key 2": "some value 2"
    ],
    someClosure: { parameter1 in
        print(parameter1)
    })
  • 1.12 应尽量避免出现多行断言,可使用本地变量或其他策略。
// 推荐
let firstCondition = x == firstReallyReallyLongPredicateFunction()
let secondCondition = y == secondReallyReallyLongPredicateFunction()
let thirdCondition = z == thirdReallyReallyLongPredicateFunction()
if firstCondition && secondCondition && thirdCondition {
    // 你要干什么
}

// 不推荐
if x == firstReallyReallyLongPredicateFunction()
    && y == secondReallyReallyLongPredicateFunction()
    && z == thirdReallyReallyLongPredicateFunction() {
    // 你要干什么
}

2. 命名

  • 2.1 在Swift中不用如Objective-C式 一样添加前缀 (如使用 GuybrushThreepwoode 而不是 LIGuybrushThreepwood)。
  • 2.2 使用帕斯卡拼写法(又名大骆驼拼写法,首字母大写)为类型命名 (如 structenumclasstypedefassociatedtype 等)。
  • 2.3 使用小骆驼拼写法 (首字母小写) 为函数,方法,变量,常量,参数等命名。
  • 2.4 首字母缩略词在命名中一般来说都是全部大写,例外的情形是如果首字母缩略词是一个命名的开始部分,而这个命名需要小写字母作为开头,这种情形下首字母缩略词全部小写。
// "HTML" 是变量名的开头, 需要全部小写 "html"
let htmlBodyContent: String = "<p>Hello, World!</p>"
// 推荐使用 ID 而不是 Id
let profileID: Int = 1
// 推荐使用 URLFinder 而不是 UrlFinder
class URLFinder {
    /* ... */
}
  • 2.5 使用前缀 k + 大骆驼命名法 为所有非单例的静态常量命名。
class MyClassName {
    // 基元常量使用 k 作为前缀
    static let kSomeConstantHeight: CGFloat = 80.0

    // 非基元常量也是用 k 作为前缀
    static let kDeleteButtonColor = UIColor.redColor()

    // 对于单例不要使用k作为前缀
    static let sharedInstance = MyClassName()

    /* ... */
}
  • 2.6 对于泛型和关联类型,可以使用单个大写字母,也可是遵从大骆驼命名方式并能描述泛型的单词。如果这个单词和要实现的协议或继承的父类有冲突,可以为相关类型或泛型名字添加 Type 作为后缀。
class SomeClass<T> { /* ... */ }
class SomeClass<Model> { /* ... */ }
protocol Modelable {
    associatedtype Model
}
protocol Sequence {
    associatedtype IteratorType: Iterator
}
  • 2.7 命名应该具有描述性 和 清晰的。
// 推荐
class RoundAnimatingButton: UIButton { /* ... */ }

// 不推荐
class CustomButton: UIButton { /* ... */ }
  • 2.8 不要缩写,简写命名,或用单个字母命名。
// 推荐
class RoundAnimatingButton: UIButton {
    let animationDuration: NSTimeInterval

    func startAnimating() {
        let firstSubview = subviews.first
    }

}

// 不推荐
class RoundAnimating: UIButton {
    let aniDur: NSTimeInterval

    func srtAnmating() {
        let v = subviews.first
    }
}
  • 2.9 如果原有命名不能明显表明类型,则属性命名内要包括类型信息。
// 推荐
class ConnectionTableViewCell: UITableViewCell {
    let personImageView: UIImageView

    let animationDuration: NSTimeInterval

    // 作为属性名的firstName,很明显是字符串类型,所以不用在命名里不用包含String
    let firstName: String

    // 虽然不推荐, 这里用 Controller 代替 ViewController 也可以。
    let popupController: UIViewController
    let popupViewController: UIViewController

    // 如果需要使用UIViewController的子类,如TableViewController, CollectionViewController, SplitViewController, 等,需要在命名里标名类型。
    let popupTableViewController: UITableViewController

    // 当使用outlets时, 确保命名中标注类型。
    @IBOutlet weak var submitButton: UIButton!
    @IBOutlet weak var emailTextField: UITextField!
    @IBOutlet weak var nameLabel: UILabel!

}

// 不推荐
class ConnectionTableViewCell: UITableViewCell {
    // 这个不是 UIImage, 不应该以Image 为结尾命名。
    // 建议使用 personImageView
    let personImage: UIImageView

    // 这个不是String,应该命名为 textLabel
    let text: UILabel

    // animation 不能清晰表达出时间间隔
    // 建议使用 animationDuration 或 animationTimeInterval
    let animation: NSTimeInterval

    // transition 不能清晰表达出是String
    // 建议使用 transitionText 或 transitionString
    let transition: String

    // 这个是ViewController,不是View
    let popupView: UIViewController

    // 由于不建议使用缩写,这里建议使用 ViewController替换 VC
    let popupVC: UIViewController

    // 技术上讲这个变量是 UIViewController, 但应该表达出这个变量是TableViewController
    let popupViewController: UITableViewController

    // 为了保持一致性,建议把类型放到变量的结尾,而不是开始,如submitButton
    @IBOutlet weak var btnSubmit: UIButton!
    @IBOutlet weak var buttonSubmit: UIButton!

    // 在使用outlets 时,变量名内应包含类型名。
    // 这里建议使用 firstNameLabel
    @IBOutlet weak var firstName: UILabel!
}
  • 2.10 当给函数参数命名时,要确保函数能理解每个参数的目的。
  • 2.11 根据苹果接口设计指导文档, 如果协议描述的是协议做的事应该命名为名词(如Collection) ,如果描述的是行为,需添加后缀 able 或 ing (如Equatable 和 ProgressReporting)。 如果上述两者都不能满足需求,可以添加Protocol作为后缀,例子见下面。
// 这个协议描述的是协议能做的事,应该命名为名词。
protocol TableViewSectionProvider {
    func rowHeight(atRow row: Int) -> CGFloat
    var numberOfRows: Int { get }
    /* ... */
}

// 这个协议表达的是行为, 以able最为后缀
protocol Loggable {
    func logCurrentState()
    /* ... */
}

// 因为已经定义类InputTextView,如果依然需要定义相关协议,可以添加Protocol作为后缀。
protocol InputTextViewProtocol {
    func sendTrackingEvent()
    func inputText() -> String
    /* ... */
}

3. 代码风格

3.1 综合

  • 3.1.1 尽可能的多使用let,少使用var。
  • 3.1.2 当需要遍历一个集合并变形成另一个集合时,推荐使用函数 mapfilter 和 reduce。
// 推荐
let stringOfInts = [1, 2, 3].flatMap { String($0) }
// ["1", "2", "3"]

// 不推荐
var stringOfInts: [String] = []
for integer in [1, 2, 3] {
    stringOfInts.append(String(integer))
}

// 推荐
let evenNumbers = [4, 8, 15, 16, 23, 42].filter { $0 % 2 == 0 }
// [4, 8, 16, 42]

// 不推荐
var evenNumbers: [Int] = []
for integer in [4, 8, 15, 16, 23, 42] {
    if integer % 2 == 0 {
        evenNumbers(integer)
    }
}
  • 3.1.3 如果变量类型可以依靠推断得出,不建议声明变量时指明类型。
  • 3.1.4 如果一个函数有多个返回值,推荐使用 元组 而不是 inout 参数, 如果你见到一个元组多次,建议使用typealias ,而如果返回的元组有三个或多于三个以上的元素,建议使用结构体或类。
func pirateName() -> (firstName: String, lastName: String) {
    return ("Guybrush", "Threepwood")
}

let name = pirateName()
let firstName = name.firstName
let lastName = name.lastName
  • 3.1.5 当使用委托和协议时,请注意避免出现循环引用,基本上是在定义属性的时候使用 weak 修饰。
  • 3.1.6 在闭包里使用 self 的时候要注意出现循环引用,使用捕获列表可以避免这一点。
myFunctionWithClosure() { [weak self] (error) -> Void in
    // 方案 1

    self?.doSomething()

    // 或方案 2

    guard let strongSelf = self else {
        return
    }

    strongSelf.doSomething()
}
  • 3.1.7 Switch 模块中不用显式使用break。
  • 3.1.8 断言流程控制的时候不要使用小括号。
// 推荐
if x == y {
    /* ... */
}

// 不推荐
if (x == y) {
    /* ... */
}
  • 3.1.9 在写枚举类型的时候,尽量简写。
// 推荐
imageView.setImageWithURL(url, type: .person)

// 不推荐
imageView.setImageWithURL(url, type: AsyncImageView.Type.person)
3.1.10 在使用类方法的时候不用简写,因为类方法不如 枚举 类型一样,可以根据轻易地推导出上下文。
// 推荐
imageView.backgroundColor = UIColor.whiteColor()

// 不推荐
imageView.backgroundColor = .whiteColor()
  • 3.1.11 不建议使用用self.修饰除非需要。
  • 3.1.12 在新写一个方法的时候,需要衡量这个方法是否将来会被重写,如果不是,请用 final 关键词修饰,这样阻止方法被重写。一般来说,final 方法可以优化编译速度,在合适的时候可以大胆使用它。但需要注意的是,在一个公开发布的代码库中使用 final 和本地项目中使用 final 的影响差别很大的。
  • 3.1.13 在使用一些语句如 else,catch等紧随代码块的关键词的时候,确保代码块和关键词在同一行。下面 if/else 和 do/catch 的例子.
if someBoolean {
    // 你想要什么
} else {
    // 你不想做什么
}

do {
    let fileContents = try readFile("filename.txt")
} catch {
    print(error)
}

3.2 访问控制修饰符

  • 3.2.1 如果需要把访问修饰符放到第一个位置。
// 推荐
private static let kMyPrivateNumber: Int

// 不推荐
static private let kMyPrivateNumber: Int
  • 3.2.2 访问修饰符不应单独另起一行,应和访问修饰符描述的对象保持在同一行。
// 推荐
public class Pirate {
    /* ... */
}

// 不推荐
public
class Pirate {
    /* ... */
}
  • 3.2.3  默认的访问控制修饰符是 internal, 如果需要使用internal 可以省略不写。
  • 3.2.4 当一个变量需要被单元测试 访问时,需要声明为 internal 类型来使用@testable import {ModuleName}。 如果一个变量实际上是private 类型,而因为单元测试需要被声明为 internal 类型,确定添加合适的注释文档来解释为什么这么做。这里添加注释推荐使用 - warning: 标记语法。
/**
 这个变量是private 名字
 - warning: 定义为 internal 而不是 private 为了 `@testable`.
 */
let pirateName = "LeChuck"

3.3 自定义操作符

不推荐使用自定义操作符,如果需要创建函数来替代。

在重写操作符之前,请慎重考虑是否有充分的理由一定要在全局范围内创建新的操作符,而不是使用其他策略。

你可以重载现有的操作符来支持新的类型(特别是 ==),但是新定义的必须保留操作符的原来含义,比如 == 必须用来测试是否相等并返回布尔值。

3.4 Switch 语句 和 枚举

  • 3.4.1 在使用 Switch 语句时,如果选项是有限集合时,不要使用default,相反地,把一些不用的选项放到底部,并用 break 关键词 阻止其执行。
  • 3.4.2 因为Swift 中的 switch 选项默认是包含break的, 如果不需要不用使用 break 关键词。
  • 3.4.3 case 语句 应和 switch 语句左对齐,并在 标准的 default 上面。
  • 3.4.4 当定义的选项有关联值时,确保关联值有恰当的名称,而不只是类型。(如. 使用 case Hunger(hungerLevel: Int) 而不是 case Hunger(Int)).
enum Problem {
    case attitude
    case hair
    case hunger(hungerLevel: Int)
}

func handleProblem(problem: Problem) {
    switch problem {
    case .attitude:
        print("At least I don't have a hair problem.")
    case .hair:
        print("Your barber didn't know when to stop.")
    case .hunger(let hungerLevel):
        print("The hunger level is \(hungerLevel).")
    }
}
  • 3.4.5 推荐尽可能使用fall through。
  • 3.4.6 如果default 的选项不应该触发,可以抛出错误 或 断言类似的做法。
func handleDigit(digit: Int) throws {
    case 0, 1, 2, 3, 4, 5, 6, 7, 8, 9:
        print("Yes, \(digit) is a digit!")
    default:
        throw Error(message: "The given number was not a digit.")
}

3.5 可选类型

  • 3.5.1 唯一使用隐式拆包可选型(implicitly unwrapped optionals)的场景是结合@IBOutlets,在其他场景使用 非可选类型 和 常规可选类型,即使有的场景你确定有的变量使用的时候永远不会为 nil, 但这样做可以保持一致性和程序更加健壮。
  • 3.5.2 不要使用 as! 或 try!。
  • 3.5.3 如果对于一个变量你不打算声明为可选类型,但当需要检查变量值是否为 nil,推荐用当前值和 nil 直接比较,而不推荐使用 if let 语法。
// 推荐
if someOptional != nil {
    // 你要做什么
}

// 不推荐
if let _ = someOptional {
    // 你要做什么
}
  • 3.5.4 不要使用 unowned,unowned 和 weak 变量基本上等价,并且都是隐式拆包( unowned 在引用计数上有少许性能优化),由于不推荐使用隐式拆包,也不推荐使用unowned 变量。
// 推荐
weak var parentViewController: UIViewController?

// 不推荐
weak var parentViewController: UIViewController!
unowned var parentViewController: UIViewController
  • 3.5.5 当拆包取值时,使用和被拆包取值变量相同的名称。
guard let myVariable = myVariable else {
    return
}

3.6 协议

在实现协议的时候,有两种方式来组织你的代码:

  1. 使用 // MARK: 注释来分割协议实现和其他代码。
  2. 使用 extension 在 类/结构体已有代码外,但在同一个文件内。

请注意 extension 内的代码不能被子类重写,这也意味着测试很难进行。 如果这是经常发生的情况,为了代码一致性最好统一使用第一种办法。否则使用第二种办法,其可以代码分割更清晰。

使用而第二种方法的时候,使用  // MARK:  依然可以让代码在 Xcode 可读性更强。

3.7 属性

  • 3.7.1 对于只读属性,计算后(Computed)属性, 提供 getter 而不是 get {}。
var computedProperty: String {
    if someBool {
        return "I'm a mighty pirate!"
    }
    return "I'm selling these fine leather jackets."
}
  • 3.7.2 对于属性相关方法 get {}set {}willSet, 和 didSet, 确保缩进相关代码块。
  • 3.7.3 对于willSet/didSet 和 set 中的旧值和新值虽然可以自定义名称,但推荐使用默认标准名称 newValue/oldValue。
var computedProperty: String {
    get {
        if someBool {
            return "I'm a mighty pirate!"
        }
        return "I'm selling these fine leather jackets."
    }
    set {
        computedProperty = newValue
    }
    willSet {
        print("will set to \(newValue)")
    }
    didSet {
        print("did set from \(oldValue) to \(newValue)")
    }
}
  • 3.7.4 在创建类常量的时候,使用 static 关键词修饰。
class MyTableViewCell: UITableViewCell {
    static let kReuseIdentifier = String(MyTableViewCell)
    static let kCellHeight: CGFloat = 80.0
}
  • 3.7.5 声明单例属性可以通过下面方式进行:
class PirateManager {
    static let sharedInstance = PirateManager()

    /* ... */
}

3.8 闭包

  • 3.8.1 如果参数的类型很明显,可以在函数名里可以省略参数类型, 但明确声明类型也是允许的。 代码的可读性有时候是添加详细的信息,而有时候部分重复,根据你的判断力做出选择吧,但前后要保持一致性。
// 省略类型
doSomethingWithClosure() { response in
    print(response)
}

// 明确指出类型
doSomethingWithClosure() { response: NSURLResponse in
    print(response)
}

// map 语句使用简写
[1, 2, 3].flatMap { String($0) }
  • 3.8.2 如果使用捕捉列表 或 有具体的非 Void返回类型,参数列表应该在小括号内, 否则小括号可以省略。
// 因为使用捕捉列表,小括号不能省略。
doSomethingWithClosure() { [weak self] (response: NSURLResponse) in
    self?.handleResponse(response)
}

// 因为返回类型,小括号不能省略。
doSomethingWithClosure() { (response: NSURLResponse) -> String in
    return String(response)
}
  • 3.8.3 如果闭包是变量类型,不需把变量值放在括号中,除非需要,如变量类型是可选类型(Optional?), 或当前闭包在另一个闭包内。确保闭包里的所以参数放在小括号中,这样()表示没有参数,Void 表示不需要返回值。
let completionBlock: (success: Bool) -> Void = {
    print("Success? \(success)")
}

let completionBlock: () -> Void = {
    print("Completed!")
}

let completionBlock: (() -> Void)? = nil

3.9 数组

  • 3.9.1 基本上不要通过下标直接访问数组内容,如果可能使用如 .first 或 .last, 因为这些方法是非强制类型并不会崩溃。 推荐尽可能使用 for item in items 而不是 for i in 0..<items.count 遍历数组。 如果需要通过下标访问数组内容,在使用前要做边界检查。
  • 3.9.2 不要使用 += 或 + 操作符给数组添加新元素,使用性能较好的.append() 或.appendContentsOf()  ,如果需要声明数组基于其他的数组并保持不可变类型, 使用 let myNewArray = [arr1, arr2].flatten(),而不是let myNewArray = arr1 + arr2 。

3.10 错误处理

假设一个函数 myFunction 返回类型声明为 String,但是总有可能函数会遇到error,有一种解决方案是返回类型声明为 String?, 当遇到错误的时候返回 nil。

例子:

func readFile(withFilename filename: String) -> String? {
    guard let file = openFile(filename) else {
        return nil
    }

    let fileContents = file.read()
    file.close()
    return fileContents
}

func printSomeFile() {
    let filename = "somefile.txt"
    guard let fileContents = readFile(filename) else {
        print("不能打开 \(filename).")
        return
    }
    print(fileContents)
}

实际上如果预知失败的原因,我们应该使用Swift 中的 try/catch 。

定义 错误对象 结构体如下:

struct Error: ErrorType {
    public let file: StaticString
    public let function: StaticString
    public let line: UInt
    public let message: String

    public init(message: String, file: StaticString = #file, function: StaticString = #function, line: UInt = #line) {
        self.file = file
        self.function = function
        self.line = line
        self.message = message
    }
}

使用案例:

func readFile(withFilename filename: String) throws -> String {
    guard let file = openFile(filename) else {
        throw Error(message: “打不开的文件名称 \(filename).")
    }

    let fileContents = file.read()
    file.close()
    return fileContents
}

func printSomeFile() {
    do {
        let fileContents = try readFile(filename)
        print(fileContents)
    } catch {
        print(error)
    }
}

其实项目中还是有一些场景更适合声明为可选类型,而不是错误捕捉和处理,比如在获取远端数据过程中遇到错误,nil作为返回结果是合理的,也就是声明返回可选类型比错误处理更合理。

整体上说,如果一个方法有可能失败,并且使用可选类型作为返回类型会导致错误原因湮没,不妨考虑抛出错误而不是吃掉它。

3.11 使用 guard 语句

  • 3.11.1 总体上,我们推荐使用提前返回的策略,而不是 if 语句的嵌套。使用 guard 语句可以改善代码的可读性。
// 推荐
func eatDoughnut(atIndex index: Int) {
    guard index >= 0 && index < doughnuts else {
        // 如果 index 超出允许范围,提前返回。
        return
    }

    let doughnut = doughnuts[index]
    eat(doughnut)
}

// 不推荐
func eatDoughnuts(atIndex index: Int) {
    if index >= 0 && index < donuts.count {
        let doughnut = doughnuts[index]
        eat(doughnut)
    }
}
  • 3.11.2 在解析可选类型时,推荐使用 guard 语句,而不是 if 语句,因为 guard 语句可以减少不必要的嵌套缩进。
// 推荐
guard let monkeyIsland = monkeyIsland else {
    return
}
bookVacation(onIsland: monkeyIsland)
bragAboutVacation(onIsland: monkeyIsland)

// 不推荐
if let monkeyIsland = monkeyIsland {
    bookVacation(onIsland: monkeyIsland)
    bragAboutVacation(onIsland: monkeyIsland)
}

// 禁止
if monkeyIsland == nil {
    return
}
bookVacation(onIsland: monkeyIsland!)
bragAboutVacation(onIsland: monkeyIsland!)
  • 3.11.3 当解析可选类型需要决定在 if 语句 和 guard 语句之间做选择时,最重要的判断标准是是否让代码可读性更强,实际项目中会面临更多的情景,如依赖 2 个不同的布尔值,复杂的逻辑语句会涉及多次比较等,大体上说,根据你的判断力让代码保持一致性和更强可读性, 如果你不确定 if 语句 和 guard 语句哪一个可读性更强,建议使用 guard 。
// if 语句更有可读性
if operationFailed {
    return
}

// guard 语句这里有更好的可读性
guard isSuccessful else {
    return
}

// 双重否定不易被理解 - 不要这么做
guard !operationFailed else {
    return
}
  • 3.11.4  如果需要在2个状态间做出选择,建议使用if 语句,而不是使用 guard 语句。
// 推荐
if isFriendly {
    print("你好, 远路来的朋友!")
} else {
    print(“穷小子,哪儿来的?")
}

// 不推荐
guard isFriendly else {
    print("穷小子,哪儿来的?")
    return
}

print("你好, 远路来的朋友!")
  • 3.11.5  你只应该在在失败情形下退出当前上下文的场景下使用 guard 语句,下面的例子可以解释 if 语句有时候比 guard 语句更合适 – 我们有两个不相关的条件,不应该相互阻塞。
if let monkeyIsland = monkeyIsland {
    bookVacation(onIsland: monkeyIsland)
}

if let woodchuck = woodchuck where canChuckWood(woodchuck) {
    woodchuck.chuckWood()
}
  • 3.11.6 我们会经常遇到使用 guard 语句拆包多个可选值,如果所有拆包失败的错误处理都一致可以把拆包组合到一起 (如 returnbreakcontinue,throw 等).
// 组合在一起因为可能立即返回
guard let thingOne = thingOne,
    let thingTwo = thingTwo,
    let thingThree = thingThree else {
    return
}

// 使用独立的语句 因为每个场景返回不同的错误
guard let thingOne = thingOne else {
    throw Error(message: "Unwrapping thingOne failed.")
}

guard let thingTwo = thingTwo else {
    throw Error(message: "Unwrapping thingTwo failed.")
}

guard let thingThree = thingThree else {
    throw Error(message: "Unwrapping thingThree failed.")
}

4. 文档/注释

4.1 文档

如果一个函数比 O(1) 复杂度高,你需要考虑为函数添加注释,因为函数签名(方法名和参数列表) 并不是那么的一目了然,这里推荐比较流行的插件 VVDocumenter. 不论出于何种原因,如果有任何奇淫巧计不易理解的代码,都需要添加注释,对于复杂的 类/结构体/枚举/协议/属性 都需要添加注释。所有公开的 函数/类/变量/枚举/协议/属性/常数 也都需要添加文档,特别是 函数声明(包括名称和参数列表) 不是那么清晰的时候。

写文档时,确保参照苹果文档中提及的标记语法合集。

在注释文档完成后,你应检查格式是否正确。

规则:

  • 4.1.1 一行不要超过160个字符 (和代码长度限制雷同).
  • 4.1.2 即使文档注释只有一行,也要使用模块化格式 (/** */).
  • 4.1.3 注释模块中的空行不要使用 * 来占位。
  • 4.1.4 确定使用新的 – parameter 格式,而不是就得 Use the new -:param: 格式,另外注意 parameter 是小写的。
  • 4.1.5 如果需要给一个方法的 参数/返回值/抛出异常 添加注释,务必给所有的添加注释,即使会看起来有部分重复,否则注释会看起来不完整,有时候如果只有一个参数值得添加注释,可以在方法注释里重点描述。
  • 4.1.6 对于负责的类,在描述类的使用方法时可以添加一些合适的例子,请注意Swift注释是支持 MarkDown 语法的。
/**
 ## 功能列表

 这个类提供下一下很赞的功能,如下:

 - 功能 1
 - 功能 2
 - 功能 3

 ## 例子

 这是一个代码块使用四个空格作为缩进的例子。

     let myAwesomeThing = MyAwesomeClass()
     myAwesomeThing.makeMoney()

 ## 警告

 使用的时候总注意以下几点

 1. 第一点
 2. 第二点
 3. 第三点
 */
class MyAwesomeClass {
    /* ... */
}
  • 4.1.8 在写文档注释时,尽量保持简洁。

4.2 其他注释原则

  • 4.2.1  // 后面要保留空格。
  • 4.2.2 注释必须要另起一行。
  • 4.2.3 使用注释 // MARK: - xoxo 时, 下面一行保留为空行。
class Pirate {

    // MARK: - 实例属性

    private let pirateName: String

    // MARK: - 初始化

    init() {
        /* ... */
    }

}

那些年提交 AppStore 审核踩过的坑

感谢@云峰小罗投递   原文链接

做iOS开发近5年了,每次提交版本时不可谓不小心翼翼,如履薄冰,但是还是难免踩到了一些坑。苹果的官方文档(AppStore审核条款)这里就不罗列了,太冗长繁琐了,而且大部分是一般app都不会触碰的到的,今天我主要想以自己的亲身经历,跟大家回顾一下这些年我提交AppStore审核时踩过的坑,并且针对如何避免给出一些tips供大家参考。大神请忽略,专家请轻拍。

1、未遵守苹果iOS APP数据储存指导方针。

如果你的App有离线数据下载功能,尤其需要关注这一点。因为离线数据一般占用存储空间比较大,可以被重新下载和重建,但是用户往往希望系统存储空间紧时也依然能够妥妥的存在着,不会被IOS系统自动清理掉。所以不能放在/Library/Caches 目录下(该目录在系统空间紧张时可能会被iOS系统清除)。 那就只能放在主目录/Documents  或 主目录/Library/自定义文件夹下,这样才不会被iOS系统自动清理掉。但是这些数据可能会很大,如果放在 主目录/Documents  或 主目录/Library/自定义的文件夹下,会被iCoud自动同步,那么用户需要为了同步消耗不少流量,苹果可能会因此拒绝你的应用上架。所以需要在程序中给自定义的目录设置“do not backup”属性。

关于数据存储需要注意的点,总结在下面:

关键数据

内容:用户创建的数据文件,无法在删除后自动重新创建

路径:主目录/Documents

管理:iOS系统即时遇到存储空间不足的情况下,也不会清除,同时会备份到iTunes或iCloud中

缓存数据

内容:可用于离线环境,可被重复下载重复生成,即使在离线时缺失,应用本身也可以正常运行

路径:主目录/Library/Caches

管理:在存储空间不足的情况下,会清空, 并且不会被自动备份到iTunes和iCloud中

临时数据

内容:应用运行时,为完成某个内部操作临时生成的文件

路径:主目录/tmp

管理:随时可能被iOS系统清除,且不会自动备份到iTunes和iCloud,尽量在文件不再使用时,应用自己清空,避免对用户设备空间的浪费

离线数据

内容:与缓存数据类似,可以被重新下载和重建,但是用户往往希望这些数据即使在存储紧张时也不会被系统自动删除

目录:主目录/Documents  或 主目录/Library/自定义的文件夹

管理:与关键数据类似,即使在存储空间不足的情况下也不会被清除,应用自己应该清除已经不再使用的文件,以免浪费用户设备空间 。需要设置”不备份到iCoud” ,否则会审核不过。

2、未提供测试账号

如果你的App有部分功能需要登录才能使用,那么你需要再提交审核时,勾选演示账户,并提供对应信息,如下图:

测试账号填写

现在很多app为了更方便快捷,防止用户忘记密码,都采用手机号+验证码的方式,这样的话就没有办法给苹果提供演示账户了,除非账户系统后台做修改提供支持。这种情况,就不需要勾选演示账户了,但是要在备注信息里跟苹果好好解释一下,说我们也是为了提升用户体验的,所以对账户系统做了改进,用户有手机就能登录,不需要注册啥的,如下图。如果你啥也不说的话,那就乖乖等着被拒吧。

测试账号说明

3、跟相关硬件配合使用的app,未提供演示视频。

这里指的硬件是不需要MFi认证的,通过BLE(低功耗蓝牙)或者WiFi连接的硬件。直接在备注里提供相关功能的演示视频即可,如下图。

硬件连接演示视频

演示视频需要把完整的连接过程操作以及连接硬件之后跟硬件相关的功能演示都包含在内。从截图可以看到我的“裤宝”演示视频我是直接放在优酷上了。所以并不像传闻中那样,需要翻墙放到YouTube上,直接放优酷土豆或者百度网盘都行。也不需要用英文,用中文即可。

4、跟相关硬件配合使用的app,未提供PPID.(Product Plan ID )

如果你的App是需要跟通过MFi认证的硬件进行交互,即使用了EA框架(ExternalAccessory.framework),配置了协议字符串(Supported external accessory protocols),那么你需要在备注信息里提供PPID。

ppid说明

很多时候,我们的App可以同时适配很多型号的硬件,每个型号的硬件对应的PPID不一样。如果AppStore提交审核通过之后,又新增了一款型号硬件支持怎么办呢?是否需要单独发一个版本,把对应的PPID增加上去了? 答案是不需要,因为App支持的PPID列表信息是放在备注信息里面的,往列表中新增PPID并不需要修改到二进制文件信息,苹果在这里也比较人性化,可以在不提交新版本的情况下增加PPID信息。

5、使用了后台定位服务,但是没有具体说明原因

之前使用后台定位功能的app都是只需要在在Info.plist中配置 Required background modes -App registers for location updates 即可.但是从2016年的某个时候开始苹果突然要求如果App要使用定位功能,除了程序里做配置,还需要在界面上显式告诉用户你的后台定位是用来干啥的,否则你就会收到类似下面的邮件。

1.1 – Apps using background location services must provide a reason that clarifies the purpose of the use, using mechanisms described in the Human Interface Guidelines.

要修改也可以简单,根据你的app需要在info.plist中配置,NSLocationAlwaysUsageDescription或者NSLocationWhenInUseUsageDescription字段说明。如下图

定位目的说明

6、上传的屏幕快照跟App具体使用截屏相差太远

AppStore提供的屏幕快照功能是为了用户在未下载时可以直观的了解这个App的功能、界面大概是什么样的。所以苹果也允许开发者对屏幕截屏做一些加工美化,并不一定要是原始截屏。但是这里有个限度,就是不能相差太远,具体尺度苹果没有给出量化标准。  公司项目中有个大版本上线了一个比较大的新功能,为了突出宣传这个功能,设计师就重新设计了一套非常Q版的功能演示截图。结果上传后被苹果告知,屏幕快照不符合App本身的功能。

以上这些是本人在AppStore审核时亲自踩过的一些坑,当然还有很多坑,我和我的团队注意到了所以努力避免了,但是个人认为也是非常需要注意的,我简单列在下面供大家参考。

使用未公开的API被发现

使用和系统接近的图标

界面太丑 或者交互太过复杂

不稳定,容易崩溃

跟应用市场上其他App太过雷同

App内有检测更新

出现第三方操作系统的名字或图标

测试不充分,某些App声明支持的操作系统版本有兼容性问题

tips

我们说了这么多踩过的坑,或者差点踩过的坑,无非就是想在以后App开发中尽可能的避免。这里介绍本人的一些经验总结,供大家参考。

1、预防在先

对产品经理规划的功能,首先需要判断是否在技术上可以实现,或者说在不使用非公开API的前提下实现。因为很多时候,即使你通过函数名动态拼接等技术手段在提交审核时躲过API扫描,但是也难免被苹果从功能上发现或者被竞争对手举报。然后对交互设计和UI效果图需要有自己的判断,界面不能太丑,交互不能太复杂,不能使用跟系统太过雷同的Icon。

2、发版前过checklist

每个项目都需要沉淀发版前的checklist,把之前踩过的坑进行备忘,也可以通过网络资讯等手段了解最近时间被拒的一些主要原因,把可能跟自己APP相关的部分进行备注,然后在发版前逐条检查一遍。

3、预提交AppStore审核

如果也预防了,发版前也过了checklist,但是有时候还是难免百密一疏有所遗漏,特别是新功能较多的版本。这里我要重点推荐的就是预提交AppStore审核。项目的版本都是有发版周期的,一般在发版前一周左右App版本基本稳定,只是还需要修改一些bug并回归测试。这个时候完全可以先提交一个版本到AppStore去审核,反正版本号是用不完的,只要不占用产品经理定的版本号就行。预提交审核有什么好处呢?

(1)可以帮助暴露潜在的问题。

这个版本可能开发了一些新功能,然后有些地方可能没有考虑到审核相关的风险。如果等待项目都要结束正式发版时才暴露出来,就追悔莫及了。

(2)在迫不得已的情况下,可以试探一下苹果的界限。

苹果审核条款其实很多时候是没有一个量化标准的,比如屏幕快照不能跟App具体使用时的截屏相差太远,拿到UI设计师给到屏幕快照时,我们有时候也没有办法确定到底是否真的符合苹果的规范,但是没有关系,我们先提交一个版本试一试就知道了;还有再比如前段时间,苹果要求6月1号以后提交的App都要支持IPV6-Only的网络。但是由于历史原因,项目中有个功能用的是第三方的SDK,他们没有办法在我们发版前提供新的支持IPV6的版本。然后我看网上也有人分享说苹果对这个要求并不是非常严格,只需要在iOS9下主要功能能支持IPV6就行了。当然作为项目负责人,肯定也不能说直接把这个功能砍掉不要了,亦或轻信网友所言忽视风险。怎么办呢?赶紧先预提交一个版本试一下再做决定。结果是确实可以通过审核,所以最终版本没有砍掉这个功能,保证了产品的完整性上线了。

4、关于AppStore加急审核

如果经过前面的努力,你还是被拒了,或者App的发布要赶上某个时间运营节点,但是由于各种原因导致预留给App审核的时间太少了。这个时候你需要使用到苹果的加急审核通道。

你在百度里搜索iOS加急审核,你会发现有很多宣称可以帮你快速审核的人,24小时通过审核,审核通过后付款,不通过不要钱。如果你不知道苹果有官方的加急审核功能,你就很容易被这些空手套白狼的人所骗,而且收费都是5000RMB起步。那我真的很想对你说,找我吧,给你友情价打5折。

苹果的加急审核如何使用呢? 在iTunesconnect页面,点击右上角的“?”图标,在弹出菜单中选择“联系我们”,

联系我们

然后在Contact Us页面,选择“App Review” —> “App Store Review” —>” Request Expedited Review”,

加急审核选项

最后在表格里填写相关信息,其中最重要的写你需要加急审核的原因。一般是写要赶某个重大节日运营节点,或者紧急修复某个严重的闪退问题,然后注明闪退现象复现的详细步骤,就可以了。

关于具体加急审核有没有次数限制,次数是跟App相关还是跟开发账号相关,苹果并没有官方的说明。但是可以肯定的是,网上传闻一年只有两次加急审核的机会是不正确的。不过为了让好钢用在刀刃上,还是慎用这个功能,以防到时真的有需要加急审核时却得不到响应。

从今年上半年开始,app审核时间大大缩短了,一般都不需要用到这个功能了。百度CarLife 最近几个版本都是3天就通过审核了,尤其是最新的支持EAP连接的版本V2.1.0,一个晚上就审核通过了。

毛主席告诉我们“与天奋斗,其乐无穷!与地奋斗,其乐无穷!与人奋斗,其乐无穷!”,但是作为iOS开发者,跟苹果奋斗,还是小心谨慎为好。最后提一句, 如果你知道你的app存在某个审核风险,但是通过了苹果审核,那么不要存在侥幸心理,请尽快修改。因为毕竟苹果是人工审核,这个版本过了可能是审核人员心情好,并不代表下个版本审核时心情也这么好。

其实想想最近的广电总局手游审查新政,对AppStore的审核规则也就没有啥可以抱怨的了。

浅析手机抓包方法实践

0x00 摘要


在移动逆向分析以及 App 开发的时候,总会需要对其网络行为进行监控测试,本文总结一些抓包思路,并对其使用方法进行实践

笔者认为在抓包界,Wireshark 应该算是综合排名第一的工具(其实 Wireshark 自带的命令行工具 tshark 更牛逼)

本文总结记录了 5 种抓包方式,掌握其一即可进行实践,欢迎大家一起交流分享

0x01 基于 Wireshark


实验步骤:

1.1 在电脑主机上使用 猎豹 Wifi之类的工具,开启热点,将所要测试的手机连接该热点,记录其IP地址

1.2 使用 Wireshark 对以上 IP 地址进行捕获

Capture——Options

1.3 总结

该方法简单粗暴高效,可以将捕获的数据包随时保存下来,便于后续分析或者进行 PCAP 可视化分析。

关于命令行工具 tshark 在此不做赘述,感兴趣的读者自行研究。

0x02 基于 tcpdump


实验环境:

下载安装 Genymotion 安卓虚拟机,在该模拟器环境种进行实践操作(基于实体手机亦然,前提是 手机必须得 ROOT

笔者仅在 Android 系统下测试,未在 iOS 系统下实验

实验步骤:

2.1 说明

模拟器中自带的 tcpdump 工具,位于: /system/xbin/ 目录下

2.2 数据包捕获

可以通过 adb shell 命令在 CMD 模式下连接模拟器, su 到 root 模式进行抓包

tcpdump -vv -s 0 -i eth1 -w /sdcard/capture.pcap

参数说明:

  • -vv:获取详细的包信息(注意是两个 v 不是 w)
  • -s 0:不限数据包的长度,如果不加则只获取包头
  • -w xxx.pcap:捕获数据包名称以及存储位置(本例中保存在 sdcard 路径下,数据包名为 capture.pcap)
  • -i eth1:捕获制定的网卡(在 genymotion 虚拟机中,使用 busybox ifconfig 命令可以查看相关信息,一般 genymotion 的 ip 地址都为 10.xx.xx.x)
  • 如果你想指定捕获的数据包长度,可以使用 -c 参数(例如 -c 128)

捕获结束,直接按 Ctrl + C 即可

2.3 数据分析

将捕获到的数据包拖到本地使用 Wireshark 进行查看:

adb pull /sdcard/capture.pcap C:\tmp

TIPS:将数据包文件 push 到手机上命令为

adb push C:\tmp\capture.pcap /sdcard/

0x03 基于 Fiddler 4


实验步骤:

3.1 下载 FIddler 4

3.2 设置 Fiddler 4

打开Fiddler,Tools-> Fiddler Options (配置完成记得重启 Fiddler)

3.3 设置手机代理

首先,获取安装 Fiddler 4 的 PC 对应的 IP 地址(ipconfig):

确保手机和 PC 是连接在同一个局域网中!!!

下面对手机进行设置(笔者使用小米测试机):点击手机中“设置”——Wi-Fi——选择已经连接的wifi——代理设置改为手动

下载 Fiddler 的安全证书

使用手机浏览器访问: http://10.2.145.187:8888,点击”FiddlerRoot certificate”,然后安装证书即可。

至此,已经全部设置完毕。

3.4 数据包捕获

重新打开 Fiddler 4,然后打开手机中的浏览器,访问任意网址,Fiddler 抓包信息如下:

Enjoy!

0x04 基于 Charles


实验环境:

win7 + Charles v3.11

一般使用 Charles 都是基于 MAC OS ,笔者在 mac 平台以及 windows 平台均试验过,操作过程和思路基本一致,因此,本文以 win7 为测试环境

实验步骤:

4.1 捕获 http 数据包

手机设置代理:

打开 Charles 即可捕获数据包(Proxy —— Proxy Settings):

4.2 捕获 https 数据包

手机端安装证书:

Android 手机或者 iPhone 均可直接访问 http://www.charlesproxy.com/ssl.zip ,然后根据图示点击证书安装

设置 Charles:

选择 Proxy —— SSL Proxying Settings —— Locations —— Add

在弹出的表单中填写 Host 域名(也就是你想要抓包链接的主机名),以及对应的 Port 端口(此处相当于过滤作用)

当然,你可以采用更加粗暴的方式:使用通配符,例如你想要捕获所有的 https 包,这里也可以直接都为空,表示捕获所有的主机和端口;或者都分别填“*”星号,匹配所有的字符,捕获所有的 https。

0x05 基于 Burpsuite


实验步骤:

5.1 捕获 http 数据包

PC 端 Burpsuite 设置:

手机端代理设置方法同以上 3.3 4.1

打开 Burpsuite 即可捕获 http 数据包:

5.2 捕获 https 数据包

手机端设置好代理之后,使用浏览器访问: http://burp/

此处存在一个问题:下载的证书是 der 格式的,我们手机端安装的是 crt 格式的,需要使用 firefox 浏览器转一下格式:可以首先在 Brupsuite 中导出 der 格式证书,然后导入火狐浏览器,然后从火狐浏览器导出证书格式为 crt

打开火狐浏览器:工具——选项——高级——证书——查看证书

成功捕获 https 数据包

0x06 总结


  • 当我们停止捕获数据包时,将Fiddler 或 Charles 关闭,此时手机端是无法正常访问网络的,因为设置了代理,这时候需要将代理关闭,即可正常浏览网页
  • 对于大多数走代理的应用可以选择 Fiddler 或 Charles,无需 root,一次配置,终身使用;对于不走代理的 App 可以利用 tcpdump 捕包,然后使用 Wireshark 查看;最简单便捷的便是第一种方法 「0x01. 基于 Wireshark」
  • 以上所有工具各有优劣,读者可以根据工作环境,按需使用,个人觉得一般情况下使用 Wireshark + Fiddler 或者 Wireshark + Charles 即可完成各平台的抓包分析任务
  • 以上工具中只有BurpSuite可以对抓包过程进行交互式操作;Wireshark支持的协议最多,也更底层,功能强大,但过于沉重
  • 对于本文涉及的相关工具的安装、设置、破解、详细使用,不在本文讨论范围之内(Charles 免费版其实还比较厚道,如果重度需要,建议购买正版),本文旨在浅析捕获移动终端数据包的方法和思路

来源:http://drops.wooyun.org/tips/12467

作者:Ms4dam0n