Instruments — là gì, các tính năng của Time Profiler và Allocations

Instruments là gì?

Instruments — là hệ thống hồ sơ hóa và theo dõi, là một phần của Xcode và dựa trên công nghệ DTrace do Sun Microsystems phát triển. Instruments kết hợp hàng chục công cụ hồ sơ (mẫu) trong một giao diện thống nhất: chỉ cần chọn một mẫu, khởi chạy ứng dụng qua Xcode và bắt đầu thu thập dữ liệu.

Kiến trúc của Instruments dựa trên mô hình client-server: một agent trên thiết bị thu thập dữ liệu và truyền đến Mac qua kết nối USB. Điều này giảm thiểu tác động của trình hồ sơ lên hiệu suất ứng dụng — Instruments hoạt động chủ yếu ở phía máy chủ. Theo WWDC 2022, overhead của Time Profiler ở tần số lấy mẫu 1 ms là dưới 3%.

Instruments hỗ trợ mẫu tùy chỉnh — nhà phát triển có thể kết hợp nhiều công cụ trong một phiên hồ sơ. Ví dụ, khởi chạy đồng thời Time Profiler + Allocations + Leaks và xem mối tương quan giữa đỉnh CPU và cấp phát bộ nhớ. Điều này mang lại bức tranh toàn diện về hiệu suất mà không thể có được khi phân tích riêng lẻ từng thành phần.

Những mẫu nào có sẵn mặc định

Xcode đi kèm với 16 mẫu Instruments được cài đặt sẵn: Time Profiler, Allocations, Leaks, Energy Log, Network, Core Animation, Metal System Trace, File Activity, System Trace và các mẫu khác. Mỗi mẫu được tối ưu hóa cho một tác vụ cụ thể và được cấu hình sẵn với các thiết lập trigger và bộ lọc chính xác.

Time Profiler: phân tích hiệu suất CPU

Time Profiler — là mẫu Instruments được sử dụng nhiều nhất. Nó hoạt động dựa trên lấy mẫu ngăn xếp cuộc gọi: cứ mỗi 1-10 mili giây, hệ thống ghi lại ngăn xếp cuộc gọi của tất cả các luồng trong ứng dụng. Sau khi dừng phiên, Instruments tổng hợp các mẫu và hiển thị phương thức và hàm nào đã tiêu tốn nhiều thời gian nhất. Kết quả được trình bày dưới dạng Call Tree — cây cuộc gọi được sắp xếp theo Self Weight.

Số liệu chính của Time Profiler là Self Weight (thời gian dành trực tiếp trong phương thức, không bao gồm các cuộc gọi đến phương thức con). Chính Self Weight cho thấy hàm nào thực sự đang tải bộ xử lý. Weight (tổng thời gian với các phương thức con) có thể gây hiểu lầm: một phương thức có Weight cao có thể chỉ đang gọi một phương thức chậm khác, còn bản thân nó thì nhanh.

import UIKit

class ImageGalleryViewController: UIViewController {
    // Time Profiler sẽ hiển thị rằng cellForItemAt có Self Weight = 40%
    // bên trong nó, decodeImage chiếm 35% — đây là nút thắt

    func collectionView(
        _ collectionView: UICollectionView,
        cellForItemAt indexPath: IndexPath
    ) -> UICollectionViewCell {
        let cell = collectionView.dequeueReusableCell(
            withReuseIdentifier: "ImageCell",
            for: indexPath
        ) as! ImageCell
        // ❌ decodeImage — nút thắt (Self Weight = 35%)
        cell.imageView.image = UIImage(contentsOfFile: imagePath)
        return cell
    }
}

Khi phân tích Time Profiler, hãy chú ý đến các phương thức chạy trong com.apple.main-thread. Nếu Self Weight trên luồng chính vượt quá ngưỡng 16 ms mỗi khung hình — UI sẽ bị chậm. Giải pháp cho những vấn đề này là di chuyển việc giải mã hình ảnh, tính toán layout và xử lý dữ liệu từ luồng chính sang luồng nền thông qua Grand Central Dispatch (GCD).

Cách đọc Call Tree trong Time Profiler

Call Tree — là biểu diễn phân cấp của tất cả các cuộc gọi phương thức, được sắp xếp theo Self Weight. Phương thức nặng nhất trong Call Tree là dòng đầu tiên. Mở rộng dòng, bạn sẽ thấy phương thức đó đã gọi những phương thức con nào và chúng đã mất bao nhiêu thời gian. Hãy tìm các phương thức nơi Self Weight (thời gian riêng) vượt quá đáng kể Weight (tổng thời gian) — đó là dấu hiệu của sự chặn đồng bộ và chờ đợi.

