I've written a simple test where I have: FragmentManager fm = getSupportFragmentManager(); FragmentTransaction ft = fm.beginTransaction(); ft.hide(_sv); ft.commit(); When the fragment gets hidden - onPause doesn't get fired. However, system fires a chain of callbacks up to onDestroyView when I use a replace method. So, I guess, I should be performing memory-recycling operations in onDestroyView method.
I've also noticed that when I hide the ViewPager component with setVisibility(GONE) its' fragments dont fire onPause callback. Is there any workaround to tell all the fragments inside the ViewPager to clean themselves with onDestroyView ? I still think I should use fragments since in a Tablet version those pages are implemented as tabs. Thanks again and I was wondering whether you could point out or give some links on implementing the memory management process. I have a lousy knoweledge about WeakReferences, recycle(), System.gc() features but I guess they are somewhat mutually-excluding. Probably, I should stick to Weak/Soft references approach, should I ? If so - could you share some insights/give link on the whole process of instantiating bitmap down to the recycling. On Sunday, July 29, 2012 12:28:08 AM UTC+3, Dianne Hackborn wrote: > > 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
