Bài 09 · Quy trình khôi phục

Khi màn hình sai, đừng đoán mò tiến tới — hãy khôi phục về trạng thái đã biết, hoặc nói rõ ràng rằng bạn không thể.

Bài toán

Một automation chạy dài chắc chắn sẽ rơi vào màn hình không mong đợi: một trang chen ngang, một ngã rẽ, một nơi nó chưa từng lên kế hoạch. Từ đó, cắm đầu đi tiếp chỉ làm mọi thứ tệ hơn. Thứ bạn cần là một quy trình trả lời đáng tin một câu hỏi:

Đưa tôi về dashboard — hoặc bảo tôi rằng anh chịu.

Công cụ vạn năng của Android cho "lùi về nơi an toàn" là phím BACK. Kỷ luật nằm ở chỗ dùng nó có giới hạn: kiểm, bấm, chờ, kiểm lại — và bỏ cuộc bằng một thất bại sạch sẽ sau số lượt cố định, không bao giờ lặp vô tận.

Bạn sẽ học được

• Node Key Press (Nhấn phím).
• Chiếc thang kiểm → bấm → chờ → kiểm lại.
• Hội tụ nhiều lối ra về các kết thúc dùng chung.
• Vì sao khôi phục phải có giới hạn.

Trước khi bắt đầu

• Hoàn thành Bài 08.

Flow

Hai lượt thử làm flow này cao quá một ảnh chụp đọc được, nên đây là mỗi ảnh một lượt, ở mức zoom đầy đủ:

Lượt thứ nhất: ① Start ② "đang ở dashboard?" — nếu đúng thì đi thẳng ra ngoài theo cạnh xanh dài bên trái ③ một lần nhấn BACK ④ một Wait để lắng ⑤ hỏi lại.

Lượt thứ hai và các kết thúc: ①–④ lặp lại đúng khuôn BACK · lắng · kiểm lại, dịch thêm một bậc sang phải, rồi ⑤ Stop: on the dashboard thu mọi lối thành công và ⑥ Stop: could not recover là kết thúc thất bại trung thực duy nhất.

Hình bậc thang chính là thiết kế: mỗi bậc sang phải là một lượt khôi phục nữa, và mọi cạnh Success xanh đều hội tụ về một kết thúc vui duy nhất.

Dựng flow

1. Flow mới. Cột mốc "màn hình đã biết" là logo Practice App (chữ "M", góc trên trái mọi trang) — bắt nó một lần làm template. Cột mốc tốt là thứ có trên màn hình đích và không đâu khác.
2. Thêm ba phép kiểm Find Image giống hệt nhau On the dashboard? — cùng template, timeout 1500 ms (một câu hỏi, không phải sự chờ đợi — quy tắc của Bài 04).
3. Xen giữa: các node Key Press với Key = BACK, mỗi node theo sau bởi một Wait 600 ms (lý do: after BACK).
4. Hai kết thúc: Stop: on the dashboard (success) và Stop: could not recover (failure, thông điệp nêu rõ điểm bỏ cuộc).
5. Nối chiếc thang như sơ đồ — Success của mọi phép kiểm về cùng một Stop thành công.
6. Save, Auto Layout.

Vì sao nó được dựng như vậy

Lựa chọn	Lý do
Kiểm trước tiên, trước mọi cú BACK	Đã ở nhà rồi? Không bấm gì, xong trong ~300 ms
Chờ sau mỗi cú BACK	Màn hình có hiệu ứng; kiểm lại tức thì sẽ đọc khung hình cũ
Kiểm lại sau mỗi cú BACK	Mỗi cú bấm phải chứng minh tiến triển — không bắn mù liên thanh
Đúng hai cú, rồi bỏ cuộc	Ở màn hình gốc của ứng dụng, BACK thoát hẳn app — nghiến BACK vô tận làm mọi thứ tệ hơn
Một Stop thành công dùng chung	"Về nhà bằng đường nào" không quan trọng; "tôi đã ở nhà" mới quan trọng

