매년 Apple은 새로운 iPhone을 출시하여 RAM과 메인 메모리의 크기를 점차적으로 늘리고 칩에 전력을 추가합니다. 현재 iPhone 15에서는 이미 "레지던트 이블 4"와 같은 콘솔 게임을 실행할 수 있습니다. 그리고 논리적인 질문이 생길 수도 있습니다. 애플리케이션의 크기를 최적화해야 할까요, 아니면 더 많은 시간을 들이지 않아도 될까요?
요컨대 여전히 크기를 최적화할 가치가 있습니다. 이 기사에서는 그렇게 하는 것이 필수적인 이유를 수집하고 몇 가지 유용한 최적화 방법을 제공했습니다.
이제 "크기가 왜 중요한가?"라는 질문에 대한 가장 진부한 대답부터 시작해 보겠습니다. - 앱스토어의 한계. App Store Connect에서는 지정된 크기 제한을 초과하는 파일을 다운로드하는 것을 허용하지 않습니다.
iOS 및 tvOS 앱의 경우 앱이 지원되는 운영 체제에서 최대 파일 크기를 초과하지 않는지 확인하세요. 압축되지 않은 앱의 총 크기는 4GB 미만이어야 합니다.
Apple Watch 앱은 75MB 미만이어야 합니다. 또한 각 Mach-O 실행 파일(예: app_name.app/app_name)은 이러한 최대 파일 크기를 초과해서는 안 됩니다.
링크
그들이 언급하는 특정 파일은 약간 혼란스러울 수 있습니다. 이를 더 잘 이해하기 위해 App Store Connect에 애플리케이션을 제출하는 과정을 살펴보겠습니다.
첫 번째 단계는 아카이브를 만드는 것입니다. 이 아카이브는 iOS, macOS, watchOS 또는 tvOS 앱에 대한 빌드 아티팩트 및 관련 정보 컬렉션을 저장합니다.
우리는 아카이브에 정확히 무엇이, 어떤 형태로 포함되어 있는지 살펴볼 기회가 있습니다.
주요 파일 중에서 다음을 찾을 수 있습니다.
앱이 포함된 제품 폴더
dSYM("디버깅 기호"의 약어), 디버깅에 필요한 정보가 포함된 Xcode에서 생성된 특수 파일, 즉 충돌 로그입니다.
Info.plist;
그런데 애플리케이션 파일은 "패키지 내용 표시"를 통해 열 수도 있으며, 파일 중에서 코드 서명의 결과인 실행 파일과 CodeResources를 찾을 수 있습니다. 다양한 애플리케이션 리소스(이미지 등)의 디지털 서명을 추적합니다.
Xcode로 돌아가서 아카이브를 생성한 후 Distribute App
버튼을 사용할 수 있습니다. 이 단계에서 .xcarchive는 .ipa 로 변경됩니다.
.ipa 파일은 "페이로드" 폴더를 포함하는 압축 패키지로 생각할 수 있습니다. 이 "Payload" 폴더 안에는 필수 "YourApp.app" 번들이 있습니다. ".app" 번들 내에서 다음과 같은 리소스를 포함하여 애플리케이션의 모든 중요한 구성 요소를 찾을 수 있습니다.
또한 앱의 무결성과 보안을 보장하기 위한 코드 서명 리소스가 포함되어 있습니다.
.ipa 의 내부를 보려면 배포 후 Export
클릭하고 형식을 .ipa 에서 .zip 으로 변환한 후 추출하면 됩니다.
요약하면 .ipa 파일은 최종 사용자가 iOS 장치에 설치하는 패키지 애플리케이션인 반면, .xcarchive 는 애플리케이션에 대한 다양한 자산과 빌드 정보가 포함된 개발자 중심 아카이브입니다.
.ipa 는 배포에 사용되는 반면, .xcarchive는 디버깅, 보관 및 추가 개발 목적으로 사용됩니다. 반면 실행 파일은 앱의 기능을 수행하는 중앙 코드이며 .ipa 패키지 내에 포함되어 있습니다.
따라서 AppStore의 한계는 다음과 같이 설명할 수 있다.
OS 버전 | .ipa 크기 | .ipa -> 페이로드 -> 앱 -> exe 크기 |
---|---|---|
iOS 9.0 이상tvOS 9.0 이상 | 4GB | 500MB |
iOS 7.X~iOS 8.X | 2GB | 60MB |
그러나 최종 애플리케이션의 크기, 즉 특정 사용자가 자신의 기기에 설치해야 하는 바이트 수를 추정하려면 앱 크기 보고서 생성과 같은 추가 작업이 필요합니다. 문서에 만드는 과정이 잘 설명되어 있으니 한 번 남겨보겠습니다.
애플리케이션의 크기를 고려해야 할 다음 이유는… AppStore입니다. 하지만 지금은 시스템 제한이 아니라 다운로드 속도 에 대해 이야기하고 있습니다. 여기에 모든 것이 분명합니다. 크기가 작을수록 비율이 높아집니다.
또한 사용자가 앱을 설치하려면 Wi-Fi 네트워크에 연결해야 하는 200MB의 제한이 있습니다. 지연으로 인해 사용자의 사기가 저하되고 이탈률이 높아질 수 있습니다.
Apple의 App Store 검색 및 검색 알고리즘은 사용자가 다운로드하고 시험해 보기가 더 쉽기 때문에 작은 앱을 선호하는 경우가 많습니다. 앱 크기가 작을수록 검색 결과 및 추천에서 앱의 가시성이 향상될 수 있습니다.
앱이 기기에 설치된 후에도 크기는 여전히 중요합니다. 작은 앱이 더 빠르게 실행되어 더 나은 사용자 경험을 제공합니다. 앱이 저장 공간을 최적화하면 배터리 수명 연장, 앱 설치 공간 감소, 기기 상태 개선에 기여합니다. 결과적으로 더 많은 사람들이 iPhone에 만족할수록 더 많은 잠재 사용자를 갖게 됩니다.
개발 중에 애플리케이션 크기를 불필요하게 늘리는 것을 방지할 수 있는 몇 가지 간단한 팁이 있습니다. 첫 번째는 이미지를 이용한 의식적인 작업입니다.
먼저 JPEG 대신 HEIC를 선택하세요. HEIC는 유사한 이미지 품질을 유지하면서 JPEG에 비해 50% 더 작은 파일을 제공합니다. 이로 인해 장치의 저장 공간이 줄어듭니다. 파일이 작을수록 네트워크를 통해 파일을 전송하기가 더 쉬울 뿐만 아니라 디스크에 더 빠르게 로드하고 저장할 수 있습니다.
HEIC는 이미지 투명성과 깊이 및 차이 정보가 포함된 보충 이미지를 저장하는 기능을 지원합니다. 무손실 압축을 지원하며 단일 컨테이너 내에 여러 이미지를 저장할 수 있습니다.
둘째, PDF와 PNG 대신 SVG (2차원 벡터 그래픽을 표시하는 데 사용되는 XML 기반 벡터 이미지 형식)를 채택해 보세요. 래스터 이미지와 달리 벡터 그래픽은 개별 픽셀을 저장하는 것이 아니라 모양과 곡선을 정의하는 수학 방정식이 특징이므로 일반적으로 파일 크기가 더 작습니다.
처음에는 접두어(각 픽셀 밀도에 대해)가 있는 3개의 이미지를 추가해야 했습니다. 그런 다음 PNG 지원이 추가되었지만(= 주어진 크기의 벡터 이미지) 여전히 “프로젝트를 조합할 때 PDF에서 3개의 PNG를 잘라내는” 수준에서 작동했습니다.
그런 다음에만 SVG를 사용하고 자산 카탈로그에 "벡터 날짜 사용" 확인란을 포함하여 사용되는 이미지의 크기를 실제로 줄이고 품질 저하 없이 무한 확장 가능성을 추가하는 것이 가능해졌습니다.
셋째, 자산 카탈로그 의 기능을 최대한 활용하십시오. 자산 카탈로그는 동일한 이미지의 다양한 해상도를 위한 사용하기 쉬운 저장소를 제공합니다. 또한 카탈로그는 개별 파일 대신 메타데이터를 사용하여 최적화된 단일 형식으로 모든 이미지 자산을 저장합니다.
이를 통해 App Store는 특정 기기에 필요한 자산만 제공할 수 있습니다. 이로 인해 다운로드 속도가 빨라지고 사용자가 기다리는 것을 좋아하지 않는다는 것을 이미 알고 있습니다.
리소스에 "주문형"을 설정할 수 있습니다. 즉, 필요한 경우에만 리소스가 장치에 다운로드되고 일정 시간 사용하지 않으면 제거됩니다.
SF 기호 라는 거대한 "무료" 이미지 카탈로그가 있다는 사실을 잊지 마십시오. Apple은 캐릭터를 늘리기 위해 지속적으로 노력하고 있으며 색상과 애니메이션까지 사용자 정의할 수 있는 기능을 추가하고 있습니다.
따라서 사진과 기타 그래픽 리소스를 사용하면 모든 것이 명확해 보입니다. 올바른 형식을 사용하고 자산을 통해 카탈로그를 추가합니다. 최종 어셈블리에 큰 리소스를 포함하지 않고 필요할 때 인터넷에서 간단히 업로드할 수 있는 기회는 항상 있습니다. 이제 코드와 라이브러리 사용에 대해 이야기해 보겠습니다.
Linking에 대해 빠르게 알려드리겠습니다. 정적 및 동적의 두 가지 유형이 있습니다.
| 공전 | 동적 |
---|---|---|
연결이 발생하는 경우 | 빌드 시간 | 실행 시간 |
종속성이 저장되는 위치 | 최종 실행 파일에서 | 별도의 동적 라이브러리에서 |
종속성을 공유하는 방법 | 앱의 모든 인스턴스에서 동일한 복사본이 사용됩니다. | 앱의 각 인스턴스에는 자체 복사본이 있습니다. |
종속성에 대한 업데이트가 처리되는 방법 | 앱 다시 빌드 | 동적 라이브러리 업데이트 |
이 기사의 주제에 따르면 종속성 저장소는 우리에게 특히 중요하며 동적 연결은 우리가 가장 좋아하는 것 같습니다.
동적 라이브러리는 클라이언트 앱에 정적으로 연결되지 않습니다. 실행 파일의 일부가 되지 않습니다. 대신, 앱이 시작되거나 실행될 때 동적 라이브러리를 앱에 로드(및 연결)할 수 있습니다.
링크
간단히 말해서 정적 라이브러리 대신 동적 라이브러리를 선택하면 앱 파일 크기가 작아지고 초기 메모리 사용량이 줄어듭니다. 그러나 균형을 유지하고 동적 라이브러리를 과도하게 사용하지 않는 것이 여전히 중요합니다. 이렇게 하면 앱 시작 시 성능이 지연될 수 있습니다.
Apple은 또한 앱에서 SPM (모듈식 코드 베이스)을 생성할 것을 권장합니다. 이는 예를 들어 App Clipps와 같은 다른 대상과 코드를 공유할 때 유용할 수 있습니다.
Swift Package Manager는 Swift 프로젝트의 종속성을 관리하는 간소화된 기본 방법을 제공합니다.
앱 크기를 줄이는 가장 효과적인 방법 중 하나는 불필요한 파일을 모두 제거하는 것입니다. 이러한 추가 파일은 예를 들어 Read.me 또는 남은 이미지일 수 있습니다. 실제로 .ipa가 무엇인지 알아낸 기사의 시작 부분에서 AppStore에 들어갈 모든 파일을 찾는 방법을 이미 배웠습니다. .ipa -> .zip -> App -> show package 내용물.
필요하지 않은 리소스를 모두 찾아 앱에서 자유롭게 삭제하세요 .
결론적으로 말하면. 앱 크기를 계속 주시해야 하는 몇 가지 중요한 이유가 있습니다.
앱 크기를 줄이는 몇 가지 방법이 있습니다.
따라서 일상적인 개발 중에 이를 잊지 마십시오. 매일 더 똑똑해지세요 🙃