guide/components/processes-and-threads.jd

page.title=Processos e encadeamentos
page.tags=lifecycle,background

@jd:body

<div id="qv-wrapper">
<div id="qv">

<h2>Neste documento</h2>
<ol>
<li><a href="#Processes">Processos</a>
  <ol>
    <li><a href="#Lifecycle">Ciclo de vida dos processos</a></li>
  </ol>
</li>
<li><a href="#Threads">Encadeamentos</a>
  <ol>
    <li><a href="#WorkerThreads">Encadeamentos de trabalho</a></li>
    <li><a href="#ThreadSafe">Mtodos seguros de encadeamento</a></li>
  </ol>
</li>
<li><a href="#IPC">Comunicao entre processos</a></li>
</ol>

</div>
</div>

<p>Quando um componente de aplicativo inicia e o aplicativo no tem nenhum outro componente em execuo,
o sistema Android inicia um novo processo no Linux para o aplicativo com um nico encadeamento
de execuo. Por padro, todos os componentes do mesmo aplicativo so executados no mesmo processo
e encadeamento (chamado de encadeamento "principal"). Se um componente de aplicativo iniciar e j existir um processo
para este aplicativo (pois outro componente do aplicativo j existe), ele ser iniciado
dentro deste processo e usar o mesmo encadeamento de execuo. No entanto,  possvel organizar para que vrios componentes
no aplicativo sejam executados em processos separados e criar encadeamentos
adicionais para qualquer processo.</p>

<p>Este documento discute como os processos e os encadeamentos funcionam em um aplicativo do Android.</p>


<h2 id="Processes">Processos</h2>

<p>Por padro, todos os componentes do mesmo aplicativo so executados no mesmo processo
e a maioria dos aplicativos no deve alterar isso. No entanto, se achar que precisa de controle sobre o processo a que um certo
componente pertence,  possvel fazer isto no arquivo de manifesto.</p>

<p>A entrada do manifesto para cada tipo de elemento de componente &mdash; <a href="{@docRoot}guide/topics/manifest/activity-element.html">{@code
&lt;activity&gt;}</a>, <a href="{@docRoot}guide/topics/manifest/service-element.html">{@code
&lt;service&gt;}</a>, <a href="{@docRoot}guide/topics/manifest/receiver-element.html">{@code
&lt;receiver&gt;}</a> e <a href="{@docRoot}guide/topics/manifest/provider-element.html">{@code
&lt;provider&gt;}</a> &mdash;  compatvel com um atributo {@code android:process} que pode especificar
um processo em que este componente dever ser executado.  possvel definir este atributo para que cada componente
seja executado em seu prprio processo ou para que alguns componentes compartilhem um processo, enquanto que outros no.  Tambm  possvel definir
{@code android:process} para que os componentes de aplicativos diferentes sejam executados no mesmo
processo &mdash; fornecido para que os aplicativos compartilhem o mesmo ID de usurio do Linux e sejam assinados
com os mesmos certificados.</p>

<p>O elemento <a href="{@docRoot}guide/topics/manifest/application-element.html">{@code
&lt;application&gt;}</a> tambm suporta um atributo {@code android:process}
para definir um valor padro que se aplique a todos os elementos.</p>

<p>O Android pode decidir desativar um processo em certo ponto, quando a memria estiver baixa e for necessria
para outros processos que atendem o usurio de forma mais imediata. Os componentes
de aplicativo em execuo no processo que  eliminado so consequentemente eliminados.  Um processo  iniciado
novamente para aqueles componentes quando houver trabalho para eles.</p>

<p>Ao decidir que processo eliminar, o sistema Android avalia a importncia relativa dele
para o usurio.  Por exemplo, ele fechar mais prontamente um processo que hospede atividades que no estejam mais
visveis na tela, comparado a um processo que hospede atividades visveis. A deciso
 exterminar processo ou no, portanto, depende do estado dos componentes em execuo neste processo. As regras
usadas para decidir quais processos sero exterminados so discutidas abaixo. </p>


<h3 id="Lifecycle">Ciclo de vida dos processos</h3>

