Por que os dispositivos de desenvolvimento oferecem mais recursos do que um dispositivo típico?

9

Criei um aplicativo que funciona no meu iPod Touch de quarta geração e no iPod touch de quinta geração da minha empresa.

Estávamos prestes a lançar, quando encontramos uma falha que ocorre após qualquer dispositivo não desenvolvedor executar o aplicativo *.

Surgiu a noção de que um dispositivo registrado como 'dispositivo de desenvolvedor' oferece ao seu aplicativo mais recursos para usar. Isso não parece certo para mim, pois não consegui pensar em nenhum motivo que exista - sinto que é mais provável que seja um problema com a criação ou criação de perfil de provisão.

No entanto, isso levou a uma discussão. Por que existem dispositivos como kits de desenvolvimento de consoles de jogos, dispositivos com mais recursos que a plataforma de destino? É claro que é bom testar o estresse de um programa, mas uma representação mais precisa da plataforma de destino não faria mais sentido?

TL; DR - Por que os kits de desenvolvimento têm mais recursos do que as plataformas de destino?

* Com um dispositivo não-desenvolvedor sendo> 3ª geração. Dispositivo iOS que baixa o aplicativo do nosso servidor, não diretamente de um computador com o aplicativo & xcode instalado.

_{Observe que há outra pergunta parecida, mas na verdade é diferente, porque essa outra pergunta está sendo feita sobre o simulador, e eu entendo que existem grandes diferenças entre o uso de um simulador e um dispositivo real.}

ios development

— Katamaritaco
fonte

7

@gnat - Esta postagem não é uma cópia de Por que é necessário testar meu aplicativo para iPhone . Eu entendo que existem grandes diferenças entre o uso de um simulador e um dispositivo real ...

— Katamaritaco

8

O ambiente de desenvolvimento (para qualquer coisa - seja um aplicativo java independente, um ambiente móvel ou um dispositivo incorporado) normalmente tem a capacidade de fazer depuração remota, log aprimorado e outros tipos de introspecção do ambiente (normalmente não se deseja para adicionar todos os ganchos para um analisador lógico em um dispositivo incorporado de produção).

Essas coisas adicionais requerem recursos adicionais. A abertura de um depurador remoto contra uma VM ou outro ambiente remoto requer alguns recursos do outro lado. No domínio severamente limitado do celular, é possível que esses recursos adicionais o ultrapassem o limite concedido a um aplicativo padrão. Assim, mais recursos são fornecidos ao ambiente de desenvolvimento para que ele não atinja o limite de recursos quando começar a fazer log ou depuração adicional.

Isso vai além do ponto em que você sempre precisa testar algo em um espelho do ambiente de produção. Confiar que ele funciona nas máquinas do desenvolvedor com todos os seus ajustes e variáveis diferentes não é suficiente para verificar se funciona corretamente na produção.

11

Sim, o controle de qualidade sempre precisa testar em um ambiente de usuário final e não em um ambiente de desenvolvimento.

— 17 de 26

Alguns anos atrás, eu estava envolvido com um projeto que tinha que desenvolver duas placas de CPU completamente diferentes. O engenheiro de hardware que fez a placa com a qual eu estava fortemente envolvido colocou vários conectores de teste em sua placa, fazendo um seguro para a fase de depuração, para garantir que pudéssemos investigar qualquer coisa. Ele tomou muita estática por desperdiçar imóveis e dinheiro. O outro cara não desperdiçou dinheiro e imóveis. O engraçado: nunca precisamos dos conectores em nossa placa. Integrar a outra diretoria era um pesadelo absoluto, porque nada poderia ser provado. Pense em "seguro".

— John R. Strohm

@ JohnR.Strohm Para um desenvolvimento, investigar é bom. Tudo o que estou tentando dizer é que, se ele foi projetado para ter uma placa de produção diferente da placa de desenvolvimento, também seria necessário testar novamente com a produção depois de ter sucesso com a de desenvolvimento (e sondar se necessário).

Isso faz muito sentido para um típico 'kit de desenvolvimento'. Por curiosidade, no caso do iOS, qualquer iDevice pode ser usado como um 'dispositivo de desenvolvedor'. Como pode haver uma diferença com duas peças do mesmo hardware?

— Katamaritaco

11

@Katamaritaco só porque é o mesmo dispositivo físico, não significa que o aplicativo tenha as mesmas permissões no iOS. A capacidade de fazer coisas como depuração remota pode alterar a quais recursos um aplicativo tem acesso.

5

Ele permite que você crie uma prova de conceito ambiciosa em termos de recursos que você poderá otimizar posteriormente.

Não faz sentido travar um aplicativo porque está 5 bytes acima do limite de memória (que pode ser resolvido configurando o otimizador para economizar espaço na versão, mas você está executando uma versão de depuração),

aparecer um aviso no log quando você ultrapassar o limite do consumidor durante o teste será bom aqui.

— catraca arrepiante
fonte

1

É parcialmente uma questão de "confiança". Supõe-se que os desenvolvedores saibam o que estão fazendo e, portanto, têm acesso irrestrito ao dispositivo e a todos os seus recursos. Isso pode ser uma grande ajuda para pequenas empresas e equipes de desenvolvimento, onde recursos não utilizados são desperdiçados.

Em um ambiente corporativo maior, ou especialmente o público em geral, esse tipo de acesso se torna um passivo, devido a questões de segurança e à necessidade de funcionar bem com outros aplicativos que também precisam de recursos.

Esta não é realmente uma ideia nova. Eu tenho duas máquinas no trabalho. Na minha máquina de desenvolvedor, tenho acesso administrativo, mas é isolado da Internet. Minha outra máquina, que eu uso para email, Office e acesso à Internet, nem me dá a capacidade de instalar programas.

É por isso que você precisa testar seu aplicativo em um dispositivo não-desenvolvedor antes de implantá-lo, para garantir que ele seja bem-comportado. :)

— Robert Harvey
fonte

0

Com o iOS, um dispositivo habilitado para Desenvolvimento permite executar diretamente compilações de depuração, que podem conter um conjunto diferente de erros do compilador que uma compilação de versão, além de executar aplicativos em um nub de depuração, que pode alterar sutilmente o tempo do encadeamento e o uso de memória, que também pode mostrar / ocultar vários erros de memória de threads e vazamentos.

Um dispositivo de desenvolvimento não seria muito útil sem um recurso de depuração, e um dispositivo de usuário com recurso de depuração apresentaria um (mais) problema grave de segurança de aplicativos e dados de aplicativos.

— hotpaw2
fonte