usage mexico android performance

usage - android versions mexico



Android-Interfaz de usuario declarativa vs programática (3)

He desarrollado esta clase para pre inflar un conjunto de vistas y reutilizarla cada vez que lo necesito. He ganado segundos en el rendimiento al actualizar la interfaz de usuario, que es bastante impresionante.

Mi Logcat dice:

updating UI inflating on demand >> 2136mS updating UI reusing from pool >> 937mS

Aquí está mi clase, simplemente no me importa mi torpe estilo de codificación Java, soy un programador integrado en C ++.

import java.util.ArrayList; import java.util.List; import android.view.LayoutInflater; import android.view.View; public class ViewPool { private List<View> mViews; private LayoutInflater mInf; private int mIdx; private int mResource; /** * Constructor, gives Inflater and resource ID to inflate * @param mInf Layout inflater * @param rID Resource ID of view to inflate * @para number number of views that must inflate on first initialization */ public ViewPool(LayoutInflater mInf, int rID, int number) { super(); int idx; mViews = new ArrayList<View>(); this.mInf = mInf; mResource = rID; mIdx=0; // index of first used item for(idx=0; idx<number;++idx) { mViews.add((View)mInf.inflate(mResource, null)); } } /** * Start from first item of pool */ public void Reset() { mIdx=0; } /** * Get a view from pool, if no more views on pool, inflate more * @return */ public View GetView() { View retval; retval = mViews.get(mIdx); ++mIdx; if(mIdx == mViews.size()) // no more views in pool?? mViews.add((View)mInf.inflate(mResource, null)); // inflate more return(retval); } }

¿Alguien ha visto o compilado pruebas comparativas comparativas declarativas (XML) con interfaces de usuario creadas mediante programación en Android?

Hay cosas que Google ha hecho para acelerar el enfoque declarativo, pero todavía tiene el paso de inflación de diseño realizado en tiempo de ejecución.

¿Alguna vez ha cambiado (o ha considerado) cambiar su UI de declarativo a programático por alguna razón?


Hice algunas pruebas MUY informales / intrépidas al respecto, y descubrí que, al tomar el enfoque programático, aunque no era tan agradable trabajar, afeitaba entre un tercio y la mitad del tiempo total empleado. La prueba se ejecutó en un Samsung Galaxy de 7 "solamente, y no en un AVD.

Como digo, esta fue una prueba muy informal / trivial (como verás en el código), con circunstancias muy limitadas, el tipo de cosa que se reúne rápidamente para satisfacer tu propia curiosidad y no generalmente para el consumo público.

R.layout.ll y R.layout.tv son archivos de diseño simple que contienen LinearLayouts y TextViews en blanco, respectivamente.

Si solo está trabajando con un puñado de vistas, me quedaría con XML / inflaters, pero para cientos, tal vez quiera considerar el enfoque programático si la velocidad es un problema.

package com.inflatervscode; import java.util.Calendar; import android.app.Activity; import android.os.Bundle; import android.widget.LinearLayout; import android.widget.TextView; public class InflaterVSCodeActivity extends Activity { @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); } // Generates a few nested LinearLayouts/TextViews, a number of // times, and works out how many milliseconds this took. @Override public void onResume() { super.onResume(); setContentView(R.layout.main); int num_repeats = 500; // Change this to however many times you want to // create a set of nested views. LinearLayout masterLL = (LinearLayout)findViewById(R.id.test); TextView results = (TextView)findViewById(R.id.results); Calendar c = Calendar.getInstance(); long startTime = c.getTimeInMillis(); for (int i=0;i<num_repeats;i++) { // Replace the section below with LinearLayout fll = new LinearLayout(this); etc LinearLayout fll = (LinearLayout)getLayoutInflater().inflate(R.layout.ll, null); LinearLayout sll = (LinearLayout)getLayoutInflater().inflate(R.layout.ll, null); LinearLayout tll = (LinearLayout)getLayoutInflater().inflate(R.layout.ll, null); TextView tv = (TextView)getLayoutInflater().inflate(R.layout.tv, null); tv.setText(i+""); tll.addView(tv); sll.addView(tll); fll.addView(sll); masterLL.addView(fll); } c = Calendar.getInstance(); long endTime = c.getTimeInMillis(); String tt = Long.toString((endTime-startTime)); results.setText("Results for "+num_tests+" tests:/n/nStart:"+Long.toString(startTime)+"/nEnd :"+Long.toString(endTime)+"/n/nDifference (ms):"+tt); }

}


Muy poco de la inflación de diseño se realiza en tiempo de ejecución. Como se indica en los documentos de la API LayoutInflator:

Por razones de rendimiento, la inflación de la vista depende en gran medida del procesamiento previo de los archivos XML que se realiza en el momento de la compilación. Por lo tanto, actualmente no es posible usar LayoutInflater con un XmlPullParser sobre un archivo XML plano en tiempo de ejecución

Si observa la source , muchas de las vistas se extraen de un mapa hash en función de su etiqueta XML.

En respuesta a su pregunta de si he evaluado el inflador, tengo que decir que no. Personalmente, me parece que la idea de realizar una evaluación comparativa del diseño de inflater en Android para su aplicación es equivalente a la evaluación comparativa del analizador DOM en Firefox para su sitio web. No creo que el ejercicio sea inútil, pero debería tener una razón mucho mejor que "el diseño de mi actividad es demasiado complicado para el inflador" ...

Si necesita un diseño generado dinámicamente, sería mejor crearlo programáticamente. Si su vista simplemente tarda mucho tiempo en inflarse, debe simplificar su vista XML.