¿Cuáles son los errores más fáciles de hacer que pueden ser los receptores de rendimiento en Android?Errores comunes de rendimiento en Android?
La documentación menciona que "algunas operaciones de coma flotante" pueden ser "del orden de milisegundos". ¿Alguien ha probado esto?
Por el bien de la discusión, supongamos que se está ejecutando en un dispositivo G1/similar.
Para sugerencias sobre el rendimiento de representación específicos, consulte los siguientes Google I/O 2009 conversaciones:
La razón por la que quieren que evitar el uso de flotador se debe a que es muy raro implementado en la CPU del teléfono (brazo Probbly), y tiene que ser implementado en un software que es lento. El punto fijo es usualmente surported en hardware aunque.
Algunos teléfonos implementan el punto flotante en el hardware, pero como usted no sabe en qué teléfono se implementará su aplicación, no lo arriesgan.
Mucha gente también dice que evite el uso de objetos, en los días de los teléfonos realmente lentos y java me la gente solía escribir java procedurally con funciones estáticas. No lo recomendaría ahora sin embargo.
No se preocupe por el rendimiento hasta que sepa que el código tiene problemas importantes. Los pequeños ajustes (ints en lugar de flotantes, que usan iteradores en lugar de enumeración de matriz explícita) tienden a ser realmente menores y es mejor que los mires cuando tu aplicación está inactiva. Haga que el 5% del código que es lento sea más complejo en lugar de hacer toda la aplicación.
De acuerdo con la gente de Android, debe evitar el uso de los nombres de interfaz para colecciones. Por ejemplo, el estándar de mejores prácticas para el estándar de Java sería decir
List<String> strings = new ArrayList<String>();
Mientras que en Android dicen que es mejor declarar que con su tipo en tiempo de ejecución
ArrayList<String> strings = new ArrayList<String>();
tenga en cuenta que, a pesar de estar en la documentación, esto no es realmente cierto. He corregido esto en la documentación de froyo. (en particular, la versión froyo de la documentación no contendrá ningún reclamo que no esté respaldado por un punto de referencia). –
WRT punto flotante:
en un G1, agregar dos flotadores requiere aproximadamente 400ns. agregar dos ints toma aproximadamente 250ns.
en un nexus one corriendo eclair (pre-JIT), ambas operaciones toman alrededor de 120ns. (las entradas son un poco más rápidas, pero tendría que ser microenfoque para notar). Hay una pequeña diferencia porcentual entre int y long, y flotación y doble, pero básicamente si puede pagar una, probablemente puede permitirse la otra.
otros dispositivos actuales estarán en algún lugar entre estos extremos. (otras operaciones también serán diferentes. La multiplicación es más costosa que la suma/resta, y la división es más cara todavía. No hay dispositivos actuales que tengan una división entera de hardware)
pero no se obsesione con nada de esto hasta que tenga un problema . lo más probable es que sus problemas de rendimiento se reduzcan a una mala elección de algoritmo o estructura de datos, como siempre lo son los problemas de rendimiento de todos.
la mayor parte de la documentación de rendimiento actual (eclair) es incorrecta. comparta las cosas usted mismo, en el (los) dispositivo (s) que le interesan.
pero si realmente estabas preguntando "¿qué debería una/servidor java programador de escritorio tener en cuenta?", Me gustaría sugerir: la asignación innecesaria. no tiene un núcleo adicional para hacer su GC como lo hace en el escritorio/servidor, y no tiene gigabytes de montón como lo hace en el escritorio/servidor. Si estás haciendo GC, no estás haciendo un trabajo real, y tu montón será como máximo de 24Mib en dispositivos actuales. por lo que es posible que desee evitar la asignación innecesaria en los bucles internos.
* pero no se obsesione con nada de esto hasta que tenga un problema. es posible que sus problemas de rendimiento se deban a una pobre elección de algoritmo o estructura de datos , al igual que todos los problemas de rendimiento siempre. * Esto es enorme. ¿Puedo darte un abrazo? – Cheezmeister
He encontrado que el emulador AppInventor es extremadamente lento para operaciones de punto flotante, incluso en una máquina 2014 i3/4Gb. Escribí un generador de fractal para comparar el emulador y descubrí que para calcular un solo píxel, 10 iteraciones tardaban poco más de dos segundos, sí, 2.000 ms. No lo he descifrado completamente para descubrir qué operaciones particulares son tan lentas, pero lo haré pronto.
Cada iteración implica cuatro multiplicaciones, dos adiciones y una resta, cinco variables. Las pruebas posteriores a cada iteración implican dos multiplicaciones, una suma y dos comparaciones: aproximadamente 30 fracasos. Todavía no he optimizado el código almacenando los resultados para la próxima iteración.
Claramente, si hay una forma de forzar el punto fijo o usar enteros solo eso ayudaría, pero la magnitud del problema que enfrenté con este pequeño proyecto no es un buen presagio.
A pesar de que estoy de acuerdo con la no optimización temprana, etc., este no es el problema aquí. Si, por ejemplo, todas las operaciones flotantes toman 1ms y todas las operaciones int 1ns, el diseño de todas las estructuras de datos para el punto fijo desde el principio es simplemente de sentido común. – Viktor
Si tiene un presupuesto de 50ms para hacer el trabajo, si toma 1ms o 1ns no importa. Haz que el código funcione y luego preocúpate por los detalles. La conversión entre puntos fijos y flotantes es un día o dos de trabajo en el mejor de los casos. Haz que tu aplicación se ejecute con algoritmos eficientes y luego si necesitas hacer estas optimizaciones. En casi todas las aplicaciones que he analizado, las grandes ganancias nunca están en micro optimizaciones. Se aseguran de que no estés haciendo cosas estúpidas (dibujando objetos 2x, clasificando cuando no es necesario, ...). Hay casos en que la microoptimización es correcta. Lo sabrá cuando ocurra – hacken