[Lecture 1] Getting Started with SwiftUI


View

UIKit과 마찬가지로 View라는 구조체(struct)를 통해 사용자의 입력(탭, 스와이프, 핀치.. 등)과 출력을 담당한다.

 

import SwiftUI

struct ContentView: View {
    var body: some View {
        VStack {
            Image(systemName: "globe")
                .imageScale(.large)
                .foregroundColor(.accentColor)
            Text("Hello!")
                .padding(.all)
        }
        .padding()
    }
}

UI구성의 내용이 담긴 ContentView는 결국 View 구조체이며, 이러한 구조체 안에는 여러 가지 변수, 메서드를 담아낼 수 있다.

눈여겨볼 것은 body 변수인데, 해당 변수는 View도 아닌, some View라고 정의되어 있다.

강의에서는 "something that behave like a View"라고 설명했다. 즉 "View처럼 행동하는 무언가" 정도로 해석이 가능하다.

 

그렇다면 왜 View가 아니라 View처럼 행동하는 무언가일까?

교수님은 해당 부분을 레고에 비유하였다. 

우리가 레고로 집을 만든다고 하였을 때, 작은 단위의 레고를 모아 의자, 소파, 테이블과 같은 작은 단위의 레고를 만들고, 그것들이 모여 거실, 방, 지붕과 같은 큰 단위로 결합하게 된다. SwiftUI 또한 작은 단위의 View가 결합되어 하나의 View를 구성하게끔 동작한다는 것이다. 즉 수많은 종류의 View 중에 어떤 형태의 View가 반환될지 모르기에 some View라는 키워드로 치환된 것이다.

조금 더 해당 표현에 대해 자세한 설명을 하자면, 화면상에 단 하나의 View만 존재하게 될 경우, 위와 같은 코드로 작성하게 된다. 하지만 해당 코드는 swiftUI에 의해 몇 가지 키워드가 치환된 형태이다. 조금 더 명시적인 형태로 작성하게 되면 아래의 코드로 적을 수 있다.

 

import SwiftUI

struct ContentView: View {
    var body: Text {
        return Text("Hello!")
    }
}

ContentView의 body는 Text라는 View구조체이며, 이는 곧 "Hello"라 적힌 Text View를 반환한다는 것. 하지만 예시보다 복잡한 여러 형태의 View가 조합되면 개발자는 이에 대한 명시를 하기 어려워지므로 some View라는 형태로 적게 된 것이며, 해당 부분에 대한 치환은 컴파일러가 알아서 처리하게 하는 것이다.

 

이처럼 body와 같이 여러 가지 View를 결합하는 View를 Combiner View라고 소개하였으며, 해당 부분의 some View는 대부분 Combiner View를 의미한다고 한다.

 

함수형 프로그래밍

ContentView의 body는 변수로 선언이 되어있지만, 메모리에 저장되지 않는다고 한다. body에 접근할 때마다 body 뒤에 이어진 { ... } 블록의 해당 함수 내용을 수행하고 반환되는 결과를 받아 오는 것이다. 이는 swift의 큰 특징 중 하나인 함수형 프로그래밍에 의한 표현이다.

 

결론

some View라는 표현은 개발자가 편하기 UI 작성하기 위한 표현이며, 이는 최종적으로 컴파일러가 body의 closure에 정의된 함수 내용을 수행하여 반환되는 특정한 View로 치환하게 된다는 이야기이다.


Zstack

View에는 여러 가지 종류의 View가 있으며 이들 중 다른 View를 결합하는 combiner View가 있다 했다. Zstack 또한 강력한 기능을 가진 Combiner View라고 소개되었는데, content { ... } 인자 내에 단순히 View를 나열하기만 하면 스크린 - 사용자 방향 순서로 view를 결합하는 기능을 수행한다. 강의에서는 이렇게 나열을 통해 View를 결합하는 것을 View Builder Machanism이라는 표현으로 소개하였다.

 

Zstack을 통해 생성한 View

Zstack에는 나열한 것을 View로 생성하는 것 이외에도 또 다른 강력한 기능이 있는데, 바로 ZStack에 적용한 속성들이 Zstack 하위의 View에 상속된다는 점이다.

 

