Get best of the week

Lo que querrá saber antes de escribir una aplicación para Apple Watch: nuestra experiencia

Le espera una plataforma muy lenta, la transición a nuevos marcos, pruebas con una atmósfera especial y notificaciones del sistema operativo "oye, muévete" un segundo antes de la descarga forzada del hilo.


Sí, esta es mi mano peluda,

nuestro horario de trenes mira a 600 mil personas al día. Y cada año más y más, a través de la aplicación móvil. Pensamos y decidimos hacer una versión para el reloj. El problema era que no sabíamos cuántos Apple Watch hay en el mercado ruso y cuántos de ellos viajan en trenes eléctricos. Pero en cualquier caso, era necesario descubrir cómo hacer esto, así que tomamos y escribimos a Apple pidiendo estadísticas.

Por extraño que parezca, no lo hicieron. Luego ayudaron en todas las formas posibles, pero aquí con las estadísticas hay un problema directo. Nadie tenía datos normales hasta hace un año, e incluso estudiar informes de ventas no ayudó. Los relojes se traen de muchas maneras al "gris" y no desde nuestra región inicialmente.

¿Por qué estadísticas? Para entender cuántas generaciones hay en el mercado. Al final, decidimos admitir todos los dispositivos.


Las últimas estadísticas que conocemos para 2017 se veían así:

  • 1.a generación (todas): 57%
  • Serie 2 (todas) - 32%
  • Serie 1 (todas) - 11%

Mirando hacia el futuro, tuvimos tres meses después del lanzamiento en 2019 así:

  • Apple Watch Series 3 (todos) - 36%
  • Serie 4 (todas) - 31%
  • Serie 5 (todas) - 24%
  • 1.a generación (todas) - 4.5%
  • Serie 2 (todas) - 2.5%
  • Serie 1 (todas) - 2%

Distribución del tamaño de pantalla de las dos últimas revisiones:

  • S4 grande a 44 mm - 58%, pequeño 40 - 42%.
  • S5 grande - 60%, pequeño 40%.

Los modelos anteriores todavía tienen 38 mm, en el número total de todas las instalaciones es un poco menos del 20%, principalmente debido a S3. Por cierto, necesitábamos fuentes para diferentes tamaños de pantalla: nuestros diseñadores hicieron adaptativos.

Plataforma muy lenta


Por lo tanto, parece que no tenemos muchos dispositivos, pero de los cuales hasta un 5% (como se esperaba) serán muy antiguos. Las primeras horas generalmente fueron concebidas, al parecer, como un dispositivo que muestra imágenes que se generan en el teléfono. Luego apareció su propio sistema operativo desarrollado, y en revisiones posteriores, también un Wi-Fi y una tarjeta SIM.

La tarjeta SIM en Rusia no funciona. Quizás, este año los operadores estarán de acuerdo, pero por ahora solo hay wifi y comunicación por teléfono (el reloj se conecta al iPhone a través de Bluetooth y luego usa su conexión a Internet).

La lógica de trabajar con la red, la memoria y el disco es casi la misma que en iOS.Quiero decir, la lógica en sí es común, los servicios son comunes, pero todavía hay una emboscada con las bibliotecas; de hecho, no muchas personas se desarrollan durante horas, por lo que puede que no haya marcos y herramientas populares en iOS / iPadOS. En nuestro caso, esto significó la necesidad de abandonar el montón de bibliotecas que conectamos a una aplicación iOS con el movimiento habitual de la mano.

Sin excepción, todos los relojes realizan accesos muy lentos al disco en comparación con la forma en que se pueden leer desde la memoria. Si en un iPhone no puede realmente molestarse donde se encuentra exactamente la tabla de 40 Kb, entonces en el reloj es fundamental mantenerla en la memoria o recibirla por el aire. Lo más importante es no leer nada del disco.

Por supuesto, cuanto más nuevo sea el reloj, más rápido todo gira, pero, de hecho, trabajamos para S3 con soporte para dispositivos anteriores y características adicionales para S4 y S5.

La versión alfa de la aplicación, que mostraba la ruta a casa, se cargó durante horas decenas de segundos. El horario de MCC se mostró durante 20 segundos en los 4 trenes más cercanos. El problema estaba en el renderizado de la tabla: demasiados elementos individuales. Imagine un navegador moderno que está tratando de representar algo en el núcleo 386SX. Entonces tuvimos problemas similares.

Naturalmente, es por eso que ella es alfa para hurgar con ella. Por beta, distribuimos la carga a través de los hilos (detectando una característica en el camino que cuando el reloj comienza en watchOS 4, el punto de entrada principal no comienza en la corriente principal). Para las horas "débiles", el número de celdas en la interfaz fue limitado.


Cada uno de ellos se procesó durante aproximadamente un segundo.



