因此,我正在使用Glide加载视频缩略图,但是加载大量视频需要花费一些时间才能查看,这是在用户手机中加载每个视频缩略图的视频列表的最佳/最快方法,在“回收者”视图中。
填充列表
public static ArrayList<String> getAllMedia(Context context) {
HashSet<String> videoItemHashSet = new HashSet<>();
String[] projection = { MediaStore.Video.VideoColumns.DATA ,MediaStore.Video.Media.DISPLAY_NAME};
Cursor cursor = context.getContentResolver().query(MediaStore.Video.Media.EXTERNAL_CONTENT_URI, projection, null, null, null);
try {
cursor.moveToFirst();
do{
videoItemHashSet.add((cursor.getString(cursor.getColumnIndexOrThrow(MediaStore.Video.Media.DATA))));
}while(cursor.moveToNext());
cursor.close();
} catch (Exception e) {
e.printStackTrace();
}
ArrayList<String> downloadedList = new ArrayList<>(videoItemHashSet);
return downloadedList;
}
滑行方法
public static void displayImageOriginal(Context ctx, ImageView img, String url) {
try {
Glide.with(ctx).load(url)
.transition(DrawableTransitionOptions.withCrossFade())
.apply(RequestOptions.centerCropTransform().skipMemoryCache(false).diskCacheStrategy(DiskCacheStrategy.ALL))
.into(img);
} catch (Exception e) {
}
}
这是Binder适配器视图
@Override
public void onBindViewHolder(RecyclerView.ViewHolder holder, final int position) {
final YVideos obj = items.get(position);
if (holder instanceof OriginalViewHolder) {
OriginalViewHolder view = (OriginalViewHolder) holder;
view.video_title.setText(obj.title);
view.duration_size.setText(obj.getDurSize());
Tools.displayImageOriginal(ctx, view.video_thumbnail, obj.name);
} else {
SectionViewHolder view = (SectionViewHolder) holder;
view.title_section.setText(obj.title);
}
}
答案 0 :(得分:0)
这一切看起来都像是标准的RecyclerView
用法,因此,如果您的适配器是单独分配给RecyclerView
的,即没有定义任何限制性能的属性,例如setItemViewCacheSize()
,{{ 1}}等,您的问题不太可能是客户端的问题。
您是否依靠setMaxRecycledViews()
在运行时为您生成缩略图?如果是这样,您将真正通过大量处理使图书馆步入正轨,因为它必须实时处理原始质量,原始分辨率的视频。事先无法生成缩略图吗?这些将加快加载速度,并使您的应用程序免于进行大量计算。如果缩略图将永远保持不变,那为什么不一次计算缩略图并让每个用户受益,而不是让每个用户每次希望渲染时都获得相同的结果?
对我来说,您的问题很可能是由于您希望获取图像并在用户已经在查看内容的同时将其呈现给用户。这意味着您加载了屏幕,并调用了Glide
,并尝试从网络中获取图像;但在此阶段,用户已经在查看列表并准备浏览。在某种程度上,您来得太晚了,onBindViewHolder()
的速度将仅与网络连接/图像服务器一样快。
您可以做的是在尝试绘制List
之前准备图像缓存。在到达该屏幕之前,您知道要渲染的图像范围是多少?您甚至可以在准备绘画之前将它们RecyclerView
load
中定义一个合适的Glide
。这样,您可以在用户查看时初始化内容的diskStrategy
。预测图像缓存策略不会在这里结束。您知道接下来准备加载哪些行的图像;因此您也可以在后台获取它们。这种方法的缺点是,它有可能浪费大量带宽来获取用户可能永远无法滚动到的图像。因此您可能需要尝试请求速率限制。
还有一些更简便的方法可以解决此问题。即使是资金最雄厚,研究最深入的应用程序,也都依靠简单的技巧来解决网络性能的瓶颈...您是否考虑过使用placeholder animation来保持应用程序的运行状态?这些功能的效果会令人惊讶!