Slicing: шта је то, принцип рада и веза са App Thinning

Шта је Slicing

Slicing — компонента App Thinning-а одговорна за креирање варијанти (кришки) бинарног фајла апликације на страни App Store-а. Када програмер отпреми универзални бинарни фајл (fat binary) који садржи код и ресурсе за све подржане конфигурације, App Store га анализира и генерише неколико кришки: одвојено за iPhone са A17 процесором, одвојено за iPad са M4, одвојено за Apple Watch. Свака кришка садржи само оне фрагменте кода и ресурсе који су неопходни за дату комбинацију архитектуре и резолуције.

Пре iOS 9, програмери су ручно креирали засебне бинарне фајлове за различите уређаје или су испоручивали универзални fat binary који је садржао све одједном. Slicing је у потпуности аутоматизовао овај процес: програмер припрема један пројекат у Xcode-у, отпрема једну архиву у App Store Connect, а Slicing на страни сервера креира оптималан број варијанти. Корисник никада не види процес резања — он добија готов .app оптимизован за свој уређај.

Slicing се примењује не само на код и слике, већ и на Metal шейдере. Apple GPU користи свој скуп инструкција (Metal Shading Language) који се разликује од инструкција PowerVR или ARM Mali. Slicing укључује у кришку само шейдере за GPU породицу циљаног уређаја. Ово је посебно важно за игре са прилагођеним шейдерима — на пример, високо детаљни ефекти пост-обраде се компајлирају само за уређаје са снажним GPU (iPad Pro M4, iPhone 16 Pro Max).

Разлика између Slicing-а и обичне компилације за архитектуру

Компајлер Xcode-а креира fat binary са неколико архитектура (armv7, arm64, arm64e), али не уклања ресурсе — све слике за све резолуције остају унутар .app. Slicing иде даље: анализира Asset Catalogs, Metal шейдере и Swift библиотеке, уклањајући из сваке кришке оно што није потребно за одређену намену. На пример, из кришке за iPhone SE не улази @3x графика, а из кришке за iPad Air — iPhone специфични контролери (ако су издвојени у посебне ресурсе).

Како ради Slicing

Процес Slicing-а почиње након отпремања билда у App Store Connect и састоји се из три фазе: анализа, резање и паковање. У фази анализе, сервер App Store-а разлаже бинарни фајл, извлачи из њега информације о подржаним архитектурама, уређајима, резолуцијама екрана и верзијама iOS-а. App Store користи мапирање свих комерцијалних модела Apple-а на њихове техничке карактеристике — база података уређаја (Device Database) се ажурира са сваким издањем iOS-а.

У фази резања, сервер креира засебне копије бинарног фајла за сваку јединствену комбинацију. За то, App Store извлачи из Asset Catalogs-а слике са одређеним ознакама (idiom, subtype, scale), бира само оне које одговарају циљаном уређају и саставља нови пакет ресурса. Swift стандардна библиотека такође подлеже резању — из ње се уклањају симболи и методе које не користи одређена апликација (dead code stripping).

У фази паковања, свака кришка се смешта у засебан дистрибуциони пакет и повезује се са метаподацима — листом модела уређаја за које је ова кришка намењена. App Store при преузимању апликације од стране корисника бира одговарајућу кришку на основу модела уређаја, верзије iOS-а и типа везе. Ако нема тачног поклапања, сервер користи најближу кришку по карактеристикама. Apple чува све варијанте у CDN мрежи CloudKit за брзу испоруку широм света.

Slicing у контексту App Thinning-а

Slicing — један је од три механизма App Thinning-а, али даје највећи допринос смањењу величине преузимања. Bitcode је одговоран за оптимизацију машинског кода, On-Demand Resources — за управљање ресурсима на уређају, а Slicing — за уклањање вишка ресурса у фази дистрибуције. Без Slicing-а, прва два механизма раде, али корисници добијају ресурсе за све уређаје, што повећава величину за 20-40% у зависности од броја Asset Catalogs-а.

