Performance Test trong phát triển di động: nó là gì, các chỉ số và cách thực hiện

Performance Test là gì?

Performance Test là một loại kiểm thử phi chức năng xác định mức độ nhanh và hiệu quả mà ứng dụng thực hiện các tác vụ của mình. Khác với kiểm thử đơn vị hoặc kiểm thử giao diện, Performance Test đo các đặc tính định lượng: thời gian phản hồi, tải CPU, tiêu thụ RAM và sử dụng pin. Theo báo cáo Sauce Labs (2025), 68% nhóm phát triển di động đưa Performance Test vào chu kỳ kiểm thử thường xuyên của họ, và 41% tự động hóa nó trong CI.

Mục tiêu chính của Performance Test là đảm bảo ứng dụng đáp ứng các yêu cầu về hiệu suất được nêu trong tài liệu. Nếu thời gian khởi động màn hình vượt quá 500 mili giây hoặc ứng dụng tiêu thụ hơn 200 MB RAM trên thiết bị trung bình, đó là tín hiệu cần tối ưu hóa. Đường cơ sở hiệu suất được thiết lập ở bản phát hành ổn định đầu tiên và được xem xét lại với mỗi bản cập nhật lớn.

Performance Test được thực hiện trên thiết bị thật, không phải trên trình mô phỏng, vì mô phỏng không cung cấp hình ảnh chính xác về việc sử dụng tài nguyên CPU, GPU và mạng. Theo Apple WWDC (2024), kiểm thử trên trình mô phỏng cho thấy kết quả cao hơn so với thiết bị thật từ 15–30%. Thiết bị thật vẫn là nguồn dữ liệu hiệu suất duy nhất đáng tin cậy.

Tần suất thực hiện Performance Test phụ thuộc vào chu kỳ phát triển. Theo khuyến nghị của Google Android Performance (2024), các phép đo cơ sở nên được chạy trên mỗi pull request và một bộ đầy đủ trước mỗi lần phát hành. Tự động hóa các phép đo này cho phép phát hiện sự suy giảm hiệu suất ở giai đoạn đầu.

Các chỉ số hiệu suất chính

Trong phát triển di động, năm chỉ số chính được xác định bao phủ 90% các kịch bản Performance Test. Thời gian khởi động (cold start và warm start) là chỉ số đầu tiên được kiểm tra ở mỗi lần phát hành. Google Play Console (2024) ghi lại thời gian khởi động theo ngưỡng: cold start không được vượt quá 5 giây, warm start — 1,5 giây. Vượt quá các ngưỡng này ảnh hưởng trực tiếp đến xếp hạng trên cửa hàng ứng dụng.

Thời gian khởi động (Cold Start)

Cold start được đo từ lúc chạm vào biểu tượng cho đến khi khung hình đầu tiên của ứng dụng xuất hiện. iOS sử dụng `dispatch_async` để khởi tạo trễ, giúp giảm thời gian khởi động có thể nhìn thấy. Cold start trên Android bao gồm tạo tiến trình, khởi tạo Application và khởi chạy Activity. Theo Google Performance (2024), cứ mỗi 100 ms trễ cold start làm giảm tỷ lệ chuyển đổi 1,2% trong các ứng dụng thương mại điện tử.

Tần số khung hình (FPS)

FPS (Frames Per Second) là tần số khung hình trong các hoạt ảnh và cuộn danh sách. Giao diện mượt mà yêu cầu 60 FPS ổn định. Android Studio Profiler và Xcode GPU Report cho thấy sự sụt giảm FPS khi thực hiện các thao tác nặng — tải hình ảnh, phân tích JSON hoặc kết xuất bố cục phức tạp. Sụt dưới 30 FPS được người dùng cảm nhận như giật lag và dẫn đến giảm tỷ lệ giữ chân 22% theo Adjust (2025).

Tiêu thụ RAM

