2010-09-27 23 views
5

Tôi có một danh sách khá đơn giản với 3 trường văn bản trên mỗi hàng. Chúng tôi đang cập nhật giá trị của chúng sau mỗi 2 giây hoặc lâu hơn với dữ liệu đến từ cuộc gọi webservice nền (AsyncTask)ArrayAdapter của ListView notifydatasetchanged() vẽ lại rất chậm

Chúng tôi so sánh các giá trị sắp tới, cập nhật chúng cho phù hợp và cuối cùng gọi đến notifyDataSetChanged() nếu cần

Điều này là vẽ lại rất chậm, do đó treo toàn bộ giao diện người dùng khi chúng tôi có nhiều hơn 3 hàng cập nhật cùng một lúc. Tất nhiên chúng tôi đang sử dụng tất cả các tối ưu hóa ListView nổi tiếng như phương pháp tiếp cận EfficientAdapter (setTag() và chủ sở hữu), và getViewTypecount()/getItemViewType(). Chúng tôi cũng đã cố gắng tối ưu hóa giao diện của mình càng nhiều càng tốt với layoutopt và cố gắng tránh chiều rộng wrap_content và chiều cao để làm sáng mọi thứ.

Chúng tôi không thực hiện các hoạt động đắt tiền trên các bản cập nhật của mình, chỉ là công cụ chuẩn: thay đổi văn bản TextView, textcolor và các giá trị màu nền.

Điều lạ duy nhất tôi có thể thấy là getView() được gọi 3-4-5 lần cho mỗi hàng, mặc dù tôi đã đọc tất cả tin những của Romain [1] nói rằng không có gì sai với điều đó

Bất kỳ ý tưởng hay gợi ý nào về cách chúng ta có thể tăng tốc nó?

Cảm ơn bạn rất nhiều!

[1] http://groups.google.com/group/android-developers/browse_thread/thread/4c4aedde22fe4594/aeb04288064f495e?show_docid=aeb04288064f495e

+0

Có vẻ như bạn đang nhận được nhiều cập nhật hơn bạn có thể vẽ - bạn đã thử giảm tần suất cập nhật xuống 10 giây để kiểm tra điều này chưa? Nếu điều này giúp bạn sẽ cần phải tìm một giải pháp để xóa hàng đợi từ nhiệm vụ với mỗi lần cập nhật. 2 giây là khá thường xuyên nếu bạn xem xét việc thu gom rác tự động có thể mất đến 1 giây (hy vọng không nhiều hơn) và các dịch vụ khác có thể trì hoãn cập nhật. –

+0

Các cuộc gọi liên tiếp, vì vậy các cuộc gọi mới được thực thi khi kết thúc trước. – Albert

+0

Trường hợp thu gom rác thải tồi tệ nhất mất hơn 200ms, đó là không có gì so với giao diện người dùng 1,5 - 2 s treo mà trải nghiệm ứng dụng trên mỗi lần vẽ lại. Tốc độ làm mới không ảnh hưởng ở đây, ngay cả khi tôi tăng lên 10 giây, sau khi cuộc gọi được kích hoạt, việc vẽ lại sẽ tiếp tục đóng băng trong 2 giây đó – Albert

Trả lời

0

Tôi cho rằng bạn có thể đặt một thẻ để ur TextView như url, nơi nó sẽ nhận được bản cập nhật từ. Và thay vì gọi "notifyDataSetChanged()", bạn có thể thử sử dụng findViewByTag (URL cập nhật) và setText cho chế độ xem đó, do đó, chế độ xem văn bản chỉ được sơn lại không phải toàn bộ danh sách lặp đi lặp lại. Có thể làm giảm đủ số lần sơn lại thêm. Chỉ là một ý nghĩ.

1

Điều này dành cho những người duyệt từ Google nghĩ rằng họ cần viết lại phương thức thay đổi dữ liệu của riêng họ. Dựa trên dữ liệu của tôi, bạn không cần phải cho nhiều trường hợp.

notifyDataSetChanged() có thể là NHẢI FASTER nhanh hơn so với mã được thay thế bằng tay và tất cả phụ thuộc vào việc triển khai listview thực tế của bạn.

Mẫu: Một danh sách xem văn bản chỉ 3 dòng đơn giản với hàng tối đa 10K ArrayList được cập nhật qua lựa chọn menu.

Manual notifyDataSetChange()

--- avg run-time: 4ms 

Mặc định miễn phí notifyDataSetChange()

--- avg run-time: 0ms <--- you can't get faster than this. 

Đừng chạy để tạo ra sự thay thế của riêng bạn, trừ khi bạn thời gian và điểm chuẩn cụ của bạn. Sử dụng các công cụ miễn phí cho đến khi cần thiết.