¿Cuáles son algunos consejos para desarrolladores para el sistema Android?
Esta es una buena manera de comenzar con la programación de Android:
Encuentre algún código que sea similar al que desea hacer
Modifíquelo e intente crear hace lo que usted hace
Experimente el problema
Utilice StackOverflow para resolver el problema
Repita el proceso anterior para cada función que desee agregar. Este enfoque te motiva porque sigues iterando y aprendes mucho sin darte cuenta. Sin embargo, hay algunas cosas más detalladas que debes hacer cuando publiques tu aplicación.
Pasar de un código que funciona a una aplicación horrible es un gran salto, especialmente Android en comparación con la plataforma iOS. Cuando publicas una aplicación en iOS, ¿solo estás saltando a un dispositivo? ¿Tu teléfono es muy similar a muchos dispositivos con pantalla del mismo tamaño, todos tienen un excelente hardware y el 95% ejecuta la misma versión del sistema operativo? No encontrarás esta situación en las aplicaciones de Android.
Tu programa debe poder manejar todo: desde la pantalla, el procesador, el sistema operativo personalizado, el nivel API y cualquier otra característica específica del dispositivo.
Este es mi consejo personal para hacer que las aplicaciones de Android sean cómodas.
Tamaño de pantalla de destino y soluciones
Actualmente existen más de 100 tamaños de pantalla diferentes en el mundo Android, pero también existen muchas soluciones. Hay dos cosas que debes asegurarte para adaptar tu aplicación a diferentes configuraciones de pantalla:
Tienes un buen diseño y estructura para los diferentes tamaños de pantalla
Tus imágenes aparecerán de manera diferente en diferentes tamaños de pantalla. Funciona bien en diferentes resoluciones
Estas son tareas separadas, es posible que tengas un diseño de súper tableta pero los gráficos encima se ven terribles. Los discutiremos por turno.
Diseñado para diferentes pantallas
1. Generalmente se hace fácilmente con ScrollView y ListView
Cuando tenemos una serie de teléfonos móviles de pantalla grande y de diferentes tamaños, La mayor diferencia es la altura de la pantalla. Por lo tanto, ScrollView y ListView generalmente funcionan de manera efectiva, aunque a veces no cubren completamente toda la pantalla. En la pestaña Panel de control de OpenSignal, podemos ver que todos los componentes están integrados de una sola vez. Para muchos tipos avanzados de etiquetas, la visualización deslizante no es necesariamente algo malo. Sería mejor si pudiera combinar todos sus diseños con varias pantallas. De lo contrario, estos dos controles le permitirán asegurarse de que su software se muestre correctamente en la mayoría de las pantallas con un mínimo esfuerzo de desarrollo.
El diseño de estilo panel no requiere desplazamiento
2: Utilice la estructura de carpetas de recursos de Android es muy poderosa, lo que permite a los desarrolladores combinar diferentes imágenes, cadenas, archivos de diseño, formas y colores. y otros recursos, en la API, código, tamaño de pantalla, etc. El siguiente es un ejemplo que muestra lo que puede hacer en la carpeta de recursos:
Se almacena en la carpeta pequeña de valores A bools.xml archivo con las siguientes líneas de código:
En el código puedo citar así:
if(getResources().getBoolean(R.bool.small_screen)){
getSupportActionBar().hide ();
}
El valor booleano se establecerá en verdadero en dispositivos de tamaño pequeño. Usaré ActionBar para ahorrar espacio en este momento. Este código es extraordinario. Parte de ActionBarSherlock. biblioteca de extensiones, que se presentará en detalle más adelante. En la carpeta de valores-sw360dp, se almacenan los archivos de recursos correspondientes a pantallas de más de 360 dp.
En la misma ubicación que el anterior, se encuentra el siguiente código
< /resources>
Para pantallas grandes, la ActionBar está configurada en el estado de visualización.
No necesito colocar el archivo bools.xml en la carpeta de valores-sw400dp, porque el El sistema operativo presionará automáticamente Búsqueda de ruta correspondiente. Por ejemplo, si un dispositivo tiene 600 dp de ancho (600/160 = 3,75 pulgadas, que es lo que normalmente llamamos un dispositivo de 7 piezas), el sistema operativo buscará el archivo bools.xml. en valores-sw600dp y las carpetas que contiene. Si no se encuentra, busque la carpeta valores-sw400dp, luego busque la carpeta valores-sw360dp, y así sucesivamente.
Se recomienda 3:160dp. = 1 pulgada. 320 dp = 2 pulgadas. dp = dip
Recomendación 4: puede utilizar estas técnicas de estructura de directorios para tratar con todos los tipos de recursos. Por ejemplo, su diseño XML utiliza nombres de directorios del sistema específicos
para resolver este problema. como el directorio :layout-sw360dp puede coincidir con máquinas con un ancho objetivo de 360 dp. Si también desea admitir el cambio de diseño de pantalla horizontal y vertical, puede utilizar el siguiente directorio:
layout-sw360dp-land
layout-sw360dp-port
No te preocupes, ¿la mitad de tus usuarios son hablantes de árabe? Luego cambie el nombre del diseño al siguiente:
layout-sw360dp-land
layout-sw360dp-port
layout-sw360dp-land-ar
layout-sw360dp-port-ar
Los dos primeros se pueden aplicar a todos los idiomas, -ar representa árabe.
Sugerencia 5: Introducción a las reglas de recursos:
XXX //Ejemplo: No se agregó ningún nombre de directorio: Predeterminado - aplicable a Nexus One, Droid 2, S2
XXX -sw360dp // ¿Teléfono más grande? Galaxy Nexus, S3, S4
XXX-sw600dp // tableta de 7″
XXX-sw720dp // tableta de 10
Hay algunas diferencias en los dispositivos Kindle, como sigue:
XXX-large-mdpi // kindle fire 7〃
XXX-large-hdpi // kindle fire 7〃 HD
Sugerencia 6: Si no desea recortar todos los archivos de diseño, puede utilizar el archivo dimens.xml.
Si prestaste atención a mi artículo anterior, notarás que tengo muchos dimens.xml en mi directorio de valores. Esto se debe a que prefiero establecer los valores en un diseño.xml. en cada archivo de diseño:
android:layout_centerHorizontal="true" android:layout_marginTop="@dimen/small_margin" android: layout_width="@dimen/dashBoardWidth" android:layout_height="@dimen/dashBoardHeight" android:id="@+id/dashboard"/> small_margin se define en el archivo dimen.xml: Esta variable 4dp está en archivos de todas las dimensiones. Tengo un archivo de Excel donde creé todas las definiciones de diferentes tamaños necesarias en función de diferentes factores. Quizás se pregunte: ¿Por qué no dejar que el sistema operativo Android se encargue de todos los problemas de tamaño? ¿Por qué no, por qué no tener un directorio de valores y un directorio de diseño en lugar de todos los valores codificados? Por supuesto que es posible, si se configura correctamente, se obtendrán todos los tamaños, pero para algunos elementos parece que no es tan fácil calcular el tamaño. Recomendación 7: Hacer el espacio en blanco más grande que el espacio de la imagen. Haga que el espacio de la imagen sea mayor que el tamaño del botón. Los botones, casillas de verificación y controles de conmutación se verán feos si se agrandan. Un botón con un tamaño de 100dip (0,63") no quiere parecer dos veces más ancho que 200dip (1,25") en una tableta. La razón es que la pantalla se ha vuelto más grande. Esto no significa que las tabletas sean para gigantes. Podemos hacer esto agregando espacios en blanco entre el espacio que agrega el botón y el espacio que expande la imagen. Sugerencia 8: utilice la herramienta GraphicalLayout para obtener una vista previa rápida. GraphicalLayout es un editor XML WYSIWG. Prefiero el enfoque de programación visible de escribir elementos directamente, en lugar de arrastrar y soltar, pero después de agregar algunos elementos, uso el menú de selección desplegable de GraphicalLayout para seleccionar diferentes tamaños de pantalla para realizar pruebas. Hay muchas opciones entre las que puedes elegir. Escalado de imagen Sugerencia 9: No escale todas las imágenes. Usar archivos de diseño para adaptarse a diferentes tamaños de pantalla es solo la mitad de la batalla. Los elementos del diseño (como las imágenes) también deben funcionar bien en pantallas de alta resolución. El enfoque conceptualmente más simple es crear un conjunto completo de directorios de imágenes y combinarlos con muchos directorios dibujables. drawable-sw600dp-ldpi drawable-sw600dp-mdpi drawable-sw600dp-hdpi drawable-sw600dp-xhdpi drawable-sw600dp-xxhdpi ...Otros son similares. No hagas esto: No te tomes la carta demasiado en serio. En términos generales, es suficiente tener directorios drawble-ldpi, drawable-hdpi y otros, y no es necesario agregar todas las situaciones. Recomendación 10: Evitar el uso de mapas de bits (jpg, png). Para algunos íconos, usar mapas de bits es una buena opción porque son fáciles de usar. Pero si puedes evitar el uso de mapas de bits, puedes ahorrar mucho espacio. Pero también se pueden conseguir buenos resultados utilizando diferentes métodos. Recomendación 11: Utilizar XML para dibujar. Los mapas de bits se pueden reemplazar con dibujos XML. El dibujo XML no es una panacea, pero todavía me sorprende lo conveniente que es. Hay una introducción detallada en la documentación de desarrollo de Android. Aquí hay un ejemplo simple: Aquí hay un rectángulo redondeado definido con un lado degradado (azul oscuro). Puede hacer referencia a él en cualquier parte del archivo de diseño y se adaptará a cualquier pantalla. Úselo para hacer botones ideales. Recomendación 12: Utilizar más dibujo XML. Introduzcamos un ejemplo del uso de dibujo XML para entusiasmarlo más. ¿El siguiente fondo de radar parece más complicado? No hay nada de malo en no usar mapas de bits para su interfaz de usuario (excepto para los íconos). Recomendación 13: seguir utilizando más dibujos XML (y mapas de bits si es necesario). Entonces, ¿cómo construimos un ícono genial para una señal meteorológica? Dejamos que la bombilla se llene dinámicamente y automáticamente según la intensidad de la luz, y ¿cómo hacemos que el puntero gire cuando hacemos clic en él? Aquí usamos mapas de bits y XML como ejemplo: Para bombillas, usamos imágenes PNG: icon_magnitude_min (una bombilla vacía) e icon_magnitude_max (una bombilla llena de luz), y luego recortamos dinámicamente el último. Para lograr esto haré esto: En el programa java obtendré una referencia al clip y luego podré usarlo para controlar la intensidad de la luz. Recomendación 14: ¿Por qué usar 9 parches (cuando puedes usar elementos de diseño XML)? Android tiene la opción de usar 9 parches para definir elementos de diseño, y algunos tutoriales explican cómo usarlos para crear un botón. lo que mantiene algunas esquinas sin cambios al estirar (y evita el procesamiento de píxeles). Si ya sabe cómo usar 9 parches, tal vez gracias al diseño web, entonces puede que valga la pena usarlos. Si no está familiarizado con los 9 parches, le sugiero que lo deje como está. Si quieres adaptar algo, como el arco de una esquina o un color, crear 9 mosaicos es más complicado que crear un mapa de bits, es como volver a la época de los editores de imágenes. Muchos de los efectos logrados con 9 parches también están disponibles vía XML. Recomendación 15: Crear vistas personalizadas anulando onDraw(). Algunas cosas en las que XML no es muy bueno. Hemos dibujado muchas imágenes en OpenSignal y WeatherSignal. Hay muchas bibliotecas para esto, pero tenemos que escribir. el código usted mismo para imágenes personalizadas. Esto es muy interesante. Es posible que nunca necesite hacer esto, pero para que la imagen sea altamente dinámica y personalizable, a menudo es la única forma factible. Recomendación 16: Utilice SVG cuando no se pueda utilizar XML. A veces es demasiado técnico anular onDraw() y escribir código diligentemente para dibujar las líneas y arcos necesarios para una vista personalizada. Después de todo, existe un lenguaje de gráficos vectoriales llamado Scalable Vector Graphics. ¿También es el centro neurálgico de una de las mejores aplicaciones de Android de todos los tiempos? De hecho, crearon esta biblioteca solo para esa aplicación y la publicaron aquí: SVG para Android. Esto es lo que usamos para dibujar el panel en OpenSignal. Recomendación 17: Archivos GZip SVG. Hazlos más pequeños y se procesarán más rápido. Recomendación 18: La biblioteca SVG no lo admite todo. Hay algunos canales alfa específicos que no parecen funcionar correctamente, e incluso hay que eliminarlos en el código. Lograr el objetivo de una visualización consistente en todas las versiones de Android Recomendación 19: en algunos sistemas Android (como TouchWhizz/HTC Sense/MotoBlur, etc.), los botones y Otros componentes de la interfaz de usuario se verán muy diferentes a los del sistema nativo. Ojalá esto no fuera cierto, pero lo es. Recomendación 20: Personaliza los componentes de tu UI. Para asegurarse de que su aplicación se vea consistente en todos los dispositivos, deberá personalizar todo. En realidad, esto no es tan difícil como cree. Una vez que lo haga, comprenderá mejor la apariencia de su aplicación. Recomendación 21: Los selectores son una poderosa herramienta para crear botones. Mencionamos anteriormente cómo definir el fondo de un botón en XML, pero ¿cómo se crea un botón que cambia cuando se presiona? Es simple: define el fondo en un archivo xml como se muestra a continuación. El archivo xml recibirá el estado actual del botón y realizará los cambios correspondientes en su apariencia. Sugerencia 22: ActionBar y muchos estilos de animación no existían en versiones anteriores de Honeycomb, por lo que puedes usar ActionBarSherlock y NineOldAndroids en su lugar. Los componentes de código abierto de Android escritos por Jake Wharton son obras maestras de la compatibilidad con versiones anteriores. Lo que es aún más sorprendente es que ABS tiene funciones poderosas para definir ActionBar. Toma la velocidad como objetivo Recomendación 23: Prueba en un teléfono lento. Encontrarás muchos problemas en un teléfono lento y al mismo tiempo te volverá loco. A nadie le gustan los programas lentos. Recomendación 24: Minimizar los niveles de diseño XML. Más capas significan que el sistema tendrá que trabajar más para analizar su código, lo que hará que la imagen se procese más lentamente. Recomendación 25: Usar Android Lint. Haga clic derecho en el directorio del proyecto y seleccione Eclipse>Herramientas de Android>Ejecutar Lint. Obtendrá información sobre el programa y mejorará la velocidad de ejecución del programa, o puede hacer que su código sea más limpio. Sugerencia 26: Android Lint puede recibir mensajes de error. Puede proporcionar información muy detallada sobre su código y brindarle sugerencias antes de cometer errores. Recomendación 27: Usar Sugerencia 28: Utilice HierarchyViewer para ver intuitivamente la jerarquía de su diseño. Esta herramienta inteligente le muestra cuántas capas hay en un diseño y puede señalar aquellas que pueden ralentizar su programa. Sugerencia 29: Utilice RelativeLayout si es posible. AbsoluteLayout ha caducado, así que no lo utilices. A menudo se encuentra con la situación de elegir entre RelativeLayout y LinearLayout y luego usar RelativeLayout directamente, porque le permite reducir la jerarquía de vistas. Por ejemplo, si desea implementar una vista de la siguiente manera: El cuadro A está en la mitad izquierda de la pantalla | El cuadro B está en la mitad derecha de la pantalla El primero Lo que se te ocurrirá es esto: android:layout_width=?match_parent? android:layout_height=?wrap_content? android:orientation=?horizontal? > android:text=?Box A ocupa la mitad izquierda de la pantalla? android:layout_width=?0dip? android:layout_height=?wrap_content? android:layout_weight=?1? /> /p> android:text=?¿El cuadro B ocupa la mitad izquierda de la pantalla? android:layout_width=?0dip? android:layout_height=?wrap_content? android:layout_weight=?1? /> Eso funciona bien, pero también puedes usar: android:layout_width=?match_parent? android:layout_height=?wrap_content? android:orientation=?horizontal? > android:text=?Box A ocupa la mitad izquierda de la pantalla. android:layout_width=?match_parent? android:layout_height=?wrap_content? android:layout_toLeftOf=?@+id/dummy_center? /> android:id=?@+id/dummy_center? android:layout_width=?0dip? android:layout_height=?0dip? android:layout_gravity=?center? /> android :text=?¿El cuadro B ocupa la mitad izquierda de la pantalla? android:layout_width=?match_parent? android:layout_height=?wrap_content? android :layout_toRightOf=?@+id/dummy_center? lativeLayout> La segunda forma es mucho más fea que la primera, de hecho bastante mala: hemos introducido un elemento completamente nuevo. Pero si queremos agregar una imagen a cada cuadro, generalmente haremos esto: El cuadro A tiene una imagen en la mitad izquierda de la pantalla|El cuadro B tiene una imagen en la mitad derecha de la pantalla Uso En el primer método, debe crear un LinearLayout con dos niveles. Si usa el segundo método, puede agregar imágenes directamente al mismo RelativeLayout. Por ejemplo, debe especificar el primero. la imagen debe estar en el lado izquierdo de "dummy_center" y A TextView A también debe estar a su izquierda. Luego tienes que usar 7 elementos y 3 niveles de vista (método LinearLayout), mientras que (método RelativeLayout) solo usa 6 elementos y 2 niveles, para que todo el trabajo esté completo. Sugerencia 30: Utilizar algunas herramientas de extensión como DDMS. Esto puede ayudarle a encontrar algunas llamadas de red innecesarias, ver el uso de la batería, información de recolección de basura, cambios de estado (por ejemplo: cuando se devuelve la llamada a onStop y onDestroy), etc. LittleEye es mi herramienta favorita actual. Recomendación 31: Utilizar AsyncTasks. El equipo de ingeniería de Android estaba harto de que la gente hiciera llamadas de red con frecuencia en el subproceso de la interfaz de usuario (anotación: operaciones que consumen mucho tiempo y bloquean fácilmente las actualizaciones de la interfaz de usuario), por lo que implementaron algunas API que generan mensajes de error a nivel de compilación. Pero todavía hay algunas tareas en muchas aplicaciones que bloquearán el hilo de la interfaz de usuario. Necesitamos considerar un diseño rápido de la interfaz de usuario y mejorar la capacidad de respuesta de la interfaz de usuario. La máquina de destino tiene poco espacio Recomendación 32: Algunos dispositivos Android tienen un límite de espacio de 100 MB. La situación ha cambiado ahora, pero muchos usuarios todavía temen que una aplicación de 5Mb desperdicie espacio. Esto no es un problema si tiene la opción de cargar la aplicación en la tarjeta SD, pero si su aplicación necesita iniciarse en onBoot, no puede cargar la tarjeta SD (por ejemplo: algunos widgets de formulario, incluso para algunos dispositivos nuevos). , los usuarios estarían felices si pudieran descargar rápidamente un pequeño APK. Recomendación 33: Utiliza recursos XML (te juro que ya te lo recordé la última vez), esto ahorrará mucho espacio que los recursos PNG, cuando solo necesitas una configuración que pueda satisfacer muchos tamaños de pantalla, un XML El archivo ahorrará espacio que un PNG que puede lograr la misma función. Sugerencia 34: Si desea utilizar PNG, es mejor optimizarlo (use PNGCrush o ImageOptim) Apuntar a errores Sugerencia 35: En el Consola de desarrollador de Android Verifique todos los errores detectados automáticamente. Recomendación 36: ProGuard ahora está habilitado de forma predeterminada (aumenta la velocidad de su aplicación y reduce el tamaño del archivo), pero también hace que StackTraces sea muy difícil de manejar. Deberá volver a rastrear sus StackTraces, por lo que deberá continuar conservando los archivos de mapeo de Proguard creados en cada compilación. Los puse todos en carpetas con el nombre del número de versión del código. Recomendación 37: Para mostrar el número de líneas en StackTraces, es necesario modificar la configuración de ProGuard. Asegúrese de que su proguard.cfg tenga la siguiente oración: -keepattributes SourceFile,LineNumberTable Recomendación 38: Utilice implementaciones por etapas. Pruebe el 5% de sus usuarios base y observe los informes de errores. Recomendación 39: Utilizar dispositivos reales para probar la plataforma. Device Anywhere y Perfecto Mobile proporcionan plataformas de prueba virtuales donde puede utilizar dispositivos móviles reales. Los encontré un poco torpes y agregar pruebas continuas podría generar algunas situaciones malas. Si trabaja en un entorno de trabajo conjunto o tiene algunos amigos desarrolladores de Android, inicie un "grupo de dispositivos". Recomendación 40: Escribe más código y menos blogs. En realidad no, compartir es cuidar. Simplemente no puedo pensar en lo que dice el Artículo 40.