0

I tried searching for a clear answer but could not find it so asking it here. Apologies if this is a nOOb question.

My question is Does Android Cache the view inflation outside the scope of the activity?

I wrote a sample app in which there are 2 activities

Activity A Activity B

A just has a button that launches B. B has a fairly complex layout.

B has a view stub and I timed theViewStub inflation (that basically renders the whole layout).

When I timed how much time it takes for B's layout to inflate. First time It took roughly 100ms. Further inflations took 15-20 ms. Weird part was after few iterations, randomly B again takes 100+ ms to inflate.

I also verified that my complex activity (B) is getting destroyed and created again (as I hit back from B and launch B again from A)

I could not find anything in the Android code base which could explain me why this is happening.

Could someone please tell me where is this caching taking place.

Here are logs of the ComplexActivity onCreate and onDestroy. I am using back press to destroy the activity

04-30 13:32:09.879: I/testInflation(19298): onCreate setting up content view
04-30 13:32:09.895: I/testInflation(19298): onCreate content view set. Time took = 15 ms.
04-30 13:32:09.895: I/testInflation(19298): onCreate inflating ui
04-30 13:32:10.004: I/testInflation(19298): onCreate ui inflated. Time took = 108 ms. Total time into method = 123 ms.
04-30 13:32:12.450: I/testInflation(19298): activity destroyed
04-30 13:32:12.903: I/testInflation(19298): onCreate setting up content view
04-30 13:32:12.911: I/testInflation(19298): onCreate content view set. Time took = 13 ms.
04-30 13:32:12.911: I/testInflation(19298): onCreate inflating ui
04-30 13:32:12.926: I/testInflation(19298): onCreate ui inflated. Time took = 13 ms. Total time into method = 26 ms.
04-30 13:32:13.958: I/testInflation(19298): activity destroyed
04-30 13:32:14.379: I/testInflation(19298): onCreate setting up content view
04-30 13:32:14.395: I/testInflation(19298): onCreate content view set. Time took = 11 ms.
04-30 13:32:14.395: I/testInflation(19298): onCreate inflating ui
04-30 13:32:14.403: I/testInflation(19298): onCreate ui inflated. Time took = 11 ms. Total time into method = 22 ms.
04-30 13:32:15.223: I/testInflation(19298): activity destroyed
04-30 13:32:15.622: I/testInflation(19298): onCreate setting up content view
04-30 13:32:15.637: I/testInflation(19298): onCreate content view set. Time took = 11 ms.
04-30 13:32:15.637: I/testInflation(19298): onCreate inflating ui
04-30 13:32:15.645: I/testInflation(19298): onCreate ui inflated. Time took = 13 ms. Total time into method = 24 ms.
04-30 13:32:16.692: I/testInflation(19298): activity destroyed
04-30 13:32:17.934: I/testInflation(19298): onCreate setting up content view
04-30 13:32:17.950: I/testInflation(19298): onCreate content view set. Time took = 11 ms.
04-30 13:32:17.950: I/testInflation(19298): onCreate inflating ui
04-30 13:32:17.965: I/testInflation(19298): onCreate ui inflated. Time took = 18 ms. Total time into method = 30 ms.
04-30 13:32:19.020: I/testInflation(19298): activity destroyed
04-30 13:32:23.825: I/testInflation(19298): onCreate setting up content view
04-30 13:32:23.833: I/testInflation(19298): onCreate content view set. Time took = 12 ms.
04-30 13:32:23.833: I/testInflation(19298): onCreate inflating ui
04-30 13:32:23.848: I/testInflation(19298): onCreate ui inflated. Time took = 11 ms. Total time into method = 23 ms.
04-30 13:32:26.622: I/testInflation(19298): activity destroyed
04-30 13:32:27.145: I/testInflation(19298): onCreate setting up content view
04-30 13:32:27.161: I/testInflation(19298): onCreate content view set. Time took = 15 ms.
04-30 13:32:27.161: I/testInflation(19298): onCreate inflating ui
04-30 13:32:27.231: I/testInflation(19298): onCreate ui inflated. Time took = 69 ms. Total time into method = 85 ms.
04-30 13:32:28.200: I/testInflation(19298): activity destroyed
04-30 13:32:28.645: I/testInflation(19298): onCreate setting up content view
04-30 13:32:28.661: I/testInflation(19298): onCreate content view set. Time took = 11 ms.
04-30 13:32:28.661: I/testInflation(19298): onCreate inflating ui
04-30 13:32:28.747: I/testInflation(19298): onCreate ui inflated. Time took = 91 ms. Total time into method = 102 ms.
Robert Harvey
  • 178,213
  • 47
  • 333
  • 501
  • @Robert Thanks for fixing the logcat output. – ReadyToLearn Apr 30 '13 at 20:44
  • Android does not kill your activity when you press back, it is kept in memory until the system runs out of memory and then and only then the activity is removed. There is a way to force killing the activites everytime you press back, if you have an Android4+ device, go to Settings->Developer options-> Do not keep Activities, and make sure that is checked – Julian Suarez Apr 30 '13 at 20:45
  • @jucas is this true even when I checked Activity's onDestroy is called? – ReadyToLearn Apr 30 '13 at 20:46
  • AFAIK it didn't in 4.0 Android destroys layout and recreate it again when phone rotated from portrait to landscape. When you press back button activity pulled out of stack of activities and garbage collected, when you run B activity again it will be 100% recreated. OS built with the thought in mind that RAM is limited and apps can be ran on any compatible device. – Maxim Apr 30 '13 at 20:48
  • @jucas also just now I tried making sure I am not keeping the activity , still seeing the same behavior – ReadyToLearn Apr 30 '13 at 20:49
  • Sorry I should have mentioned. I am running the app on API15 (4.0.3) – ReadyToLearn Apr 30 '13 at 20:50
  • yes even though you receive the onDestroy(), it is just a signal for the system telling it that it is ok to remove the activity from memory but the user might come back to that activity so it is kept in memory to allow fast app switching @Maxim the activity is indeed removed from the stack of activites but it is not garbage collected right away – Julian Suarez Apr 30 '13 at 20:53
  • @jucas when activity out of activity stack it will be re-created when called again, because onDestroy() has been called. It won't be recreated when was paused. – Maxim Apr 30 '13 at 20:56

