Get best of the week

O que você deseja saber antes de escrever um aplicativo para o Apple Watch: nossa experiência

Uma plataforma muito lenta espera por você, a transição para novas estruturas, testando com uma atmosfera especial e notificações do sistema operacional “ei, mova” um segundo antes do descarregamento forçado do encadeamento.


Sim, esta é a minha mão cabeluda,

nosso horário de trem é de 600 mil pessoas por dia. E a cada ano mais e mais - através do aplicativo móvel. Pensamos e decidimos fazer uma versão para o relógio. O problema era que não sabíamos quantos Apple Watch existem no mercado russo e quantos circulam em trens elétricos. Mas, em qualquer caso, era necessário descobrir como fazer isso, então pegamos e escrevemos para a Apple solicitando estatísticas.

Curiosamente, eles não o fizeram. Então eles ajudaram de todas as formas possíveis, mas aqui com estatísticas há um problema direto. Ninguém tinha dados normais há um ano e nem mesmo estudar relatórios de vendas ajudou. Os relógios são trazidos de várias maneiras para o "cinza" e não da nossa região inicialmente.

Por que estatísticas? Para entender quantas gerações existem no mercado. No final, decidimos dar suporte a todos os dispositivos.


As últimas estatísticas que conhecemos para 2017 eram assim:

  • 1ª geração (tudo) - 57%
  • Série 2 (tudo) - 32%
  • Série 1 (tudo) - 11%

Olhando para o futuro, tivemos três meses após o lançamento em 2019 assim:

  • Apple Watch Series 3 (tudo) - 36%
  • Série 4 (tudo) - 31%
  • Série 5 (tudo) - 24%
  • 1ª geração (tudo) - 4,5%
  • Série 2 (tudo) - 2,5%
  • Série 1 (todos) - 2%

Distribuição do tamanho da tela das duas últimas revisões:

  • S4 grande em 44 mm - 58%, pequeno 40 - 42%.
  • S5 grande - 60%, pequeno 40%.

Os modelos anteriores ainda possuem 38 mm, no número total de todas as instalações é um pouco menos de 20%, principalmente devido ao S3. A propósito, precisávamos de fontes para diferentes tamanhos de tela - nossos designers criaram adaptáveis.

Plataforma muito lenta


Portanto, parece que não temos muitos dispositivos, mas dos quais cerca de 5% (conforme o esperado) serão muito antigos. As primeiras horas foram geralmente concebidas, ao que parece, como um dispositivo que mostra imagens geradas no telefone. Então apareceu o seu próprio sistema operacional desenvolvido e em revisões posteriores - também um Wi-Fi e um cartão SIM.

O cartão SIM na Rússia não funciona. Talvez este ano as operadoras concordem, mas por enquanto só há wi-fi e comunicação via telefone (o relógio se conecta ao iPhone via Bluetooth e depois usa sua conexão com a Internet).

A lógica de trabalhar com a rede, memória e disco é quase a mesma do iOS.Quero dizer, a lógica em si é comum, os serviços são comuns, mas ainda há uma emboscada com bibliotecas - na verdade, muitas pessoas não estão desenvolvendo por horas, portanto, pode não haver estruturas e ferramentas populares no iOS / iPadOS. No nosso caso, isso significava a necessidade de abandonar a pilha de bibliotecas que conectamos a um aplicativo iOS com o movimento manual das mãos.

Sem exceção, todos os relógios fazem acessos de disco muito lentos, em comparação com a forma como eles podem ser lidos da memória. Se em um iPhone você realmente não consegue se preocupar exatamente onde a tabela de 40 Kb está localizada, então no relógio é essencial mantê-la na memória ou recebê-la pelo ar. O mais importante é não ler nada do disco.

Obviamente, quanto mais novo o relógio, mais rápido ele gira, mas, de fato, trabalhamos para o S3 com suporte para dispositivos anteriores e recursos adicionais para o S4 e S5.

A versão alfa do aplicativo, que mostrava o caminho para casa, carregada por horas dezenas de segundos. A programação da MCC foi mostrada por 20 segundos nos 4 trens mais próximos. O problema estava na renderização da tabela - muitos elementos individuais. Imagine um navegador moderno que esteja tentando renderizar algo no núcleo 386SX. Então tivemos problemas semelhantes.

Naturalmente, é por isso que ela é alfa para brincar com ela. Na versão beta, distribuímos a carga pelos threads (capturando um recurso ao longo do caminho que, quando o relógio inicia no watchOS 4, o ponto de entrada principal não inicia no mainstream). Por horas "fracas", o número de células na interface foi limitado.


Cada um deles foi renderizado por cerca de um segundo.



