App Thinning
앱이 디바이스에 설치될 때 앱스토어와 운영체제가 디바이스의 특성에 맞게 설치되도록 설치 최적화 기술입니다.
iOS 9에서 도입된 기능으로 앱의 크기를 최적화 하고 사용자 기기에 저장되는 앱의 전체 크기를 줄이는데 사용됩니다.
이에 따른 전반적인 이점으론 아래와 같은데,
빠른 다운로드와 설치
앱의 크기가 작아지면 사용자는 앱을 더 빨리 다운로드 할 수 있습니다.
디바이스 공간 최적화
App THinning을 사용하면 특정 디바이스, 버전에 필요한 리소스만 다운로드 하므로, 불필요한 데이터를 저장하는 것을 방지합니다.
예를 들어, 아이폰 X 와 3rd Generation IPad는 다른 해상도를 사용하기 떄문에 각 디바이스에 적합한 리소스만을 다운로드 할 수 있게 됩니다.
앱에서 3x, 2x리소스만 저장한다던지,
기능(하드웨어)적으로 3D Touch, 카메라, 지문인식등 디바이스가 제공하는 기능의 리소스만을 저장합니다.
App Thinning의 주요 기술은 3가지 입니다.
슬라이싱(slicing), 비트코드(bitcode), 주문형 리소스(On-Demand-resource)
슬라이싱 Slicing
다양한 운영체제와 기기에 대하여 app bundle의 변형(variants)을 생성하고 전달하는 기능입니다.
그림에서 App variant라고 생각하면 되는데, 앱스토어 커넥트에 업로드하게되면 앱스토어는 앱이 지원하는 기기 및 운영체제 버전에 따라 변형(variants)을 생성하고 제공합니다.
그림으로 쉽게 이해해보면
예를 들어 다양한 전체 기기(아이폰, 아이패드...) 에 대응하기위해 아래와 같은 것들이 있다면
아이패드 미니를 위한 App Slicing은 아래와 같을 것이고,
아이폰 6+를 위한 App Slicing은 아래와 같을 것입니다.
이처럼 앱스토어 커넥트는 기기와 운영체제에 맞춰 변형(variants)를 만들고, 앱스토어에서 앱을 다운로드하면 각 기기에 맞는 변형된 앱이 설치됩니다.
해당 기기에 맞는 프레임워크, 라이브러리만을 가져오기 때문에 효율적일 수 있습니다.
iOS 9.0 이상에서 슬라이스된 앱을 지원합니다.
그 이하 버전은 앱스토어에서 universal variants를 제공합니다.
* univarsal variants는 Mobile Device Management(MDM), Apple School Manager, Apple Buisiness Manager를 통해 대량 구매한 앱 혹은 iTunes 12.6이하 버전을 사용하여 다운로드한 앱을 통해서도 제공이 된다고 합니다.
주문형리소스 ODR(On-Demand-Resource)
예를 들어봅시다.
게임을 방금 시작한 경우 레벨 1이겠죠.
근데 만약 레벨 5에 대한 데이터가 필요할까요?
레벨 5에 대한 데이터는 레벨 5가 될 경우 그에 해당하는 데이터를 로드하면 될것입니다.
그런 것 들을 On Demand Resource(ODR)라고 합니다.
그림으로 보자면,
물론 XCode Project에는 level1, 2, 3, 4, 5... 등등의 데이터가 포함되어 있을것입니다.
ODR이 될 경우엔. 그림은 이렇게 바뀌겠죠
각 Level에 대한 데이터는 우선 앱스토어가 소유하고 있다가.
기기가 ODR Resource가 필요하면 앱스토어에서 데이터를 로드하면 됩니다.
ODR의 특징이 있는데요
- ODR은 앱스토어에 *IPA와 별도로 저장됩니다.
- ODR은 앱 번들에 포함되지 않습니다.
- ODR은 iCloud에 저장되지 않습니다.
- 시스템이 관리하는 메모리에 저장되어 여러 앱에서 캐싱될 수 있습니다.
* IPA : 앱의 메인 패키지 파일(".ipa")파일
비트코드
마지막 비트코드입니다. 아직 이해한지, 이해한게 맞는지도 잘 모르겠는데요,,
정리를 해보자면..
비트코드는 컴파일된 프로그램의 중간표현(Intermediate Representation)입니다.
여기서 중간 표현이 뭔지 모르겠지만 일단 한 번 쭉 보시면 아실거에요.
"비트코드가 포함된 앱을 앱스토어 커넥트에 업로드하면, 앱은 앱스토어에서 컴파일 되고 사용자 기기에 설치되게 됩니다."
이 말은 아래의 말과 같은 말입니다.
개발자가 앱스토어에 앱을 업로드 할 때 "중간표현"의 코드로 제출하면 Apple은 이 중간표현 코드를 최종 실행 가능한 바이너리 형식으로 변화시킵니다.
본질적으론 앱이 다운로드 되기 전에 디바이스에 맞게 앱을 최적화하여 바이너리 를 새로 만들어서 제공합니다.
bitcode를 사용하면 최신 컴파일러 용으로 자동 앱을 컴파일하게 됩니다.
쉽게 ==> bitcode가 없던 시절에는 앱이 실행될 수 있는 모든 환경(32bit, 64bit, arm6, arm7, arm64...) 등등 모든 환경에 대한 바이너리를 생성하여 하나의 파일에 합쳐야 했다고 합니다.
만약 32bit 칩셋을 사용하다가, 64bit칩셋으로 변경했다고 할 경우 bitcode가 없다면 개발자가 일일이 수정해야할 부분이 생긴다는 말입니다.
그래서, bitcode를 사용하면 앱의 크기가 왜 더 작아질까요?
위에서 설명한 32bit, 64bit, arm6, arm7, arm64.. 등등 모든 환경에 대응하지 않고 기기에 포함된 아키텍처에만 최적화를 하면 되기 때문입니다.
이외의 아키텍처의 최적화는 제거되므로 앱이 더 가벼워질 수 있습니다.
bitcode를 사용하면 ==> 앱의 최종 컴파일 결과를 AppStore에 등록.
bitcode를 사용하면 ==> 앱스토어가 사용자에 맞게 컴파일해서 다운로드.
가 될 수 있겠죠.
이게 가능한 이유는 *LLVM(Low Level Virtual Machine)에 있습니다.
* LLVM : 기계어로 내 코드를 컴파일 하는데 사용되는 라이브러리입니다.
LLVM에는 Swift, objc와 같은 앱을 만들기 위해 사용되는 "프론트엔드"와 기계어로 컴파일 해주는 "백엔드"가 있습니다.
(프론트엔드) (백엔드)
Swift <-----------bitcode---------->기계어
여기서 bitcode는 Swift 와 기계어 그 사이 어딘가의 중간단계 코드입니다
앱을 bitcode형태로 제출하게 되면
애플이 새로운 cpu에대한 지원, 처리방식을 기계어로 변환해주는 앱스토어의 "백엔드"에 추가하면
수많은 앱들의 개발자가 새로운 CPU에대해 직접 대응하지 않아도 됩니다.
bitcode의 특징은 아래정도가 있습니다.
- iOS앱의 경우 bitcode가 default이며 선택사항입니다.
- 비트코드를 제공하려면 앱 번들의 모든 앱과 프레임워크가 전부 비트코드를 포함해야합니다.
- watchOS, tvOS의 앱들은 비트코드가 필요합니다.