Xây dựng và xuất bản trong phát triển di động: nó là gì, các định dạng và cách hoạt động

Định dạng xây dựng: APK, AAB, IPA

APK vs AAB

APK (Android Package Kit) — định dạng truyền thống để xây dựng và xuất bản ứng dụng di động trên Android. APK chứa toàn bộ mã, tài nguyên và tệp kê khai của ứng dụng. AAB (Android App Bundle) — định dạng được Google giới thiệu vào năm 2018 và trở thành bắt buộc cho các ứng dụng mới kể từ tháng 8 năm 2021. AAB không được cài đặt trực tiếp — Google Play tạo APK được tối ưu hóa cho từng thiết bị từ AAB một cách động.

Lợi ích của AAB: kích thước tải xuống trung bình nhỏ hơn 15% (bằng cách chỉ cung cấp các tài nguyên cần thiết: mật độ màn hình phù hợp, ngôn ngữ, kiến trúc CPU). AAB cũng hỗ trợ phân phối mô-đun — bạn có thể tải mô-đun theo yêu cầu (Play Feature Delivery) hoặc trì hoãn (Play On-Demand). Đối với nhà phát triển, AAB là bắt buộc; để phân phối bên ngoài Google Play (tải sideload, chợ ứng dụng) — chỉ APK.

IPA

IPA (iOS App Store Package) — tệp cài đặt iOS, là một kho lưu trữ ZIP chứa ứng dụng đã được ký. IPA chứa thư mục Payload/ với gói .app, Provisioning Profile và chữ ký. IPA chỉ được xây dựng trên macOS thông qua Xcode, tạo một kho lưu trữ (.xcarchive) và xuất IPA. Để phân phối qua App Store, IPA được ký bằng Apple Distribution Certificate; cho Ad Hoc hoặc Enterprise — bằng các chứng chỉ tương ứng.

Biên dịch và tối ưu hóa: JIT, AOT, ART, Bitcode

JIT vs AOT

JIT (Just-In-Time) — biên dịch mã trong quá trình thực thi ứng dụng, ảnh hưởng đến tốc độ xây dựng và xuất bản. Trên Android đến phiên bản 5.0 (Lollipop), Dalvik VM với biên dịch JIT đã được sử dụng. Mỗi khi khởi động ứng dụng, bytecode DEX được chuyển đổi thành mã máy «ngay lập tức». Nhược điểm: chậm khi khởi động lần đầu và tiêu thụ thêm năng lượng. AOT (Ahead-Of-Time) — biên dịch mã trước khi khởi động ứng dụng, trong quá trình cài đặt. Bắt đầu từ Android 7.0 (Nougat), ART (Android Runtime) biên dịch hoàn toàn ứng dụng trong quá trình cài đặt.

ART (Android Runtime) — môi trường thực thi đã thay thế Dalvik trong Android 5.0. ART sử dụng phương pháp kết hợp: biên dịch AOT khi cài đặt + JIT cho các phương thức được thực thi thường xuyên. Điều này kết hợp tốc độ của AOT (khởi động nhanh) với tính linh hoạt của JIT (tối ưu hóa thích ứng). Kết quả: hiệu suất ứng dụng Android tăng 20-30% so với Dalvik. Đối với nhà phát triển, việc chuyển đổi sang ART là minh bạch — mã không yêu cầu thay đổi.

Bitcode và App Thinning

Bitcode — biểu diễn trung gian của mã (IR) mà Apple sử dụng để biên dịch lại IPA cho các kiến trúc bộ xử lý khác nhau. Bitcode là tùy chọn: đối với ứng dụng iOS, nó được bật theo mặc định; đối với watchOS và tvOS, nó là bắt buộc. Apple có thể biên dịch lại Bitcode khi bộ xử lý mới được phát hành mà không cần sự tham gia của nhà phát triển. App Thinning — công nghệ của Apple bao gồm Slicing (chỉ cung cấp tài nguyên cần thiết cho thiết bị) và On-Demand Resources (tải tài nguyên theo yêu cầu). App Thinning giảm kích thước tải xuống từ App Store xuống 30-50%.

DEX — định dạng bytecode cho Android, được thực thi bởi ART/Dalvik. Mã nguồn Kotlin/Java được biên dịch thành tệp class, sau đó thành DEX thông qua dx hoặc d8 (công cụ hiện đại và nhanh hơn). Multidex — cơ chế cho các ứng dụng vượt quá giới hạn 65.536 phương thức trong một tệp DEX duy nhất. Trong các dự án hiện đại, multidex được bật tự động nếu targetSdkVersion >= 21.

Ký mã: Code Signing, Keystore, Provisioning Profile

Android: Keystore

