Chúng ta có nên sử dụng RecyclerView để thay thế ListView không?

Tài liệu Android cho biết:

Tiện ích RecyclerView là phiên bản ListView tiên tiến và linh hoạt hơn. Tiện ích này là một thùng chứa để hiển thị các tập dữ liệu lớn có thể cuộn rất hiệu quả bằng cách duy trì số lượng lượt xem hạn chế. Sử dụng tiện ích RecyclerView khi bạn có các bộ sưu tập dữ liệu có các thành phần thay đổi khi chạy dựa trên hành động của người dùng hoặc các sự kiện mạng

Trên thực tế ListViewcó thể thực hiện tất cả các điều trên nếu hiệu quả không thành vấn đề và chúng tôi đã tìm thấy nhiều vấn đề khi chúng tôi sử dụng RecyclerViewđể thay thế ListView:

1. Không có onItemClickListener () cho lựa chọn mục danh sách - giải pháp

2. Không có phân chia giữa các mục danh sách - giải pháp

3. Không có bộ chọn chồng lấp tích hợp, không có phản hồi trực quan khi bạn nhấp vào danh sách mục - giải pháp

4. Không có addHeaderView cho tiêu đề danh sách - giải pháp

Có lẽ nhiều vấn đề hơn ...

Vì vậy, khi chúng ta sử dụng RecyclerViewđể thay thế ListView, chúng ta phải thực hiện thêm mã hóa để đạt được hiệu quả tương tự như ListView.

CÂU HỎI:

• Có đáng để chúng ta thay thế ListViewbằng RecyclerViewhoàn toàn?
• Nếu không thì trong trường hợp nào chúng ta nên sử dụng tốt hơn RecyclerViewthay vào đó ListView, và ngược lại?

Nếu ListView phù hợp với bạn, không có lý do gì để di chuyển. Nếu bạn đang viết một giao diện người dùng mới, bạn có thể tốt hơn với RecyclerView.

RecyclerView mạnh mẽ khi bạn cần tùy chỉnh danh sách của mình hoặc bạn muốn hình ảnh động tốt hơn. Những phương thức tiện lợi đó trong ListView gây ra nhiều rắc rối cho mọi người, đó là lý do tại sao RecyclerView cung cấp giải pháp linh hoạt hơn cho họ.

Thay đổi lớn bạn cần thực hiện để di chuyển là trong bộ điều hợp của bạn. Nếu bạn muốn tiếp tục gọi điện notifyDataSetChanged, bạn sẽ mất hầu hết các lợi ích hoạt hình & ràng buộc. Nhưng nếu bạn có thể thay đổi bộ điều hợp của mình để gửi các sự kiện thông báo chi tiết (được thêm / xóa / di chuyển / cập nhật), thì bạn sẽ có được hiệu suất và hiệu suất tốt hơn nhiều. Những sự kiện này cho phép RecyclerView chọn hình động chính xác và nó cũng giúp nó tránh onBindcác cuộc gọi không cần thiết . Bạn sẽ nhận được một lợi ích lớn nếu quan điểm mặt hàng của bạn là phức tạp. Ngoài ra, trong tương lai, sẽ có nhiều thành phần hơn xung quanh RecyclerView.

Theo tôi, nếu ListView đáp ứng tất cả các nhu cầu hiện tại của ứng dụng của bạn và đáp ứng tất cả các trường hợp sử dụng thì không cần phải thay thế nó bằng RecyclerView.

RecyclerView mang lại sức mạnh to lớn cho các nhà phát triển của mình với chi phí tăng độ phức tạp cho các nhà phát triển. Có một số điều nhất định có thể được thực hiện dễ dàng trong ListView giờ đây có thể mất rất nhiều nỗ lực không cần thiết.

Nhưng vâng, có rất nhiều điều mà ListView không bao giờ có thể làm được, như tính năng LayoutManager tuyệt vời có thể cho phép bạn thay đổi linh hoạt bố cục thành lưới ngang, dọc, lưới hoặc so le.

Tôi đã viết một câu trả lời chi tiết về chủ đề này ở đây .