Algumas otimizações da própria interface do usuário e voaram para o S4, e para dispositivos mais antigos, foi necessário reduzir o número de trens exibidos.

Eles inseriram acima e abaixo “mostrar os que partiram” e “mostrar próximo” e no eleito - “mostrar tudo”. Como esse cronograma geralmente muda, muitas vezes era necessário redesenhá-lo: estamos falando de situações em que a composição da tabela muda por causa de um trem que partiu ou por causa de uma alteração no cronograma (mostramos movimento em tempo real, ou seja, sabemos onde exatamente cada particular de fato, e como isso afetará todas as estações ao longo da rota).

Muitas vezes, existem situações em que os dados ficam desatualizados um segundo após a solicitação. Com a abordagem básica, toda a tabela foi distorcida, esse é o caminho padrão para o iOS. Lá, a atualização é geralmente imperceptível. E aqui eles fizeram muita porcaria com base no processamento da matriz de entrada, que analisa os dados primeiro, depois cria o diff, depois localiza os elementos da interface do usuário que podem ser alterados sem tocar no restante e os atualiza apenas. Não há bibliotecas adequadas para uma solução completa no WatchOS, mas existe um kit de diferenciação, que fornece uma lista de como e o que foi alterado pelos índices da matriz de dados com marcação. Eles escreveram o código em torno dele e o colocaram em todas as tabelas. Isso deu um aumento nas atualizações de desempenho.

Em geral, os trens N mais próximos são exibidos rapidamente e, se você quiser esperar, mas quiser uma imagem completa, pode clicar em "Mostrar tudo".

Como eu disse, o mostrador do relógio é grande, mas lento. Primeiro, usamos um conjunto padrão de bibliotecas iOS que funcionavam no disco. Pegamos a programação, gravamos em um disco, o serviço solicitado, tiramos do disco, desenrolamos na tela. Como se viu, você precisa armazenar o cache na memória. E, no entanto, estamos acostumados a salvar todos os estados de trabalho do usuário em disco e a lê-los a partir daí - só precisamos gravar e armazenar tudo o que pudemos na memória.



Por que a gravação constante é necessária? Porque se o usuário alternar o aplicativo, o descarregamento ocorrerá quase instantaneamente. Normalmente, você não tem tempo para gravar nada no disco de freio, por isso precisa fazê-lo constantemente e de forma iterativa enquanto o usuário está trabalhando.

E então estamos nos aproximando da próxima emboscada.

Manic Energy Conservation


A bateria do relógio é pequena e todo o sistema operacional é afiado para preservar a energia o máximo possível. Na prática, isso pode significar que o usuário está fazendo o seguinte:

  1. Inicia o download de algo (por exemplo, uma programação completa)
  2. Abaixa a mão
  3. Está esperando
  4. Levanta a mão para ver o que está carregado

De fato, acontece o seguinte:

  1. O usuário começa a baixar a programação completa
  2. Abaixa a mão
  3. Os relógios entendem que eles não trabalham com eles e colocam o processo em um análogo do hibernado.
  4. O usuário espera e depois levanta a mão para olhar o resultado.
  5. No momento da subida, o relógio entende que eles continuam trabalhando com eles, acordam e acordam o processo.
  6. O usuário vê o início do indicador de download.

Ao mesmo tempo, do ponto de vista do encadeamento, pode ser o momento certo ou um "segundo muito longo" - se você escrever código em intervalos, poderá repentinamente pegar até um ano em que meio segundo estava esperando. Portanto, lembre-se de que o tempo é relativo.

O processo de despertar ameaça você com um longo processo de depuração - é possível detectar falhas no fato de o local estar desocupado ou de algo interessante acontecer.

O processo de adormecer pode se transformar em um processo de descarregamento (sem acordar); portanto, é necessário gravar algumas coisas no disco. O sistema operacional informa o segmento "Ir para o plano de fundo" e chama o método apropriado. Normalmente, você tem cerca de um segundo para sair rapidamente e despejar em segundo plano. Quando um usuário faz isso enquanto grava em um disco (que, lembro-me, é terrivelmente lento em dispositivos de até S4), a gravação pode não ocorrer. Para fazer isso, é necessário entrar no modo "operação importante" e, com a ajuda de várias chamadas especiais, manter o segmento "consciente". Para fazer isso, você precisa de um manipulador separado que solicite ao processo de gravação quando ele terminará e libere o thread para suspensão.

Arquitetura


Nosso primeiro aplicativo em 2017 foi apenas um espaço em branco, capaz de mostrar o cronograma gerado no telefone. Foi usado para mostrar dados de um trem de longa distância em uma pista, um carro e um local.