<p>O sistema Android tenta manter um processo do aplicativo pelo maior perodo possvel,
mas eventualmente precisa remover processos antigos para recuperar memria para processos novos e mais importantes.  Para determinar
quais processos manter
e quais exterminar, o sistema posiciona cada um em uma "hierarquia de importncia" com base
nos componentes em execuo e no estado deles.  Processos com menos importncia
sero eliminados primeiro e, em seguida, aqueles com a menor importncia depois deles tambm sero, consecutivamente, at que os recursos
do sistema sejam recuperados.</p>

<p>H cinco nveis na hierarquia de importncia. A lista a seguir mostra os tipos
de processo em ordem de importncia (o primeiro processo  o <em>mais importante</em>
e o <em>eliminado por ltimo</em>):</p>

<ol>
  <li><b>Processos em primeiro plano</b>
    <p>Um processo necessrio para o que o usurio est fazendo.  Considera-se
      um processo como em primeiro plano se qualquer uma das condies for verdadeira:</p>

      <ul>
        <li>Se ele hospedar uma {@link android.app.Activity} com a qual o usurio esteja interagindo (se o mtodo {@link android.app.Activity#onResume onResume()} de {@link
android.app.Activity}
for chamado).</li>

        <li>Se ele hospedar um {@link android.app.Service} vinculado  atividade com a qual o usurio
esteja interagindo.</li>

        <li>Se ele hospedar um {@link android.app.Service} em execuo "em primeiro plano"&mdash; se o servio