Разлика између Slicing-а и Bitcode-а је у тачки примене: Slicing ради на нивоу ресурса (слике, шейдери, NIB фајлови), Bitcode — на нивоу машинског кода. Slicing дели код по архитектурама (arm64 vs arm64e), Bitcode омогућава Apple-у да прекомпајлира код за нове архитектуре. Bitcode + Slicing заједно дају максималну оптимизацију: Bitcode генерише код за одређену архитектуру, а Slicing уклања сувишне ресурсе за ту архитектуру.

Однос са On-Demand Resources — Slicing и ODR се не преклапају. Slicing одлучује који ресурси ће уопште ући у дистрибуцију на уређај, а ODR управља када ће се ти ресурси учитати и истоварити. Програмер може означити ресурс ODR ознаком, а Slicing ће га укључити у кришку ако одговара уређају. Apple препоручује истовремено коришћење сва три механизма за минималну величину инсталације.

Варијанте Slicing-а за различите уређаје

Slicing креира засебне кришке по неколико димензија: архитектура процесора, величина екрана (резолуција), верзија iOS-а и GPU породица (за Metal). Архитектура одређује скуп инструкција CPU-а: arm64 — основни 64-битни скуп (iPhone 5s — iPhone X), arm64e — проширени скуп са подршком за Pointer Authentication и PAC (iPhone XS и новији, iPad Pro са A12X+). Кришка за arm64e укључује код са инструкцијама за заштиту меморије недоступним на arm64 уређајима.

Резолуција екрана — друга кључна димензија Slicing-а. Apple користи скале @1x (iPhone 3GS), @2x (iPhone 4 — iPhone SE 3), @3x (iPhone 6 Plus и новији) и специфичне за iPad (2x и 3x са додатним метрикама). Slicing укључује у кришку само слике са скалом која одговара циљаном уређају. Уз правилну организацију Asset Catalogs у Xcode-у, ово елиминише потребу за ручним управљањем скуповима ресурса — довољно је додати слику у каталог, наводећи подржане типове уређаја.

GPU породица — трећа димензија, критична за Metal апликације. Apple користи класификацију GPU по генерацијама: Apple GPU family 1 (A7), family 2 (A8), ... family 8 (M4). Metal шейдери се компајлирају за сваку породицу посебно, јер се скуп инструкција Metal Shading Language проширује са сваком генерацијом GPU-а. Slicing укључује у кришку само шейдере за GPU породицу циљаног уређаја, што значајно смањује величину игара и апликација које користе Metal за рендеровање.

Утицај архитектуре на величину кришке

Архитектура CPU-а директно утиче на величину кришке: arm64e код садржи додатне инструкције Pointer Authentication (PAC) и Signed Return Address које повећавају бинарни фајл за 5-10% у поређењу са arm64. Међутим, ово повећање је компензовано чињеницом да Slicing укључује arm64e код само у кришке за уређаје са A12+ процесорима. За iPhone SE (треће генерације) са A15 Bionic, Slicing креира засебну кришку оптимизовану за могућности овог чипа.

Подешавање Slicing-а у Xcode-у

Подешавање Slicing-а у Xcode-у је минимално — главна конфигурација се врши кроз Asset Catalogs и Build Settings. Asset Catalog треба да садржи ресурсе организоване по типовима уређаја (Any, iPhone, iPad, Apple Watch, Apple TV) са тачним навођењем скале и режима приказа. Xcode аутоматски укључује у компилацију само оне ресурсе који одговарају циљаним уређајима наведеним у подешавањима Deployment Target.

Кључно подешавање Slicing-а у Xcode-у — Build Setting App Thinning. Доступне вредности:

• None — Slicing је искључен, апликација се испоручује као universal fat binary
• Automatic — Xcode укључује Slicing са подразумеваним подешавањима
• Manual — програмер бира одређене комбинације за Slicing

