Por que o Android usa Java? [fechadas]


114

OK, isso realmente deveria ser perguntado a alguém do Google, mas eu só quero outras opiniões.

Mesmo o Android suporta aplicativos de código nativo, a principal ferramenta de desenvolvimento é Java. Mas por que? Quero dizer, não é muito lento interpretar o código em um dispositivo móvel? Ao apresentar o Froyo, o Google disse que o novo compilador JIT pode atingir aplicativos 2 a 5 vezes mais rápidos. Isso significa que usar Java em vez de código nativo é 2x vezes mais lento.

Sim, eu sei que usar aplicativos de código gerenciado é mais seguro em termos de estabilidade do sistema, já que a máquina virtual tem melhor controle do programa, mas ainda assim, essa queda de desempenho é enorme, e não vejo razão para usá-la.


12
O código Java não é interpretado, pelo menos não no Android - é compilado e executado em uma máquina virtual.
Radomir Dopieralski

4
Achei que o Java provou que a Sun pode ser (em algumas áreas, mas quase sempre) tão rápido quanto o código nativo. Além disso, os caras do Google são um pacote inteligente - estou confiante de que o JIT que eles lançaram recentemente produzirá um código muito bom, mais cedo ou mais tarde.

1
@ b-gen-jack-o-neill A resposta é realmente não, porque a VM pode dizer qual código está sendo executado em tempo de execução e como está sendo executado. Por exemplo, a Apple usa LLVM no OS X com o propósito explícito de otimizar funções gráficas de desempenho crítico em tempo de execução. Isso é feito especificamente porque é mais rápido do que as técnicas de código nativo.
PeterAllenWebb

1
@ b-gen-jack-o-neill, bytecode Java pode ser compilado para código nativo em tempo de execução.
Mike Daniels

1
@ b-gen-jack-o-neill - a VM tem acesso a mais informações sobre o ambiente de execução do que um compilador típico, portanto, pode fazer escolhas mais inteligentes. Até que ponto isso compensa a sobrecarga extra varia de aplicativo para aplicativo.
CurtainDog

Respostas:


98

Alguns pontos:

  1. Java é uma linguagem conhecida, os desenvolvedores a conhecem e não precisam aprendê-la

  2. é mais difícil atirar em si mesmo com Java do que com código C / C ++, pois não tem aritmética de ponteiro

  3. ele é executado em uma VM, então não há necessidade de recompilá-lo para cada telefone lá fora e fácil de proteger

  4. grande número de ferramentas de desenvolvimento para Java (ver ponto 1)

  5. vários telefones celulares já usavam Java ME, então o Java era conhecido na indústria

  6. a diferença de velocidade não é um problema para a maioria dos aplicativos; se fosse você deveria codificar em linguagem de baixo nível


5
Rodar em uma VM (portanto, sem recompilar) é uma grande vantagem. Além disso, ele facilmente separa os processos uns dos outros, evitando que um aplicativo nocivo destrua seu telefone ou interfira em outros aplicativos
Falmarri

1
Sobre o aplicativo desonesto - parece interessante. Corrija-me se eu estiver errado, mas CPUs x86 têm biult na proteção por meio de modos de paginação e toque, portanto, o aplicativo não pode alterar sua página na memória, portanto, não pode interferir com outro aplicativo que não seja o uso da API do sistema operacional. Mas esse recurso tem CPUs ARM? Na verdade, não tenho ideia. Caso contrário, isso seria ótimo + para Java nesta plataforma.
B.Gen.Jack.O.Neill

A CPU não tem nada a ver com um aplicativo malicioso fazendo coisas nefastas
Falmarri

4
A proteção de memória faz parte de algumas arquiteturas de CPU. Ele evita que um aplicativo malicioso acesse a memória atribuída a um aplicativo diferente. en.wikipedia.org/wiki/Memory_protection
josefx

1
@Falmarri: Sim, é verdade. Basicamente, é muito simples. Seu aplicativo atribuiu seu próprio espaço de endereço. Todos os endereços que você deseja acessar são traduzidos por MMU. Você deseja acessar o endereço 0x0000 e MMU o traduz para, por exemplo, 0x0E21. E para evitar que você mude o endereço de base, sua instrução privilegiada e seu programa, quando iniciado pelo SO, atribuiu o nível de privilégio mais baixo. Do contrário, uma única instrução CLI (desativar interrupções)
travaria o

39

No nível do código de byte, o Android não usa Java. A fonte é Java, mas não usa JVM.


7
sim. Java é a fonte, mas não foi compilado para o código de bytes compatível com a máquina virtual java. É por isso que eles provavelmente farão a maior parte / toda a disputa de patente com a sun / oracle. Eles estão apenas usando a sintaxe da linguagem.
John Gardner

1
Ele ainda precisa suportar a maioria das funções do java vm. Portanto, eles não podem otimizá-los.
Josefx

1
Então por que a necessidade de instalar o JDK ao desenvolver no android? É apenas para o emulador?
jiggunjer de

@jiggunjer Android Studio é desenvolvido em Java, na verdade. E o emulador também.
Rudra B. Saraswat

20

A melhoria da estabilidade do sistema é muito importante em um dispositivo como um telefone celular.

A segurança é ainda mais importante. O ambiente Android permite que os usuários executem aplicativos semi-confiáveis ​​que podem explorar o telefone de maneiras realmente desagradáveis, sem excelente segurança. Ao executar todos os aplicativos em uma máquina virtual, você garante que nenhum aplicativo pode explorar o kernel do sistema operacional, a menos que haja uma falha na implementação da VM. A implementação da VM, por sua vez, é presumivelmente pequena e tem uma superfície de segurança pequena e bem definida.

