为什么此分页库示例的性能远不只是回收者视图?

时间:2018-10-28 08:27:17

标签: android performance android-recyclerview android-jetpack android-paging

因此,我一直在阅读Android的新分页库。具体来说,我正在尝试使用带有适配器,视图模型和数据源(由改造网络调用支持)的recyclerview加载永无休止的图像列表(使用Glide)。

这是基本代码:

// inside my activity
PhotosListAdapter adapter = new PhotosListAdapter(getApplicationContext());

PhotosViewModel viewModel = ViewModelProviders.of(this).get(PhotosViewModel.class);

viewModel.getPhotosList().observe(this, adapter::submitList);

RecyclerView recyclerView = findViewById(R.id.main_recycler_view);
recyclerView.setLayoutManager(new LinearLayoutManager(this));
recyclerView.setHasFixedSize(true);
recyclerView.setAdapter(adapter);

...

// My adapter code:
@Override
public void onBindViewHolder(@NonNull PhotoViewHolder photoViewHolder, int i) {
    Photo photo = getItem(i);
    if (photo != null) {
        mGlide.load(photo.previewURL).into(photoViewHolder.mPhotoImageView);
    }

}

private static final DiffUtil.ItemCallback<Photo> DIFF_CALLBACK = new DiffUtil.ItemCallback<Photo>() {
    @Override
    public boolean areItemsTheSame(@NonNull Photo photo, @NonNull Photo other) {
        return photo.id == other.id; // these are just ints
    }

    @Override
    public boolean areContentsTheSame(@NonNull Photo photo, @NonNull Photo other) {
        return photo.previewURL.equals(other.previewURL); // this is just a string
    }
};

...

// My View Model code:
private LiveData<PagedList<Photo>> mData;

public PhotosViewModel() {
    PhotosDataSource photosDataSource = new PhotosDataSource();
    mData = new LivePagedListBuilder<>(new DataSource.Factory<Integer, Photo>() {
        @Override
        public DataSource<Integer, Photo> create() {
            return photosDataSource;
        }
    }, 25).build();
}

public LiveData<PagedList<Photo>> getPhotosList() {
    return mData;
}

// My Data Source:
Call<SearchResult> search = mPixabayService.search(PixabayApi.api_key, "photo", 1, params.requestedLoadSize, true);
    search.enqueue(new Callback<SearchResult>() {
        @Override
        public void onResponse(Call<SearchResult> call, Response<SearchResult> response) {
            if (response.isSuccessful()) {
                SearchResult body = response.body();
                callback.onResult(body.hits, null, 2);
            }
            // TODO add error cases
        }

        @Override
        public void onFailure(Call<SearchResult> call, Throwable t) {

        }
    });

 @Override
public void loadAfter(@NonNull LoadParams params, @NonNull LoadCallback callback) {
    Call<SearchResult> result = mPixabayService.search(PixabayApi.api_key, "photo", (Integer)params.key, params.requestedLoadSize, true);
    result.enqueue(new Callback<SearchResult>() {
        @Override
        public void onResponse(Call<SearchResult> call, Response<SearchResult> response) {
            if (response.isSuccessful()) {
                List<Photo> hits = response.body().hits;
                callback.onResult(hits, (Integer)params.key + 1);
            }
        }

        @Override
        public void onFailure(Call<SearchResult> call, Throwable t) {

        }
    });
}

但是,我只是使用静态项目列表的适配器构建了相同的示例,并且在我的模拟器上滚动起来似乎更加流畅。我的代码中缺少什么吗?

我怀疑这可能会使情况变得更糟:

  1. 在这种情况下,recyclerview.setHasFixedSize(true)有意义吗? (我确实还注意到,当我向下滚动然后返回到原始图像时,图像的大小是不同的?有没有办法防止这种情况?)
  2. 这是因为DIFF_CALLBACK中有些奇怪吗?我实际上并不十分了解这堂课的目的
  3. 预计
  4. viewModel.getPhotosList().observe(this, adapter::submitList);会比较慢,因为它会使列表无效(与静态列表相比);但是,这是否会导致5倍的延迟??
  5. 我注意到我在仿真器上跑得很快,在静态的recyclerview上这似乎不是问题;但是,LivePage对其窜动检测是否有所不同?我猛扑时屏幕似乎发疯了。换句话说,我感觉到的“分页库性能参差不齐”是否仅是因为我上下浮动(而不是缓慢地上下滚动)?
  6. 我只是在某个地方缺少关键配置设置吗?

1 个答案:

答案 0 :(得分:3)

当然,静态列表将更平滑-开销更少。如果实际可行,那就去吧。当将整个列表保存在内存中不可行时,或者从数据源(尤其是远程数据源)请求整个列表太耗时/昂贵时,可以使用分页列表。

1)取决于您的UI。固定大小是它在屏幕上显示的大小,而不是列表的大小。通常,对于全尺寸列表或不随内容增长/缩小的列表而言,这是正确的。

2)DiffUtil及其回调与分页无关,它们已预先存在分页库。它们围绕更改列出列表,以使对适配器的最有效调用成为可能,而不是执行整个notifyDataSetChanged。但是他们确实花了一些时间。务必做到这一点很重要,否则您将错过通知或使用效率较低的通知。

3)预计会比什么慢?但是在使用可观察对象的任何地方,您都会看到速度变慢,您可能会在线程之间发布消息。这是他们很多时候被严重滥用的原因之一,人们不了解他们的实际工作。是的,降低5倍的速度似乎不太可能,尤其是如果您最终使用效率较低的notifyDataSetChanged而不是更精确的通知时。

4)猛扑时,您可以更快地装载更多物品。这可能会导致更多的远程负载。因此,如果您遇到问题,那将是您逃跑的时候。通常,您要提前足够长的时间在单独的线程上预加载,这不是问题。您尝试过使用页面大小和预取距离吗?