Keystore — tệp chứa khóa riêng tư và chứng chỉ để ký ứng dụng Android trong quá trình xây dựng. Keystore được tạo thông qua keytool (lệnh -genkey) hoặc Android Studio. Quan trọng: không được làm mất Keystore — nếu không có nó, bạn sẽ không thể cập nhật ứng dụng trên Google Play. Tham số ký: keyAlias, keyPassword, storePassword và storeFile. Định dạng: JKS (Java KeyStore) hoặc PEPK (Play Encrypted Private Key) cho AAB.

App Bundle ID (Android) — định danh duy nhất của ứng dụng theo ký hiệu gói (com.example.app). Version Code — số nguyên để đánh số phiên bản nội bộ (mỗi bản build mới tăng nó lên). Version Name — chuỗi hiển thị cho người dùng (1.2.3). Các tham số này được đặt trong build.gradle ở cấp ứng dụng.

iOS: Apple Certificate và Provisioning Profile

Apple Certificate — chứng chỉ số xác minh danh tính của nhà phát triển. Các loại: Development (để gỡ lỗi), Distribution (cho App Store), Ad Hoc (để phân phối hạn chế). Chứng chỉ được tạo trong Apple Developer Account và tải xuống Keychain. Provisioning Profile — tệp liên kết chứng chỉ, App ID (Bundle Identifier) và danh sách các thiết bị được phép. Không có Provisioning Profile, ứng dụng sẽ không chạy trên thiết bị.

Bundle ID (iOS) — định danh duy nhất của ứng dụng (com.example.app). Build Number — số bản build, tăng lên sau mỗi bản build. Marketing Version — phiên bản hiển thị cho người dùng. Quản lý phiên bản: đối với iOS, các tham số được đặt trong Info.plist và Project Settings; đối với Android — trong build.gradle. Tại IT Sectr, chúng tôi tự động hóa việc cập nhật phiên bản thông qua Fastlane — điều này loại bỏ lỗi con người khi phát hành.

Quy trình xuất bản lên cửa hàng

Google Play Console

Google Play Console — công cụ xuất bản ứng dụng Android. Quy trình: đăng ký tài khoản nhà phát triển ($25 một lần), tạo ứng dụng, điền siêu dữ liệu (tên, mô tả, ảnh chụp màn hình, danh mục), tải lên AAB, cấu hình giá cả và phân phối, đánh giá. Google kiểm tra ứng dụng tự động (vi-rút, tuân thủ chính sách) và thủ công cho một số danh mục. Việc đánh giá mất từ vài giờ đến 2-3 ngày.

App Store Connect

App Store Connect — nền tảng của Apple để xuất bản ứng dụng iOS. Quy trình: tài khoản nhà phát triển Apple ($99/năm), tạo ứng dụng trong App Store Connect, chuẩn bị IPA trong Xcode (Archive → Distribute App → App Store Connect), tải lên qua Transporter hoặc Xcode, điền siêu dữ liệu, gửi đi đánh giá. App Review — đánh giá thủ công của Apple có thể mất từ 24 giờ đến 7 ngày. Các lý do từ chối điển hình: nút không hoạt động, nội dung không đầy đủ, yêu cầu quyền mà không giải thích.

Thử nghiệm beta: TestFlight, Closed/Open Beta

TestFlight (iOS)

TestFlight — công cụ chính thức của Apple để thử nghiệm beta ứng dụng iOS. TestFlight hỗ trợ Internal Testing (tối đa 100 người thử qua email, không cần đánh giá) và External Testing (tối đa 10.000 người thử, cần đánh giá của Apple). Các bản build có sẵn trong 90 ngày, sau đó cần tải lên bản build mới. TestFlight tự động cập nhật ứng dụng cho người thử khi tải lên bản build mới.

Internal / Closed / Open Beta (Android)

Internal Testing (Android) — tối đa 100 người thử, không cần đánh giá của Google, bản build có sẵn ngay lập tức. Closed Beta — tối đa 1000 người thử qua email hoặc Google Groups, không cần đánh giá. Open Beta — số lượng người thử không giới hạn qua liên kết công khai, cần đánh giá của Google. Staged Rollout — tăng dần tỷ lệ người dùng nhận được bản cập nhật (5% → 20% → 50% → 100%). Đây là phương pháp phát hành an toàn nhất.

App Thinning (iOS) — tự động giảm kích thước IPA tải xuống: Slicing (chỉ tài nguyên cần thiết cho thiết bị), Bitcode (tối ưu hóa bộ xử lý), On-Demand Resources (tải xuống theo yêu cầu). Tại IT Sectr, chúng tôi sử dụng TestFlight cho thử nghiệm beta iOS và Internal Testing cho Android — điều này giúp phát hiện vấn đề trước khi phát hành đại trà.