View의 공통 속성인 padding()을 Zstack에 적용한 모습

예시의 padding 이외에도 foregroundColor 등 View가 가진 공통 속성들의 적용이 가능하며, 당연하게도 하위 View에 직접 속성을 적용하게 된다면 오버라이딩과 같은 효과를 줄 수 있다.

 

참고 영상

https://www.youtube.com/watch?v=bqu6BquVi2M&ab_channel=Stanford 

'iOS > Stanford' 카테고리의 다른 글

[Assignment 1] Memorize  (0) 2023.07.06
[Lecture 2] Learning more about SwiftUI  (0) 2023.07.05
[Lecture 1] Getting Started with SwiftUI - 1  (0) 2023.06.16
day06_multiTouch  (0) 2022.03.26
day05_view  (0) 2021.12.30

Lecture 1: Getting started with SwiftUI


iOS 관련 유명한 강의인 스탠포드 대학의 cs193p Developing Applicaitons for iOS 강의다.

해당 강의는 누구나 스탠포드 유튜브 채널에서 시청이 가능하다.

기존의 2017버전 강의에서는 실시간 강의영상이었다면 이번에는 코로나 팬데믹으로 인한 온라인 강의 영상이므로 교수님이 작성하는 코드나 제공되는 시청자료들을 더 좋은 환경에서 볼 수 있다.

 

기존 2017버전에서는 UIKit 프레임워크를 이용한 MVC 패턴의 앱개발이 주 내용이었다면, 2021 버전에서는 이제 현업에서 적극적으로 사용되는 MVVM 패턴과 이에 맞게 애플에서 개발한 swiftUI 프레임워크를 이용한 앱개발이 주 내용이 될 것이다.

 

지난번 2017강의를 들으면서 내용들을 전부 옮겨 적으려 해서 학습에도, 기록에도 힘이 들었기에 이번에는 강의 내용을 모두 옮겨적는다기보단 내가 보았을 때 흥미로운 내용 위주로, 하나의 강의 내에 여러 흐름으로 나누어서 작성하는 것을 통해 빠르게 학습하고 빠르게 기록하는 것에 초점을 두고 글을 적으려고 한다.


이번 첫강의에서는 swiftUI로 작성된 프로젝트를 전반적으로 훑어보면서 swiftUI 프레임워크의 구성을 간략하게 알아보았다.

 

swiftUI project File Hierarchy

가장 먼저 swiftUI로 프로젝트를 생성하게 되면 다음과 같은 파일이 자동으로 생성된다.

(프로젝트명)App.swift 파일과 ContetnView.swift 파일이 이번 swiftUI 프레임워크의 주요 파일이다.

 

import SwiftUI

@main
struct MemoriesApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
        }
    }
}​

 

App.swift 파일은 다음과 같이 작성이 되어있으며, 주의깊게 봐야할 부분이 @main 어노테이션이다.

해당 어노테이션은 UIKit으로 생성한 프로젝트에서 AppDelegate 파일에 있던 어노테이션으로 앱의 진입지점(entry point)를 나타낸다. 즉 swiftUI의 진입지점(entry point)은 App.swift 파일이며 해당 App 객체의 생성으로 앱의 실행으로 이어진다는 얘기이다. 

 

다음으로 주목해야 할 부분은 App 객체의 body 부분에 할당된 ContentView() 객체이다.

ContentView() 객체를 생성하는 것을 볼 수 있고, 해당 객체는 ContentView.swift 파일에 선언되있는 것을 확인할 수 있다.

 

 

ContentView.swift 파일을 살펴보게면 xcode에서 3개의 영역를 제공한다.

  1. 코드를 작성하는 textEditor 영역
  2. 앱의 UI가 어떻게 보이게 될지 미리 보여주는 preView 영역
  3. 사용자에게 보여질 UI를 구성하는 각 개별의 View를 설정 할 수 있는 inspector 영역

흥미로운 점은 이 3개의 영역이 실시간으로 연동이 된다는 점이다. 강의에서는 sync 되어있다는 표현을 사용했는데 즉, 사용자가 마주하는 Text, Image와 같은 UI뷰의 설정을 3개의 영역 모두에서 접근이 가능하며 해당 수정사항이 실시간으로 일어난다는 것.

 

 