Algunas optimizaciones de la propia interfaz de usuario, y voló a S4, y para dispositivos más antiguos tuvieron que reducir la cantidad de trenes mostrados.

Insertaron arriba y abajo "mostrar a los difuntos" y "mostrar a continuación", y en los elegidos - "mostrar todo". Dado que este horario a menudo cambia, a menudo era necesario volver a dibujarlo: estamos hablando de situaciones en las que la composición de la mesa cambia ya sea por un tren que partió o por un cambio en el horario (mostramos el movimiento en tiempo real, es decir, sabemos exactamente dónde está cada uno en particular de hecho, y cómo afectará a todas las estaciones a lo largo de la ruta).

A menudo hay situaciones en las que los datos se vuelven obsoletos un segundo después de la solicitud. Con el enfoque básico, toda la tabla se retorció, esta es la forma estándar para iOS. Allí, la actualización es generalmente imperceptible. Y aquí han hecho una gran cantidad de basura basada en el procesamiento de la matriz entrante, que analiza primero los datos, luego construye el diff, luego encuentra los elementos de la interfaz de usuario que se pueden cambiar sin tocar el resto, y luego solo los actualiza. No hay bibliotecas adecuadas para una solución completa en WatchOS, pero hay un Kit diferenciador que, de acuerdo con la matriz de datos con marcado, proporciona una lista de cómo y qué ha cambiado por índice. Escribieron su código alrededor y lo pusieron en todas las tablas. Esto dio un aumento en las actualizaciones de rendimiento.

En general, los trenes N más cercanos se muestran rápidamente, y si desea esperar, pero desea una imagen completa, puede hacer clic en "mostrar todo".

Como dije, el dial en el reloj es grande, pero lento. Primero, usamos un conjunto estándar de bibliotecas de iOS que funcionaban a través del disco. Obtuvimos el cronograma, lo grabamos en un disco, el servicio lo solicitó, lo sacó del disco, lo desenrolló en la pantalla. Al final resultó que, necesita almacenar el caché en la memoria. Y, sin embargo, estamos acostumbrados a guardar todos los estados de trabajo del usuario en el disco y luego leerlos desde allí, solo tuvimos que grabar y almacenar todo lo que pudimos en la memoria.



¿Por qué es necesaria la grabación constante? Porque si el usuario cambia la aplicación, la descarga ocurre casi al instante. Por lo general, no tiene tiempo para escribir nada en el disco de frenado, por lo que debe hacerlo de manera constante e iterativa mientras el usuario está trabajando.

Y luego nos acercamos a la próxima emboscada.

Conservación de energía maníaca


La batería del reloj es pequeña y todo el sistema operativo se agudiza para conservar la energía lo máximo posible. En la práctica, esto puede significar que el usuario está haciendo lo siguiente:

  1. Comienza a descargar algo (por ejemplo, un horario completo)
  2. Baja la mano
  3. Está esperando
  4. Levanta una mano para ver lo que está cargado.

De hecho, sucede lo siguiente:

  1. El usuario comienza a descargar la programación completa.
  2. Baja la mano
  3. Los relojes entienden que no trabajan con ellos y ponen el proceso en un análogo de hybernate.
  4. El usuario espera, luego levanta la mano para mirar el resultado.
  5. En el momento del ascenso, el reloj comprende que continúan trabajando con ellos, se despiertan y despiertan el proceso.
  6. El usuario ve el inicio del indicador de descarga.

Al mismo tiempo, desde el punto de vista del hilo, este puede ser el momento correcto o un "segundo muy largo": si escribe código en los tiempos de espera, puede atrapar inesperadamente incluso un año en el que ha estado esperando medio segundo. Por lo tanto, solo recuerda que el tiempo es relativo.

El proceso de despertar lo amenaza con un largo proceso de depuración: allí puede detectar accidentes por el hecho de que el lugar esté desocupado o que ocurra algo más interesante.

El proceso de quedarse dormido puede convertirse en un proceso de descarga (sin despertarse), por lo que debe escribir algunas cosas en el disco. El sistema operativo le dice al hilo "Ir al fondo" y llama al método apropiado. Por lo general, tiene aproximadamente un segundo para salir rápidamente y volcar en segundo plano. Cuando un usuario hace esto mientras escribe en un disco (que, recuerdo, es infernalmente lento en dispositivos hasta S4), la grabación puede no tener lugar. Para hacer esto, debe ingresar al modo de "operación importante" y, con la ayuda de varias llamadas especiales, mantener el hilo "consciente". Para hacer esto, necesita un controlador separado que le pregunte al proceso de grabación cuándo finalizará, y luego libera el hilo para dormir.

Arquitectura


Nuestra primera aplicación en 2017 fue solo un espacio en blanco, capaz de mostrar el horario generado en el teléfono. Se utilizó para mostrar datos de un tren de larga distancia en una vía, un automóvil y un lugar.