Sao không dùng Loop? Bạn có thể diễn đạt đây bằng vòng lặp 2 lượt — và ở Bài 12 logic tương tự mang hình vòng lặp. Trải phẳng, chiếc thang đọc được trong một cái liếc và mỗi bậc về sau có thể phân hóa (một phím khác ở lượt hai chẳng hạn). Cho hai lượt, trải phẳng rõ hơn; cho năm lượt, dùng vòng lặp. Biết chọn hình dạng dễ đọc tự nó là một kỹ năng khóa học này dạy.

Chạy thử

• Từ dashboard: phép kiểm đầu khớp → success dưới một giây, không bấm gì.
• Điều hướng giả lập sang verify.html, chạy: kiểm trượt → BACK (trình duyệt lùi về dashboard) → chờ → phép kiểm hai khớp → success, một cú bấm.
• Mở hẳn một ứng dụng khác, chạy: hai cú bấm, ba phép kiểm trượt → failure · Not on a known screen after 2 BACK presses — kết cục trung thực mà bên gọi xử lý được.

Best practices

• Chọn cột mốc chỉ có ở màn hình đích. Logo và khung cố định ăn đứt bất kỳ thứ gì xuất hiện ở nhiều trang.
• Timeout kiểm ngắn — mỗi phép kiểm là một câu hỏi; ba câu hỏi 1500 ms tốn tối đa 4,5 giây ở ca bỏ cuộc.
• Luôn chờ sau phím điều hướng.
• Giới hạn mọi quy trình khôi phục. Stop thất bại không phải bi quan; nó là bản hợp đồng khiến flow này an toàn để gọi từ bất kỳ đâu.
• Flow này là viên gạch thực thụ đầu tiên của bạn — Bài 11 và 12 gọi nó như một hàm.

Lỗi thường gặp

Lỗi	Hậu quả	Cách sửa
BACK mà không kiểm lại	Bạn không biết nó có giúp gì không	Kiểm sau mỗi cú bấm
Vòng BACK vô tận	Thoát app, rồi bấm BACK trong launcher	Số lượt cố định + kết thúc thất bại
Cột mốc xuất hiện ở nhiều màn hình	"Khôi phục" nhầm trang	Chọn cột mốc đặc trưng hơn
Không chờ	Kiểm lại đọc khung hình trước-BACK	600 ms sau mỗi cú
Timeout kiểm dài	Đường bỏ cuộc chậm chạp	1500 ms mỗi phép kiểm

Khắc phục sự cố

Nó báo đã khôi phục mà màn hình vẫn sai. Cột mốc của bạn không đặc trưng — nó khớp ở trang khác. Chọn template cụ thể hơn.

BACK không tác dụng ở app nào đó. Vài màn hình chặn BACK. Đó chính là lý do quy trình bỏ cuộc sạch sẽ — bên gọi quyết bước kế (khởi động lại app, báo người).

Từ trình duyệt lúc nào cũng tốn cả hai cú bấm. Cú đầu rơi giữa hiệu ứng. Tăng khoảng chờ đầu lên 800 ms.

Tóm tắt

• Khôi phục = kiểm → bấm → chờ → kiểm lại, có giới hạn, với thất bại trung thực.
• Key Press BACK là nước đi vạn năng "về phía an toàn"; không giới hạn thì nó thành mối nguy.
• Kết thúc thất bại của flow khôi phục là lời hứa với những bên gọi tương lai của nó.

Tiếp theo

Quy trình không bao giờ lặp lại việc — nhưng các flow của bạn thì vẫn có thể, qua các lần chạy. Bài 10 · Cooldown bằng bộ nhớ cho flow trí nhớ sống lâu hơn lần chạy, để "việc này làm rồi" thành thứ nó biết được.

Xem thêm: Key Press · Find Image · Sub Flow