【问题标题】:Tips to speed up Gallery widget in Android Honeycomb在 Android Honeycomb 中加速 Gallery 小部件的提示
【发布时间】:2011-08-06 22:55:34
【问题描述】:

我正在寻找一种在 Android Honeycomb 中加速图库视图小部件的好方法。我目前正在使用它来显示一些大约 340 x 600 像素的相当大的图像,我希望它在滚动图像时像黄油一样光滑。

目前它相当快,但它无法与加载带有 ImageViews 的 ScrollView 并滚动浏览相比。

这是我的自定义 BaseAdapter 中 getView() 方法的简化版本:

        public View getView(int position, View convertView, ViewGroup parent) {

        if (convertView == null) {
            convertView = (ImageView) new ImageView(Main.this);
        }

        BitmapFactory.Options options = new BitmapFactory.Options();
        options.inPurgeable = true;

        ((ImageView) convertView).setImageBitmap(createReflection(BitmapFactory.decodeFile(ImageFile, options)));

        convertView.setPadding(20, 0, 20, 0);

        return convertView;
    }

我一直在尝试延迟加载图像,但我不太喜欢这个结果。

【问题讨论】:

  • 当您运行 Traceview 以衡量性能问题所在时,它显示了什么?
  • 我很想告诉你,但我无法让 Traceview 在 Eclipse 中工作:(
  • 我现在开始工作了。 Traceview 表示每次调用 getView() 需要 52 毫秒,其中 46 到 48 毫秒用于解码图像。请注意,这是在 1.2 GHz 而不是标准 1.0 GHz 的超频平板电脑上运行的,所以我预计默认时钟速度会慢一些。

标签: android widget gallery android-3.0-honeycomb galleryview


【解决方案1】:

使用Gallery 和:

使用 ImageViews 加载 ScrollView 并在其中滚动

ScrollView 场景中,您是在预加载所有图像,而不是像在Gallery 场景中那样动态加载它们。

如果您的图片数量很少,并且您有足够的 RAM 来支持所有图片,那么只需使用您的 ScrollView

除此之外,AFAIK 您无能为力。您可以维护一个位图缓存,您可以在其中继续解码Gallery 中当前图像之前的一些图像,并让您的Adapter 从缓存中提取。然而,这只会让你走这么远——小卷轴会很流畅,但是超过你的缓存容量仍然会导致解码是按需完成的。这几乎是不可避免的。

【讨论】:

  • 是的,我有点期待这个答案。问题是我无法确定显示了多少 ImageView - 它可能在几到几千之间,所以我根本无法预加载它们。这就是我在我的应用程序的初始版本中所做的,但它导致了一些人的 OOM 错误,因为他们显示了更多的图像(我正在开发一个电影管理应用程序,其中每张图像都是电影的封面艺术 - 查看市场上的 Mizuu 电影进行视觉解释)。我一直在想我可以在滚动过程中加载较小的图像,但我真的不知道
  • 您可以尝试创建图像的并行低分辨率再现并尝试提前对它们进行解码,将它们用作延迟加载的占位符而不是某些静态占位符。 Android 可以拉伸低分辨率图像——这或多或少是您在放大 Google 地图图块时获得的效果。您甚至可以尝试使用模糊效果,这样放大后的低分辨率图像看起来不会那么像素化。如果您可以将低分辨率文件的大小保持在 ~1K,那么您可能可以加载数千个。请注意,我只是在这里集思广益,从未尝试过这种技术...... :-)
  • 非常感谢,CW。我可能会再给懒加载一次 - 干杯! :)
【解决方案2】:

Gallery 目前不支持 convertView。对于 convertView,您将始终收到 null。这是一个已知问题,没有 ETA 可修复。

【讨论】:

  • 是否有计划实际添加 Horizo​​ntalListView 而不是 Gallery?无论如何似乎大多数人都想要:)
  • 暂时没有这样的计划。这几乎就是画廊已经是什么。
  • 我明白了。非常感谢您的解释,罗曼。我希望它会尽快修复。
  • 就像我说的,没有预计到达时间。该修复不会成为 ICS 的一部分。
【解决方案3】:

打开应用程序的硬件加速会产生重大影响(至少在我的示例应用程序中是这样)。

在您的 android 清单的应用程序元素中添加 android:hardwareAccelerated="true" http://developer.android.com/guide/topics/manifest/application-element.html#hwaccel

【讨论】:

  • 启用了硬件加速,但是,这确实加快了速度,尤其是在处理大型位图时。
【解决方案4】:

文件 IO 是减慢您的图库视图的因素之一。 我正在开发一个幻灯片应用程序,我有 1280x720 分辨率的照片。 每个文件的实际文件 I/O 需要 300-400 毫秒。

由于文件 I/O 通常在 UI 线程上运行,这将在任何正在进行的照片转换中导致非常明显的“hick”。

为了避免这种情况,您应该:

  1. 设置一个已经缓存的临时加载drawable imageView.setImageResource(R.drawable.my_loading_drawable);
  2. 创建一个 AsyncTask
    • 在doInBackground(即文件I/O)中加载drawable
    • 更新 onPostExecute 中的 imageView imageView.setImageDrawable(drawable);

PS 如果用户浏览多张图片,上述方法通常会触发多个并行异步任务,这些任务都将使用文件 I/O。对性能不利,可能会使您的应用程序崩溃。您可能应该采用更结构化的方法,一次只允许一个异步任务。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-03-24
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-08-20
    • 2018-10-09
    相关资源
    最近更新 更多