path: root/docs/html-intl/intl/es/preview/features/background-optimization.jd

page.title=Optimizaciones en segundo plano
page.metaDescription=Nuevas restricciones para difusiones implícitas.
page.keywords="android N", "implicit broadcasts", "job scheduler"
page.image=images/cards/card-nyc_2x.jpg

@jd:body

<div id="qv-wrapper">
  <div id="qv">
    <h2>
      Contenido del documento
    </h2>

    <ol>
      <li>
        <a href="#connectivity-action">Restricciones en CONNECTIVITY_ACTION</a>
      </li>

      <li>
        <a href="#sched-jobs">Programación de trabajos en red en conexiones
        sin medición</a>
      </li>

      <li>
        <a href="#monitor-conn">Control de la conectividad de la red mientras la aplicación
        se está ejecutando</a>
      </li>

      <li>
        <a href="#media-broadcasts">Restricciones en NEW_PICTURE y
        NEW_VIDEO</a>
      </li>

      <li>
        <a href="#new-jobinfo">Nuevos métodos de JobInfo</a>
      </li>

      <li>
        <a href="#new-jobparam">Nuevos métodos de JobParameter</a>
      </li>

      <li>
        <a href="#further-optimization">Cómo optimizar aún más tu aplicación</a>
      </li>
    </ol>
  </div>
</div>

<p>
  Los procesos en segundo plano pueden consumir mucha memoria y batería. Por ejemplo, una
  difusión implícita puede iniciar muchos procesos en segundo plano registrados para
  escucharla, aunque esos procesos quizá no desempeñen un trabajo considerable. Esto puede
  afectar de forma significativa tanto el rendimiento del dispositivo como la experiencia de usuario.
</p>

<p>
  Para atenuar este problema, la N Developer Preview aplica las siguientes 
  restricciones:
</p>

