Học cách suy nghĩ về các sự kiện thực sự là chìa khóa ở đây Bạn có thể làm điều đó :)
Nguyên tắc đầu tiên là:.. không bao giờ trì hoãn thread UI. Chuỗi giao diện người dùng chịu trách nhiệm giữ cho ứng dụng của bạn cảm thấy nhạy cảm. Bất kỳ công việc bạn làm ở đó không nên chặn; làm những gì bạn cần làm và quay trở lại càng nhanh càng tốt. Chắc chắn tránh làm I/O trên chuỗi giao diện người dùng. (Có một số nơi bạn không thực sự có thể giúp nó do yêu cầu vòng đời, ví dụ như lưu trạng thái ứng dụng trong .) Nếu bạn bao giờ gọi Thread.sleep trên chuỗi giao diện người dùng bạn đang làm sai.
Android thực thi điều này với lỗi "Ứng dụng không phản hồi" (hoặc "ANR") mà người dùng nhìn thấy. Bất cứ khi nào bạn nhìn thấy điều này trong ứng dụng Android, điều đó có nghĩa là nhà phát triển đã làm điều gì đó khiến cho chuỗi giao diện người dùng bị trì hoãn quá lâu. Nếu thiết bị thực sự bị sa lầy vì một lý do nào đó lỗi này có thể không thực sự là lỗi của nhà phát triển ứng dụng, nhưng thường có nghĩa là ứng dụng đang làm điều gì đó sai.
Bạn có thể sử dụng mô hình này để tận dụng lợi thế của mình bằng cách đăng sự kiện của riêng bạn. Điều này cung cấp cho bạn một cách dễ dàng để nói cho ứng dụng của bạn, "làm điều này sau." Trong Android, chìa khóa để đăng sự kiện của riêng bạn là ở lớp Handler. Phương thức postDelayed cho phép bạn lên lịch một số Runnable sẽ được thực thi sau một số mili giây nhất định.
Nếu bạn có một Hoạt động trông giống như thế này:
public class MyActivity extends Activity {
private Handler mHandler = new Handler();
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
mHandler.postDelayed(new Runnable() {
public void run() {
doStuff();
}
}, 5000);
}
private void doStuff() {
Toast.makeText(this, "Delayed Toast!", Toast.LENGTH_SHORT).show();
}
}
Sau đó, 5 giây sau khi hoạt động được tạo ra, bạn sẽ thấy bánh mì nướng tạo ra trong doStuff.
Nếu bạn đang viết View tùy chỉnh thậm chí còn dễ dàng hơn. Chế độ xem có phương thức postDelayed riêng của chúng sẽ nhận mọi thứ được đăng lên đúng Handler và bạn không cần phải tạo của riêng mình.
Quy tắc thứ hai là: Chế độ xem nên chỉ được sửa đổi trên chuỗi giao diện người dùng. Những ngoại lệ mà bạn nhận được và bỏ qua có nghĩa là đã xảy ra sự cố và nếu bạn bỏ qua chúng, ứng dụng của bạn có thể sẽ bắt đầu hoạt động sai theo những cách thú vị. Nếu ứng dụng của bạn thực hiện hầu hết công việc trong các chủ đề khác, bạn có thể post sự kiện trực tiếp vào chế độ xem bạn muốn sửa đổi để các sửa đổi sẽ chạy chính xác.
Nếu bạn có một tham chiếu đến Activity từ phần mã của bạn, bạn cũng có thể sử dụng Activity#runOnUIThread, thực hiện chính xác tên của nó. Bạn có thể thích cách tiếp cận này nếu đăng lên một chế độ xem không thực sự có ý nghĩa trong ngữ cảnh.
Đối với các bản cập nhật cho lượt xem không xuất hiện cho đến khi bạn nhấn nút, loại chế độ xem này là gì? Có phải chế độ xem tùy chỉnh đang vẽ các bản cập nhật này không? Nếu vậy, bạn có nhớ gọi invalidate sau khi thay đổi dữ liệu để kích hoạt vẽ lại không? Chế độ xem chỉ tự vẽ lại sau khi chúng bị vô hiệu.
Cũng thấy lỗi của cách của tôi là tôi đang cố gắng sửa đổi các chế độ xem trong một chuỗi khác nhau liên tục chạy để giao diện người dùng không bị khóa ... vì tôi không chắc chắn cách vượt qua các giá trị được tạo bởi chuỗi đang chạy của tôi ... tới giao diện người dùng. Phản ứng vô cùng hữu ích mặc dù, và tôi cảm ơn bạn rất nhiều vì nó –
Sử dụng AsyncTask – Falmarri