我有一个当用户点击它appwidget时启动的。activity
在我的活动中，我有一个gridview包含相对较小的Drawables（图像，因为可绘制可能不仅仅是图像），但用户可以size。
我注意到它需要too Long to size them at runtime when Scrolling trough the gridview.
我想在用户将 appwidget 放在屏幕上时一开始就调用它lruCache。one timeappWidget's onUpdate
问题
当我在我的 appWidget 中定义一个 lruCache 时
private final int lruCacheSize = (int) (Runtime.getRuntime().maxMemory()/1024);
private LruCache<String, BitmapDrawable> myLruCache;
...
myLruCache = new LruCache<String, BitmapDrawable>(lruCacheSize) {
@Override
protected int sizeOf(String key, BitmapDrawable value) {
// TODO Auto-generated method stub
return super.sizeOf(key, value);
}
};
只要appWidget的进程存在，它就存在吗？或者来自 lruCache 的缓存文件是否保留在我的应用程序的 cacheDir 中？还是会在appWidget的进程完成后被删除？如果它确实存在于我的 appWidget 的整个进程生命周期中，我如何从我的 Activity 中访问它？
我不想每次用户单击 appWidget 时都创建一个 LruCache 并用 gridview 稍后需要的所有相对较小的图像填充它。我想这样做一次，或者如果用户清除每小时检查一次的缓存（以节省电池）。
问题
我怎样才能做到这一点？还是有更好/更简单的方法。
时间并不是真正(if it happens once at the very beginning)的问题，我在将 appWidget 放置在屏幕上时通知用户正在准备缓存。
任何帮助表示赞赏。
关于CommonsWare回答者的更新
Use Traceview to determine specifically why your implementation is slow.
应用程序滚动很慢，因为我提供了三种尺寸（小、中、大）并且我在通过我的 gridview 滚动时缩放它们。（因为在活动启动时缩放它们需要几秒钟，所以我不想要那个）。
在这里查看我在我的图像视图中所做的事情，稍后将显示可绘制对象（这是一个 appIcon）：
android:scaleType="fitXY"
android:adjustViewBounds="true"
这会导致滞后，因为我对每个图像都执行此操作，具体取决于所选比例大小是中小还是大。
There is no "Cache-File" in your code.
那么我误解了一些东西。lruCache 不会在我的应用程序的 Cache-Directory 中创建一个 Cache-File 吗？如果不是，如何工作？
First, you cannot force the user to install the app widget. Work on solving the actual performance problem, rather than trying to build some optimization that will not help all users.
我的“应用程序”只是一个应用程序小部件。没有像 FaceBook 那样的 appIcon。当他加载我的应用程序时，它只是一个 appWidget。当您单击按钮时，它会启动一个活动。
Second, your process can readily be terminated milliseconds after onUpdate() completes. Do not fill a cache, only to have it never be used.
我想使用我想用onUpdateappWidget中的Drawables填充的缓存，然后我想在我的活动中使用缓存中的这些Drawables。所以我不明白为什么我永远不会使用缓存？也许我误解了什么。
Picasso would give you better performance from the user's standpoint.
现在更新后是否符合我的需求？
-------------------------------------------------- ------------------------------------------
更新 2
Since the scaling should be done by the GPU and take microseconds, I have difficulty believing that is your problem. What specifically did Traceview show you that made you think that scaling has something to do with this?
我注意到 Scrolling 在中等大小时非常流畅，因为这几乎是PackageManager. 如果滚动槽很大，每行只显示 2 或 3 个应用程序图标（在中等显示 5 或 6 个，但它更流畅）m 它会滞后。（其背后的逻辑相同）。因此，唯一的逻辑答案可以在 ImageView 的 XML 中进行缩放。正如我评论 XML-Scaling 并将 appIcons 缩放到大尺寸并将它们直接缩放到我的 GridView 适配器时，它运行非常流畅（一开始只有一个或非常小的滞后，因为convertView它是空的？？）
onUpdate() will be called much more frequently than the user will actually use your app widget.
那是在每次点击之后或在指定时间。但是我检查缓存是否已被清除，如果没有，请不要更改任何内容，如果是，请将 Drawables 加载到缓存中。