¿Cómo es desarrollar aplicaciones para Android e iOS al mismo tiempo?

Un cielo y un infierno.

Uno: entorno de desarrollo

Xcode para iOS es la basura entre la basura, especialmente el soporte actual para Swift. Cuando lo usé antes, el resaltado de código fallaba cada tres veces. La cantidad de fallas de Xcode debe ser varias veces mayor que la del IDE de Android, y está realmente atascado. Parece que no hay 60 fotogramas al arrastrar hacia arriba y hacia abajo.

Eclipse antes de Android también era una basura, pero Intelijia/Android Studio posterior era mucho mejor. Hay demasiados códigos, así que simplemente le asigno memoria 3G (mi computadora es 16G rmbp de 13 pulgadas), lo cual será mucho mejor. Pero desde que Android cambió completamente a Gradle, siento que la compilación de Gradle es realmente lenta, especialmente cuando varios módulos dependen de él. Es una pesadilla cuando el método que requiere multidex excede 6k5, porque la compilación incremental no es compatible después de activar multidex. En este sentido, iOS es mucho mejor. iOS usa cocopod para administrar dependencias, y la velocidad de compilación de cambiar algunas líneas de código es de hecho más rápida que Gradle.

Sin embargo, iOS puede usar AppCode, pero esto no puede seguir el ritmo de lanzamiento de Xcode, como iOS9, Xcode7, pero escribir AppCode es demasiado antiguo y varios errores gramaticales pueden generar una nueva versión de desarrollo. , pero la versión de desarrollo que admite nuevas funciones de iOS definitivamente está incompleta.

En segundo lugar, el lenguaje de desarrollo

La sintaxis OC de iOS es extraña y engorrosa, pero los hábitos son buenos. Esto llama a C/C++ mucho mejor que el Java utilizado por Android. Más tarde, Swift se mejoró demasiado y aún es inmaduro. La razón principal es que Xcode es demasiado basura, pero ahora cada vez más aplicaciones de iOS están escritas en Swift. Java para Android está muerto, muerto en 1.7. Es imposible instalar Lambda 1.8, aunque existen bibliotecas de terceros que lo hacen. Kotlin de Jetbrain acaba de comenzar a admitir Android, ni siquiera 1.0. Si desea utilizar Kotlin para escribir Android, debe esperar al menos 2 o 3 años.

Tres: navegación de página y guardado de escenas

IOS usa ViewController, Android usa Activity, VC's push==startActivity de Android, VC's present==DialogFragment.show.

No importa qué sistema haya, hay un problema de memoria insuficiente cuando la aplicación se corta en segundo plano, Android admite de forma nativa escenas de guardado serializadas, de modo que la aplicación se puede restaurar después del reciclaje (por supuesto). no es necesario hacer esto, como Baidu. Una determinada versión del mapa es así, sobrecargándose cada vez que se corta). Los fragmentos son tan complejos que iOS no los admite de forma predeterminada, lo que requiere que los desarrolladores escriban ellos mismos códigos muy complejos. Entonces puedes ver que básicamente ninguna aplicación de iOS se puede restaurar a la escena después de haber sido destruida en segundo plano. Generalmente, las aplicaciones de iOS con páginas de recarga complejas necesitan usar ViewController para incrustarse entre sí, lo que se denomina contenedor ViewController. En Android, un fragmento incrustado activo incorpora fragmentos secundarios.

Debido a que no es necesario guardar datos entre VC, simplemente asigne un valor a un determinado atributo del objeto VC directamente. Androd debe pasar Intent y los datos deben admitir la serialización. Por supuesto, si no quieres guardar la escena, como en iOS. De hecho, no sé cuál es mejor, porque algunas personas en iOS se quejaron de que el enfoque de iOS hacía que las dos parejas VCS fueran demasiado poderosas.

Cuatro: Memoria de la aplicación

Después de iniciar la aplicación iOS, casi la mitad de la memoria total del sistema está disponible, pero hay una gran brecha entre Android y Android, desde 32 MB. a 195 MB+ (memoria total 2G), que está relacionada con la memoria total de todo el teléfono. Me pregunto cuál es el tamaño del montón de un teléfono Android que no ha usado memoria 3G o 4G. Esto hace que la memoria de Android sea más propensa a sufrir problemas. De todos modos, un problema es que el código no está bien escrito y se pierde memoria debido a referencias fuertes.

Cinco: UI, adaptación de compatibilidad

IOS ha pasado de los primeros marcos manuales al cambio de tamaño automático para adaptarse a ip4 e ip5, a AutoLayout posterior y luego a la clase Size. Pero el diseño automático de StoryBoard es muy, muy difícil de utilizar. Una interfaz ligeramente compleja y un montón de restricciones a la izquierda que son imposibles de cambiar. En comparación, ahora me duelen los ojos cuando me quejo. Mucha gente usa bibliotecas de AutoLayout de código de terceros, como Masonry, pero todavía me resulta tedioso de usar. Para adaptarse, iOS9 agregó UIStackView, que en realidad es LinearLayout de Android. Otro problema con AutoLayout es el bloqueo, por lo que básicamente nadie usará AutoLayout en las celdas de UITableView, y todos son diseños de cuadros manuales.