기존의 UIKit 프레임워크의 XML 형태와 달리 xcode가 코드로 짜여진 UI를 실시간으로 처리하는 것처럼 와닿았다. 

 

해당 부분이 반가운 점은 UIKit을 사용할 때에는 기존의 UI를 IBAction, IBOutlet을 통해 연결했는데, 가끔씩 라인을 이동한다던지, 이름을 변경하게 되었을 때 싱크가 끊어지는 경우가 종종 생긴다는 점이었다.

 

애플도 해당 문제점을 정확히 파악하고 있었을 것이고 확실한 것은 아니지만 SwiftUI를 통해 해당 문제점을 해결하기 위래 노력을 많이 한 것으로 느껴졌다.

 

import SwiftUI

struct ContentView: View {
    var body: some View {
        VStack {
            Image(systemName: "globe")
                .imageScale(.large)
                .foregroundColor(.accentColor)
            Text("Hello!")
                .padding(.all)
        }
        .padding()
    }
}

struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        ContentView()
    }
}

 

ContentView.swift의 내용을 살펴보면 View 구조체와 PreViewProvider 구조체가 보인다.

PreViewProvider의 경우 이름에서 알 수 있듯이 UI의 실시간 반영을 위한 preView를 위한 코드부분이다. 

 

결국 개발자가 UI를 구성하는 코드를 작성하는 곳은 ContentView라는 이름의 View 구조체인 것이다.

 

참고 영상

https://www.youtube.com/watch?v=bqu6BquVi2M&ab_channel=Stanford 

'iOS > Stanford' 카테고리의 다른 글

[Lecture 2] Learning more about SwiftUI  (0) 2023.07.05
[Lecture 1] Getting Started with SwiftUI - 2  (0) 2023.06.22
day06_multiTouch  (0) 2022.03.26
day05_view  (0) 2021.12.30
day04_swift_part2  (0) 2021.10.25

 

rsync error: some files could not be transferred (code 23) Command PhaseScriptExecution failed with a nonzero exit code

I tried to connect flutter project to my iPhone, but suddenly this error showed up after adding Google AdMob. I've already tried keychain solution(Xcode 10.2.1 Command PhaseScriptExecution failed w...

stackoverflow.com

출시된 앱의 업데이트를 위해 빌드하다가 마주한 오류다. 스택오버플로우에서 찾아보니 최근에 진행된 xcode 14.3 업데이트로 인해 발생한 오류이다. 

 

해결법은 간단하게도 해당 프로젝트의 cocoadpods 디렉터리 내에 있는 frameworks.sh 파일 속 "readlink" 명령어를 "readlink -f" 라는 옵션명을 덧붙이면 해결이 된다. 본인의 경우 "프로젝트 디렉토리/Pods/Target Support Files/Pods-프로젝트명" 위치에 "Pods-프로젝트명-frameworks.sh" 이름으로 파일이 있었다.

 

readlink 명령어에 대해 궁금해져서 찾아보았더니 유닉스 명령어로, 심볼릭 링크의 값을 출력하는 명령어이다. 7가지 옵션이 있는 것으로 나오는데, 각 옵션과 역할은 다음과 같다.

  • -f, --canonicalize : 심볼릭 링크의 원본 위치를 출력한다.
  • -n, --no-newline : 새로운 라인은 출력하지 않는다.
  • -q, --quiet, : 메시지를 출력하지 않는다.
  • -s, --silent : 대부분 에러 메시지를 출력하지 않는다.
  • -v, --verbose : 상세한 정보를 출력한다.
  • --help : 사용법을 출력한다.
  • --version : 버전 정보를 출력한다.

-f 명령어, 즉 심볼릭 링크의 원본 위치 참조를 통해 해결된 것을 보니 xcode 14.3 업데이트 항목에 cocoapods와의 연동과정에 필요한 경로 변경이 일어나 발생한 오류로 추정이 된다.

 

혹시나 해서 -f 명령어를 지우고 cocoapods를 업데이트해보았는데도 동일한 오류가 발생한 것을 보니 아직 cocoapods 측의 업데이트 대응이 진행 중인 것으로 보인다.

