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 تصاویر با برچسب‌های خاص (idiom, subtype, scale) را از Asset Catalogs استخراج می‌کند, فقط آنهایی را که با دستگاه هدف مطابقت دارند انتخاب می‌کند و یک بسته منابع جدید می‌سازد. کتابخانه استاندارد Swift نیز تحت برش قرار می‌گیرد — نمادها و روش‌هایی که توسط برنامه خاص استفاده نمی‌شوند از آن حذف می‌شوند (dead code stripping).

در مرحله بسته‌بندی, هر برش در یک بسته توزیع جداگانه قرار می‌گیرد و با ابرداده‌ها مرتبط می‌شود — لیست مدل‌های دستگاهی که این برش برای آنها در نظر گرفته شده است. App Store هنگام دانلود برنامه توسط کاربر, برش مناسب را بر اساس مدل دستگاه, نسخه iOS و نوع اتصال انتخاب می‌کند. اگر تطابق دقیق وجود نداشته باشد, سرور از نزدیکترین برش از نظر مشخصات استفاده می‌کند. Apple همه انواع را در شبکه CDN CloudKit برای تحویل سریع در سراسر جهان ذخیره می‌کند.

Slicing در زمینه App Thinning

Slicing — یکی از سه مکانیزم App Thinning است, اما بیشترین سهم را در کاهش اندازه دانلود دارد. Bitcode مسئول بهینه‌سازی کد ماشین است, On-Demand Resources — برای مدیریت منابع روی دستگاه, و Slicing — برای حذف منابع اضافی در مرحله توزیع. بدون Slicing, دو مکانیزم اول کار می‌کنند, اما کاربران منابعی را برای همه دستگاه‌ها دریافت می‌کنند که اندازه را بسته به تعداد Asset Catalogs 20-40% افزایش می‌دهد.

تفاوت بین 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 مگابایت برای دانلود موبایل), 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 کار نکرده است.