App Size Optimization trong phát triển di động: nguyên lý cơ bản, phương pháp và thực tiễn

App Size Optimization là gì

App Size Optimization là một lĩnh vực trong phát triển di động nhằm giảm thiểu kích thước gói cài đặt ứng dụng. Nó bao gồm loại bỏ mã nguồn và tài nguyên chết, nén hình ảnh, tối ưu hóa thư viện, phân chia bản dựng cho các kiến trúc khác nhau và sử dụng công nghệ phân phối theo yêu cầu.

Kích thước ứng dụng ảnh hưởng không đồng đều đến các phân khúc người dùng khác nhau. Ở các khu vực có cơ sở hạ tầng di động phát triển (Mỹ, Châu Âu, Nhật Bản), sự khác biệt giữa 50 và 100 MB có thể không đáng kể. Ở các khu vực đang phát triển (Ấn Độ, Indonesia, Brazil), mỗi megabyte thừa đều làm giảm tỷ lệ chuyển đổi cài đặt do giới hạn gói dữ liệu và tốc độ internet di động. Google Play giới hạn kích thước APK ở mức 200 MB, nhưng khuyến nghị giữ dưới 100 MB.

Đối với iOS App Store, kích thước tải xuống tối đa qua mạng di động là 200 MB (trước năm 2023 là 150 MB). Nếu IPA vượt quá giới hạn này, người dùng chỉ có thể cài đặt ứng dụng qua Wi-Fi. Apple cũng hỗ trợ App Thinning, bao gồm Slicing, Bitcode và On-Demand Resources — các công nghệ tự động giảm kích thước cài đặt trên một thiết bị cụ thể mà không cần sự can thiệp của nhà phát triển.

Tại sao kích thước ứng dụng quan trọng

Kích thước ứng dụng không chỉ ảnh hưởng đến tỷ lệ chuyển đổi cài đặt mà còn ảnh hưởng đến tỷ lệ giữ chân người dùng, tần suất cập nhật và tốc độ khởi chạy đầu tiên. Mỗi megabyte thừa là một rào cản giữa người dùng và việc sử dụng sản phẩm của bạn.

Ảnh hưởng đến tỷ lệ chuyển đổi cài đặt

Theo dữ liệu từ Google I/O 2024, giảm APK 10 MB làm tăng tỷ lệ chuyển đổi cài đặt trung bình 3,5%. Đối với các ứng dụng có kích thước 150+ MB, tỷ lệ chuyển đổi có thể thấp hơn 20–30% so với các ứng dụng cùng loại có kích thước 50 MB. Hiệu ứng này đặc biệt rõ rệt trên Google Play, nơi người dùng nhìn thấy kích thước trước khi cài đặt. Trên App Store, kích thước được hiển thị trên trang ứng dụng và người dùng có gói dữ liệu hạn chế trì hoãn cài đặt sang Wi-Fi, sau đó thường quên mất ứng dụng.

Tần suất cập nhật và cập nhật OTA

Các ứng dụng lớn ít được cập nhật OTA hơn — người dùng trì hoãn tải xuống bản vá sang Wi-Fi, bỏ lỡ các bản sửa lỗi bảo mật quan trọng. Google Play cho phép Incremental Updates (bản vá lên tới 10 MB), nhưng việc cài đặt lại hoàn toàn vẫn tải xuống toàn bộ APK hoặc AAB. Apple App Store sử dụng Delta Updates, chỉ truyền các tệp đã thay đổi, nhưng ngay cả delta cũng có thể đáng kể khi tài nguyên thay đổi.

Khởi chạy đầu tiên và giải nén

Kích thước ảnh hưởng trực tiếp đến thời gian khởi chạy đầu tiên: ứng dụng phải giải nén tài nguyên, biên dịch mã nguồn (Android) hoặc ký bộ nhớ đệm (iOS). Một ứng dụng 200 MB có thể khởi chạy chậm hơn 10–15 giây so với ứng dụng 50 MB trên một thiết bị trung bình. Điều này làm xấu đi Trải nghiệm khởi tạo — người dùng có thể đóng ứng dụng mà không chờ nó tải xong.

Tối ưu hóa tài nguyên và tài sản

Tài nguyên — hình ảnh, phông chữ, âm thanh, video — chiếm 60–80% kích thước của một ứng dụng di động điển hình. Tối ưu hóa tài nguyên mang lại lợi ích lớn nhất với công sức tối thiểu. Các hướng chính là: nén, loại bỏ trùng lặp và tài sản không dùng, chọn định dạng phù hợp.

Tối ưu hóa hình ảnh

WebP — định dạng hình ảnh từ Google cung cấp khả năng nén tốt hơn 25–35% so với PNG và 15–20% tốt hơn so với JPEG ở cùng chất lượng hình ảnh. Android hỗ trợ WebP gốc từ API 18. Đối với iOS, WebP được hỗ trợ qua thư viện SDWebImage hoặc Kingfisher, và từ iOS 17 đã có hỗ trợ gốc. AVIF — định dạng hiện đại hơn giúp tiết kiệm thêm 10–15% so với WebP, nhưng giải mã chậm hơn.

Loại bỏ tài nguyên không dùng — cách đơn giản nhất để giảm kích thước. Trên Android, sử dụng tính năng tái cấu trúc với Android Studio: Analyze → Run Inspection → Unused Resources. Trên iOS — Build Settings → Remove Unused Resources. Thường thì trong dự án còn sót lại sprite từ các phiên bản trước, biểu tượng cũ, hình ảnh màn hình khởi động không dùng làm phình to kích thước mà không có tải trọng chức năng nào.

