[Swift] Improving Build Efficiency with Good Coding Practices 번역

https://developer.apple.com/documentation/xcode/improving-build-efficiency-with-good-coding-practices

Improving Build Efficiency with Good Coding Practices

코드가 내보내는 symbols 수를 줄이고 컴파일러에 필요한 명시적 정보를 제공하여 컴파일 시간을 단축합니다.

Overview

빌드 시간을 몇 초라도 단축하면 개발 과정에 상당한 영향을 미칠 수 있습니다.

Xcode는 가능한 한 빨리 당신의 코드를 만들기 위해 모든 것을 합니다.

빌드 작업을 병렬화하고 사용 가능한 모든 리소스를 활용하여 완제품을 출력합니다.

그러나 컴파일러를 위해 불필요한 작업을 만들지 않도록 함으로써 Xcode를 도울 수 있습니다.

 

 

수년간 Xcode 컴파일러는 컴파일 시간을 단축하기 위한 최적화를 내놓았습니다.

이러한 최적화 대부분은 자동이지만 일부에서는 사용자가 코드를 약간 변경해야 합니다.

또한 Swift에 Objective-C 코드를 모두 지원하는 프로젝트는 빠른 컴파일 시간을 보장하기 위해 추가적인 최적화가 필요할 수 있습니다.

Note

You can also optimize build times through project-level changes. For more information on optimizing build times, see Improving the Speed of Incremental Builds.

Include Framework Names in Import Statements

헤더를 소스 파일로 import할 때 항상 부모 프레임워크 또는 라이브러리의 이름을 import 문에 포함하세요.

C 기반 코드에서 헤더를 가져오면 일반적으로 헤더 파일의 내용이 소스로 복사됩니다.

프레임워크 이름을 포함하면 컴파일러는 모듈 맵을 사용하여 헤더를 가져올 수 있으므로 import 시간이 크게 단축됩니다.

모듈 맵을 사용하면 컴파일러는 프레임워크의 헤더 파일을 한 번 로드하고 처리하며 symbol 정보 결과를 디스크에 캐시합니다.

다른 소스 파일에서 동일한 프레임워크를 가져오면 컴파일러는 캐시된 데이터를 재사용하므로 헤더 파일을 다시 읽고 사전 처리할 필요가 없습니다.

 

 

시스템 프레임워크와 프로젝트에서 만드는 사용자 정의 프레임워크 모두 프레임워크 이름을 포함하세요.

다음 예제에서는 모듈 맵이 있는 시스템과 사용자 지정 프레임워크에 대한 import 문을 보여 줍니다.

마지막 import 문은 사용 가능한 모듈 맵을 사용하지 않고 헤더 파일 내용을 계속 로드하고 직접 처리합니다.

// Imports the framework’s module map
#import <UIKit/UIKit.h>
#import <PetKit/PetKit.h>     // Custom framework

// Performs a textual inclusion of the header file.
#import "MyHeader.h"

사용자 정의 프레임워크에 모듈 맵을 추가하는 방법은 Create Module Maps for Custom Frameworks and Libraries를 참고하세요.

 

Minimize the Number of Symbols You Share Between Swift and Objective-C

프로젝트에서 Swift와 Objective-C 코드를 혼합할 때 Swift 코드는 Objective-C 코드의 일부를 알아야 할 수 있으며, 그 반대의 경우도 마찬가지입니다.

컴파일러는 두 개의 특수 헤더 파일을 사용하여 symbol 정보의 교환을 처리합니다.

• Objective-C bridging header는 Swift 코드에서 사용할 수 있는 Objective-C symbols를 결정합니다.
• compiler-generated Swift header는 Objective-C 코드에서 사용할 수 있는 모든 공개 Swift symbol의 목록입니다.

두 헤더 파일의 크기를 줄이면 컴파일러의 작업량이 감소하고 컴파일 시간이 단축됩니다.

파일 크기가 작을수록 컴파일러는 헤더를 더 빨리 처리할 수 있습니다.

또한 소스 파일을 컴파일할 때 symbol 조회 시간이 빨라집니다.

 

 

Objective-C 브리징 헤더의 내용을 구성할 때 Swift 소스에서 실제로 참조하는 헤더와 symbol만 포함하세요.

Swift 코드가 Objective-C 클래스의 일부만 사용하는 경우, Swift 코드가 사용하지 않는 symbol를 구현 파일 또는 내부 전용 헤더 파일의 categories에 옮기세요.

 

 

다음 그림은 외부에서 사용하는 symbols와 클래스에서 내부적으로 사용하는 symbols를 구분하는 방법을 보여줍니다.

MyViewController.h 헤더에는 Swift 코드에서 공개적으로 참조하는 symbols의 하위 집합만 포함되어 있습니다.

MyViewController-Internal.h header에는 클래스의 category extension에 나머지 symbols가 포함됩니다.

Objective-C 구현 파일에 두 헤더를 모두 포함하되 Objective-C 브리징 파일에는 공용 헤더만 포함합니다.

 

컴파일러는 생성된 헤더를 사용하여 Objective-C 코드에서 모든 공개 Swift symbols를 자동으로 사용할 수 있도록 합니다.

생성된 헤더의 크기를 최소화하려면 다음과 같은 방법으로 Swift 코드를 업데이트하세요.