La versión moderna para trenes es "adulta" y autónoma, es decir, puede vivir en cualquier momento sin un teléfono. Incluso desde el momento de la instalación (aunque la forma habitual para que la aplicación ingrese al reloj es a través del teléfono, y en este punto es muy conveniente copiar los datos del perfil y todas las rutas seleccionadas desde el teléfono).

La arquitectura en el reloj es probablemente la más moderna en los patrones de iOS. Redux no es un problema. Nosotros, como en la aplicación "grande", usamos la máquina de estado. El MVC estándar es el siguiente: hay un modelo por un lado, hay vistas para este modelo, en el medio del controlador. El controlador toma datos del modelo, convierte, muestra en la pantalla. En la dirección opuesta, el controlador escucha los mensajes de visualización y proporciona datos al modelo. Basado en este patrón, se han creado muchos tipos de arquitecturas.

Tenemos un estado donde los eventos pueden volar y mutarlo. Los efectos secundarios, que hacen un trabajo útil, pueden apartarse del estado. A partir de estos resultados, los eventos vuelan al estado. El estado completo de la aplicación se almacena en la historia, como un punto único de verdad. El estado se puede dividir en pedazos y dividir, pero en cualquier caso, almacena el conjunto de datos completo. La implementación específica de la arquitectura depende de la religión, tenemos RXFeedback.

La máquina de estados está muy bien cubierta por pruebas. Esto nos ahorró mucho tiempo solo en el reloj, porque las pruebas no se pueden realizar dentro del reloj. Este no es un iPhone para ti. Aquí debes hacer esto:

  1. Compile la aplicación en el emulador y vea.
  2. . , . id Xcode .




Usé S4 y S1 para probar. Dado que muchas cosas son muy difíciles de verificar en el reloj en sí, resultó ser increíblemente conveniente aislar estados específicos (estados), transferirlos a otro componente y ya cubrirlos con pruebas de todos los lados.

El décimo Xcode (que era antes de octubre de 2019) se complació de que, por alguna razón, cuando la aplicación comenzó en el reloj, dejó de funcionar en el simulador. Se decidió cortar el desinfectante comercial, si alguien está interesado.

En consecuencia, al ensamblar objetivos con estados dedicados y con lógica común (había muchos de ellos), debe hacerlos compatibles con el reloj. Accidentalmente enganchamos UIKit un par de veces, y este es el marco UI del teléfono, no es compatible con el reloj. Si accidentalmente recoge en el lanzamiento, la biblioteca simplemente no se conectará.

Autonomía


Caso de uso básico: el usuario tiene un reloj y un teléfono. Regularmente los mantiene juntos, y el reloj puede usar Internet desde el teléfono.



Con los nuevos lanzamientos de relojes, se hizo posible usar su propio Wi-Fi y su propia tarjeta SIM de reloj (hay un e-sim incorporado).

Nuestra tarea es sincronizar favoritos entre dos aplicaciones (en el teléfono y el reloj). Cada vez que comenzamos, tratamos de leer la última verdad, y cada vez que cambiamos la lista, tratamos de encontrar inmediatamente el segundo dispositivo y contarle al respecto. Resulta que, obviamente, no siempre, por lo tanto, si es posible, sincronizamos al inicio. Si hay dos favoritos diferentes que se enfrentan a conflictos, consideramos más preciso lo que está en el teléfono y resolvemos los conflictos a su favor.

De lo contrario, la aplicación no está conectada al teléfono. El caché está dentro, las solicitudes a la red se envían desde el reloj (si es posible), si no, a través del puente a través del teléfono. Como resultado, puede usarlo de forma autónoma durante el tiempo que desee, pero solo necesita instalar la aplicación de alguna manera por primera vez (nuestra versión no admite la instalación desde el reloj directamente desde la aplicación). Después de eso, puede olvidarse de la sincronización, si lo desea. Antes de watchOS 2, el esquema de aplicación habitual era que todo se contaba y se hacía por teléfono, y el reloj solo mostraba el resultado.

Total


La aplicación básica para iOS aquí . La aplicación de reloj está emparejada con ella. La aplicación utiliza una versión del lanzamiento, pero en un dispositivo específico se adapta a ella en términos de velocidad y adapta la interfaz al tamaño de la pantalla. La primera autorización al instalar por teléfono, en el mismo lugar, copiando favoritos y rutas frecuentes. Más sincronización o existencia autónoma. Geolocalización desde el teléfono (esto es necesario para comprender si se encuentra en Moscú o desde Moscú, si no permite geo o no, está orientado al tiempo, invirtiendo las solicitudes de la mañana). Hubo casi tantas instalaciones como se esperaba (tomamos en cuenta que no hay muchas horas en Rusia, y sus usuarios están en trenes eléctricos). A juzgar por las revisiones, los usuarios de la aplicación en el reloj están contentos de ver su horario en la escalera mecánica.

More articles:


All Articles