https://www.youtube.com/watch?v=nqNLrpMQrU8 

Lazy Sequences in Swift Explained (Performance Tips) – iOS

유튜브 채널 iOS Academy에서 발견한 영상. lazy sequence에 관련된 영상이다. 재밌게 시청해서 가져왔다. 

 

lazy

우선 lazy 키워드에 대한 간략한 설명을 하자면 말 그대로 lazy하게 변수를 할당하는 키워드이다. 대다수의 언어가 그렇겠지만 swift에서 변수, 상수의 경우 우선적으로 초기화가 이루어져야지만 컴파일이 완료된다. 하지만 lazy의 경우, 해당 변수의 초기화가 완료되었다고 판단하고 컴파일이 우선적으로 이루어진다. 이후 lazy로 생성된 변수에 접근하게 될 경우에 뒤늦게 초기화가 이루어지게 된다. 해당 부분의 경우 cs193p swift강의를 보면서 처음 마주했는데, 사실 당시에는 필요성이 크게 와닿지 않았다. 

 

lazy sequence

앞선 얘기는 lazy stored property에 관련된 이야기였고 이번글은 lazy sequence에 관련된 이야기를 하려 한다. swift에서 collection 타입의 자료들을 다루게 되면 가장 많이 다루게 되는 부분이 고차함수가 아닐까 싶다. rest-api를 사용할 때 반환된 요청을 map() 혹은 filter()와 같은 고차함수들을 통해 파싱을 하게 되는데, 이때 입력되는 자료의 수가 많다면 성능 저하가 일어나기 쉬울 것이다. 해당 자료들을 모두 사용하게 된다면 어쩔 수 없으나 대다수의 경우 해당 자료에서 일부분의 자료만 뽑아내어 사용자에게 보여주는 일이 많다. 여기서 lazy sequence를 통해 어느 정도의 성능개선을 이루어낼 수 있다.

 

0부터 1,000,000이 담긴 배열을 생성, map() 메소드를 통해 원소값들을 가공한 뒤 필요한 자료를 호출한 모습이다. 1,000,001 개의 원소를 탐색, 마지막으로 threeTimesArr에 결과를 저장하는 과정이 더해져 1,000,002번의 자료 접근이 일어나게 된다. 곱셈이라는 단순한 작업이었지만 처리해야 할 자료의 수가 많고 더욱 복잡한 자료의 연산이 일어난다면 성능 저하를 유발하게 된다.

 

이번엔 lazy를 이용한 연산이다. 앞서 말했듯이 lazy는 해당 자료에 접근이 일어날 경우에 초기화가 이루어지게 된다. lazy를 통한 map()메소드는 마찬가지로 자료의 접근이 일어날 때에 필요한 부분에서 연산이 일어나게 되고, 자료를 반환하는 모습을 볼 수 있다. 따라서 arr [50]의 자료접근, threeTimesArr[50]에 자료를 저장하는 과정 총 두 번의 접근을 통해 값을 출력하는 모습을 보여준다. 개발과정에서 이러한 lazy sequence를 통해 성능개선을 이루어낼 수 있지 않을까 싶다.

 

이상 lazy 키워드를 통한 성능개선에 관련된 이야기였으며 아마도 iOS 개발을 하면서 정말 유용하게 사용할 수 있는 미세먼지팁이 되지 않을까 싶다. 혹시나 틀린 정보를 적었다면 성장중인 아기개발자를 위해 따끔한 지적 부탁드립니다.

foreground
사용자와의 상호작용을 처리하기 위해 CPU를 포함한 시스템 자원할당에 높은 우선순위를 가지게 됩니다.
시스템은 이러한 리소스 할당을 위해 백그라운드 상태의 앱을 종료하기도 합니다.

background
사용자 이벤트를 받기 어려운 상태입니다. 
가능한 적은 시스템 자원을 사용해야 하고, 시스템에 의해 종료되기도 합니다.

 

 

Apple Developer Documentation

 

developer.apple.com

The current state of your app determines what it can and can’t do at any time. For example, a foreground app has the user’s attention, so it has priority over system resources, including the CPU. By contrast, a background app must do as little work as possible, and preferably nothing, because it’s offscreen. As your app changes from state to state, you must adjust its behavior accordingly.

 

