在Appwidget中準備LruCache

我有一個appwidget，當用戶點擊它時，它會啓動一個activity。在Appwidget中準備LruCache

在我的活動中，我有一個gridview包含相對較小的Drawables（圖像，因爲繪製可能不僅僅是圖像），但用戶可以size他們。

我注意到，它需要too Long to size them at runtime when Scrolling trough the gridview.

我要準備一個lruCache只one time我appWidget's onUpdate這是在最開始的時候用戶放置在屏幕上的appwidget調用。

問題

當我在appWidget與

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); 
      } 
     };

它只會存在，只要過程定義lruCache存在appWidget的？或者，來自lruCache的緩存文件保留在我的應用程序的cacheDir中？或者在appWidget完成後刪除它？如果它確實存在於我的appWidget的進程生命週期中，我如何從我的活動訪問它？

我不想在appWidget一個LruCache創建每次用戶點擊，並與所有的較小的圖像在GridView以後需要填補它。我想這樣做一次，或者如果用戶清除將每小時檢查一次的緩存（以節省電池）。

問題

我怎樣才能做到這一點？還是有一個更好/更簡單的方法。

時間並不是真的(if it happens once at the very beginning)問題，我通知用戶在將appWidget放在屏幕上時正在準備緩存。

任何幫助表示讚賞。

更新關於CommonsWare的answere

Use Traceview to determine specifically why your implementation is slow.

的應用滾動很慢，因爲我提供三種尺寸（小，中，大），我在同時滾動槽我的gridview的縮放它們。（因爲它在活動啓動時需要幾秒鐘的時間來縮放它們，所以我不想那樣）。

在這裏看到我在我的ImageView稍後顯示的繪製（這是一個APPICON）做：

android:scaleType="fitXY" 
    android:adjustViewBounds="true"

這將導致延遲，因爲我這樣做了everyimage取決於如果選擇規模大小小中或大。

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.

我的「應用程序」只是一個appwidget。在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.

我想用我想在appWidget的onUpdate，以填補與可繪製的緩存，然後我想使用從Cache這些可繪製在我的活動。所以我不明白爲什麼我永遠不會使用緩存？也許我誤解了一些東西。

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?

我注意到，滾動處於中等大小非常流暢的，因爲這是幾乎從PackageManager的APPICON的起源大小。如果滾動槽大，其中每行僅顯示2或3個appIcons（在中等的情況下顯示5或6，但它更流暢）。（具有相同的邏輯）。因此，唯一的邏輯回答可以在ImageView中的XML中進行縮放。正如我評論說，XML擴展和縮放appIcons的大小大，並把它們直接調到我的適配器的GridView它運行非常順利（只有一個或非常小的滯後在開始，因爲convertView爲空??）

onUpdate() will be called much more frequently than the user will actually use your app widget.

這是在每次onclick或在指定的時間。但我檢查緩存是否已被清除，如果不是，請不要更改任何內容，如果是的話將Drawables加載到緩存。

來源

2014-12-20 MMike

-1

我注意到當滾動Gridview的時候，在運行時調整它們的長度太長。

使用Traceview來確定爲什麼你的實現速度慢。

它只存在，只要進程存在appWidget？

它只會存在於您的應用程序的整個生命週期中。

或者，來自lruCache的緩存文件是否保留在我的應用程序的cacheDir中？

代碼中沒有「緩存文件」。

我不想每次創建用戶都點擊appWidget一個LruCache，然後填充GridView稍後需要的所有相對較小的圖像。我想這樣做一次，或者如果用戶清除將每小時檢查一次的緩存（以節省電池）。

首先，您不能強制用戶安裝應用程序窗口小部件。致力於解決實際的性能問題，而不是嘗試構建一些無法幫助所有用戶的優化。

其次，您的過程可以在onUpdate()完成後立即終止毫秒。不要填充緩存，只能讓它永遠不會被使用。

還是有更好/更簡單的方法。

使用Traceview確定確切地說您的問題在哪裏。然後，解決這個問題。例如，問題可能是您將這些圖像加載到主應用程序線程中，並且使用像畢加索這樣的庫會從用戶的角度給您提供更好的性能。

的應用滾動很慢，因爲我提供三種尺寸（小，中，大），我在同時滾動槽我的GridView

因爲縮放應該由做大規模推廣GPU和微秒，我很難相信這是你的問題。 Traceview告訴你什麼特別讓你覺得縮放與此有關？

lruCache不在我的應用程序的緩存目錄中創建緩存文件嗎？

號

如果作品不是如何呢？

這是一個內存中緩存。

所以我不明白爲什麼我永遠不會使用緩存？

onUpdate()將被稱爲多更頻繁地比用戶將實際使用你的應用插件。

來源

2014-12-20 14:59:54 CommonsWare

感謝您對CommonsWare的支持。我已經更新了關於你的回答的問題。請參閱更新。 – MMike

@MMike：查看更新的答案。 – CommonsWare

再次感謝您的時間CommonsWare，我再次更新了我的問題。我們越來越接近問題及其解決方案。 – MMike

在Appwidget中準備LruCache

回答

相關問題