Talvez o mais importante, quando os programas são compilados para codificar para uma máquina virtual, eles não precisam ser recompilados para um novo hardware. O mercado de chips para telefones é diversificado e está mudando rapidamente, então isso é um grande negócio.

Além disso, o uso de Java torna menos provável que os aplicativos que as pessoas escrevem sejam exploráveis. Sem saturações de buffer, erros com ponteiros, etc ...


Outra resposta de David diz que o Android não usa jvm
Ssenyonjo

13

O código nativo não é necessariamente mais rápido do que o código Java. Onde estão os dados do seu perfil mostrando que o código nativo pode ser executado mais rápido?

Por que Java?

  • O Android funciona em muitas plataformas de hardware diferentes. Você precisaria compilar e otimizar seu código nativo para cada uma dessas plataformas diferentes para ver quaisquer benefícios reais.

  • Há um grande número de desenvolvedores já proficientes em Java.

  • Java tem um grande suporte de código aberto, com muitas bibliotecas e ferramentas disponíveis para tornar a vida dos desenvolvedores mais fácil.

  • Java protege você de muitos dos problemas inerentes ao código nativo, como vazamentos de memória, uso incorreto de ponteiros, etc.

  • Java permite que eles criem aplicativos sandbox e um modelo de segurança melhor para que um aplicativo ruim não consiga derrubar todo o sistema operacional.


7

Em primeiro lugar, de acordo com o Google, o Android não usa Java. É por isso que a Oracle está processando o Google. A Oracle alega que o Android infringe alguma tecnologia Java, mas o Google diz que é Dalvik.

Em segundo lugar, não vejo um interpretador de código de bytes Java desde 1995.

Você pode sustentar sua conjectura de desempenho com alguns benchmarks reais? O escopo de suas presunções não parece justificado, dadas as informações imprecisas que você forneceu.


4

Java tem um argumento bastante convincente para o Google usá-lo no Android: ele tem uma grande base de desenvolvedores. Todos esses desenvolvedores estão (mais ou menos) prontos para desenvolver para sua plataforma móvel.

Lembre-se de que, tecnicamente falando, o Android não usa Java puro .


2
Acho que todas as pessoas interessadas em desenvolvimento para dispositivos móveis também estão interessadas em linguagens "mais legais" do que Java.
Earlz

4

Conforme mencionado em outro lugar, o principal problema é que o Android foi projetado como um sistema operacional portátil, para ser executado em uma ampla variedade de hardware. Ele também se baseia em uma estrutura e linguagem familiares a muitos desenvolvedores móveis existentes.

Finalmente, eu diria que é uma aposta contra o futuro - quaisquer problemas de desempenho existentes se tornarão irrelevantes à medida que o hardware melhorar - da mesma forma, ao fazer com que os desenvolvedores codifiquem uma abstração, o Google pode extrair e alterar o sistema operacional subjacente com muito mais facilidade do que se os desenvolvedores estavam codificando para as APIs POSIX / Unix.

Para a maioria dos aplicativos, a sobrecarga de usar uma linguagem baseada em VM em vez de nativa não é significativa (o gargalo para aplicativos que consomem serviços da web, como o Twitter, é principalmente a rede). O Palm WebOS também demonstra isso - e que usa JavaScript em vez de Java como linguagem principal.

Dado que quase todas as VMs JIT compilam para o código nativo, a velocidade do código bruto é frequentemente comparável à velocidade nativa. Muitos atrasos atribuídos a linguagens de nível superior têm menos a ver com a sobrecarga da VM do que outros fatores (um tempo de execução de objeto complexo, verificação de acesso à memória por meio de verificação de limites etc.).

Lembre-se também de que, independentemente da linguagem usada para escrever um aplicativo, muito do trabalho real é feito em APIs de nível inferior. A linguagem de nível superior geralmente é apenas encadear chamadas de API.

Existem, é claro, muitas exceções a essa regra - jogos, aplicativos de áudio e gráficos que ultrapassam os limites do hardware do telefone. Mesmo no iOS, os desenvolvedores geralmente optam por C / C ++ para obter velocidade nessas áreas.


1

O novo JIT está executando os aplicativos 2 a 5 vezes mais rápido do que o antigo dalvikVM (ambos JAVA). Portanto, a comparação não é C sobre JAVA, mas JIT sobre dalvikVM.


1

Em primeiro lugar, trata-se da mesma coisa que o Windows Mobile ou o iPhone, o framework .net precisa de sua própria VM, assim como de cacau.

E mesmo que o desempenho não seja o melhor, porque é uma interpretação do código de bytes, o Android traz toda a comunidade Java como desenvolvedores em potencial. Mais aplicativos, mais clientes, etc.

Para finalizar, nenhum desempenho não é tão ruim, é por isso que o java é usado mesmo em dispositivos menores (ver JavaMe).


Cocoa não é baseado em VM - é todo código nativo compilado - mas ao contrário do C / C ++ puro, ele tem um tempo de execução dinâmico (semelhante a Smalltalk / Ruby / Python) - que tem seus próprios problemas de desempenho e otimizações. É notável que a maioria dos jogos do iPhone são em grande parte C ++ em vez de Obj-C.
JulesLt
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.