App Thinning — khái niệm, thành phần và cách hoạt động

App Thinning là gì

App Thinning — là công nghệ tối ưu hóa phân phối ứng dụng iOS toàn diện do Apple giới thiệu cùng với iOS 9 (tháng 9 năm 2015). Mục tiêu của App Thinning là giảm thiểu kích thước ứng dụng mà người dùng tải xuống thiết bị của họ mà không thay đổi mã nguồn và chức năng. Công nghệ hoạt động ở ba cấp độ: ở giai đoạn xây dựng (biên dịch), phía App Store (phân phối) và trên thiết bị (quản lý tài nguyên).

Trước App Thinning, các nhà phát triển đưa vào tệp nhị phân tài nguyên cho tất cả các thiết bị có thể — hình ảnh @2x và @3x, mã 32-bit và 64-bit, shader Metal cho các GPU khác nhau. Điều này dẫn đến kích thước ứng dụng phình to: người dùng iPhone 6 Plus với màn hình Retina HD nhận được tài nguyên vector cho iPad Pro mà không bao giờ được sử dụng. Apple đã giải quyết vấn đề này bằng cách chuyển một phần công việc xây dựng lên máy chủ App Store.

Theo nghiên cứu của Apple (WWDC 2015, Session 412), một ứng dụng thông thường hỗ trợ nhiều kiến trúc và độ phân giải có thể giảm 30-50% sau khi áp dụng App Thinning. Đối với trò chơi có nhiều kết cấu độ phân giải cao, lợi ích có thể đạt 70-80%. Apple tiếp tục cải tiến công nghệ: iOS 17 đã bổ sung tối ưu hóa cho ARM64e và cải thiện On-Demand Resources cho các ứng dụng sử dụng Swift Package Manager.

Vấn đề mà App Thinning giải quyết

Kích thước ứng dụng di động không ngừng tăng lên. Theo Sensor Tower (2025), kích thước trung bình của ứng dụng iOS đã tăng 45% trong 5 năm qua. Đối với người dùng có gói dữ liệu hạn chế hoặc internet chậm, mỗi megabyte đều quan trọng. App Thinning giải quyết vấn đề này mà không cần sự tham gia của nhà phát triển — chỉ cần bật hỗ trợ trong cài đặt dự án và tải bản dựng lên App Store Connect.

Cách App Thinning hoạt động

Quy trình App Thinning bắt đầu sau khi tải kho lưu trữ ứng dụng lên App Store Connect. App Store phân tích tệp nhị phân và chia nó thành các phân đoạn theo kiến trúc (armv7, arm64, arm64e), độ phân giải màn hình (iPhone, iPad) và phiên bản iOS. Mỗi tổ hợp sẽ tạo một biến thể riêng. Khi người dùng nhấp vào “Tải xuống”, App Store xác định kiểu thiết bị, phiên bản iOS và loại kết nối (Wi-Fi / mạng di động) và chỉ gửi biến thể tương ứng.

Đối với người dùng, quy trình này minh bạch — không có tùy chọn “phiên bản nhẹ” hay hộp thoại cài đặt. App Store tự động chọn biến thể phù hợp nhất dựa trên siêu dữ liệu của thiết bị được gửi đến máy chủ khi yêu cầu tải xuống. Nếu thiết bị sử dụng Wi-Fi, App Store có thể gửi biến thể với tài nguyên chất lượng cao hơn (ví dụ: video ProRes cho iPhone 16 Pro). Khi tải xuống qua mạng di động, bộ tối thiểu có thể được sử dụng.

Cấp độ tối ưu hóa thứ hai — Bitcode. Khi tùy chọn ENABLE_BITCODE được bật, Xcode biên dịch ứng dụng không phải bằng mã máy mà bằng biểu diễn LLVM trung gian. App Store biên dịch lại Bitcode cho kiến trúc bộ xử lý của người dùng, cho phép Apple áp dụng các tối ưu hóa trình biên dịch cho các thế hệ chip mới (A17, M4) mà không cần nhà phát triển cập nhật ứng dụng. Bitcode là bắt buộc cho watchOS và tvOS, nhưng tùy chọn cho iOS.

Các thành phần của App Thinning: Slicing, Bitcode, ODR

App Thinning bao gồm ba cơ chế độc lập, mỗi cơ chế chịu trách nhiệm cho một khía cạnh tối ưu hóa. Slicing chia tệp nhị phân thành các biến thể theo kiến trúc và độ phân giải màn hình. Nhà phát triển cấu hình Slicing thông qua Asset Catalogs — Xcode tự động chỉ bao gồm trong lát cắt những tài nguyên phù hợp với thiết bị mục tiêu. Ví dụ: iPhone SE (thế hệ thứ ba) sẽ chỉ nhận hình ảnh @2x và mã arm64, trong khi iPad Pro M4 sẽ nhận hình ảnh @3x và mã arm64e.