Targeted Device Families у General → Deployment Info одређује за које типове уређаја се саставља апликација (iPhone / iPad / Universal). Slicing се ослања на овај параметар при резању — ако апликација подржава само iPhone, кришка за iPad се не креира. Deployment Target (минимална верзија iOS-а) такође утиче на Slicing: за старе верзије iOS-а могу бити потребне armv7 кришке које нису потребне за iOS 13+. Apple препоручује постављање Deployment Target на најновију стабилну верзију iOS-а — ово смањује број кришки и величину бинарног фајла.

Параметри Asset Catalog-а за Slicing

За максималну ефикасност Slicing-а, Asset Catalogs треба да користе специфичне ознаке за сваки ресурс. Xcode пружа у Attributes Inspector-у за слике: Width Class (Any, Compact, Regular), Height Class (Any, Compact, Regular), Gamut (sRGB, Display P3), Memory (Any, Low, High), Graphics (Any, Low, High). Комбинујући ове ознаке, програмер контролише у које кришке ће ући свака слика. На пример, слика за iPad са ознаком Regular Width + Regular Height ући ће само у кришке за iPad у landscape оријентацији.

# Извоз кришке за одређени уређај
xcodebuild -exportArchive \
  -archivePath "App.xcarchive" \
  -exportPath "sliced/" \
  -exportOptionsPlist "export.plist" \
  -thinning "iPhone17,2" # iPhone 16 Pro Max

Xcodebuild са параметром -thinning и идентификатором модела креира кришку само за тај модел. Листа идентификатора може се наћи у Device Database Apple (формат: iPhone17,2 — iPhone 16 Pro Max, iPad14,1 — iPad Pro 11 M4). Овај метод је користан за проверу величине кришке пре слања у App Store Connect. CI/CD може користити ову команду за аутоматску верификацију — ако величина кришке прелази лимит (нпр. 100 MB за мобилно преузимање), pipeline издаје упозорење.

Провера резултата Slicing-а

Након отпремања архиве у App Store Connect, Apple пружа детаљну статистику о величинама кришки. App Store Connect → Activity → изаберите билд → App Thinning — приказује Estimated App Store Size за сваку категорију уређаја: iPhone, iPad, Apple Watch, tvOS. Величине су подељене по верзијама iOS-а и типовима процесора. Ако нека кришка прелази очекивану величину, App Store Connect је означава жутим упозорењем.

Локална провера кроз Xcode Organizer: након архивације, отворите Window → Organizer, изаберите архиву и кликните на App Thinning Profiles. Xcode ће приказати величине за сваку могућу кришку на основу тренутне конфигурације пројекта. Такође је доступна опција Export за креирање IPA-а са одређеним Slicing профилом. Xcode генерише .app-thinning.plist са информацијама о томе који ресурси су ушли у сваку кришку.

За аутоматизацију провере Slicing-а у CI/CD-у користите xcodebuild са -thinning и анализирајте величину креираних .app фајлова. Apple пружа командну алатку app-size (инсталира се кроз Xcode Command Line Tools) која исписује детаљан извештај: величину кода, величину ресурса по категоријама (слике, шейдери, NIB), величину Swift библиотека. Поређење величина кришки пре и после оптимизације Asset Catalogs-а помаже да се идентификују ресурси који не учествују у Slicing-у због неправилне конфигурације.

# Анализа величине кришке
app-size -m "sliced/App.app" \
  --format json

App-size исписује JSON извештај са разбијањем по категоријама ресурса. Ако је Slicing правилно подешен, у одељку „images” биће само један скуп скале (@2x или @3x), а не све варијанте. Грешка у конфигурацији Asset Catalogs-а се манифестује тако што су све скале (@1x, @2x, @3x) присутне у кришки — то значи да Xcode није могао да одреди циљани уређај за ове слике и Slicing није функционисао.