• Swift 클래스의 내부 메서드 및 프로퍼티를 private으로 표시합니다. 이 키워드가 있으면 생성된 헤더 파일에 기호가 포함되지 않습니다.
• function-based API보다 block-based API를 선택합니다. 블록은 구현의 일부이며 public symbol 정보를 생성하지 않습니다.
• 최신 버전의 Swift 언어를 지원합니다. Swift 3 이전 버전에서는 대부분의 symbol에 대해 Objective-C 유형 정보를 자동으로 추론하여 생성된 헤더의 크기를 증가시킵니다. 이후 버전의 스위프트는 더 적은 상황에서 자동 유형 추론을 수행하여 헤더의 전체 크기를 줄입니다.

Provide the Swift Compiler with Explicit Type Information

Swift 컴파일러는 사용자가 지정한 값에서 변수 유형을 추론할 수 있습니다.

단순 값의 경우 추론 과정이 빠릅니다.

예를 들어 0.0 값을 프로퍼티에 할당하면 컴파일러는 해당 유형이 부동 소수점 번호인지 신속하게 확인할 수 있습니다.

그러나 변수에 복잡한 값을 할당하는 경우 컴파일러는 모든 유형 정보를 계산하기 위해 추가 작업을 수행해야 합니다.

 

 

다음 구조체는 bigNumber 프로퍼티에 명시적 type 정보가 없습니다.

해당 프로퍼티의 type을 결정하기 위해 Swift 컴파일러는 reduce(_:_:)함수의 결과를 평가해야 하며, 이는 무시할수 없는 시간이 걸립니다.

struct ContrivedExample {
   var bigNumber = [4, 3, 2].reduce(1) {
      soFar, next in
      pow(next, soFar)
   }
}

컴파일러가 type을 결정하도록 하는 대신, 가장 좋은 방법은 아래 예시와 같이 type을 명시적으로 제공하는 것입니다.

명시적 type 정보를 제공하면 컴파일러가 수행해야 하는 작업이 줄어들고 더 많은 오류 검사를 수행할 수 있습니다.

struct ContrivedExample {
   var bigNumber : Double = [4, 3, 2].reduce(1) {
      soFar, next in
      pow(next, soFar)
   }
}

 

Define Delegate Methods in Explicit Protocols

Delegate는 Apple 플랫폼의 표준 설계 패턴이며 객체 간 통신에 유용한 방법을 제공합니다.

Delegate를 통해 임의 개체 간의 통신이 가능해지더라도 항상 Delegate에 대한 명시적 type 정보를 제공하세요.

 

 

any type의 옵셔널로 선언된 delegate의 다음 예를 보세요.

이 선언은 완벽하게 합법적이지만, 실제로 컴파일러에 더 많은 작업을 만듭니다.

컴파일러는 프로젝트 또는 참조된 프레임워크의 어떤 객체에 함수가 포함되어 있다고 가정해야 하며, 따라서 전체 프로젝트를 검색하여 함수가 어딘가에 존재하는지 확인해야 합니다.

weak var delegate: AnyObject?
func reportSuccess() {
   delegate?.myOperationDidSucceed(self)
}

any object대신에 더 나은 접근법은 특정 type 정보를 제공하는 것입니다.

일반적으로 타입 정보를 delegate 프로토콜을 사용하여, 아래 예처럼 지정합니다.

명확한 프로토콜은 컴파일러에서 좀 더 빨리 메서드를 찾는데 도와 줍니다.

또한 컴파일러는 delegate 프로퍼티에 할당한 객체에 대해 추가적인 유형 검사를 수행할 수 있습니다.

weak var delegate: MyOperationDelegate?
func reportSuccess() {
   delegate?.myOperationDidSucceed(self)
}

protocol MyOperationDelegate {
   func myOperationDidSucceed(_ operation: MyOperation)
}

 

Simplify Complex Swift Expressions

Swift 언어를 사용하면 매우 표현적인 방법으로 코드를 작성할 수 있지만 코드가 컴파일 시간에 영향을 미치지 않도록 해야 합니다.

reduce 함수를 사용하여 값 집합을 합하는 함수의 예를 생각해 보세요.

모든 인수에 대해 nil을 넘으면 함수가 nil을 반환하지만, 하나 이상의 인수를 넘으면 해당 인수의 합계가 계산됩니다.

이 함수는 컴파일러가 클로저에서 한 줄 식을 사용하여 해당 클로저의 return type을 결정하는 Swift 기능을 활용합니다.

func sumNonOptional(i: Int?, j: Int?, k: Int?) -> Int? {
   return [i, j, k].reduce(0) {
      soFar, next in
      soFar != nil && next != nil ? soFar! + next! : (soFar != nil ? soFar! : (next != nil ? next! : nil))
   }
}

이 함수는 합법적인 Swift 구문을 나타내지만, 한 줄의 클로저는 코드를 읽기 어렵게 하고 컴파일러가 평가하기 어렵게 만듭니다.

실제로 컴파일러는 적절한 시간 내에 식을 입력할 수 없다는 오류와 함께 중단합니다.

한 줄의 클로저도 불필요합니다.

reduce 함수의 정의는 사용자가 전달한 것과 동일한 유형(이 경우 optional Int)을 반환하도록 합니다.

 

 

이렇게 복잡한 표현을 쓰기보다는 좀 더 단순하고 읽기 쉬운 것을 만드는 것이 좋습니다.

다음 코드는 한 줄 클로저 버전과 동일한 동작을 제공하지만 읽기 쉽고 빠르게 컴파일할 수 있습니다.

func sumNonOptional(i: Int?, j: Int?, k: Int?) -> Int? {
   return [i, j, k].reduce(0) {
      soFar, next in
      if let soFar = soFar {
         if let next = next { return soFar + next }
         return soFar
      } else {
         return next
      }
   }
}