Ha habido muchos debates durante el proceso de desarrollo de iOS, como el diseño del dibujo del código (ya sea un marco manual o varias bibliotecas de diseño de terceros) o el guión gráfico completo/Xib, los cuales son repugnantes. Dibujo de código, VC es diseño y negocio, este último no puede ser utilizado por humanos. StobyBoard/Xib no es legible en absoluto, lo cual es un desastre para la gestión de versiones. Y personalmente dudo que Xcode pueda abrir un guión gráfico complejo sin que falle.

Android generalmente usa XML para dibujar diseños y códigos para empresas, lo cual es relativamente mejor. XML es muy fácil de leer y escribir. ListView escribe una celda mucho más rápido que UITableView. iOS requiere que calcules la altura tú mismo. Por supuesto, no es necesario. Como dije anteriormente, si no le temes al retraso, el problema con la compatibilidad con Android es la compatibilidad con Rom, especialmente de fabricantes nacionales. Debido a que hay demasiados cambios en la capa del marco, es fácil meterse en problemas.

En cuanto a los peligros de las API del sistema y las actualizaciones de versiones del sistema, mi impresión es que tanto iOS como Android no faltarán y no podrán escapar. Acepto mi destino honestamente y encuentro soluciones.

Seis: subprocesos múltiples

Operación GCD del marco de subprocesos múltiples Executor de iOS y Java. En lo que respecta al desarrollo del lado del cliente, creo que no hay problemas ni dificultades en ninguno de los dos y ambos pueden satisfacer las necesidades. Por supuesto, tal vez soy demasiado superficial.

Siete: Almacenamiento

Aunque iOS tiene CoreData, nadie lo usa. Todo el mundo ama SQLite. Androd oficialmente no tiene una solución ORM. Para ser honesto, SQLite, ORM de terceros, de todos modos me siento culpable por las pocas carpetas asignadas a la aplicación por iOS. Si escribe en una carpeta que no debería escribirse, como una carpeta de la que iCloud hará una copia de seguridad, la App Store la rechazará. Pero Android es muy informal. Se puede leer y escribir toda la tarjeta SD. Una determinada versión de Android prohíbe escribir en el segundo espacio de almacenamiento (principalmente tarjetas SD).

Ocho: Animación

RunLoop de iOS es el Handler/Looper/MessageQueue de Android. iOS tiene múltiples modos de RunLoop que pueden suprimir otros mensajes de la interfaz de usuario mientras se desplaza, de manera muy similar a MessageQueue. IdleHandler en Android. Debido a que iOS necesita compartir código con OS X ***, que es visualización en pantalla dividida y procesamiento de eventos (pantalla táctil en teléfonos móviles, mouse y teclado en computadoras), existen CALayer y UIView. Debido a que Android no tiene bagaje histórico, View lo maneja. La animación de IOS se puede operar directamente usando CALayer, mientras que Android generalmente usa Animator para operar View. Sin embargo, debido a la compatibilidad de la versión, muchas personas todavía usan animaciones 2.x para las animaciones de Android, lo cual es mucho peor. Una de las ventajas de Animator es que puedes cambiar las propiedades a voluntad con el tiempo. Recuerdo que Facebook hizo lo mismo con Pop para iOS, sino tendrías que usarlo tú mismo.

Paquete CADisplayLink.

TimingFunction es responsable de la velocidad durante la animación en iOS, mientras que en Android es la ruta correspondiente al interpolador de la curva de Bézier UIBezier.

Ver la escena de corte del controlador UIViewControllerTransitioning corresponde a ActivityTransition de Android5, pero no puede mantenerse al día con la versión móvil general de Android. . . . Pocas personas usan ActivityTransition. Androd no tiene la biblioteca dinámica UIKit para iOS, por lo que solo puede escribir algunos efectos especiales por sí mismo.

Nueve: En el estante

Tomaré la situación interna como ejemplo. Si tiene una aplicación nueva, necesita un mes para prepararla para la AppStore. El tío Apple revisa tu aplicación una vez por semana. Si un elemento falla, espere otra semana. Los comentarios solo le darán capturas de pantalla y descripciones. Puede corregirlo y luego habrá nuevos problemas la próxima semana, por lo que le llevará aproximadamente un mes ir y venir cuatro veces.

En China no existe Google Play. Tienes que ir a Xiaomi Store, Wandoujia, App Store o 4 Days. Es mucho más fácil que Apple, pero hay muchos canales y es más molesto. Generalmente, es necesario cambiar el script de Gradle para empaquetar paquetes de diferentes canales para determinar cuánto se distribuye realmente en el mercado de aplicaciones correspondiente. Todos ellos están relacionados con el dinero.

Diez: Siento que Apple me está jodiendo cuando escribo sobre iOS, y que los fabricantes de teléfonos móviles me están jodiendo cuando escribo sobre Android.