Bitcode — là LLVM IR (Intermediate Representation) — biểu diễn độc lập với máy của chương trình. Khi Bitcode được bật, Xcode không tạo mã máy cuối cùng mà lưu biểu diễn trung gian. App Store Connect khi tải bản dựng lên sẽ nhận Bitcode và biên dịch lại cho kiến trúc của tất cả các thiết bị được hỗ trợ. Bitcode cho phép Apple áp dụng các tối ưu hóa không có sẵn ở giai đoạn biên dịch của nhà phát triển — ví dụ: sử dụng các lệnh xử lý mới (SME, SVE) trên chip M4.

On-Demand Resources (ODR) — cơ chế thứ ba, cho phép giải phóng tài nguyên ứng dụng sau khi sử dụng. Nhà phát triển đánh dấu tài nguyên (cấp độ trò chơi, hình ảnh onboarding, video) bằng thẻ ODR. iOS tải các tài nguyên được đánh dấu theo yêu cầu ở nền và giải phóng chúng khi thiếu bộ nhớ hoặc sau khi sử dụng. ODR đặc biệt hiệu quả đối với trò chơi có lượng nội dung lớn — các cấp độ đầu có thể được phân phối cùng ứng dụng và các cấp độ còn lại tải dần theo tiến trình.

Khi nào nên chọn từng thành phần

Việc chọn cơ chế App Thinning phụ thuộc vào loại ứng dụng và đối tượng mục tiêu. Slicing được khuyến nghị luôn bật — không yêu cầu hành động bổ sung nào từ nhà phát triển ngoài việc tổ chức Asset Catalogs đúng cách và mang lại mức giảm ổn định 20-30%. Bitcode nên bật nếu ứng dụng sử dụng shader Metal tùy chỉnh hoặc dự định hỗ trợ kiến trúc Apple mới mà không cần biên dịch lại. ODR phù hợp cho các ứng dụng có khối lượng nội dung lớn — trò chơi, trình chỉnh sửa ảnh, ứng dụng phát trực tuyến.

Đối với ứng dụng doanh nghiệp thông thường (nguồn cấp dữ liệu, biểu mẫu, API REST), Slicing và cấu hình ODR tối thiểu cho hình ảnh onboarding là đủ. Trò chơi với đồ họa 3D được hưởng lợi từ cả ba cơ chế: Slicing loại bỏ shader không cần thiết, Bitcode tối ưu hóa kết xuất cho GPU và ODR giải phóng cấp độ đã hoàn thành. Theo Apple (WWDC 2024), sự kết hợp của cả ba cơ chế giảm kích thước cài đặt ban đầu trung bình 45-55% so với tệp nhị phân phổ quát.

Cấu hình App Thinning trong Xcode

Để bật App Thinning trong dự án Xcode, cần thực hiện một số bước. Slicing được cấu hình qua App Thinning trong cài đặt xây dựng: Build Settings → App Thinning. Ba giá trị có sẵn: None (không tối ưu hóa), Automatic (cài đặt tự động mặc định) và Manual với lựa chọn các biến thể cụ thể để kiểm tra. Apple khuyến nghị Automatic cho hầu hết các dự án.

Đối với Asset Catalogs, điều quan trọng là tổ chức tài nguyên đúng cách: hình ảnh được đặt trong danh mục phổ quát với chỉ định chiều rộng/cao và Xcode tự động tạo các biến thể @1x, @2x và @3x. Xcode khi xây dựng chỉ bao gồm các độ phân giải được sử dụng trong dự án. Shader Metal được biên dịch riêng cho từng họ GPU — Apple GPU, PowerVR, Mali — điều này cũng được quản lý qua Asset Catalogs.

Bitcode được bật bằng cờ ENABLE_BITCODE = YES trong Build Settings. Đối với iOS, cờ này là tùy chọn (tắt mặc định từ Xcode 14), nhưng đối với watchOS và tvOS là bắt buộc. Khi bật Bitcode trong dự án sử dụng thư viện bên thứ ba, tất cả chúng cũng phải được biên dịch với Bitcode, nếu không bản dựng sẽ thất bại. Bitcode làm tăng thời gian biên dịch 20-30% nhưng cung cấp khả năng tương thích hoàn toàn với các kiến trúc tương lai.

Kiểm tra kết quả App Thinning