1 Bạn có thể sử dụng giao diện để cung cấp trình nghe nhấp chuột. Tôi cũng sử dụng kỹ thuật này với ListViews.
2 Không có bộ chia: Chỉ cần thêm vào hàng của bạn một Chế độ xem với chiều rộng của match_parent và chiều cao 1dp và tạo cho nó một màu nền .
3 Chỉ cần sử dụng bộ chọn StateList cho nền hàng. Cũng có thể tránh
4 addHeaderView trong ListViews: chỉ cần đặt Tiêu đề bên ngoài Chế độ xem.

Vì vậy, nếu tính hiệu quả là mối quan tâm của bạn, thì đúng vậy , đó là một ý tưởng tốt để thay thế ListView bằng RecyclerView.

Cho đến gần đây tôi vẫn đang sử dụng ListView cho các danh sách rất đơn giản. Ví dụ: nếu tôi muốn hiển thị một danh sách các tùy chọn văn bản đơn giản ...

Tôi dựa trên quyết định đó về 'các yếu tố con người', rằng việc tạo một ListView đơn giản với ít mã hơn sẽ tốt hơn nếu hiệu suất là không quan trọng. Tôi thường nghĩ về một giáo sư ở trường đại học thích nói: "Giáo viên của tôi, Niclaus Wirth, nhà phát minh của Pascal, đã từng nói nếu một chương trình có hơn 50 dòng mã thì chắc chắn là sai ..."

Nhưng điều đã thuyết phục tôi ngừng sử dụng ListView là gần đây nó đã được chuyển sang danh mục "Di sản" trong công cụ thiết kế Android Studio cùng với RelativeLayout.

Tôi nghĩ rằng đây là hình thức 'phản đối'. Sẽ là quá khó chịu nếu nó thực sự bị phản đối và tất cả các nhà phát triển có lương tâm đã chuyển mã của họ sang RecyclerView.

Hơn nữa, phần giới thiệu cho ListView cảnh báo ngay trên đầu rằng RecyclerView là một lựa chọn tốt hơn: "Đối với cách tiếp cận hiện đại, linh hoạt và hiệu quả hơn để hiển thị danh sách, hãy sử dụng RecyclerView."
https://developer.android.com/reference/android/widget/ListView

Ngoài ra, hướng dẫn về ListView vẫn đang nói về trình tải con trỏ, nhưng sau đó, chính getSupportCoderLoader () đã không được dùng nữa trong API 28.
https://developer.android.com/guide/topics/ui/layout/listview

Những cải tiến gần đây cho Android Studio:

Tệp -> Mới -> Đoạn -> Đoạn (Danh sách)

Điều này cung cấp cho chúng tôi một RecylerView hoạt động đầy đủ với văn bản cơ bản. Điều đó loại bỏ lý do thực sự cuối cùng của tôi khi sử dụng ListView bởi vì giờ đây việc cài đặt RecylerView cơ bản trở nên dễ dàng.

Tóm lại, tôi không có ý định sử dụng ListView cho sự phát triển mới bởi vì việc dán nhãn nó có 'di sản' chỉ còn một bước nữa là không tán thành nó.

Trường hợp duy nhất khi sử dụng ListView vẫn ổn khi danh sách không động hoặc bị ảnh hưởng bởi các sự kiện mạng. Ví dụ: điều hướng.

Đối với bất kỳ mục đích sử dụng nào khác, RecyclerView làm lu mờ ListView. Vì RecyclerView chỉ quan tâm đến việc tái chế nên việc thực hiện những thứ liên quan trực quan được kết hợp chặt chẽ trong ListView sẽ dễ dàng hơn, như thay đổi vị trí / sắp xếp lại, hoạt hình (thực tế là nó đi kèm với RecyclerView.ItemAnimator), bố cục tùy chỉnh (cổ phiếu có StaggeredGrid) danh sách cũ hoặc kiểu lưới nhưng cũng có thư viện này mở rộng hơn nữa).

Ngoài ra nếu bạn muốn sử dụng CardView tôi tin rằng đó là cách duy nhất để đi (một số cách đọc tốt khi sử dụng thẻ hoặc danh sách).

Một thay thế tuyệt vời là sử dụng BaseAd CHƯƠNG. Nó hỗ trợ mẫu Viewholder sử dụng và của tôi chứa hơn 100 hàng với bitmap và nút và nó chạy rất mượt.