Allocations: theo dõi bộ nhớ thời gian thực

Allocations — là công cụ giám sát tất cả các cấp phát bộ nhớ của ứng dụng. Nó hiển thị đối tượng nào, với số lượng bao nhiêu và tổng kích thước ra sao được tạo ra tại mỗi thời điểm. Không giống như Memory Profiler trong Android Studio, Allocations hỗ trợ Heapshot — ảnh chụp nhanh các đối tượng sống với khả năng so sánh hai ảnh chụp.

Giao diện của Allocations gồm hai phần chính: All Allocations (thống kê tổng theo loại đối tượng) và Call Trees (cây cuộc gọi với phân tích theo phương thức tạo đối tượng). Để tìm rò rỉ, hãy sử dụng Heapshot Analysis: chụp nhanh trước khi thực thi kịch bản, thực thi kịch bản, chụp nhanh sau đó — và so sánh xem đối tượng mới nào còn lại trong bộ nhớ.

Theo Apple Developer Documentation, mẫu rò rỉ phổ biến nhất được phát hiện qua Allocations là việc tạo quá nhiều UIView và CALayer khi cuộn collection. Nếu mỗi lần cuộn, số lượng UIView sống tăng lên, nhưng collection tái sử dụng cell — thì ở đâu đó đang tạo thêm view mà không giải phóng view cũ. Allocations hiển thị ngăn xếp cuộc gọi chính xác nơi các view này được tạo ra.

Heapshot Analysis: so sánh ảnh chụp bộ nhớ

Heapshot — là ảnh chụp nhanh các đối tượng sống trong Allocations. Chụp Heapshot trước khi thực thi kịch bản, thực thi kịch bản và chụp Heapshot thứ hai. Sự khác biệt giữa các ảnh chụp sẽ cho thấy đối tượng nào đã được tạo và không được giải phóng. Kết quả lý tưởng — chỉ tăng các đối tượng tạm thời (Autorelease pool). Để phân tích chính xác, hãy sử dụng kết hợp Allocations + Leaks trong một phiên. Allocations cho thấy đối tượng nào không được giải phóng, và Leaks — tại sao (tham chiếu mạnh nào đang giữ chúng). Hãy chạy phiên kép mỗi khi nghi ngờ có rò rỉ.

Leaks: tự động tìm rò rỉ bộ nhớ

Leaks — là công cụ chuyên biệt để phát hiện rò rỉ bộ nhớ trong ứng dụng iOS và macOS. Không giống như Allocations chỉ hiển thị cấp phát, Leaks chủ động quét heap để tìm retain cycles — tình huống khi hai hoặc nhiều đối tượng giữ nhau bằng tham chiếu mạnh.

Leaks hoạt động cùng với Cycles & Roots — trình trực quan hóa đồ thị lưu giữ đối tượng. Khi phát hiện rò rỉ, Leaks hiển thị tất cả các đối tượng trong chu trình, retain count của chúng và các trường chính xác qua đó tham chiếu được truyền. Nhà phát triển chỉ cần nhìn vào đồ thị và hiểu tham chiếu nào cần được thay thế bằng weak.

Công cụ tự động đánh dấu rò rỉ bằng điểm đánh dấu màu đỏ trên dòng thời gian. Leaks hoạt động theo thời gian thực: ngay khi hệ thống phát hiện rò rỉ, nó lập tức báo hiệu cho nhà phát triển. Điều này cho phép sửa lỗi “tại chỗ” mà không cần chờ dump và phân tích sau.

Theo WWDC 2022, Leaks có thể phát hiện cả retain cycles đa cấp phức tạp — ví dụ, khi ba hoặc nhiều đối tượng tạo thành một chuỗi tham chiếu mạnh khép kín. Để chẩn đoán các chu trình như vậy, đồ thị Cycles & Roots là không thể thiếu: nó hiển thị trực quan cách các đối tượng tham chiếu lẫn nhau.

Cách đọc đồ thị Cycles & Roots

Mỗi nút của đồ thị là một đối tượng, mỗi mũi tên là một tham chiếu mạnh. Chu trình là một vòng khép kín của các mũi tên. Màu của nút hiển thị trạng thái: đỏ — đối tượng bị rò rỉ, xanh lá — gốc (GC Root), xám — đối tượng trung gian. Để sửa rò rỉ, hãy tìm một mũi tên có thể chuyển thành weak mà không phá vỡ logic — và thay đổi loại tham chiếu trong mã.

