实施全球LruCache VS许多当地LruCaches [英] Implementing a global LruCache vs many local LruCaches
问题描述
若干活动在我的应用程序，显示图像的的ListView 其中的的ImageView 。
这方面的一个例子是一个搜索屏幕，其中用户的搜索时，获取的结果，和每个结果的照片示出。
我试图权衡实施全球性的成本/效益 LruCache VS是每一个活动遏制其自己的本地 LruCache 。
下面是我的两个主要问题。周围的事实，我的应用程序是相当大的，这意味着有三个可显示这些图像相当多屏两种运转。此外，我的应用程序具有导航的流行侧面菜单的方式。这是因为，我可以打开菜单，点击 b活动，打开菜单，点击活动A ，打开菜单...等，并ABABABABABABABAB的创建一个活动堆下去。
全球
不会活动 s的的ImageView S使用位图 - 从全球 LruCache 包含对这些位图？假设用户通过点击某些按钮导航远离这个活动。这活动是现在的活动堆栈和仍持有提到那些位图。如果 LruCache 弹出一个位图关闭，可以在位图真正被回收时的ImageView 在某些活动在堆栈上持有对它的引用？
我有previously创建了自己的自定义缓存。如果我叫循环（）在位图键，然后将用户击中背部按钮返回到一些活动包含一个的ImageView 设置为位图在栈中，该应用程序会崩溃。这就是为什么我相信的ImageView S上活动堆栈仍持有引用在S位图秒。
本地
正如我前面提到的。我的应用程序是相当大的，和导航的侧面菜单样式，用户可以创造相当大的活动栈。这将创造大量 LruCache 取值。而且，由于你必须声明的大小 LruCache 当你初始化，就似乎没有采摘的大小没有什么好办法。
思考？建议？
在这一点上，我认为我必须做全球性的，但我不知道如何解决活动堆栈引用问题。我无法想象这是没有问题的许多应用程序都没有碰到。我不知道为什么我没有找到关于它的信息。
我试图权衡实施全球性的成本/效益 LruCache VS让每个活动包含它自己的本地LruCache。
全球LruCache是继续前进，因为同组的位图可能在不同的活动实例被称为的方式。该LruCache可以定义的应用程序一部分。如果活动栈可以承载相同的活动（如ABABABAB ..）的多个实例，然后在活动创造一个LruCache本地将是一个坏主意。很快，内存situtation将达到，为LruCache在每个活动实例保留在Dalvik虚拟机定义的内存量。假设，应用程序的内存为32MB，你决定LruCache大小为4Mb的，即1/8。现在，当我们创建活动A的近7实例，那么内存消耗会去7 * 4 = 28MB，这本身可能触发OOM。
不会使用位图从全球LruCache ImageViews Activitys 包含对这些位图？
是的ImageView也有很强的参照位。如果参考被保持在LruCache，然后引用计数为2的那一刻。
如果该LruCache弹出一个位图了，可以说位图真的被收回 当在堆栈上的一些活动的ImageView的持有参考 它？
没有位图的内存无法被回收，因为还存在一些ImageView的是有很强的参考吧。
在这一点上，我认为我必须做全球性的，但我不知道该怎么 解决了活动堆栈引用问题。
LruCache主要作用是保持强引用这些经常使用的位图。所以，如果有任何的ImageView未持有强引用，位图是被垃圾收集pvented $ P $。
还记得，为Android 2.3.3及更低版本中，您需要实现引用计数机制，以回收位图。
Several Activitys in my app display images in a ListView where each row of the ListView contains an ImageView.
An example of this would be a search screen where the user searches, gets results, and a picture of each result is shown.
I'm trying to weigh the cost/benefits of implementing a global LruCache vs having each Activity contain its own local LruCache.
Here are my two main problems. Both revolve around the fact that my app is quite large, meaning there are quite a few screens which show these images. Also, my app has the popular side menu way of navigating. Because of this, I could open the menu, tap Activity B, open the menu, tap Activity A, open the menu... etc. and create an Activity stack of ABABABABABABABAB indefinitely.
Global
Won't Activitys with ImageViews using Bitmaps from a global LruCache contain references to these Bitmaps? Suppose the user navigates away from this Activity by clicking some Button. That Activity is now on the Activity stack and still holds references to those Bitmaps. If the LruCache pops a Bitmap off, can that Bitmap really be reclaimed when an ImageView in some Activity on the stack holds a reference to it?
I had previously created my own custom cache. If I called recycle() on a Bitmap and then the user hit the back button to go back to some Activity on the stack that contained an ImageView set to that Bitmap, the app would crash. This is why I believe ImageViews on Activitys on the stack still hold references to Bitmaps.
Local
As I mentioned earlier. My app is quite large, and side menu style of navigation allows the user to create rather large Activity stacks. This would create a lot of LruCaches. And, since you have to declare the size of the LruCache when you initialize it, there wouldn't seem to be any good way of picking a size.
Thoughts? Suggestions?
At this point I think I have to do global, but I don't know how to solve the Activity stack reference problem. I can't imagine this isn't a problem many apps haven't run into. I don't know why I'm not finding information about it.
I'm trying to weigh the cost/benefits of implementing a global LruCache vs having each Activity contain its own local LruCache.
Global LruCache is the way to move forward, since the same set of bitmaps might be referred in different activity instances. The LruCache can be defined part of Application. If the activity stack can host multiple instances of the same activity (like ABABABAB..), then creating a LruCache locally in that activity will be a bad idea. Very soon Out Of Memory situtation will be reached, as LruCache in each activity instance reserves the defined amount of memory in Dalvik VM. Assume, application memory is 32Mb and you decide LruCache size as 4Mb i.e. 1/8th. Now when we create nearly 7 instances of Activity A, then memory consumption will go to 7*4=28Mb, that itself might trigger OOM.
Won't Activitys with ImageViews using Bitmaps from a global LruCache contain references to these Bitmaps?
Yes ImageView will also have a strong reference to the bitmap. If the reference is maintained in LruCache, then the reference count will be 2 at that moment.
If the LruCache pops a Bitmap off, can that Bitmap really be reclaimed when an ImageView in some Activity on the stack holds a reference to it?
No the bitmap memory can't be reclaimed, as still some ImageView is have a strong reference to it.
At this point I think I have to do global, but I don't know how to solve the Activity stack reference problem.
LruCache main role is holding strong reference to the bitmap which are more frequently used. So that if there is no strong reference held by any ImageView, the bitmap is prevented from being garbage collected.
Also remember, for Android 2.3.3 and lower versions, you need to implement reference counting mechanism, in order to recycle the bitmaps.
这篇关于实施全球LruCache VS许多当地LruCaches的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
