Slicing: ano ito, prinsipyo ng paggana at kaugnayan sa App Thinning

Ano ang Slicing

Slicing — ay isang bahagi ng App Thinning na responsable sa paggawa ng mga variant (slice) ng binary file ng app sa panig ng App Store. Kapag nag-upload ang developer ng universal binary file (fat binary) na naglalaman ng code at resource para sa lahat ng suportadong configuration, sinusuri ito ng App Store at bumubuo ng ilang slice: hiwalay para sa iPhone na may A17 processor, hiwalay para sa iPad na may M4, hiwalay para sa Apple Watch. Ang bawat slice ay naglalaman lamang ng mga fragment ng code at resource na kinakailangan para sa partikular na kombinasyon ng arkitektura at resolusyon.

Bago ang iOS 9, ang mga developer ay manu-manong gumagawa ng hiwalay na binary file para sa iba't ibang device o naghahatid ng universal fat binary na naglalaman ng lahat nang sabay-sabay. Slicing ay ganap na awtomatiko ang prosesong ito: ang developer ay naghahanda ng isang proyekto sa Xcode, nag-upload ng isang archive sa App Store Connect, at ang Slicing sa panig ng server ay lumilikha ng pinakamainam na bilang ng mga variant. Ang user ay hindi kailanman nakikita ang proseso ng paghiwa — siya ay tumatanggap ng handa na .app na na-optimize para sa kanyang device.

Ang Slicing ay inilalapat hindi lamang sa code at mga larawan, kundi pati na rin sa Metal shader. Ang Apple GPU ay gumagamit ng sarili nitong set ng instruction (Metal Shading Language) na naiiba sa mga instruction ng PowerVR o ARM Mali. Ang Slicing ay nagsasama sa slice lamang ng mga shader para sa pamilya ng GPU ng target na device. Ito ay lalong mahalaga para sa mga laro na may custom na shader — halimbawa, ang mga high-detail post-processing effect ay compile lamang para sa mga device na may malakas na GPU (iPad Pro M4, iPhone 16 Pro Max).

Pagkakaiba sa pagitan ng Slicing at ordinaryong compilation para sa arkitektura

Ang Xcode compiler ay lumilikha ng fat binary na may ilang arkitektura (armv7, arm64, arm64e), ngunit hindi tinatanggal ang mga resource — lahat ng larawan para sa lahat ng resolusyon ay nananatili sa loob ng .app. Slicing ay lumalayo pa: sinusuri nito ang Asset Catalogs, Metal shader, at Swift library, tinatanggal mula sa bawat slice ang hindi kailangan para sa isang partikular na layunin. Halimbawa, mula sa slice para sa iPhone SE ay hindi pumapasok ang @3x graphics, at mula sa slice para sa iPad Air — mga controller na partikular sa iPhone (kung hiwalay na nakalaan sa mga resource).

Paano gumagana ang Slicing

Ang proseso ng Slicing ay nagsisimula pagkatapos i-upload ang build sa App Store Connect at binubuo ng tatlong yugto: pagsusuri, paghiwa, at pag-package. Sa yugto ng pagsusuri, ang server ng App Store ay nag-parse ng binary file, kumukuha ng impormasyon tungkol sa mga suportadong arkitektura, device, resolusyon ng screen, at bersyon ng iOS. Ginagamit ng App Store ang pagmamapa ng lahat ng komersyal na modelo ng Apple sa kanilang mga teknikal na detalye — ang database ng device (Device Database) ay ina-update sa bawat paglabas ng iOS.

Sa yugto ng paghiwa, ang server ay lumilikha ng hiwalay na kopya ng binary file para sa bawat natatanging kombinasyon. Para dito, kinukuha ng App Store ang mga larawan na may partikular na tag (idiom, subtype, scale) mula sa Asset Catalogs, pinipili lamang ang mga naaayon sa target na device, at bumubuo ng bagong package ng resource. Ang Swift standard library ay sumasailalim din sa paghiwa — ang mga simbolo at pamamaraan na hindi ginagamit ng partikular na app ay tinatanggal mula dito (dead code stripping).

