Android, programación orientada a objetos vs diseñar para el funcionamiento

Soy un noob completo para Android, pero he estado programando c # durante mucho tiempo. Estoy escribiendo una aplicación android y he llegado a un punto en el que el programador c # en mí quiere empezar a crear un diseño ligeramente acoplado y y mover el código en diferentes capas, utilizando interfaces, etc

Pero luego me tropiezo con el diseño de las directrices de rendimiento que me está diciendo que evitar la creación de objetos y luego también está diciendo para optimizar judicialmente .

¿Acabo de construir basado en un buen diseño y luego tratar con problemas de rendimiento a medida que vienen?

Lo último que quiero hacer es pasar por el trabajo de construir una aplicación y hacer que funcione mal. ¿Puede alguien señalarme algunos ejemplos de aplicación que están bien diseñados y tienen buen rendimiento o simplemente hacer algunas recomendaciones?

Gracias

He encontrado AndEngine para ser bastante bien diseñado y tiene que estar preocupado con el rendimiento, ya que es una biblioteca de desarrollo de juegos – por lo que podría tirar hacia abajo una copia de él y leer la fuente.

En el documento "Diseño para el desempeño", quisiera señalar esta declaración:

Tenga en cuenta que aunque este documento abarca principalmente las micro-optimizaciones, éstas casi nunca harán o interrumpirán su software. La elección de los algoritmos y estructuras de datos adecuados siempre debe ser su prioridad , pero está fuera del alcance de este documento.

Un ejemplo de esto sería la creación de un sistema de partículas. Una buena manera de modelar es tener un objeto ParticleSystem que contiene una colección de objetos de partículas … tal vez esas partículas implementan una interfaz de partículas … este no es el lugar para evitar la creación de objetos. Sin embargo, por razones de rendimiento, querrá optimizar el ParticleSystem para reciclar objetos de partículas en lugar de crearlos desde cero cada vez que genere uno.

Personalmente, no he encontrado el rendimiento para ser un factor limitante, pero supongo que realmente dependerá de qué tipo de aplicación que está construyendo.

Mi opinión es construir un diseño adecuado primero, probar el rendimiento y optimizar desde allí.

Preste más atención a la cita de Donald Knuth que aparece en el mismo artículo:

"Debemos olvidarnos de las pequeñas eficiencias, digamos alrededor del 97% del tiempo: la optimización prematura es la raíz de todo mal.

Entonces si usted está tratando con el otro 3% que usted verá …

Como regla general, lo que debemos hacer es mantener la estructura de datos tan simple y normalizada como sea posible. Al igual que no sólo tirar en hash mesa de datos de las estructuras sólo porque son fáciles de agarrar. Saber hacer el perfil ( aquí está mi método ) y si usted tiene un problema verdadero del funcionamiento entonces lo soluciona. De lo contrario, cuanto más sencillo mejor, incluso si eso significa arrays simples, listas y bucles O (N).

La razón para mantener la estructura de datos normalizada es, si no lo es, entonces puede tener estados inconsistentes, y tendrá una fuerte tentación de escribir código de estilo de notificación para intentar mantenerlo coherente. Esos pueden ser verdaderos asesinos de rendimiento. Si lo hace, el perfil le dirá que es lo que está sucediendo. Si debe tener datos redundantes, creo que es mejor ser capaz de tolerar alguna incoherencia temporal, que se repara periódicamente al pasar por los datos. Esto es mejor que intentar garantizar intensamente la consistencia en todo momento mediante notificaciones.

Otro problema con la estructura de datos no normalizada es que puede tener gran cantidad de objetos de creación y destrucción. Eso también puede ser un asesino de rendimiento real, aunque se puede mejorar con la técnica de la piscina.