Hey. I noticed an unpleasant thing - a very slow reaction to a button that opens a new activation. It seemed to me that somewhere half a second, and when measured, it turned out from 0.5 for an empty form to 5 seconds for a window saturated with elements!

For accuracy, I turned off the animations in the system through the menu for developers. Here is what came out for the form with four buttons:

  • + 150ms - touch and first call onUserIteraction - startActivity (intent);
  • + 200ms - command - onPause of the current activation.
  • + 100ms - onPause - start onCreate of the next activation.
  • + 200ms - the duration of super.onCreate ()
  • + 100ms - the duration of setContentView ().
  • + 80ms - setContentView - onAttachedToWindow - this happens when everything is formed, filled, drawn and transferred to the system.

  • + 1150ms - onAttachedToWindow - onStop ()

    2s - GENERAL TIME!

If you load the form stronger, then at some point the screen is just black for a while.

My only idea is that while the current form is shown, create all of the following in the background, so that they are ready and stopped in RAM so that they can only edit the field data and start, and visually they opened immediately, without friezes and black screens. Is it possible

  • And what happens in activations, any calculations? Can you show the screen? (just wondering) - gil9red
  • android does not create other "forms" in advance, as long as they are not in the foreground - pavlofff
  • No, I created a simple test application. There is nothing to show - just a button causing the next activation. In between, only System.currentTimeMillis () occurs, recording and sending to extar only time in the long variable. - Eugene
  • @pavlofff, what if there is only one 600MHz core? Waiting for real filled activations is simply not a long one. It is even necessary to postpone any activity in the background until the called activity becomes available to the user, it takes up to 5 seconds. - Eugene
  • Absolutely correct strategy. At the start, do a minimum, then, after appearing before the user, load the data and initialize the elements. Take the profiler and see who ate the processor. - tse

1 answer 1

First, you need to deal with overlays - each unwanted overlay of elements on each other slows down the application. The phone draws something that is not visible to the eye and spends resources on it. For example, you say that you have 4re buttons, if it is an ImageButton and they close the message screen, then the background is not visible, so that the phone does not load it enough to write in the class of this activity:

getWindow().setBackgroundDrawable(null);

In the layout layout, make sure that you do not set an extra background. Also, if you have an ImageButton, then the installation of images is best done from the class using the Picasso or Glide libraries. In my opinion glide copes better with the task.