iOS 앱의 생명주기에 관련된 용어다. iOS는 총 다섯 개의 상태(state)가 존재하며, 생명주기에 따라 상태가 변화한다. 개발자는 앱의 생명주기를 관리하며 각 상태에 따른 적절한 동작들을 정의할 수 있다.

 

애플의 공식 문서에 따르면 foreground 상태의 경우 사용자의 상호작용을 최우선으로 취급해야 하기에, 시스템 자원을 최우선으로 할당받게 된다. 반면 background 상태의 경우 화면에 보이는 상태가 아니기 때문에, 가능한 적은 일을 해야 한다.

 

app-based life-cycle events

Not running

앱이 실행되지 않았거나, 완전히 종료되어 동작하지 않는 상태

Inactive

앱이 실행되면서 foreground 상태에 진입하지만 어떠한 이벤트도 받지 않는 상태. 앱의 상태전환과정에서 잠깐 머무는 단계

Active

앱이 실행 중이며, foreground에 있고, 사용자의 상호작용을 받고 있는 상태

Background

앱이 background에 있으며, 다른 앱으로 전환되거나, 홈버튼을 눌러 나갔을 때의 상태. 일정 시간이 지나면 Suspended 상태로 전환

Suspended

앱이 background상태에서 특별한 작업이 없을 경우 해당단계로 진입. 앱은 메모리상에 올라가 있지만, 아무 일도 하지 않기 때문에 배터리를 사용하지 않는다. iOS의 자원할당에 따라서 이 상태의 앱은 메모리에서 해제될 수 있다.

 

각 단계마다 UIKit은 UIApplicationDelegate 객체를 통해 생명주기 이벤트를 발생시켜 개발자에게 알려주는데, 해당 부분을 통해 개발자는 앱의 생명주기에 따른 앱의 동작을 제어하게 된다.

 

여기까지 iOS13까지의 앱 생명주기에 대한 내용이며, iOS13 이후에는 약간의 변화가 생겼다. iOS13 업데이트부터 아이패드에서 멀티윈도우를 지원하기 시작했고, 하나의 앱 프로세스에서 하나 이상의 UI를 제공할 수 있게 되었다. 따라서 프로세스의 생명주기와 UI화면의 생명주기 부분을 나누어서 관리하기 시작했고, UI화면 관리 부분을 애플 측은 "scene-based life-cycle"로 정의했다.

 

scene-based life-cycle events

해당 부분에 대한 설명을 적으려면 주제를 조금 벗어나게 되므로 다음글에 이어서 적도록 하겠다.

 

참고 블로그

https://icksw.tistory.com/178

https://icksw.tistory.com/137

프로그램 실행을 위한 진입 지점을 가리키는 어노테이션입니다.

 

[iOS] 앱이 시작할 때 main.c 에 있는 UIApplicationMain 함수에 의해서 생성되는 객체는 무엇인가?

Apple Developer Documentation developer.apple.com iOS 개발자라면 가장 근본적으로 알아야 할 App life Cycle에 관련된 질문이다. 질문에 대해 단답식으로 대답하자면 아래와 같이 대답할 수 있다. "UIApplication 객

hyun083.tistory.com

지난 글과 주제가 같은 글이다. 

 

사용자가 iOS앱을 클릭하면, UIKit 프레임 워크 안에 숨겨진 main() 함수가 수행되고, 뒤이어 UIApplicationMain() 함수가 수행되는데, 이때 UIApplicationMain() 함수를 호출하는 어노테이션이 바로 @UIApplicationMain 어노테이션이다. iOS 탬플릿을 생성하면 기본적으로 생성되는 파일 중 "appDelegate.swift"에서 해당 어노테이션이 자동으로 생성되는 것을 볼 수 있다. xcode12 기준으로 해당 어노테이션은 @main으로 변경되었다.

*swiftUI로 프로젝트를 생성한 경우, "OOOOApp.swift" 파일에서 찾아볼 수 있다.

 

 

GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Lang

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhance...

github.com

