If you have a fragment that holds on to a lot of memory in its view hierarchy and are concerned about this, then use FragmentTransaction.remove() to make it no longer visible -- that will remove it from its parent view and destroy its view hierarchy, so it doesn't hold on to any references. (If you are manually loading bitmaps in the fragment, in onDestroyView() you can clear the references there.) Of course this means a bit more overhead when the user returns to the fragment, since its view hierarchy needs to be re-inflated and initialized again. But it won't be any worse than the first time the user visited it, and you need that to be fast as well.
It is true that FragmentTransaction.hide() does not remove and the destroy the fragment's view hierarchy, just doing View.setVisibility(). But that is not all -- it takes care of managing the fragment lifecycle so that fragment will be paused and stopped (since it is no longer visible). You can implement the lifecycle to free up resources if you need to. This will also result in them being freed when the entire activity is stopped, which is probably what you want as well. You shouldn't be directly hiding the view associated with a fragment. That is what FragmentTransaction.hide/show() is for. There is no need to directly hide the view owned by it, and doing so means that you are letting the correct fragment semantics execute. (And for what it's worth, if you have no reason to use fragments with ViewPager, there is nothing forcing you to -- you can write your own adapter that directly manages raw views and doesn't use fragments at all.) On Sat, Jul 28, 2012 at 1:45 PM, Dmitriy F <[email protected]> wrote: > Thanks for the answers! Would you mind to suggest on the part about > fragments, bitmaps and memory management ? I decided to implement the app > with 3 activities and about 8 fragments. The fragment number might slightly > increase yet I think it's not the fragments but their bitmaps that gonna > cause troubles with memory. > > For displaying the fragments I have two containers: a ViewPager(rotates > 3-4 fragments) element and a FrameLayout(displays strictly one fragment) > element. Right now I'm simply hiding one type of container and showing > another - setVisibility or fragmentTransaction.hide (I haven't figured out > what is the difference between these two apart from the latest gives an > ability of adding to activity's backstack). Is their any better way of > switching between the containers ? > > Additionally, even if those fragments might not hold much memory by > themselves - should I wrap those objects with SoftReference ? > > Could you tell any precautions/advices for implementing an app with such > structure ? Thanks. > > > On Saturday, July 28, 2012 9:36:27 PM UTC+3, Romain Guy (Google) wrote: > >> 1) Does ImageView.SetImageResource applied against the same id twice or >>> thrice consumes memory for the same bitmap or uses a separate range for >>> every imageview element ? >>> >> >> I don't quite understand your question. When a Bitmap is loaded as a >> Drawable (which is what ImageView does), it gets cached by the system >> (using weak references.) This means that if do this: >> >> Drawable d1 = loadDrawable(R.drawable.**myImage); >> Drawable d2 = loadDrawable(R.drawable.**myImage); >> >> you will get 2 different instances of Drawable, but the underlying Bitmap >> will be loaded in memory only once. >> >> 2) same as 1. but for BitmapFactory.decodeResource >>> >> >> Every time you call this method you will load a new instance of a Bitmap >> object, which means you will use more memory. >> >> >>> 3) What part of Bitmap object consumes the most memory. If it's >>> "backbone memory object" than what is it ? Where can I elucidate the >>> structure of bitmap memory for myself ? >>> >> >> A Bitmap is backed by a byte array containing all the pixels. This is >> what consumes the most memory. As of Android 3.0, this byte array can be >> found in Bitmap.java, in previous versions of the platform the pixel >> storage exists on the native side (you'd have to investigate SkBitmap.cpp.) >> >> -- >> Romain Guy >> Android framework engineer >> [email protected] >> >> -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