Sa yugto ng pag-package, ang bawat slice ay inilalagay sa hiwalay na distribution package at iniuugnay sa metadata — listahan ng mga modelo ng device kung saan ang slice na ito ay nilayon. App Store kapag dina-download ng user ang app ay pumipili ng angkop na slice batay sa modelo ng device, bersyon ng iOS, at uri ng koneksyon. Kung walang eksaktong tugma, ginagamit ng server ang pinakamalapit na slice ayon sa mga detalye. Iniimbak ng Apple ang lahat ng variant sa CDN network ng CloudKit para sa mabilis na paghahatid sa buong mundo.

Slicing sa konteksto ng App Thinning

Slicing — ay isa sa tatlong mekanismo ng App Thinning, ngunit nagbibigay ng pinakamalaking kontribusyon sa pagbawas ng laki ng pag-download. Bitcode ay responsable para sa pag-optimize ng machine code, On-Demand Resources — para sa pamamahala ng resource sa device, at Slicing — para sa pag-alis ng labis na resource sa yugto ng pamamahagi. Kung wala ang Slicing, gumagana ang unang dalawang mekanismo, ngunit ang mga user ay tumatanggap ng resource para sa lahat ng device, na nagpapalaki ng laki ng 20-40% depende sa bilang ng Asset Catalogs.

Ang pagkakaiba sa pagitan ng Slicing at Bitcode ay nasa punto ng aplikasyon: Slicing ay gumagana sa antas ng resource (mga larawan, shader, NIB file), Bitcode — sa antas ng machine code. Ang Slicing ay naghahati ng code ayon sa arkitektura (arm64 vs arm64e), pinapayagan ng Bitcode ang Apple na i-recompile ang code para sa mga bagong arkitektura. Bitcode + Slicing na magkasama ay nagbibigay ng pinakamataas na pag-optimize: ang Bitcode ay bumubuo ng code para sa partikular na arkitektura, at ang Slicing ay nag-aalis ng mga hindi kinakailangang resource para sa arkitekturang iyon.

Kaugnayan sa On-Demand Resources — ang Slicing at ODR ay hindi nag-o-overlap. Ang Slicing ay nagpapasya kung aling mga resource ang papasok sa pamamahagi sa device, at ang ODR ay namamahala kung kailan ilo-load at buburahin ang mga resource na ito. Maaaring markahan ng developer ang isang resource ng ODR tag, at isasama ito ng Slicing sa slice kung naaayon ito sa device. Apple ay nagrerekomenda na gamitin ang lahat ng tatlong mekanismo nang sabay-sabay para sa pinakamaliit na laki ng pag-install.

Mga variant ng Slicing para sa iba't ibang device

Ang Slicing ay lumilikha ng hiwalay na slice ayon sa ilang dimensyon: arkitektura ng processor, laki ng screen (resolusyon), bersyon ng iOS, at pamilya ng GPU (para sa Metal). Arkitektura ay tumutukoy sa set ng instruction ng CPU: arm64 — pangunahing 64-bit set (iPhone 5s — iPhone X), arm64e — pinalawak na set na may suporta para sa Pointer Authentication at PAC (iPhone XS at mas bago, iPad Pro na may A12X+). Ang slice para sa arm64e ay naglalaman ng code na may mga instruction sa proteksyon ng memory na hindi available sa mga arm64 device.

