Android – ¿Por qué mi aplicación utiliza alrededor de 40 MB de proceso de fondo en caché?

Estoy empezando una nueva aplicación con minSdkVersion = "14" y targetSdkVersion = "17". Contiene un viewpager con 6 páginas. Hay 3 webviews y 3 otros views.

Cuando empujo mi aplicación a fondo haciendo clic en el botón de regreso o inicio, utiliza alrededor de 40 MB en "proceso de fondo en caché" y no entiendo por qué.

Este es un ejemplo de uno de mi webview:

import android.os.Bundle; import android.support.v4.app.Fragment; import android.util.Log; import android.view.LayoutInflater; import android.view.View; import android.view.ViewGroup; import android.webkit.WebView; import android.webkit.WebViewClient; import android.widget.RelativeLayout; public class Presentation extends Fragment { boolean isOption = false; RelativeLayout main = null; WebView web_main = null; public Presentation () { } @Override public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) { super.onCreate(savedInstanceState); main = (RelativeLayout) inflater.inflate(R.layout.webview, container, false); return main; } @Override public void onActivityCreated(Bundle savedInstanceState) { // TODO Auto-generated method stub super.onActivityCreated(savedInstanceState); web_main = new WebView(getActivity().getApplicationContext()); web_main.setWebViewClient(new WebViewClient()); web_main.getSettings().setAppCacheEnabled(false); web_main.loadUrl("file:///android_asset/main.html"); main.removeAllViews(); main.addView(web_main); } @Override public void onDestroy() { super.onDestroy(); Log.i(getClass().getName(), "[OnDestroy]"); main.removeAllViews(); web_main.destroy(); main = null; web_main = null; System.gc(); } } 

He seguido varios tutoriales y respuestas, pero no hay efecto en el proceso de fondo en caché Esta es mi actividad principal:

 public class AppTest extends FragmentActivity { /** * The {@link android.support.v4.view.PagerAdapter} that will provide * fragments for each of the sections. We use a * {@link android.support.v4.app.FragmentPagerAdapter} derivative, which * will keep every loaded fragment in memory. If this becomes too memory * intensive, it may be best to switch to a * {@link android.support.v4.app.FragmentStatePagerAdapter}. */ SectionsPagerAdapter mSectionsPagerAdapter; /** * The {@link ViewPager} that will host the section contents. */ ViewPager mViewPager; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main_content); // Create the adapter that will return a fragment for each of the three // primary sections of the app. mSectionsPagerAdapter = new SectionsPagerAdapter( getSupportFragmentManager()); // Set up the ViewPager with the sections adapter. mViewPager = (ViewPager) findViewById(R.id.pager); mViewPager.setAdapter(mSectionsPagerAdapter); } @Override protected void onStop() { super.onStop(); System.gc(); Log.i(getClass().getName(), "[OnStop]"); android.os.Debug.stopMethodTracing(); } @Override public boolean onCreateOptionsMenu(Menu menu) { // Inflate the menu; this adds items to the action bar if it is present. getMenuInflater().inflate(R.menu.main_content, menu); return true; } @Override protected void onDestroy() { super.onDestroy(); mViewPager.removeAllViews(); Log.i(getClass().getName(), "[OnDestroy]"); } /** * A {@link FragmentPagerAdapter} that returns a fragment corresponding to * one of the sections/tabs/pages. */ public class SectionsPagerAdapter extends FragmentStatePagerAdapter { public SectionsPagerAdapter(FragmentManager fm) { super(fm); } @Override public Fragment getItem(int position) { // getItem is called to instantiate the fragment for the given page. // Return a DummySectionFragment (defined as a static inner class // below) with the page number as its lone argument. Fragment fragment = null; switch (position) { case 0: fragment = new Presentation(); break; /* case 1: fragment = new Edition(); break; case 2: fragment = new Programme(); break; case 3: fragment = new Twitter(); break; case 4: fragment = new Partenaire(); break; case 5: fragment = new Information(); break;*/ default: fragment = new Presentation(); break; } return fragment; } @Override public int getCount() { // Show 6 total pages. return 6; } @Override public CharSequence getPageTitle(int position) { switch (position) { case 0: return "Presentation"; case 1: return "Edition"; case 2: return "Program"; case 3: return "Tweets"; case 4: return "Partners"; case 5: return "Information"; } return null; } } } 

¿Puede alguien ver lo que está mal?

EDIT He intentado poner webview en el diseño, pero sigue siendo el mismo De hecho, quiero saber lo que se pone en caché cuando la aplicación está en estado de fondo?

"Procesos de fondo en caché" generalmente se refiere a procesos que no tienen una actividad de primer plano y no tienen un servicio en ejecución. Estos procesos se mantienen en la memoria porque tenemos suficiente memoria y podemos permitir al usuario volver rápidamente a ellos. Si Android comienza a quedarse sin RAM, estos procesos serán los primeros en ser destruidos para liberar RAM. A veces, se puede mantener un antiguo proceso de aplicación cuando la misma aplicación se cambia a un nuevo proceso.

Por lo que puedo decir, el espacio ocupado en el "proceso de fondo en caché" estado va a ser determinado por lo que su aplicación está utilizando actualmente. Por ejemplo, si una aplicación utiliza 20 MB en primer plano, entonces si RAM está disponible, se ocupará la misma cantidad de espacio.

Si su aplicación tiene 3 ImageViews y 3 WebViews, puede ocupar muy bien 40MB de espacio RAM dependiendo de lo que está almacenado en esos ImageViews y WebViews. Puede utilizar las herramientas de creación de perfiles para ver cuánta memoria está utilizando su aplicación y cuáles son sus componentes. Si la memoria utilizada en el primer plano es similar a la que se encuentra en el estado de fondo, entonces todo es como debería ser.

Nota: Los fabricantes pueden meterse con la aplicación de configuración y redefinir lo que se entiende por "proceso de fondo en caché". En ese caso, tendrás que contactar con ellos para ver cómo exactamente lo definen y de qué se compone.

  • Error de memoria insuficiente al reiniciar la aplicación (Android)
  • Público o privado, realmente importa con las variables de Android
  • Alineación de la memoria en iPhone y Android
  • Merory Leak; Los objetos no tienen raíz de GC
  • Fuera de los errores de memoria se producen con un tamaño de montón alto pero tamaño asignado bajo. ¿Por qué?
  • SQLite Android asignación de la ventana de cursor de 2048 kb falló
  • Pasar Actividad Contexto para que los constructores lo utilicen internamente - ¿es esto malo?
  • ¿Por qué Android no limpia la memoria después de terminar la actividad?
  • ¿Por qué tengo fugas de memoria cuando estoy haciendo simpy setContentView (R.layout.somelayout)?
  • Android con poca memoria, por ninguna razón obvia
  • ¿Las referencias de fuga de Butterknife después de la actividad terminada?
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.