@main: Type-Based Program Entry Points
A Swift language feature for designating a type as the entry point for beginning program execution. Instead of writing top-level code, users can use the @main attribute on a single type. Libraries and frameworks can then provide custom entry-point behavior through protocols or class inheritance.

 

애플이 작성한 swift-evolution 문서를 확인해 보면 프로그램을 실행하기 위한 진입지점으로 유형을 가리키는 기능이라고 적혀있다. 뒤에 이어지는 내용에는 사용자는 탑 레벨 코드를 적는 것 대신, 유형에 @main 속성을 사용할 수 있다고 한다. 완벽하게 이해되지는 않지만 뒤에 이어지는 글이 큰 힌트를 준다. "프로토콜과 클래스 상속을 통한 진입지점의 커스텀이 가능하다."

 

UIApplicationMain() 함수는 애플리케이션 객체와 애플리케이션 델리이트를 생성하고 이벤트 루프를 설정한다. 이때에 @main 어노테이션이 붙어있는 클래스(AppDelegate)를 인스턴스화하여 전달해 주게 되는 것이고, 이러한 과정에서 해당 클래스의 상속 클래스 이름과 채택한 프로토콜의 이름을 전달하는 것이 @main의 역할이라고 생각하면 될 것 같다.

 

Apple Developer Documentation

 

developer.apple.com

iOS 개발자라면 가장 근본적으로 알아야 할 App life Cycle에 관련된 질문이다. 질문에 대해 단답식으로 대답하자면 아래와 같이 대답할 수 있다.

"UIApplication 객체가 생성됩니다."

사용자가 앱 아이콘을 눌러 앱을 실행하게 되면 대략 사진과 같은 형태의 생명주기를 통해 메모리에 할당되었다가 소멸된다. 여기서 이번 글에 눈여겨볼 부분은 바로 UIApplicationMain() 호출 부분이다. swift이전에 obj-c로 작성되었던 앱은 c언어 기반이었기에 앱이 실행되면 운영체제가 가장 먼저 main.m 파일 안에 main() 함수를 호출하여 앱이 시작되었다고 한다.

 

swift가 c언어 기반은 아니지만 obj-c와 함께 사용되기 위한 언어여서인지, 동일하게 main() 함수를 호출을 해야하는데, 우선 xcode로 생성한 iOS 개발 템플릿에는 main.swift 파일은 보이지 않는다. 이유는 UIKit 프레임워크 안에 main() 함수를 숨겨놓았다고 한다. 따라서 앱이 실행되면 가장 먼저 운영체제가 개발자는 찾아볼 수 없는 main() 함수를 호출하고, main() 함수는 뒤이어 UIApplicationMain() 함수를 호출하여 UIApplication 객체가 생성이 되는 것이다. 그렇다면 UIApplication은 무엇일까?

 

UIApplication

 

Apple Developer Documentation

 

developer.apple.com

The centralized point of control and coordination for apps running in iOS.

문서에 따르면 iOS에서 실행중인 앱의 제어와 조정을 담당하는 중앙지점이라고 적혀있다. 즉 여기서부터 실직적인 앱이라고 부를 수 있고, 해당 객체가 생성되고 나서야 개발자가 작성한 코드대로 이벤트 처리 등 앱의 동작을 제어할 수 있는 것이다.

 

모든 iOS앱은 단 하나의 UIApplication 인스턴스를 가지며, 개발자가 원한다면 UIApplication의 shared 프로퍼티를 통해 객체에 접근할 수 있다고 한다. 사실 무슨 말인지는 정확하게 와닿지 않아서 이 부분에 대해서는 나중에 시간을 들여 더 깊이 알아봐야겠다.

 

참고 문서 및 블로그

https://atelier-chez-moi.tistory.com/29

https://zeddios.tistory.com/538

https://blog.naver.com/soojin_2604/222423840595

App Thining

 

https://help.apple.com/xcode/mac/current/#/devbbdc5ce4f

To see this page, you must enable JavaScript. Pour afficher cette page, vous devez activer JavaScript. Zur Anzeige dieser Seite müssen Sie JavaScript aktivieren. このページを表示するには、JavaScript を有効にする必要があります。

help.apple.com