<ul>
  <li>Las aplicaciones orientadas a la Preview no reciben difusiones {@link
  android.net.ConnectivityManager#CONNECTIVITY_ACTION} si 
  en su manifiesto registran que las reciben. Las aplicaciones que se ejecutan en segundo plano
  aún pueden escuchar {@code CONNECTIVITY_CHANGE} en su subproceso principal al
  registrar un {@link android.content.BroadcastReceiver} con {@link
  android.content.Context#registerReceiver Context.registerReceiver()}.
  </li>

  <li>Las aplicaciones no pueden enviar ni recibir difusiones {@link
  android.hardware.Camera#ACTION_NEW_PICTURE} ni {@link
  android.hardware.Camera#ACTION_NEW_VIDEO}. Esta optimización
  afecta a todas las aplicaciones, no solo a las orientadas a la Preview.
  </li>
</ul>

<p>
  El framework de Android ofrece varias soluciones para mitigar la necesidad de
  estas difusiones implícitas. Por ejemplo, {@link android.app.job.JobScheduler}
  y <a href="https://developers.google.com/android/reference/com/google/android/gms/gcm/GcmNetworkManager">
  {@code GcmNetworkManager}</a> proporcionan mecanismos sólidos para programar operaciones
  de red cuando se cumplen las condiciones especificadas, como una conexión a una
  red de uso no medido. Ahora también puedes usar {@link android.app.job.JobScheduler}
  para reaccionar a cambios en relación con los proveedores de contenido. Los objetos {@link android.app.job.JobInfo}
  encapsulan los parámetros que usa {@link android.app.job.JobScheduler}
  para programar el trabajo. Cuando se cumplen las condiciones del trabajo, el sistema
  ejecuta ese trabajo en el {@link android.app.job.JobService} de tu aplicación.
</p>

<p>
  En este documento, aprenderemos cómo usar métodos alternativos, como
  {@link android.app.job.JobScheduler}, para adaptar tu aplicación a esas nuevas
  restricciones.
</p>

<h2 id="connectivity-action">
  Restricciones en CONNECTIVITY_ACTION
</h2>

<p>
  Las aplicaciones orientadas a la N Developer Preview no reciben difusiones {@link
  android.net.ConnectivityManager#CONNECTIVITY_ACTION} si en su
  manifiesto registran que las reciben, y los procesos dependen de que
  no se inicie esa difusión. Esto podría ser un problema para aplicaciones que buscan
  escuchar los cambios en la red o realizar múltiples actividades en red cuando el
  dispositivo se conecta a una red sin medición de uso. Ya existen varias soluciones
  en relación con esta restricción en el framework de Android, pero elegir
  la correcta depende de lo que quieras lograr con tu aplicación.
</p>

<p class="note">
  <strong>Nota:</strong> Un {@link android.content.BroadcastReceiver} registrado con
  {@link android.content.Context#registerReceiver Context.registerReceiver()}
  continúa recibiendo esas difusiones mientras la aplicación está en segundo plano.
</p>

<h3 id="sched-jobs">
  Programación de trabajos en red en conexiones sin medición de uso
</h3>

<p>
  Cuando uses la clase {@link android.app.job.JobInfo.Builder JobInfo.Builder}
  para crear tu objeto {@link android.app.job.JobInfo}, aplica el método {@link
  android.app.job.JobInfo.Builder#setRequiredNetworkType
  setRequiredNetworkType()} y pasa {@link android.app.job.JobInfo
  JobInfo.NETWORK_TYPE_UNMETERED} como parámetro de trabajo. El siguiente ejemplo de código
  programa la ejecución de un servicio cuando el dispositivo se conecta a una red sin
  medición de uso y se está cargando:
</p>

<pre>
public static final int MY_BACKGROUND_JOB = 0;
...
public static void scheduleJob(Context context) {
  JobScheduler js =
      (JobScheduler) context.getSystemService(Context.JOB_SCHEDULER_SERVICE);
  JobInfo job = new JobInfo.Builder(
    MY_BACKGROUND_JOB,
    new ComponentName(context, MyJobService.class))
      .setRequiredNetworkType(JobInfo.NETWORK_TYPE_UNMETERED)
      .setRequiresCharging(true)
      .build();
  js.schedule(job);
}
</pre>

<p>
  Cuando se cumplan las condiciones para tu trabajo, tu aplicación recibirá un callback para ejecutar
  el método {@link android.app.job.JobService#onStartJob onStartJob()} en la
   {@code JobService.class} especificada. Para ver más ejemplos de la implementación de {@link
  android.app.job.JobScheduler}, consulta la <a href="{@docRoot}samples/JobScheduler/index.html">aplicación de ejemplo JobScheduler</a>.
</p>

<p>
  Las aplicaciones que usan servicios de GMSCore y están orientadas a Android 5.0 (API nivel 21)
  o anterior, pueden usar <a href="https://developers.google.com/android/reference/com/google/android/gms/gcm/GcmNetworkManager">
  {@code GcmNetworkManager}</a> y especificar {@code Task.NETWORK_STATE_UNMETERED}.
</p>

<h3 id="monitor-conn">
  Control de la conectividad de la red mientras la aplicación se está ejecutando
</h3>

<p>
  Las aplicaciones que se ejecutan en segundo plano aún pueden escuchar {@code
  CONNECTIVITY_CHANGE} con un {@link
  android.content.BroadcastReceiver} registrado. No obstante, la API {@link
  android.net.ConnectivityManager} ofrece un método más robusto para solicitar
  un callback solo cuando se cumplen las condiciones de red especificadas.
</p>

<p>
  Los objetos {@link android.net.NetworkRequest} definen los parámetros del
  callback de la red en términos de {@link android.net.NetworkCapabilities}. Creas
  objetos {@link android.net.NetworkRequest} con la clase {@link
  android.net.NetworkRequest.Builder NetworkRequest.Builder}. {@link
  android.net.ConnectivityManager#registerNetworkCallback(android.net.NetworkRequest,
  android.net.ConnectivityManager.NetworkCallback) registerNetworkCallback()}
  y luego pasa el objeto {@link android.net.NetworkRequest} al sistema. Cuando
  se cumplen las condiciones de la red, la aplicación recibe un callback para ejecutar el método
  {@link android.net.ConnectivityManager.NetworkCallback#onAvailable
  onAvailable()} definido en su clase {@link
  android.net.ConnectivityManager.NetworkCallback}.
</p>

<p>
  La aplicación continuará recibiendo callbacks hasta que la aplicación salga o llame a
  {@link android.net.ConnectivityManager#unregisterNetworkCallback
  unregisterNetworkCallback()}.
</p>

<h2 id="media-broadcasts">
  Restricciones en NEW_PICTURE y NEW_VIDEO
</h2>

<p>
  En la N Developer Preview, las aplicaciones no pueden enviar ni recibir difusiones {@link
  android.hardware.Camera#ACTION_NEW_PICTURE} ni {@link
  android.hardware.Camera#ACTION_NEW_VIDEO}. Esta restricción ayuda a
  aliviar el impacto en el rendimiento y la experiencia de usuario cuando varias aplicaciones deben
  activarse para procesar una nueva imagen o video. La N Developer Preview
  extiende {@link android.app.job.JobInfo} y {@link
  android.app.job.JobParameters} para proporcionar una solución alternativa.
</p>

<h3 id="new-jobinfo">
  Nuevos métodos de JobInfo
</h3>

<p>
  Para activar trabajos en los cambios del URI de contenido, la N Developer Preview amplía
  la API {@link android.app.job.JobInfo} con los siguientes métodos:
</p>

<dl>
  <dt>
    {@code JobInfo.TriggerContentUri()}
  </dt>

  <dd>
    Encapsula parámetros necesarios para activar un trabajo en cambios del URI de contenido.
  </dd>

  <dt>
    {@code JobInfo.Builder.addTriggerContentUri()}
  </dt>

  <dd>
    Pasa un objeto {@code TriggerContentUri} a {@link
    android.app.job.JobInfo}. Un {@link android.database.ContentObserver}
    controla el URI de contenido encapsulado. Si hay múltiples objetos {@code
    TriggerContentUri} asociados a un trabajo, el sistema proporciona un
    callback aunque se informe un cambio en un solo URI de contenido.
  </dd>

  <dd>
    Si cambia algún desencadenante del URI determinado, agrega el marcador {@code TriggerContentUri.FLAG_NOTIFY_FOR_DESCENDANTS} para
    activar el trabajo. Este marcador
    corresponde al parámetro {@code notifyForDescendants} pasado a {@link
    android.content.ContentResolver#registerContentObserver
    registerContentObserver()}.
  </dd>
</dl>

<p class="note">
  <strong>Nota:</strong> no se puede usar {@code TriggerContentUri()} junto
  con {@link android.app.job.JobInfo.Builder#setPeriodic
  setPeriodic()} ni {@link android.app.job.JobInfo.Builder#setPersisted
  setPersisted()}. Para controlar de forma constante la presencia de cambios, programa un nuevo
  {@link android.app.job.JobInfo} antes de que el {@link
  android.app.job.JobService} de la aplicación termine de administrar la callback más reciente.
</p>

<p>
  El siguiente código de ejemplo programa la activación de un trabajo cuando el sistema informe
  un cambio en el URI de contenido, {@code MEDIA_URI}:
</p>

<pre>
public static final int MY_BACKGROUND_JOB = 0;
...
public static void scheduleJob(Context context) {
  JobScheduler js =
          (JobScheduler) context.getSystemService(Context.JOB_SCHEDULER_SERVICE);
  JobInfo.Builder builder = new JobInfo.Builder(
          MY_BACKGROUND_JOB,
          new ComponentName(context, MediaContentJob.class));
  builder.addTriggerContentUri(
          new JobInfo.TriggerContentUri(MEDIA_URI,
          JobInfo.TriggerContentUri.FLAG_NOTIFY_FOR_DESCENDANTS));
  js.schedule(builder.build());
}
</pre>
<p>
  Cuando el sistema informa un cambio en el(los) URI de contenido especificado(s), tu aplicación
  recibe un callback y se pasa un objeto {@link android.app.job.JobParameters} 
  al método {@link android.app.job.JobService#onStartJob onStartJob()}
  en {@code MediaContentJob.class}.
</p>

<h3 id="new-jobparam">
  Nuevos métodos de JobParameter
</h3>

<p>
  La N Developer Preview también amplía {@link android.app.job.JobParameters} para
  permitir que tu aplicación reciba información útil sobre qué autoridades de contenido
  y URI activaron el trabajo:
</p>

<dl>
  <dt>
    {@code Uri[] getTriggeredContentUris()}
  </dt>

  <dd>
    Devuelve el arreglo de los URI que activaron el trabajo. Ese arreglo será {@code
    null} si ningún URI activó el trabajo (por ejemplo, el trabajo
    se activó debido al cumplimiento de un plazo o por otro motivo), o la cantidad de URI
    modificados es superior a 50.
  </dd>

  <dt>
    {@code String[] getTriggeredContentAuthorities()}
  </dt>

  <dd>
    Devuelve el arreglo de cadenas de autoridades de contenido que activaron el trabajo.
    Si el arreglo devuelto no es {@code null}, usa {@code getTriggeredContentUris()}
    para recuperar los detalles de los URI que se modificaron.
  </dd>
</dl>

<p>
  El siguiente código de ejemplo anula el método {@link
  android.app.job.JobService#onStartJob JobService.onStartJob()} y
  registra las autoridades de contenido y los URI que activaron el trabajo:
</p>

<pre>
&#64;Override
public boolean onStartJob(JobParameters params) {
  StringBuilder sb = new StringBuilder();
  sb.append("Media content has changed:\n");
  if (params.getTriggeredContentAuthorities() != null) {
      sb.append("Authorities: ");
      boolean first = true;
      for (String auth :
          params.getTriggeredContentAuthorities()) {
          if (first) {
              first = false;
          } else {
             sb.append(", ");
          }
           sb.append(auth);
      }
      if (params.getTriggeredContentUris() != null) {
          for (Uri uri : params.getTriggeredContentUris()) {
              sb.append("\n");
              sb.append(uri);
          }
      }
  } else {
      sb.append("(No content)");
  }
  Log.i(TAG, sb.toString());
  return true;
}
</pre>

<h2 id="further-optimization">
  Cómo optimizar aún más tu aplicación
</h2>

<p>
  Optimizar tus aplicaciones para que se ejecuten en dispositivos con poca memoria o en condiciones de niveles bajos
  de memoria puede mejorar el rendimiento y la experiencia del usuario. Eliminar
  dependencias en servicios en segundo plano y receptores de difusiones implícitas
  registrados estadísticamente puede ayudar a que tu aplicación se ejecute mejor en esos dispositivos. Si bien
  la N Developer Preview toma medidas para reducir algunos de esos problemas, te
  recomendamos que optimices tu aplicación para que pueda ejecutarse sin utilizar esos
  procesos en segundo plano.
</p>

<p>
  La N Developer Preview presenta algunos comandos adicionales de <a href="{@docRoot}tools/help/adb.html">Puente de Depuración Android (en inglés, Android Debug Bridge, ADB)</a> que
  puedes usar para probar el comportamiento de la aplicación con esos procesos en segundo plano deshabilitados:
</p>

<ul>
  <li>Para simular condiciones en las que no hay difusiones implícitas ni servicios en segundo plano
  disponibles, ingresa el siguiente comando:
  </li>

  <li style="list-style: none; display: inline">
<pre class="no-pretty-print">
{@code $ adb shell cmd appops set RUN_IN_BACKGROUND ignore}
</pre>
  </li>

  <li>Para volver a habilitar las difusiones implícitas y los servicios en segundo plano, ingresa el
  siguiente comando:
  </li>

  <li style="list-style: none; display: inline">
<pre class="no-pretty-print">
{@code $ adb shell cmd appops set RUN_IN_BACKGROUND allow}
</pre>
  </li>
</ul>