Resolusyon ng screen — pangalawang pangunahing dimensyon ng Slicing. Gumagamit ang Apple ng mga scale @1x (iPhone 3GS), @2x (iPhone 4 — iPhone SE 3), @3x (iPhone 6 Plus at mas bago) at partikular sa iPad (2x at 3x na may karagdagang metric). Ang Slicing ay nagsasama sa slice lamang ng mga larawan na may scale na naaayon sa target na device. Sa tamang organisasyon ng Asset Catalogs sa Xcode, inaalis nito ang pangangailangan na manu-manong pamahalaan ang mga set ng resource — sapat na upang idagdag ang larawan sa catalog, na nagsasaad ng mga suportadong uri ng device.

Pamilya ng GPU — pangatlong dimensyon, kritikal para sa mga Metal application. Gumagamit ang Apple ng klasipikasyon ng GPU ayon sa henerasyon: Apple GPU family 1 (A7), family 2 (A8), ... family 8 (M4). Metal shader ay compile para sa bawat pamilya nang hiwalay, dahil ang set ng instruction ng Metal Shading Language ay lumalawak sa bawat henerasyon ng GPU. Ang Slicing ay nagsasama sa slice lamang ng mga shader para sa pamilya ng GPU ng target na device, na makabuluhang nagpapababa ng laki ng mga laro at app na gumagamit ng Metal para sa rendering.

Epekto ng arkitektura sa laki ng slice

Arkitektura ng CPU ay direktang nakakaapekto sa laki ng slice: ang arm64e code ay naglalaman ng karagdagang instruction na Pointer Authentication (PAC) at Signed Return Address na nagpapalaki ng binary file ng 5-10% kumpara sa arm64. Ngunit ang pagtaas na ito ay binabayaran ng katotohanan na ang Slicing ay nagsasama ng arm64e code lamang sa mga slice para sa mga device na may A12+ processor. Para sa iPhone SE (ikatlong henerasyon) na may A15 Bionic, lumilikha ang Slicing ng hiwalay na slice na na-optimize para sa mga kakayahan ng chip na ito.

Pag-configure ng Slicing sa Xcode

Ang pag-configure ng Slicing sa Xcode ay minimal — ang pangunahing configuration ay ginagawa sa pamamagitan ng Asset Catalogs at Build Settings. Asset Catalog ay dapat maglaman ng mga resource na nakaayos ayon sa uri ng device (Any, iPhone, iPad, Apple Watch, Apple TV) na may tamang indikasyon ng scale at mode ng display. Ang Xcode ay awtomatikong nagsasama sa compilation lamang ng mga resource na naaayon sa target na device na tinukoy sa mga setting ng Deployment Target.

Ang pangunahing setting ng Slicing sa Xcode — Build Setting App Thinning. Mga available na value:

• None — Slicing ay naka-disable, ang app ay inihatid bilang universal fat binary
• Automatic — Xcode ay nag-a-activate ng Slicing na may default na setting
• Manual — ang developer ay pumipili ng partikular na kombinasyon para sa Slicing

Targeted Device Families sa General → Deployment Info ay tumutukoy kung para sa anong mga uri ng device ang app ay binuo (iPhone / iPad / Universal). Ang Slicing ay umaasa sa parameter na ito sa paghiwa — kung ang app ay sumusuporta lamang sa iPhone, ang slice para sa iPad ay hindi nilikha. Deployment Target (pinakamababang bersyon ng iOS) ay nakakaapekto rin sa Slicing: para sa mga lumang bersyon ng iOS ay maaaring kailanganin ang armv7 slice na hindi kailangan para sa iOS 13+. Inirerekomenda ng Apple na itakda ang Deployment Target sa pinakabagong stable na bersyon ng iOS — binabawasan nito ang bilang ng mga slice at laki ng binary file.

Mga parameter ng Asset Catalog para sa Slicing