애플리케이션을 설치할 때, 앱스토어와 운영체제가 디바이스의 환경에 맞게 설치하는 설치 최적화 기술이다.

필요한 만큼의 리소스만 다운로드하기에 적은 디스크 사용량, 빠른 다운로드를 제공한다.

해당 기술에는 slicing(슬라이싱), bitcode(비트 코드), on-demand resource(주문형 리소스)가 있다.

 

slicing

Slicing is the process of creating and delivering variants of the app bundle for different target devices and operating system versions.

슬라이싱은 여러 가지 디바이스와 운영체제를 위한 앱 번들의 variants(변형)을 생성 및 제공하는 과정을 뜻한다. variants(변형)에는 각 디바이스와 운영체제가 필요로 하는 실행 가능한 아키텍처와 리소스가 담겨있다고 한다. 개발자가 앱스토어 커넥트에 풀버전의 앱 빌드를 업로드하게 되면 앱스토어는 자동적으로 variants를 생성하고 전달한다고 한다.

유저가 앱스토어에서 앱을 다운로드하게 되면, 유저의 디바이스와 운영체제 버전에 맞는 variants를 다운로드하게 된다.

 

bitcode

Bitcode is an intermediate representation of a compiled program.

비트코드는 컴파일된 프로그램의 중간 표현이라고 한다. 즉, 기계 코드도 아니고, 프로그래밍 코드도 아닌 그 중간의 형태라고 보면 된다. 개발자는 앱스토어 커넥트에 자신의 앱에 비트 코드를 포함시켜 올릴 수 있으며 그러한 비트 코드는 컴파일되어 앱스토어에 연결된다. 애플은 업로드된 비트 코드를 통해서 개발자의 새로운 버전의 앱 업로드 없이도 앱 바이너리를 최적화할 수 있다고 한다.

*앱 바이너리 : 기계코드가 포함된 파일

 

자세한 부분까지 이해하기 쉽지 않으나, 본인이 보기엔 디바이스의 프로세서 아키텍처의 변경(32bit, 64bit)과 같은 부분에서 비트 코드가 없다면, 개발자가 새로 컴파일하여 새로운 앱을 배포해야했으나, 기계어도, 프로그래밍 언어도 아닌 중간 형태의 비트 코드를 통해서 새로운 아키텍처의 변경에도 자동적으로 최적화가 이루어진다는 얘기 같다. 추가적인 정보는 더 찾아봐야 할 거 같다.

 

on-demand resource

On-demand resources are resources—such as images and sounds—that you can tag with keywords and request in groups, by tag.

주문형 리소스는 이미지, 음원과 같은 앱의 리소스를 키워드로 태그 해놓고, 태그를 통해 그룹으로 요청이 가능한 리소스다.

앱스토어는 사용자에게 현재 필요한 리소스를 관리하고 다운로드하게 한다. 또한 주문형 리소스의 슬라이싱 작업을 통해 variants의 최적화 작업을 진행한다고 한다. 이러한 주문형 리소스는 다음과 같은 이점을 제공한다.

  • 앱의 사이즈가 작아지게 되고, 이를 통해 더 빠른 다운로드를 제공, 사용자가 앱의 최초 실행 경험을 개선하게 된다.
  • 사용자가 앱을 체험하면서 필요하게 되는 주문형 리소스들을 백그라운드에서 다운로드하게 된다.
  • 운영체제가 더 이상 필요로 하지 않는 주문형 리소스들은 제거하게 되고, 이로 인해 저장공간을 절약한다.

대표적인 예시를 들 수 있는 경우가 게임의 추가 리소스 다운이다. 일반적으로 이미지와 음원이 많은 게임 앱의 경우, 최초 실행을 위한 최소한의 리소스를 우선적으로 받고, 게임 실행 후 필요한 부분만 리소스를 추가적으로 다운로드하여 저장공간 절약, 실행을 위한 다운로드 시간 감소 등 대용량 앱 사용에 더욱 쾌적한 환경을 제공할 수 있다.

 

참고 자료 및 블로그

https://zeddios.tistory.com/655

https://jiseok-zip.tistory.com/entry/iOSApp-Thinning#toc-정의%20▾ 

+ Recent posts