Performance budget · Project Handbook

Vì sao "app phải nhanh" không dùng được

Câu đó không kiểm chứng được, nên không ai làm sai và cũng không ai làm đúng. Khi một build chậm đi, không có căn cứ nào để chặn nó — chỉ còn cảm giác, và cảm giác thì thua deadline.

Performance budget biến chất lượng từ ý kiến thành một con số có thể bị vi phạm.

Ngân sách của Alliance App

Chỉ số	Đích	Ngưỡng báo động	Đo ở đâu
Cold start P95	≤ 2,0s	> 3,0s	Device Tier 1 low-end, build release
Warm start P95	≤ 1,0s	> 1,5s	Device Tier 1 low-end
Render màn hình chính sau khi có dữ liệu	≤ 500ms	> 1,0s	Device Tier 1 low-end
API P95 của luồng chính	≤ 1,0s	> 2,0s	Đo phía server, tách riêng theo endpoint
Crash-free sessions	≥ 99,5%	< 99,0%	Crash reporting trên production
ANR rate (Android)	≤ 0,2%	> 0,35%	Android vitals
Bộ nhớ khi dùng bình thường	Theo tier device	Vượt 20% so với baseline	Profiler trên device Tier 1
Kích thước bản tải về	Đặt sau khi đo baseline	Tăng > 10% trong một release	Bảng điều khiển store

Các con số này là quality target nội bộ, không phải tiêu chuẩn của Apple hay Google. Chúng tồn tại để đội tự chặn mình sớm.

Neo với ngưỡng thật của store

Ngưỡng nội bộ phải chặt hơn ngưỡng của store, vì chạm ngưỡng store là đã muộn — hậu quả lúc đó không còn nằm trong tầm kiểm soát của đội.

Google Play định nghĩa bad behavior threshold trên dữ liệu user-perceived, tính theo daily active users: crash rate từ 1,09% và ANR rate từ 0,47% trở lên. Vượt ngưỡng thì Play có thể giảm hiển thị app và gắn cảnh báo lên store listing. Ngoài ra còn ngưỡng riêng cho từng device model: từ 8% daily users của model đó.

Đọc bảng trên theo góc này: đích nội bộ 99,5% crash-free tương đương crash rate 0,5%, tức còn cách ngưỡng Play khoảng hai lần. Khoảng cách đó là phần đệm để đội có thời gian phản ứng, không phải phần dư để tiêu.

Đo thế nào cho ra số thật

Bốn quy tắc, vi phạm một cái là số đo mất giá trị:

Đo trên build release, không đo trên build debug. Chênh lệch có thể tới vài lần.
Đo trên device low-end Tier 1, không đo trên máy của dev.
Dùng P95, không dùng trung bình. Trung bình che mất đúng nhóm user đang khổ nhất.
Đo lặp lại, không đo một lần. Lần chạy đầu sau khi cài luôn chậm bất thường.

Cảnh báo regression theo phần trăm

Đây là phần quan trọng hơn cả ngưỡng tuyệt đối. Ví dụ:

Release trước:  cold start P95 = 1,7s
Release mới:    cold start P95 = 2,2s
Đích:           ≤ 2,0s  →  vẫn còn trong ngưỡng?  Không, đã vượt.
Nhưng kể cả khi đích là 2,5s thì vẫn phải cảnh báo: +29% so với bản trước.

Quy tắc: chậm đi quá 10% so với release liền trước thì phải giải thích được lý do trước khi cắt bản, kể cả khi vẫn nằm trong ngân sách. Không có quy tắc này thì app sẽ chậm đi đều đặn 5% mỗi release, và sau một năm không ai chỉ ra được release nào làm hỏng.

Số đo lấy từ automation chạy định kỳ trên device Tier 1, không lấy từ một lần bấm tay trước ngày release.

Khi chưa có dữ liệu baseline

Đừng bịa ngưỡng. Trình tự đúng:

Đo hiện trạng trên device Tier 1, ghi lại thành baseline.
Chạy hai tuần, xem dao động tự nhiên là bao nhiêu.
Đặt đích cao hơn hiện trạng một mức hợp lý, và ngưỡng báo động ở mức chắc chắn là bất thường.
Ghi ngày đặt ngưỡng, xem lại mỗi quý.

Ngưỡng đặt trước khi có baseline sẽ hoặc quá lỏng nên vô dụng, hoặc quá chặt nên bị tắt đi sau hai tuần.

Giới hạn

Performance budget chặn được regression, không làm app nhanh lên. Muốn nhanh lên thì phải có hạng mục tối ưu riêng, có người và có thời gian.
Không đưa mọi chỉ số vào CI làm gate. Gate chỉ đặt ở cold start và kích thước bản tải về — hai thứ đo ổn định và rẻ. Phần còn lại theo dõi theo xu hướng, không chặn build.
Số đo trên device cloud dao động mạnh hơn device thật. Dùng nó để phát hiện xu hướng, đừng dùng để phán quyết một release.