A versão moderna para trens é “adulta” e autônoma, ou seja, pode viver a qualquer momento sem telefone. Mesmo a partir do momento da instalação (embora a maneira usual de o aplicativo entrar no relógio seja pelo telefone, e nesse momento é muito conveniente copiar os dados do perfil e todas as rotas selecionadas do telefone).

A arquitetura do relógio é provavelmente a mais moderna nos padrões do iOS. Redux não é um problema. Nós, como no aplicativo "grande", usamos a máquina de estado. O MVC padrão é este: existe um modelo, por um lado, há visualizações para este modelo, no meio do controlador. O controlador pega os dados do modelo, converte, exibe na tela. Na direção oposta, o controlador ouve as mensagens de exibição e fornece dados ao modelo. Com base nesse padrão, muitos tipos de arquiteturas foram criados.

Temos um estado em que os eventos podem ocorrer e sofrer mutações. Os efeitos colaterais, que fazem um trabalho útil, podem sair do estado. A partir desses resultados, os eventos voam para o estado. O estado completo do aplicativo é armazenado na história, como um ponto único da verdade. O estado pode ser dividido em partes e dividido, mas, em qualquer caso, armazena o conjunto de dados completo. A implementação específica da arquitetura depende da religião, temos o RXFeedback.

A máquina de estado é muito bem coberta por testes. Isso economizou muito tempo apenas no relógio, porque os testes não podem ser realizados dentro do próprio relógio. Este não é um iPhone para você. Aqui você precisa fazer isso:

  1. Crie o aplicativo no emulador e veja.
  2. . , . id Xcode .




Eu usei S4 e S1 para testar. Como muitas coisas são muito difíceis de verificar no relógio, tornou-se incrivelmente conveniente isolar estados (estados) específicos, transferi-los para outro componente e já existem testes de todos os lados.

O décimo Xcode (que era antes de outubro de 2019) agradou que, por algum motivo, quando o aplicativo foi iniciado no relógio, ele parou de funcionar no simulador. Foi decidido cortando o desinfetante comercial, se alguém estiver interessado.

Assim, ao montar destinos com estados dedicados e com lógica comum (havia muitos deles), você precisa torná-los compatíveis com o relógio. Conectamos acidentalmente o UIKit algumas vezes, e essa é a estrutura da interface do usuário do telefone, que não é suportada no relógio. Se você acidentalmente pegar na versão - a biblioteca simplesmente não se conectará.

Autonomia


Caso de uso básico - o usuário tem um relógio e um telefone. Ele os mantém regularmente juntos, e o relógio pode usar a Internet pelo telefone.



Com os novos lançamentos de relógios, tornou-se possível usar seu próprio Wi-Fi e seu próprio cartão SIM de relógio (existe um e-sim embutido).

Nossa tarefa é sincronizar os favoritos entre dois aplicativos (no telefone e no relógio). Toda vez que começamos, tentamos ler a última verdade e toda vez que mudamos a lista, tentamos encontrar imediatamente o segundo dispositivo e contar a ele sobre isso. Acontece que, obviamente, nem sempre, portanto, se possível, sincronizamos na inicialização. Se houver dois favoritos diferentes que são confrontados com conflitos, consideramos mais preciso o que está ao telefone e resolvemos conflitos a seu favor.

Caso contrário, o aplicativo não está conectado ao telefone. O cache está dentro, as solicitações para a rede são enviadas a partir do relógio (se possível), se não, através da ponte via telefone. Como resultado, você pode usá-lo de forma autônoma pelo tempo que desejar, mas você só precisa instalar o aplicativo pela primeira vez (nossa versão não suporta a instalação a partir do relógio diretamente do aplicativo). Depois disso, você pode esquecer a sincronização, se quiser. Antes do watchOS 2, o esquema de aplicação usual era que tudo era contado e feito no telefone, e o relógio apenas mostrava o resultado.

Total


O aplicativo básico para iOS aqui . O aplicativo de relógio está emparelhado com ele. O aplicativo usa uma versão do release, mas em um dispositivo específico, ele se adapta a ele em termos de velocidade e adapta a interface ao tamanho da tela. A primeira autorização ao instalar via telefone, no mesmo local, copiando favoritos e rotas frequentes. Sincronização adicional ou existência autônoma. Localização geográfica a partir do telefone (isso é necessário para entender se você está em Moscou ou em Moscou, se você não permite a localização geográfica ou não, é orientado pelo tempo, invertendo as solicitações matinais). Havia tantas instalações quanto o esperado (levamos em conta que não há muitas horas na Rússia e seus usuários estão em trens elétricos). A julgar pelas avaliações, os usuários do aplicativo no relógio ficam felizes em ver sua programação na escada rolante.

More articles:


All Articles