Tiêu thụ RAM là chỉ số quan trọng thứ ba. Rò rỉ bộ nhớ là nguyên nhân chính gây suy giảm hiệu suất trong các phiên lâu dài. Instruments Allocations và Android Memory Profiler giúp phát hiện các tham chiếu vòng trong Swift và Activity không được giải phóng trong Android. Mức tiêu thụ pin là một chỉ số thường bị bỏ qua trong quá trình kiểm thử. Theo Apple Developer (2024), các ứng dụng có mức tiêu thụ năng lượng cao sẽ bị hạn chế ở chế độ nền trên iOS. Energy Log trong Xcode ghi lại hồ sơ công suất của ứng dụng theo từng phiên.

Các loại kiểm thử hiệu suất

Kiểm thử tải (Load Test) kiểm tra hành vi của ứng dụng dưới số lượng người dùng đồng thời dự kiến. Đối với backend di động, điều này có nghĩa là mô phỏng 1000–10000 yêu cầu API đồng thời. Phía máy chủ phải xử lý tải cao điểm mà không tăng thời gian phản hồi quá 20% so với giá trị cơ sở. Theo điểm chuẩn k6 (2024), một cấu hình Load Test điển hình bao gồm đường tăng dần từ 0 đến 1000 VUs (người dùng ảo) trong 5 phút.

Kiểm thử ứng suất (Stress Test) xác định điểm dừng hoạt động của ứng dụng — thời điểm hệ thống ngừng phản hồi các yêu cầu hoặc suy giảm không thể chấp nhận. Khác với Load Test, Stress Test gây quá tải cho hệ thống vượt quá giới hạn bình thường. Điểm dừng hoạt động được ghi lại dựa trên một trong các tiêu chí: thời gian phản hồi vượt quá 10 giây, tỷ lệ lỗi 5XX vượt quá 5%, hoặc mức tiêu thụ RAM đạt 90% bộ nhớ khả dụng.

Kiểm thử khối lượng (Volume Test) đánh giá hành vi của ứng dụng khi làm việc với khối lượng dữ liệu lớn. Trong bối cảnh di động, điều này bao gồm kiểm thử với hàng nghìn bản ghi trong cơ sở dữ liệu cục bộ, hàng chục gigabyte bộ nhớ đệm, hoặc hàng triệu thông báo push. SQLite trên Android và Core Data trên iOS thể hiện hiệu suất khác nhau khi vượt quá 100.000 bản ghi.

Công cụ cho Performance Test

Xcode Instruments

Xcode Instruments là công cụ chính để phân tích hiệu suất ứng dụng iOS. Time Profiler cho thấy phương thức nào tiêu thụ nhiều CPU nhất, trong khi Allocations theo dõi việc cấp phát và giải phóng bộ nhớ. Instruments hỗ trợ ghi âm trong các phiên dài (lên đến 30 phút) và xuất dấu vết để so sánh giữa các bản dựng. Activity Monitor trong Instruments hiển thị tải hệ thống tổng thể theo thời gian thực.

Android Studio Profiler

Android Studio Profiler là công cụ phân tích tích hợp sẵn cho Android. Nó kết hợp các công cụ phân tích CPU, Bộ nhớ, Mạng và Năng lượng thành một giao diện duy nhất. Một tính năng của Android Profiler là hỗ trợ các phiên tương tác: nhà phát triển có thể thực hiện các hành động trong ứng dụng và thấy phản hồi tức thời của các chỉ số. Theo Google I/O (2024), Profiler hỗ trợ ghi âm ở định dạng .perf, có thể so sánh với đường cơ sở trong CI.

Charles Proxy

Charles Proxy và Proxyman là các công cụ phân tích lưu lượng mạng. Chúng hiển thị thời gian của mỗi yêu cầu HTTP, kích thước phản hồi và tiêu đề. Đối với Performance Test, điều quan trọng là thu thập các yêu cầu mất hơn 500 ms — đây là các ứng cử viên cho việc lưu vào bộ nhớ đệm hoặc tối ưu hóa. Charles hỗ trợ chế độ throttle mô phỏng mạng chậm: 3G, Edge và LTE. Proxyman là một thay thế nhẹ hơn cho macOS với kiến trúc Swift gốc.