Sau khi tải lên App Store Connect, kích thước lát cắt có thể được kiểm tra trong phần Activity → Build Metric. App Store Connect hiển thị Estimated App Store Size cho các thiết bị khác nhau. Để kiểm tra cục bộ, Xcode cung cấp lệnh xcodebuild với cờ -exportArchive và tùy chọn thinning để tạo lát cắt trên máy cục bộ. Kết quả Slicing có thể được xem trong Organizer (Window → Organizer) sau khi lưu trữ — tab App Thinning Profiles hiển thị kích thước cho các thiết bị khác nhau.

# Kiểm tra cục bộ Slicing
xcodebuild -exportArchive \
  -archivePath "App.xcarchive" \
  -exportPath "export/" \
  -exportOptionsPlist "export.plist" \
  -thinning "<thin-for-all-variants>"

Xcodebuild với cờ -thinning tạo tệp .app cho mỗi tổ hợp kiến trúc, độ rộng bit và GPU. Tham số <thin-for-all-variants> tạo tất cả các biến thể có thể — hữu ích để kiểm tra. Đối với đường ống CI, hãy chỉ định một tổ hợp cụ thể, ví dụ iPhone14,4 (iPhone SE 3). Các tệp .app kết quả có thể được phân tích bằng tiện ích app-size.

Lợi ích và tác động của App Thinning

Lợi ích chính của App Thinning là giảm kích thước tải xuống cho người dùng cuối. Theo Apple (WWDC 2024), một ứng dụng thông thường sử dụng cả ba cơ chế App Thinning tải xuống nhanh hơn trung bình 40% qua mạng di động và chiếm ít hơn 35% dung lượng đĩa. Điều này ảnh hưởng trực tiếp đến tỷ lệ chuyển đổi cài đặt: theo Sensor Tower, cứ mỗi 10 MB kích thước ứng dụng làm giảm tỷ lệ chuyển đổi 1%.

Lợi ích thứ hai — tối ưu hóa cho thiết bị tương lai thông qua Bitcode. Apple có thể biên dịch lại ứng dụng Bitcode cho các kiến trúc mới mà không cần sự tham gia của nhà phát triển. Ví dụ, trong quá trình chuyển đổi từ Intel sang Apple Silicon (M1), các ứng dụng Bitcode hoạt động trên macOS qua Rosetta 2 mà không cần xây dựng bổ sung. Các nhà phát triển không bật Bitcode buộc phải biên dịch lại ứng dụng cho arm64.

Lợi ích thứ ba — ODR (On-Demand Resources) giảm tải lên bộ nhớ thiết bị. Các trò chơi với hàng chục cấp độ, như Asphalt 8: Airborne, sử dụng ODR để tải các đường đua mới theo tiến trình. Nhà phát triển có thể đặt Initial Install Tags cho tài nguyên tải cùng ứng dụng và Prefetch Tags cho nội dung tải nền sau khi cài đặt. Apple kiểm soát giới hạn ODR: tối đa 512 MB mỗi yêu cầu và tối đa 20 GB bộ nhớ đệm tổng trên thiết bị.

Hạn chế của App Thinning

App Thinning có một số hạn chế quan trọng cần xem xét khi thiết kế ứng dụng. Thứ nhất, Slicing không áp dụng cho ứng dụng phân phối qua Enterprise (in-house) hoặc Ad Hoc — các bản dựng này chứa tất cả các biến thể và không qua App Store. Để kiểm tra Slicing, nhà phát triển có thể sử dụng TestFlight, cũng xử lý Slicing trên máy chủ Apple.

Thứ hai, Bitcode làm tăng thời gian xây dựng và kích thước kho lưu trữ .xcarchive khoảng 30-50%. Không phải tất cả thư viện bên thứ ba đều hỗ trợ Bitcode — nếu ít nhất một phụ thuộc được biên dịch mà không có Bitcode, bản dựng dự án với ENABLE_BITCODE sẽ thất bại. Apple khuyến nghị kiểm tra tính tương thích của thư viện trước khi bật Bitcode. Ngoài ra, Bitcode không hỗ trợ Swift Package Manager đầy đủ — một số gói Swift có thể phá vỡ bản dựng Bitcode.

Thứ ba, On-Demand Resources không đảm bảo nội dung khả dụng ngay lập tức — tải ODR diễn ra ở nền và có thể bị trì hoãn nếu thiết bị ở chế độ pin yếu hoặc tín hiệu yếu. Nhà phát triển phải triển khai xử lý trạng thái tải ODR qua NSBundleResourceRequest và hiển thị chỉ báo tiến trình cho người dùng. Lỗi tải ODR không được chặn chức năng của ứng dụng — cần có graceful fallback.