Tối ưu hóa phông chữ và âm thanh

Phông chữ tùy chỉnh có thể chiếm 5–15 MB, đặc biệt nếu bao gồm toàn bộ bộ phông chữ (tất cả kiểu: Regular, Bold, Italic, BoldItalic). Chỉ sử dụng các kiểu cần thiết và tập hợp con ký tự thông qua subsetting — loại bỏ glyph cho các ngôn ngữ không được ứng dụng hỗ trợ. Các dịch vụ như Google Fonts và Transfonter cho phép tạo tập hợp ký tự tối thiểu. Đối với âm thanh, sử dụng AAC/HE-AAC thay vì WAV và các định dạng không nén — tiết kiệm đến 90% mà không mất chất lượng.

Tối ưu hóa mã nguồn và thư viện

Mã nguồn chiếm 20–40% kích thước ứng dụng, nhưng việc tối ưu hóa nó phức tạp hơn tài nguyên vì đòi hỏi phân tích phụ thuộc, làm rối và loại bỏ mã chết mà không có rủi ro làm hỏng chức năng.

ProGuard và R8 cho Android

ProGuard là công cụ dành cho Android thực hiện làm rối, thu nhỏ và tối ưu hóa mã nguồn. R8 — người kế nhiệm của nó, được tích hợp trong Android Gradle Plugin, hoạt động nhanh hơn và hiệu quả hơn. R8 loại bỏ các lớp và phương thức không dùng, rút ngắn tên biến và viết lại mã nguồn để giảm số lượng lệnh. Mức giảm kích thước tệp DEX điển hình với R8 là 30–50%.

// build.gradle — cấu hình R8 để thu nhỏ
android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile(
                'proguard-android-optimize.txt')
            shrinkResources true
        }
    }
}

Tối ưu hóa thư viện và phụ thuộc

Thư viện — nguyên nhân phổ biến gây phình to kích thước. Một thư viện có thể kéo theo các phụ thuộc bắc cầu làm tăng kích thước thêm 5–20 MB mà không mang lại lợi ích trực tiếp cho ứng dụng. Sử dụng Gradle Version Catalog cho Android và Swift Package Manager cho iOS với khai báo phụ thuộc rõ ràng. Phân tích kích thước bằng Build Analyzer trong Android Studio hoặc Xcode Build Timeline. Thay thế thư viện nặng bằng các lựa chọn thay thế nhẹ hơn: ví dụ OkHttp (3 MB) thay vì Apache HTTP (15 MB).

Loại bỏ mã không dùng trong iOS

Dead Code Stripping — tự động loại bỏ các phương thức và lớp không dùng ở giai đoạn liên kết trong Xcode. Được bật qua Build Settings → Dead Code Stripping = YES. Bitcode — biểu diễn trung gian mà Apple có thể biên dịch lại cho các kiến trúc khác nhau, loại bỏ các hàm không dùng. Tuy nhiên, từ Xcode 14, Bitcode trở thành tùy chọn và đóng góp của nó vào việc giảm kích thước là 5–15% cho các dự án Objective-C và ít hơn cho Swift.

App Thinning và phân phối theo yêu cầu

App Thinning — công nghệ của Apple tự động giảm kích thước ứng dụng đã cài đặt bằng cách chỉ cung cấp những tài nguyên cần thiết cho một thiết bị cụ thể. Nó bao gồm ba thành phần: Slicing, On-Demand Resources và Bitcode. Trên Android, tương đương là Android App Bundle (AAB) với Dynamic Delivery.

Android App Bundle (AAB)

AAB — định dạng xuất bản trên Google Play nơi cửa hàng tạo APK riêng cho từng thiết bị, chỉ bao gồm tài nguyên cho kiến trúc (armeabi-v7a, arm64-v8a), mật độ màn hình (mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi) và ngôn ngữ của nó. Mức giảm kích thước cài đặt điển hình khi chuyển từ APK phổ thông sang AAB là 20–40%. Play Feature Delivery cho phép tải mô-đun theo yêu cầu, trong khi mô-đun Install-time được bao gồm trong cài đặt cơ bản.

// build.gradle — cấu hình AAB và Dynamic Features
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}

On-Demand Resources trong iOS

On-Demand Resources (ODR) — cơ chế iOS nơi tài nguyên (cấp độ trò chơi, hình ảnh độ phân giải cao, video) được tải xuống từ máy chủ Apple chỉ khi người dùng thực sự cần. Kích thước cài đặt ban đầu có thể giảm 50–80%. Tài nguyên được chia thành ba loại: Initial Install Tags (tải xuống trong khi cài đặt), Prefetched Tag Order (tải xuống nền sau khi cài đặt) và On-Demand (chỉ tải xuống khi có yêu cầu). Apple khuyến nghị sử dụng ODR cho nội dung không cần trên màn hình đầu tiên: cấp độ trò chơi, nội dung bổ sung, hướng dẫn bằng video.

SwiftUI hỗ trợ ODR qua thuộc tính Bundle.module, trong khi UIKit sử dụng NSBundleResourceRequest. Đối với trò chơi trên Unity và Unreal Engine, ODR được tích hợp ở cấp độ wrapper gốc. Hạn chế chính là tài nguyên ODR bị hệ thống xóa khi dung lượng thấp, vì vậy dữ liệu quan trọng phải được bao gồm trong bản dựng chính.