Para sa maximum na kahusayan ng Slicing, ang Asset Catalogs ay dapat gumamit ng mga partikular na tag para sa bawat resource. Xcode ay nagbibigay sa Attributes Inspector para sa mga larawan: Width Class (Any, Compact, Regular), Height Class (Any, Compact, Regular), Gamut (sRGB, Display P3), Memory (Any, Low, High), Graphics (Any, Low, High). Sa pamamagitan ng pagsasama ng mga tag na ito, kinokontrol ng developer kung saang slice papasok ang bawat larawan. Halimbawa, ang larawan para sa iPad na may tag na Regular Width + Regular Height ay papasok lamang sa mga slice para sa iPad sa landscape na oryentasyon.

# I-export ang slice para sa partikular na device
xcodebuild -exportArchive \
  -archivePath "App.xcarchive" \
  -exportPath "sliced/" \
  -exportOptionsPlist "export.plist" \
  -thinning "iPhone17,2" # iPhone 16 Pro Max

Xcodebuild na may parameter na -thinning at identifier ng modelo ay lumilikha ng slice lamang para sa modelong iyon. Ang listahan ng mga identifier ay matatagpuan sa Apple Device Database (format: iPhone17,2 — iPhone 16 Pro Max, iPad14,1 — iPad Pro 11 M4). Ang pamamaraang ito ay kapaki-pakinabang para sa pagsusuri ng laki ng slice bago ipadala sa App Store Connect. CI/CD ay maaaring gamitin ang command na ito para sa awtomatikong pag-verify — kung ang laki ng slice ay lumampas sa limitasyon (halimbawa, 100 MB para sa mobile download), ang pipeline ay naglalabas ng babala.

Pagsusuri ng mga resulta ng Slicing

Pagkatapos i-upload ang archive sa App Store Connect, ang Apple ay nagbibigay ng detalyadong estadistika tungkol sa mga laki ng slice. App Store Connect → Activity → piliin ang build → App Thinning — nagpapakita ng Estimated App Store Size para sa bawat kategorya ng device: iPhone, iPad, Apple Watch, tvOS. Ang mga laki ay nahahati ayon sa bersyon ng iOS at uri ng processor. Kung ang isang slice ay lumampas sa inaasahang laki, minamarkahan ito ng App Store Connect ng dilaw na babala.

Lokal na pagsusuri sa pamamagitan ng Xcode Organizer: pagkatapos ng archival, buksan ang Window → Organizer, piliin ang archive at i-click ang App Thinning Profiles. Ipapakita ng Xcode ang mga laki para sa bawat posibleng slice batay sa kasalukuyang configuration ng proyekto. Available din ang opsyon na Export para sa paggawa ng IPA na may partikular na Slicing profile. Xcode ay bumubuo ng .app-thinning.plist file na may impormasyon tungkol sa kung anong mga resource ang pumasok sa bawat slice.

Para sa automation ng pagsusuri ng Slicing sa CI/CD, gamitin ang xcodebuild na may -thinning at suriin ang laki ng mga nilikhang .app file. Apple ay nagbibigay ng command-line tool na app-size (ini-install sa pamamagitan ng Xcode Command Line Tools) na naglalabas ng detalyadong ulat: laki ng code, laki ng resource ayon sa kategorya (mga larawan, shader, NIB), laki ng Swift library. Ang paghahambing ng mga laki ng slice bago at pagkatapos ng pag-optimize ng Asset Catalogs ay tumutulong na matukoy ang mga resource na hindi kalahok sa Slicing dahil sa maling configuration.

# Pagsusuri ng laki ng slice
app-size -m "sliced/App.app" \
  --format json

App-size ay naglalabas ng JSON report na may breakdown ayon sa kategorya ng resource. Kung ang Slicing ay na-configure nang tama, sa seksyong „images” ay magkakaroon lamang ng isang set ng scale (@2x o @3x), hindi lahat ng variant. Ang error sa configuration ng Asset Catalogs ay nagpapakita sa katotohanan na ang lahat ng scale (@1x, @2x, @3x) ay naroroon sa slice — nangangahulugan ito na hindi matukoy ng Xcode ang target na device para sa mga larawang ito, at hindi gumana ang Slicing.