[xcode-build] Framework 분리와 Build 최적화로 Build 시간 줄이기

목차

- 빌드 최적화 원리
- Framework 추가하는 방법
- Workspace 추가
- WorkSpace + MyApp + Feature Framework
    - xcode 에서 설정할 것
    - 코드 파일에서 설정할것 접근 제어자: public
    - BuildPhase 에서 Feature 추가 
- architecture에 따른 빌드 파일
    - arm64
    - x86_Intel
- 증분 컴파일, 전체 모듈 컴파일(Debug, Release)
    - 전체 모듈 컴파일
    - 변경된 부분만 컴파일 + 기존 캐시된 컴파일 사용

빌드 최적화 하는 방법

1. 모든 파일 컴파일 → Framework 단위 컴파일
2. 모든 파일 컴파일 → 변경 사항만 컴파일
3. 빌드 파일(실행파일)을 사용자 architecture 에 맞춰서 생성(Intel 칩만 해당)

• 위의 방법을 이용해 Alex 님이 앱 빌드 시간을 40~50초 걸리는 것을 2.5초로 단축했다고 하여 정리함

빌드 최적화 원리

• Xcode에 번들에 있는 파일이 변경사항이 있을 때마다 모든 파일을 컴파일하면?
  • 빌드 시간 오래 걸림
• Debug의 경우에 모든 파일을 컴파일 할 필요 없기 때문에 변경된 파일만 컴파일 하도록 할 것임
• 또한 파일의 개수가 많아지면 모든 파일의 변경사항 유무를 조사하는 것만 해도 시간이 많이 소요되므로 Framework 단위로 분리
• 예를 들어 맥북이 인텔칩인 경우 디버그할 때는 x86_intel 아키텍쳐 시뮬레이터만 만들어도 충분한데, arm64 아키텍처까지 만드는 경우를 막을 것임

---

증분 컴파일(Debug, Release)

• 증분 컴파일: 변경 사항이 있는 파일만 컴파일을 다시하고, 변경 사항이 없는 파일은 캐시된 빌드파일을 사용
• 전체 모듈 컴파일: 빌드마다 모든 파일을 다시 컴파일하여 build 파일 생성

위치: Navigator에서 ****MyApp 클릭 → “Targets” 클릭 → “Build Settings” → “compilation mode” 검색

빌드할 파일 전략

옵션 선택 가능

 

• Debug 파일의 경우 Incremental 로 되어있는지 확인
• 경우에 따라서 Release 에서도 Incremental 로 해도 좋다.

모듈 단위로 Framework 분리

Workspace

• *.xcworkspace 를 뜻함
• 기본은 위와 같지만 하얀색 파일을 만들면 이런 구조가 가능해짐
• “Workspace = app + frame” 의 구조를 만들어 갈 수 있음

1. Workspace 추가(순서 중요)

• xcode → File → Save As Workspace
• “MyWorkspace” → 이름은 앱과 같아도 되고 달라도 됨
• xcode 버그 때문에 같은 과정을 두번해줘야 저 하얀색파일이 생김

2. Framework 추가(순서 중요)

• New Project → Framework → “MyFeature” (이름은 원하는 이름으로)
  • Add to: 여기를 종전에 만들어준 Workspace라고 설정
  • Group : 마찬가지로 전에 만들어준 workspace 설정
• 이렇게 하면 Workspace 로 들어오면 Feature를 사용할 수가 있음
• *.xcworkspace 로 구동해야 Framework와 App 모두 사용 가능

• feature라는 파일의 framework 가 생김

Framework 와 App 연결 - Linking

• Framework 에서 간단한 extension 파일을 생성해서 기존의 MyApp 에서 활용하도록 설정
  • 간단한 Extension 추가

Resources 에 넣는거 아닙니다. Feature 바로 밑에 넣어주세요.

import Foundation

extension String {
    static var ownerName: String { "Damagucci-Juice" }
}

import Feature      // No such module "Feature"
import SwiftUI

struct ContentView: View {
    var body: some View {
        Text(String.ownerName)
        .padding()
    }
}

• Feature 프레임워크를 생성은 해주었으나, MyApp에서 사용하려면 Linking 을 해줘야함.
• MyApp → Targets → Genearal → Frameworks, Libraries and Embedded Content → “ + “

• 서류 가방 모양의 저것을 클릭하고 Add를 해줘야하는 모습

• 추가가 잘 된 모습

• 여기서 확인을 해보면 알 수 있다.
• 그런데도 Feature 프레임워크는 인지를 하는데, 하나 안되는 부분이 있다.

여전히 발생하는 오류

• Feature 프레임워크에서 설정한 코드의 접근제어자가 기본적으로 internal 로 되어있기 때문
• ownerName 의 접근 제어자를 public 으로 변경

extension String {
    public static var ownerName: String { "Damagucci-Juice" }
}

아키텍쳐 별로 빌드 타겟 설정하기

• Simulater 를 돌리는데 x86 버젼과 arm64 버전 모두를 돌리면 build 파일을 만드는데 시간이 소요
• 배포하는 버전이 아닌 Debug 용 버전에서는 자신의 cpu 아키텍쳐에 맞춰서 Build 파일을 만드는 설정
• Finder 에서 앱 Build 파일 찾는 법
  • xcode 상단바 → Product → show build folder in fider
    • Product → Debug-iphonesimulator → MyApp.swiftmodule

• 필자는 M1 환경이여서 arm64 파일로만 simulator를 만드는데, 그 원인이 되는 설정이 다음과 같다.

• MyApp → Targets → Build Settings → Archiectures → Build Active Architecture Only
• Build Active Architecture Only: 현재 cpu 에 맞춰서 simulator를 생성
  • Debug - Yes: 디버그 모드에선 현재 M1 칩을 사용하고 있으므로 Arm64 버전의 시뮬레이터만 생성하겠다는 뜻
  • Release - No: 배포 버전에서는 Intel 시뮬레이터와 Arm64 시뮬레이터 모두를 생성
• 주의: M1 의 경우 Yes 로 설정해도 Intel 버전 simulator 빌드가 안되는 것으로 확인
  • Intel 칩 사용중이신 분들의 제보를 기다립니다..

framework 를 재설치 하는 경우가 많을 때 header 파일 관리

• 예를들어서 네이버 로그인을 인증을 넣는다고하면, pod 인스톨을 새로하면 원래 가지고 있던 header 파일의 정보를 다시 입력해줘야하는 경우가 종종 있음
• 그러지말고, SDK의 source code 를 직접 다운로드 받아서 프로젝트에 넣어 놓고, 그 안에서 헤더 파일을 관리하면 프로젝트를 새로 시작할 때마다 매번 header 파일을 새로 넣어줄 필요가 없다. 

 

출처

• 선데이 테코톡에서 듣고 정리 < from Alex_감사합니다 : ) >