import XCTest

class PerformanceTests: XCTestCase {

    func testLaunchPerformance() {
        measure(metrics: [XCTClockMetric(),
                         XCTMemoryMetric()]) {
            XCUIApplication().launch()
        }
    }

    func testScrollPerformance() {
        let app = XCUIApplication()
        app.launch()
        let tableView = app.tables["list"]
        measure {
            tableView.swipeUp()
            tableView.swipeDown()
        }
    }
}

Performance Test trong đường ống CI/CD

Tích hợp Performance Test vào CI/CD là tiêu chuẩn công nghiệp cho giai đoạn 2025–2026. Đường ống hiệu suất bao gồm ba giai đoạn: pre-commit (đo nhanh trên pull request), nightly (bộ kiểm thử đầy đủ) và pre-release (so sánh với đường cơ sở trên các thiết bị tham chiếu). Bitrise và GitHub Actions hỗ trợ chạy Xcode Instruments CLI và Gradle Profiler.

GitHub Actions (2024) đã công bố một mẫu chính thức cho Performance Test iOS sử dụng `xcodebuild test-without-building`. Mẫu này chạy kiểm thử trên một trong các máy của GitHub và công bố báo cáo dưới dạng artifact. Đường cơ sở được lưu trữ trong tệp JSON trong kho lưu trữ: nếu ngưỡng bị vượt quá 10%, đường ống sẽ thất bại với lỗi. Cách tiếp cận này ngăn chặn sự suy giảm hiệu suất mà không cần xem xét thủ công từng bản dựng.

Vấn đề của Performance Test di động trong CI là kết quả không ổn định trên các máy khác nhau. Apple Silicon (M1–M4) và Intel Xeon cho thời gian thực thi khác nhau. Giải pháp là sử dụng tỷ lệ phần trăm so với đường cơ sở thay vì các giá trị tuyệt đối. Nếu một kiểm thử mất nhiều hơn 15% so với đường cơ sở, bản dựng đó sẽ được đánh dấu là cần xem xét.

Viết Performance Test trên iOS và Android

XCTest Performance trên iOS sử dụng phương thức `measure(metrics:)`, phương thức này chạy một khối mã 10 lần và trả về thống kê: trung bình, trung vị, độ lệch chuẩn. Đối với kiểm thử hiệu suất cơ sở dữ liệu, XCTest sử dụng thuận tiện XCTMemoryMetric, công cụ này thu thập mức tiêu thụ RAM cao nhất. Ngưỡng được thiết lập thông qua `XCTPerformanceReport` sau khi kiểm thử hoàn tất.

Android Macrobenchmark là một thư viện của Google để đo hiệu suất ở cấp độ ứng dụng. Macrobenchmark chạy các kịch bản người dùng (khởi động Activity, cuộn RecyclerView, mở WebView) và đo thời gian thực thi. Baseline Profile là một tập hợp các lớp và phương thức mà trình biên dịch Android tối ưu hóa trước. Google Play sử dụng Baseline Profile để tăng tốc lần khởi động đầu tiên lên 30%.

@RunWith(AndroidJUnit4::class)
class StartupBenchmark {
    @get:Rule
    val benchmarkRule = MacrobenchmarkRule()

    @Test
    fun startup() {
        benchmarkRule.measureRepeated(
            packageName = "com.example.app",
            metrics = listOf(StartupTimingMetric()),
            iterations = 5
        ) {
            pressHome()
            startActivityAndWait()
        }
    }
}

Cả hai cách tiếp cận — XCTest Performance và Android Macrobenchmark — đều sử dụng cùng một khái niệm: đo lặp đi lặp lại với tính trung bình và so sánh với ngưỡng. Hiệu suất không thể được rút gọn thành một con số duy nhất. Mỗi lần phát hành phải đi kèm với một báo cáo hiệu suất chứa xu hướng của các chỉ số trong 5 bản dựng gần nhất. Một báo cáo như vậy cho phép nhóm nhìn thấy sự suy giảm trước khi người dùng nhận thấy.