Performance

Hãy hình dung Main thread như MỘT nhân viên duy nhất đứng ở quầy, vừa phải vẽ lại màn hình vừa phải phản hồi mọi cú chạm của người dùng. Để mắt nhìn thấy chuyển động mượt (60 khung hình/giây), nhân viên đó phải xong phần việc của MỖI khung hình trong khoảng 16 mili-giây — nhanh hơn một cái chớp mắt rất nhiều.

Nếu bạn giao cho nhân viên đó một việc nặng — gọi mạng, đọc database, decode một tấm ảnh lớn, parse một JSON khổng lồ — ngay trên Main thread, nhân viên đó bị "kẹt" ở việc nặng đó và không kịp vẽ khung hình tiếp theo đúng hạn. Kẹt nhẹ thì màn hình giật (jank, người dùng thấy cuộn không mượt); kẹt quá lâu (khoảng 5 giây với sự kiện chạm) thì hệ thống coi như app đã "đứng hình" và tự hỏi người dùng có muốn đóng app không — đây chính là ANR.

Cách giải quyết đã học ở phần Coroutines + Flow: việc nặng nào cũng nên đẩy sang đúng làn phù hợp — Dispatchers.IO cho việc ngồi chờ (mạng, đọc/ghi file, DB), Dispatchers.Default cho việc tính toán nặng CPU — chỉ để lại cho Main thread đúng một việc: cập nhật UI.

// SAI: đọc file cấu hình lớn ngay trên Main — nhân viên ở quầy phải dừng vẽ để đi đọc file
fun onScreenOpen() {
    val config = File(path).readText()   // block Main thread
    render(config)
}

// ĐÚNG: nhường việc đọc file cho làn IO, Main thread chỉ nhận kết quả rồi vẽ
viewModelScope.launch {
    val config = withContext(Dispatchers.IO) { File(path).readText() }
    render(config)
}

ANR (Application Not Responding) là hậu quả trực tiếp của phần trước, chỉ khác ở MỨC ĐỘ nghiêm trọng: Main thread bị chặn đủ lâu (khoảng 5 giây khi đang có sự kiện chạm chờ xử lý) khiến hệ thống kết luận app không còn phản hồi. Ba thủ phạm quen mặt nhất: tự ý gọi Room/đọc file/gọi mạng một cách ĐỒNG BỘ (không suspend) ngay trên Main; tự decode một bitmap độ phân giải lớn trực tiếp; hoặc một vòng lặp tính toán quá nặng không nhường CPU cho việc vẽ UI.

• Không bao giờ tự truy vấn Room/đọc file/gọi mạng đồng bộ trên Main — luôn qua coroutine + dispatcher phù hợp (IO/Default), đúng như phần Coroutines + Flow.
• Không tự decode bitmap lớn trên Main — dùng thư viện ảnh (Coil/Glide), chúng đã tự làm việc decode ở background giúp bạn.
• Việc tính toán nặng nên chia nhỏ hoặc chuyển hẳn sang Dispatchers.Default, không cố nhồi hết vào một vòng lặp chạy liền một mạch trên Main.

Một danh sách sản phẩm vài trăm dòng, nếu vẽ mới từng dòng mỗi khi cuộn hay mỗi khi có gì đó đổi, sẽ ngốn rất nhiều thời gian vẽ (giống hệt lỗi "vẽ lại toàn bộ 100 dòng" đã nói ở phần XML/Compose). Cả RecyclerView lẫn Compose LazyColumn đều được thiết kế để TÁI SỬ DỤNG, không phải vẽ lại từ đầu:

• RecyclerView: dùng ListAdapter + DiffUtil (đã học ở phần XML/Compose) để chỉ cập nhật đúng dòng thay đổi; tránh layout lồng nhiều tầng bên trong mỗi item; giữ kích thước item ổn định để hệ thống không phải đo lại nhiều lần khi cuộn.
• Tải ảnh qua Coil/Glide — hai thư viện này tự có cache, tự decode off-thread; không tự giữ bitmap lớn trong biến của mình vì nó chiếm bộ nhớ ngay cả khi item đã cuộn ra khỏi màn hình.
• Danh sách RẤT lớn (hàng nghìn dòng trở lên): dùng Paging để tải theo trang, không tải hết một lần rồi giữ tất cả trong bộ nhớ.
• Compose LazyColumn: luôn truyền key ổn định cho từng item (vd id sản phẩm) — nhờ vậy khi danh sách đổi thứ tự hoặc chèn/xoá, Compose biết chính xác "đây vẫn là item cũ, chỉ đổi vị trí" thay vì hiểu nhầm là item hoàn toàn mới rồi vẽ lại từ đầu.