1 Answers1

0

android:launchMode An instruction on how the activity should be launched. There are four modes that work in conjunction with activity flags (FLAG_ACTIVITY_* constants) in Intent objects to determine what should happen when the activity is called upon to handle an intent. They are:

"standard"

"singleTop"

"singleTask"

"singleInstance"

The default mode is "standard".

with "standard" and "singleTop" activities on one side, and "singleTask" and "singleInstance" activities on the other. An activity with the "standard" or "singleTop" launch mode can be instantiated multiple times. The instances can belong to any task and can be located anywhere in the activity stack. Typically, they're launched into the task that called startActivity() (unless the Intent object contains a FLAG_ACTIVITY_NEW_TASK instruction, in which case a different task is chosen — see the taskAffinity attribute).

In contrast, "singleTask" and "singleInstance" activities can only begin a task. They are always at the root of the activity stack. Moreover, the device can hold only one instance of the activity at a time — only one such task.

So by default it is standard , than it will use the activity from backstack . Read about android Activity stack . and when activity is coming from back stack and all. It's taking less time when u again launch the activity , because it has lot many objects in heap

As per this documents , when activity is poped from the stack ... it's going to be destroyed.http://developer.android.com/guide/components/tasks-and-back-stack.html

But your activity taking different time when u launch it. That is because system's garbage collector runs at some period of time and clears the allocated memory to object. So After starting Activity A , you are going in ACtivity B.Now you are pressing back button :-that means Activity B is going to be pop out of stack and will be destroyed soon.But you are starting that activity before garbage collector runs .That's why it's taking less time

Do one thing , run System.gc() at on destroy ....or write finish() in onPause() ...ur Activity will take almost same time to inflate layout.

Pranav Jadav
  • 763
  • 5
  • 11
  • Isn't the activity gone when destroyed. There is no back stack at that point. A->B->(back, resulting in destroying and throwing B away)->A – ReadyToLearn Apr 30 '13 at 21:04
  • I printed the "this" pointer of the activity and it always gave me the new activity whenever i launched the activity again. – ReadyToLearn Apr 30 '13 at 23:51
  • Actually thing is that , when u start B activity from Activity A..it will start activity B and Activity A will be in the backstack . In this case if u press back button than Activity B will be destroy and the previous activity of the stack (which is Activity A) will come to front . This time it will call the onRestart() method of the Activity A. – Pranav Jadav May 01 '13 at 15:51
  • My main concern is not Activity A. It's activity B (complex activity) that I have question for. So my question is why views are inflated faster the next time activity B is created – ReadyToLearn May 01 '13 at 16:31
  • The activity created next time is always new. Still I specifically called System.gc() and verified that the dalvik freed up memory. But next time launch of the complex activity is still fast (20ms) as against 100+ ms. Also it's not the activity launch, it's more about the view being inflated faster (although these maybe related) – ReadyToLearn May 01 '13 at 21:01
  • I think we are moving away from the topic. My question was for a A simple/standard activity and not singleInstance. I'll try your suggestion. I want to understand why the things are faster the next time as compared to first launch of the activity. – ReadyToLearn May 01 '13 at 22:33
  • Have tested with calling finish() on onPause. No effect. I don't think I wanna make this activity single instance and it changes the whole question. – ReadyToLearn May 01 '13 at 23:43
  • So could you please tell me what could be going on with normal activity re-inflations? – ReadyToLearn May 02 '13 at 04:42