tiver chamado {@link android.app.Service#startForeground startForeground()}.

        <li>Se ele hospedar um {@link android.app.Service} que esteja executando um de seus retornos de chamada
do ciclo de vida ({@link android.app.Service#onCreate onCreate()}, {@link android.app.Service#onStart
onStart()}, ou {@link android.app.Service#onDestroy onDestroy()}).</li>

        <li>Se ele hospedar um {@link android.content.BroadcastReceiver} que esteja executando seu mtodo {@link
        android.content.BroadcastReceiver#onReceive onReceive()}.</li>
    </ul>

    <p>Geralmente, somente poucos processos em primeiro plano existem em um determinado momento.  Eles sero eliminados
somente como ltimo recurso &mdash; se a memria estiver baixa demais para suportar a execuo de todos.  Geralmente, neste ponto,
o dispositivo atingiu o estado de paginao de memria. Portanto, eliminar alguns processos em primeiro plano
 necessrio para que a interface permanea responsiva.</p></li>

  <li><b>Processos visveis</b>
    <p>Um processo que no tenha nenhum componente em primeiro plano,
      mas que ainda possa afetar o que o usurio v na tela. Um processo  considerado visvel
      se uma das condies a seguir for verdadeira:</p>

      <ul>
        <li>Se ele hospedar um {@link android.app.Activity} que no esteja em primeiro plano,
mas ainda seja visvel para o usurio (o seu mtodo {@link android.app.Activity#onPause onPause()} tiver sido chamado).
Isto poder ocorrer, por exemplo, se a atividade em primeiro plano iniciar um dilogo, o que permitir
que a atividade anterior seja vista por trs dela.</li>

        <li>Se ele hospedar um {@link android.app.Service} que esteja vinculado a uma atividade visvel
(ou em primeiro plano).</li>
      </ul>

      <p>Um processo visvel  considerado extremamente importante e no ser eliminado a no ser
que seja necessrio para manter em execuo os processos em primeiro plano. </p>
    </li>

  <li><b>Processos de servio</b>
    <p>Um processo que esteja executando um servio que tenha sido iniciado com o mtodo {@link
android.content.Context#startService startService()} e no
esteja em uma das duas categorias mais altas. Apesar de processos de servio no estarem diretamente ligados a tudo o que os usurios veem,
eles esto geralmente fazendo coisas com que o usurio se importa (como reproduzindo msica em segundo plano
ou baixando dados na rede), ento o sistema os mantm em execuo a no ser que haja memria suficiente
para ret-los juntamente com todos os processos visveis e em primeiro plano. </p>
  </li>

  <li><b>Processos em segundo plano</b>
    <p>Um processo que mantenha uma atividade que no esteja atualmente visvel para o usurio (se o mtodo
{@link android.app.Activity#onStop onStop()} da atividade tiver sido chamado). Esses processos no tm impacto direto
na experincia do usurio e o sistema poder elimin-los a qualquer momento para recuperar memria para processos
em primeiro plano,
visveis ou de servio. Geralmente h vrios processos em segundo plano em execuo e eles so mantidos
em uma lista LRU (least recently used - menos usados recentemente) para garantir que o processo com a atividade
que foi mais vista recentemente pelo usurio seja a ltima a ser eliminada. Se uma atividade implementar o seu mtodo de ciclo de vida
corretamente e salvar o estado atual, eliminar o seu processo no ter efeito visvel
na experincia do usurio, pois quando ele navegar de volta  atividade, ela restaurar
todo o estado visvel. Consulte o documento <a href="{@docRoot}guide/components/activities.html#SavingActivityState">Atividades</a>
para obter informaes sobre os estados de restaurao e de gravao.</p>
  </li>

  <li><b>Processos vazios</b>
    <p>Um processo que no possui nenhum componente de aplicativo ativo.  O nico motivo para manter este tipo de processo
ativo  para armazenamento em cache, para aprimorar o tempo de inicializao
na prxima vez em que um componente precisar execut-lo.  O sistema frequentemente elimina esses processos para equilibrar os recursos do sistema em geral
entre os armazenamentos em cache do processo e os de ncleo subjacente.</p>
  </li>
</ol>


  <p>O Android coloca o processo no maior nvel possvel, com base na importncia dos componentes
atualmente ativos no processo.  Por exemplo, se um processo hospedar um servio e uma atividade visvel
, ele ter a classificao de um processo visvel, e no a de um processo de servio.</p>

  <p>Alm disso, a classificao de um processo pode ser elevada porque outros processos
dependem dele &mdash; um processo que est servindo a outro processo nunca pode ter classificao menor
do que a do processo que est sendo servido. Por exemplo, se um provedor de contedo no processo A estiver servindo um cliente no processo B,
ou se um servio no processo A estiver vinculado a um componente no processo B, o processo A ser sempre considerado
menos importante do que o processo B.</p>

  <p>Como um processo que executa um servio tem classificao maior do que um processo com atividades em segundo plano,
uma atividade que iniciar uma operao de longo prazo poder tambm iniciar um <a href="{@docRoot}guide/components/services.html">servio</a> para esta operao, em vez de simplesmente
criar um encadeamento de trabalho &mdash; especificamente se a operao exceder a atividade.
Por exemplo, uma atividade que esteja fazendo upload de uma imagem para um site dever iniciar um servio
para fazer o upload para que ele possa continuar em segundo plano mesmo se o usurio deixar a atividade.
Usar um servio garante que a operao tenha pelo menos a prioridade "processo de servio",
independente do que acontecer  atividade. Este  o mesmo motivo pelo qual os receptores de transmisso devem
empregar servios em vez de simplesmente usar operaes que consomem tempo em um encadeamento.</p>


<h2 id="Threads">Encadeamentos</h2>

<p>Quando um aplicativo  executado, o sistema cria um encadeamento de execuo para ele,
chamado de "principal". Este encadeamento  muito importante, pois est encarregado de despachar eventos
para os widgets adequados da interface do usurio, incluindo eventos de desenho.  tambm o encadeamento
em que o aplicativo interage com componentes do kit de ferramentas da IU do Android (componentes dos pacotes {@link
android.widget} e {@link android.view}). Portanto, o encadeamento principal, s vezes,
tambm chama o encadeamento da IU.</p>

<p>O sistema <em>no</em> cria um encadeamento separado para cada instncia de um componente. Todos os componentes
executados no mesmo processo so instanciados no encadeamento da IU, e as chamadas do sistema
para cada componente so despachadas deste encadeamento. Consequentemente, mtodos que respondam aos retornos de chamada
(como {@link android.view.View#onKeyDown onKeyDown()} para informar aes de usurio
ou um mtodo de retorno de chamada do ciclo de vida) sempre sero executados no encadeamento da IU do processo.</p>

<p>Por exemplo, quando o usurio toca em um boto na tela, o encadeamento da IU do aplicativo despacha
o evento de toque para o widget que, em troca, ativa o seu estado pressionado e publica uma solicitao de invalidao
 fila do evento. O encadeamento da IU retira a solicitao da fila e notifica o widget de que ele deve
desenhar novamente por conta prpria.</p>

<p>Quando o aplicativo realiza trabalho intenso em resposta  interao do usurio, este modelo de nico encadeamento
pode produzir desempenho inferior a no ser que voc implemente o aplicativo adequadamente. Especificamente, se tudo estiver
acontecendo no encadeamento da IU, realizar operaes longas, como acesso  rede
ou consultas a banco de dados, bloquear toda a IU. Quando o encadeamento  bloqueado, nenhum evento pode ser despachado,
incluindo eventos de desenho. Da perspectiva do usurio,
o aplicativo parece travar. Pior ainda, se o encadeamento da IU for bloqueado por mais do que alguns segundos
(cerca de 5 segundos atualmente), o usurio receber a vergonhosa mensagem "<a href="http://developer.android.com/guide/practices/responsiveness.html">aplicativo
no respondendo</a>" (ANR). O usurio poder, ento, decidir fechar o aplicativo e desinstal-lo
se estiver descontente.</p>

<p>Alm disso, o kit de ferramentas de IU do Android <em>no</em>  seguro para encadeamentos. Portanto, voc no deve manipular a IU
a partir de um encadeamento de trabalho &mdash; deve-se realizar toda a manipulao para a interface do usurio
a partir do encadeamento da IU. Com isso dito, h duas regras simples para o modelo de encadeamento nico do Android:</p>

<ol>
<li>No bloquear o encadeamento da IU
<li>No acessar o kit de ferramentas de IU do Android fora do encadeamento da IU
</ol>

<h3 id="WorkerThreads">Encadeamentos de trabalho</h3>

<p>Por causa do modelo de encadeamento nico descrito acima,  essencial para a capacidade de resposta da IU do aplicativo
que voc no bloqueie o encadeamento da IU. Caso tenha operaes a realizar
que no sejam instantneas, dever certificar-se de faz-las em encadeamentos separados (encadeamentos de "segundo plano"
ou "de trabalho").</p>

<p>Por exemplo, abaixo apresenta-se o cdigo de uma escuta de clique que baixa uma imagem de um encadeamento separado
e exibe-a em uma {@link android.widget.ImageView}:</p>

<pre>
public void onClick(View v) {
    new Thread(new Runnable() {
        public void run() {
            Bitmap b = loadImageFromNetwork("http://example.com/image.png");
            mImageView.setImageBitmap(b);
        }
    }).start();
}
</pre>

<p> primeira vista, parece no apresentar problemas, pois ele cria um novo encadeamento para lidar
com a operao de rede. No entanto, ele viola a segunda regra do modelo de encadeamento nico: <em>no acessar o kit de ferramentas de IU do Android
de fora do encadeamento da IU</em> &mdash; este exemplo modifica o {@link
android.widget.ImageView} a partir do encadeamento de trabalho em vez de o encadeamento da IU. Isto pode resultar em comportamentos
inesperados e indefinidos, que podem ser difceis de rastrear e consumir bastante tempo.</p>

<p>Para resolver este problema, o Android oferece vrias maneiras de acessar o encadeamento da IU a partir
de outros encadeamentos. Abaixo h uma lista dos mtodos que podem ajudar:</p>

<ul>
<li>{@link android.app.Activity#runOnUiThread(java.lang.Runnable)
Activity.runOnUiThread(Runnable)}</li>
<li>{@link android.view.View#post(java.lang.Runnable) View.post(Runnable)}</li>
<li>{@link android.view.View#postDelayed(java.lang.Runnable, long) View.postDelayed(Runnable,
long)}</li>
</ul>

<p>Por exemplo,  possvel resolver o cdigo acima usando o mtodo {@link
android.view.View#post(java.lang.Runnable) View.post(Runnable)}:</p>

<pre>
public void onClick(View v) {
    new Thread(new Runnable() {
        public void run() {
            final Bitmap bitmap = loadImageFromNetwork("http://example.com/image.png");
            mImageView.post(new Runnable() {
                public void run() {
                    mImageView.setImageBitmap(bitmap);
                }
            });
        }
    }).start();
}
</pre>

<p>Agora esta implementao  segura para encadeamentos: a operao de rede  concluda a partir de um encadeamento separado
enquanto que a {@link android.widget.ImageView}  manipulada a partir do encadeamento da IU.</p>

<p>No entanto,  medida que a complexidade da operao aumenta, este tipo de cdigo pode tornar-se complexo
e difcil demais para ser mantido. Para lidar com interaes mais complexas com um encadeamento de trabalho, considere
usar um {@link android.os.Handler} nele para processar as mensagens entregues
pelo encadeamento da IU. Apesar de que, talvez, a melhor soluo seja estender a classe {@link android.os.AsyncTask},
que simplifica a execuo das tarefas do encadeamento de trabalho que precisam interagir com a IU.</p>


<h4 id="AsyncTask">Uso de AsyncTask</h4>

<p>{@link android.os.AsyncTask} permite que voc trabalhe de forma assncrona
na interface do usurio. Ela realiza operaes de bloqueio em um encadeamento de trabalho e, em seguida, publica os resultados
no encadeamento da IU, sem que voc precise lidar com os encadeamentos e/ou os manipuladores.</p>

<p>Para us-la, voc deve atribuir a subclasse {@link android.os.AsyncTask} e implementar o mtodo de retorno de chamada {@link
android.os.AsyncTask#doInBackground doInBackground()}, que executa uma srie
de encadeamentos de segundo plano. Para atualizar a IU, deve-se implementar {@link
android.os.AsyncTask#onPostExecute onPostExecute()}, que entrega o resultado de {@link
android.os.AsyncTask#doInBackground doInBackground()} e  executado no encadeamento da IU para que seja possvel
atualizar a IU de forma segura.  possvel, em seguida, executar a tarefa chamando {@link android.os.AsyncTask#execute execute()}
a partir do encadeamento da IU.</p>

<p>Por exemplo,  possvel implementar o exemplo anterior usando {@link android.os.AsyncTask}
da seguinte forma:</p>

<pre>
public void onClick(View v) {
    new DownloadImageTask().execute("http://example.com/image.png");
}

private class DownloadImageTask extends AsyncTask&lt;String, Void, Bitmap&gt; {
    /** The system calls this to perform work in a worker thread and
      * delivers it the parameters given to AsyncTask.execute() */
    protected Bitmap doInBackground(String... urls) {
        return loadImageFromNetwork(urls[0]);
    }

    /** The system calls this to perform work in the UI thread and delivers
      * the result from doInBackground() */
    protected void onPostExecute(Bitmap result) {
        mImageView.setImageBitmap(result);
    }
}
</pre>

<p>Agora a IU est segura e o cdigo est mais simples, pois ele separa o trabalho
em uma parte que deve ser feita em um encadeamento de trabalho e outra parte que deve ser feita no encadeamento da IU.</p>

<p>Leia a referncia {@link android.os.AsyncTask} para compreender melhor
o uso desta classe, mas a seguir h uma viso geral rpida sobre como ela funciona:</p>

<ul>
<li> possvel especificar o tipo dos parmetros, valores de progresso e valor final
da tarefa, usando genricos</li>
<li>O mtodo {@link android.os.AsyncTask#doInBackground doInBackground()}  executado automaticamente
em um encadeamento de trabalho</li>
<li>{@link android.os.AsyncTask#onPreExecute onPreExecute()}, {@link
android.os.AsyncTask#onPostExecute onPostExecute()} e {@link
android.os.AsyncTask#onProgressUpdate onProgressUpdate()} so invocados no encadeamento da IU</li>
<li>O valor retornado por {@link android.os.AsyncTask#doInBackground doInBackground()}
 enviado para {@link android.os.AsyncTask#onPostExecute onPostExecute()}</li>
<li> possvel chamar {@link android.os.AsyncTask#publishProgress publishProgress()} a qualquer momento em {@link
android.os.AsyncTask#doInBackground doInBackground()} para executar {@link
android.os.AsyncTask#onProgressUpdate onProgressUpdate()} no encadeamento da IU</li>
<li> possvel cancelar a tarefa a qualquer momento, a partir de qualquer encadeamento</li>
</ul>

<p class="caution"><strong>Ateno:</strong> outro problema que pode ocorrer ao usar
um encadeamento de trabalho so reinicializaes inesperadas da atividade devido a <a href="{@docRoot}guide/topics/resources/runtime-changes.html">alteraes na configurao em tempo de execuo</a>
(como quando o usurio altera a orientao da tela), que podem eliminar o encadeamento de trabalho. Para ver como  possvel
manter uma tarefa durante uma dessas reinicializaes e como cancelar adequadamente a tarefa
quando a atividade for eliminada, consulte o cdigo fonte do aplicativo <a href="http://code.google.com/p/shelves/">Prateleiras</a> de exemplo.</p>


<h3 id="ThreadSafe">Mtodos seguros de encadeamento</h3>

<p> Em algumas situaes, os mtodos implementados podem ser chamados a partir de mais de um encadeamento e, portanto,
devem ser programados para serem seguros para encadeamento. </p>

<p>Isto  especialmente verdadeiro para mtodos que podem ser cancelados remotamente &mdash; como mtodos em um <a href="{@docRoot}guide/components/bound-services.html">servio vinculado</a>. Quando uma chamada
de um mtodo implementado em um {@link android.os.IBinder} tiver origem no mesmo processo
em que {@link android.os.IBinder IBinder} estiver em execuo, o mtodo ser executado no encadeamento do autor da chamada.
No entanto, quando a chamada tiver origem em outro processo, o mtodo ser executado em um encadeamento
escolhido a partir de uma srie de encadeamentos que o sistema mantm no mesmo processo que {@link android.os.IBinder
IBinder} (ele no ser executado no encadeamento da IU do processo).  Por exemplo, enquanto o mtodo
{@link android.app.Service#onBind onBind()} de um servio seria chamado a partir de um encadeamento da IU do processo
de um servio, os mtodos implementados no objeto que {@link android.app.Service#onBind
onBind()} retorna (por exemplo, uma subclasse que implementa mtodos de RPC) seriam chamados
a partir dos encadeamentos no conjunto. Como um servio pode ter mais de um cliente, mais de um encadeamento no conjunto
pode envolver o mesmo mtodo {@link android.os.IBinder IBinder} ao mesmo tempo. Os mtodos {@link android.os.IBinder
IBinder} devem, portanto, ser implementados para serem seguros para encadeamentos.</p>

<p> De forma semelhante, um provedor de contedo pode receber solicitaes de dados que tenham origem em outros processos.
Apesar de as classes {@link android.content.ContentResolver} e {@link android.content.ContentProvider}
ocultarem os detalhes de como a comunicao entre processos  gerenciada, os mtodos {@link
android.content.ContentProvider} que respondem a essas solicitaes &mdash; os mtodos {@link
android.content.ContentProvider#query query()}, {@link android.content.ContentProvider#insert
insert()}, {@link android.content.ContentProvider#delete delete()}, {@link
android.content.ContentProvider#update update()} e {@link android.content.ContentProvider#getType
getType()} &mdash; sero chamados de um conjunto de encadeamentos no processo do provedor de contedo, no no encadeamento da IU
para o processo.  Como esses mtodos podem ser chamados a partir de qualquer quantidade de encadeamentos
ao mesmo tempo, eles tambm devem ser implementados para serem seguros para encadeamento. </p>


<h2 id="IPC">Comunicao entre processos</h2>

<p>O Android oferece um mecanismo para comunicao entre processos (IPC) usando chamadas de procedimento remoto (RPCs),
onde um mtodo  chamado por uma atividade ou outro componente de aplicativo, mas  executado
remotamente (em outro processo), com qualquer resultado retornado
de volta ao autor da chamada. Isto acarreta na decomposio de uma chamada de mtodo e de seus dados para um nvel em que o sistema operacional
possa entender, transmitindo-a do processo local e do espao de endereo ao processo remoto
e ao espao de endereo e, em seguida, remontando e restabelecendo a chamada l.  Os valores de retorno
so transmitidos na direo oposta.  O Android fornece todo o cdigo para realizar essas operaes
de IPC para que voc possa concentrar-se em definir e implementar a interface de programao de RPC. </p>

<p>Para realizar o IPC, o aplicativo deve vincular-se a um servio usando {@link
android.content.Context#bindService bindService()}. Para obter mais informaes, consulte o guia do desenvolvedor <a href="{@docRoot}guide/components/services.html">Servios</a>.</p>


<!--
<h2>Beginner's Path</h2>

<p>For information about how to perform work in the background for an indefinite period of time
(without a user interface), continue with the <b><a
href="{@docRoot}guide/components/services.html">Services</a></b> document.</p>
-->