Nối tiếp phần XML/Compose: recomposition càng lan rộng thì càng tốn công vẽ lại những phần lẽ ra không cần đổi. Có hai cách thu hẹp phạm vi đó — một là tổ chức lại code (đọc state gần nơi dùng, tách composable nhỏ), hai là giúp Compose TỰ TIN hơn khi quyết định có cần vẽ lại hay không.

Compose chỉ dám bỏ qua (skip) việc vẽ lại một composable nếu nó chắc chắn tham số truyền vào KHÔNG ĐỔI so với lần trước. Nếu tham số là một class mà Compose không chắc có immutable hay không (vd một class thường chứa var, hoặc một List có thể bị sửa ngầm ở nơi khác), Compose đành phải vẽ lại cho chắc — dù thực chất dữ liệu giống hệt lần trước. Đây là lý do nên ưu tiên data class chỉ chứa val, và các kiểu Compose biết chắc là ổn định (String, Int, các kiểu immutable của Kotlin).

Một tình huống thực tế khác: giá trị offset khi cuộn danh sách đổi liên tục theo TỪNG PIXEL, nhưng bạn chỉ cần biết một điều đơn giản hơn — "đã cuộn qua khỏi 200px hay chưa" để quyết định có hiện nút "lên đầu trang" hay không. Nếu đọc thẳng offset thô, composable đó sẽ recompose theo từng pixel cuộn — rất lãng phí.

val showScrollToTop by remember {
    derivedStateOf { listState.firstVisibleItemScrollOffset > 200 }
}
// showScrollToTop chỉ đổi giá trị (true/false) đúng lúc vượt ngưỡng — không đổi theo từng pixel

Memory leak xảy ra khi một object đáng lẽ phải được dọn (garbage collected) lại không thể dọn được, vì có gì đó vẫn đang giữ tham chiếu tới nó — giống việc giữ mãi một tấm danh thiếp của người đã nghỉ việc, khiến người đó vẫn "còn tồn tại" trong hệ thống dù thực ra đã rời đi từ lâu. Ba nguồn quen thuộc nhất: một object sống lâu (singleton, ViewModel) giữ tham chiếu tới Activity/View/Context của một màn hình đã đóng; một listener đăng ký rồi quên gỡ; hoặc một coroutine/handler vẫn tiếp tục chạy dù màn hình đã không còn.

• Chỉ giữ Application Context (sống suốt vòng đời app) ở những nơi sống lâu — không giữ Context của một Activity/Fragment cụ thể, đúng như đã học ở phần Android fundamentals.
• Luôn gỡ listener đã đăng ký khi không còn cần (thường ở đúng callback vòng đời tương ứng lúc đăng ký).
• Luôn chạy coroutine trong viewModelScope/lifecycleScope, và collect Flow gắn với viewLifecycleOwner (Fragment) — đúng như phần Coroutines + Flow — để chúng tự huỷ theo đúng vòng đời, không phải tự bạn nhớ huỷ tay.

Quy trình đúng khi tối ưu hiệu năng là ĐO trước, sửa sau — đừng đoán mò rồi tối ưu nhầm chỗ không phải là bottleneck thật, vừa mất thời gian vừa có thể làm code phức tạp thêm mà không ích gì.

Android Studio Profiler chính là bộ dụng cụ đo đó — nhưng nó không phải MỘT cái đồng hồ chung chung, mà là 7 công cụ nhỏ, mỗi cái soi đúng MỘT khía cạnh khác nhau. Biết chọn đúng công cụ cho đúng nghi ngờ (nghi ngờ leak thì khác với nghi ngờ jank) sẽ nhanh hơn hẳn việc mở đại một cái rồi đoán: