Your application should be able to restart at any time without loss of user data or state in order to handle events such as configuration changes or when the user receives an incoming phone call and then returns to your application much later after your application process may have been destroyed.
Por padrão, quando alguma configuração, como por exemplo posição da tela ou mudança do idioma do sistema, é modificada, a activity passa pelo ciclo de vida rumo a destruição e logo em seguido é recriada pelo Android. Então, em uma rotação do dispositivo e consequentemente a configuração da posição da tela se modificando, a activity é destruida e recriada.
Esse assunto é importante e tenho vivenciado sua importância principalmente em aplicativos que possuem uma grande necessidade de comunicação com um webservice. Por exemplo, imagine em uma Activity que realiza uma busca de produtos em um grande banco de dados através de um webservice e os liste. Agora imagine que toda vez que o usuário rotacionar a tela essa busca acabe sendo refeita. Isso seria uma péssima experiência para o usuário!
A própria documentação do Android indica o problema de recriar Activities que realizem grandes processamentos:
If restarting your activity requires that you recover large sets of data, re-establish a network connection, or perform other intensive operations, then a full restart due to a configuration change might be a slow user experience.
Saved Instance State
A primeira maneira de se combater essa situação é deixar que a activity seja recriada, porém, evitar que os dados sejam novamente buscados, salvando os dados como um estado da Activity.
O método onSaveInstanceState() da classe Activity tem o papel de guardar em formado de objeto Bundle o estado de uma activity quando ela é em seu clico de vida passa pelo “pause” ou “stop”, o que atende a sua recriação Então, todos os produtos carregados do webservice podem ser salvos em uma instância de Bundle no método onSaveInstanceState() e capturados no método onRestoreInstaceState() também da Activity após a sua destruição e recriação, sem que o webservice seja requisitado.
To properly handle a restart, it is important that your activity restores its previous state through the normal Activity lifecycle, in which Android calls
onSaveInstanceState()before it destroys your activity so that you can save data about the application state. You can then restore the state duringonCreate()oronRestoreInstanceState().
android:configChanges
If your application doesn’t need to update resources during a specific configuration change and you have a performance limitation that requires you to avoid the activity restart, then you can declare that your activity handles the configuration change itself, which prevents the system from restarting your activity.
Se sua activity precise de um maior esforço em questão de performance e nem mesmo a recriação é desejada mesmo com os estados salvos, é possível usar o atributo android:configChanges da tag no AndroidManifest.xml.
activity android:configChanges="VALUE" ...
Lists configuration changes that the activity will handle itself. When a configuration change occurs at runtime, the activity is shut down and restarted by default, but declaring a configuration with this attribute will prevent the activity from being restarted. Instead, the activity remains running and its
method is called.onConfigurationChanged()
A activity relacionada a tag não será recriada se a configuração informada como valor a esse atributo for modificada, como por exemplo, se informarmos o valor “orientation” a activity não será destruída e recriada caso realizemos rotação no dispositivo e a orientação da tela mude.
Ao invés de ser automaticamente destruída e recriada pelo próprio Android, o método onConfigurationChanged() da Activity é invocado e nele poderemos realizar as adaptações da activity a mudança de configurações essenciais e manter o que desejamos.
Note: Using this attribute should be avoided and used only as a last resort. Please read Handling Runtime Changes for more information about how to properly handle a restart due to a configuration change.
Como diz a documentação, lembre-se que esse meio deve ser usado como último recurso, quando sua activity precise de um grande enfoque em performance, já que grandes complicações podem ser trazidas e um maior trabalho nas mãos dos desenvolvedores para que a aplicação não perca a sintonia com as mudanças de configurações.
Referência:
http://developer.android.com/guide/topics/resources/runtime-changes.html
Tássio Auad 