Energy Log: phân tích mức tiêu thụ năng lượng

Energy Log — là mẫu Instruments để đo mức tiêu thụ năng lượng của ứng dụng. Nó thu thập dữ liệu từ các cảm biến phần cứng của thiết bị: tải CPU, trạng thái Wi-Fi và mạng di động, sử dụng GPS, màn hình và Bluetooth. Energy Log hiển thị hoạt động nào trong ứng dụng gây ra mức tiêu thụ pin lớn nhất và chồng chúng lên biểu đồ tiêu thụ năng lượng theo thang thời gian.

Công cụ phân loại hoạt động theo mức tiêu thụ năng lượng: thấp (hoạt động bộ xử lý bình thường), trung bình (truyền Wi-Fi), cao (GPS, mạng di động, GPU). Nếu Energy Log hiển thị chỉ báo màu đỏ mức cao trong thời gian dài — ứng dụng đang xả pin ở chế độ nền và sẽ bị người dùng gỡ bỏ.

Các vấn đề điển hình được Energy Log phát hiện: WakeLock không giới hạn thời gian (ứng dụng giữ bộ xử lý hoạt động sau khi hoàn thành tác vụ), Location Updates độ chính xác cao ở chế độ nền (yêu cầu tọa độ sau mỗi vài giây), bất thường phiên mạng (kết nối lại thường xuyên với máy chủ). Energy Log khuyên nên ghi lại mọi sự cố như vậy và thêm điều kiện để tắt hoạt động tiêu tốn năng lượng.

Để kiểm tra mức tiêu thụ năng lượng, hãy sử dụng thiết bị thật chạy bằng pin — trên trình giả lập, các chỉ số tiêu thụ năng lượng không chính xác. Hãy chạy Energy Log cùng với kiểm thử UI để tự động hóa việc kiểm tra mức tiêu thụ pin trong CI.

Cách khởi chạy và diễn giải kết quả Instruments

Khởi chạy Instruments từ Xcode bằng hai cách: qua menu Product → Profile (⌘I) hoặc mở Instruments như một ứng dụng riêng biệt trong Launchpad. Cách đầu tiên thuận tiện hơn: Xcode tự động biên dịch ứng dụng ở chế độ hồ sơ và chạy nó trên thiết bị được kết nối với mẫu đã chọn. Sau khi dừng phiên, Instruments lưu dấu vết vào tệp có phần mở rộng .trace.

Việc diễn giải kết quả phụ thuộc vào mẫu. Đối với Time Profiler, hãy xem Call Tree được sắp xếp theo Self Weight — các phương thức ở trên cùng là nút thắt cổ chai chính của bạn. Đối với Allocations — xem # Living sau kịch bản tuần hoàn: nếu số lượng đối tượng tăng lên — hãy tìm rò rỉ. Đối với Leaks — xem các điểm đánh dấu đỏ và đồ thị Cycles & Roots. So sánh kết quả trước và sau khi tối ưu hóa — đây là cách duy nhất để xác nhận hiệu quả của các thay đổi.

// Dòng lệnh cho Instruments trong CI
// Tích hợp Instruments vào pipeline CI/CD
import XCTest

class PerformanceTests: XCTestCase {
    func testScrollPerformance() {
        // Đo thời gian cuộn collection
        measure(metrics: [XCTCPUMetric(), XCTMemoryMetric()]) {
            app.scrollToBottom()
        }
    }
}

Trong CI, có thể chạy Instruments từ dòng lệnh qua xcodebuild -showBuildSettings và xcrun xctrace. Điều này cho phép tự động hóa việc hồ sơ hóa tại mỗi commit và không bỏ lỡ hồi quy. Để phân tích, hãy sử dụng so sánh Baseline: nếu số liệu xấu đi 5% so với commit trước — pipeline nên dừng lại.

Các lỗi chính khi làm việc với Instruments: hồ sơ hóa trên trình giả lập thay vì thiết bị thật (dữ liệu CPU và GPU không chính xác), thu thập dữ liệu không có kịch bản (kết quả ngẫu nhiên), bỏ qua Call Tree (chỉ nhìn vào biểu đồ, không xem các phương thức cụ thể). Sửa những lỗi này mang lại 80% chất lượng hồ sơ hóa.