Escolar Documentos
Profissional Documentos
Cultura Documentos
Trabalho Acadmico
Marco Beckmann
Pelotas, 2012
MARCO BECKMANN
Trabalho Acadmico apresentado ao Curso de Bacharelado em Cincia da Computao da Universidade Federal de Pelotas, como requisito parcial obteno do ttulo de Bacharel em Cincia da Computao. Orientadora: Profa. Dra. Lisane Brisolara de Brisolara Co-Orientador: Prof. Dr. Jlio Carlos Balzano de Mattos
PELOTAS 2012
Banca examinadora :
................................................................................................. Profa. Dra. Lisane Brisolara de Brisolara (Orientadora) ................................................................................................. Prof. Dr. Jlio Carlos Balzano de Mattos (Co- Orientador)
RESUMO BECKMANN, Marco. Avaliao das Boas prticas de Codificao para Plataforma Android 2012. Trabalho acadmico (Graduao) - Bacharelado em Cincia da Computao. Universidade Federal de Pelotas, Pelotas. Com o avano da tecnologia, os software embarcado tem se tornado cada vez mais complexo, acarretando em um maior uso de recursos de hardware na sua execuo. A eficincia uma preocupao frequente sobretudo quando trata-se de dispositivos mveis, tais como celulares e smartphones. Visando um aumento na eficincia desta execuo so sugeridas uma srie de boas prticas de codificao, que buscam a melhoria do cdigo a partir da anlise e refatorao do mesmo. Este trabalho prope o estudo e avaliao de boas prticas para software desenvolvido para a Plataforma Android, incluindo uma anlise do impacto destas prticas no desempenho de aplicativos reais executados nesta plataforma.
software
embarcado,
instrumentao
de
cdigo,
ABSTRACT BECKMANN, Marco. Trabalho acadmico (Graduao) - Bacharelado em Cincia da Computao. Universidade Federal de Pelotas, Pelotas. With the advance of technology, embedded software has become increasingly complex, resulting in a greater use of hardware resources in its execution. The efficiency is often a concern, especially when mobile devices are used such as cell phones and smartphones. To improve the efficiency of this execution are suggested a number of best practices that aim to optimize code through analysis and refactoring. This work proposes the study and evaluation of the best practices for the Android operating system, including an analysis of the impact of these practices on the performance of real applications running on this mobile platform. Keywords: Android, embedded software, code profiling, optimization, efficiency
LISTA DE FIGURAS Figura 1 Exemplo de Grafo de Fluxo de Controle (COSTA, 2011). .................... 16 Figura 2 Programa Exemplo (COSTA, 2011). ........................................................... 16 Figura 3 Representao de Alto Nvel da Instrumentao (COSTA, 2011)...... 17 Figura 4 Exemplo de Profile ........................................................................................ 18 Figura 5 Arquitetura Android (GOOGLE, 2012b) .................................................... 20 Figura 6 Emulador do Android .................................................................................... 24 Figura 7 Arquivo Aberto no Traceview ...................................................................... 26 Figura 8 Declarao Static ............................................................................................ 28 Figura 9 Declarao Final Static.................................................................................. 28 Figura 10 Codificaes alternativas para uma iterao........................................ 30 Figura 11 Classe Exemplo ............................................................................................ 31 Figura 12 Mtodos de sntese gerados pelo compilador ..................................... 31 Figura 13 Cdigos para avaliao da prtica esttico x virtual.......................... 34 Figura 14 Cdigos para avaliao da prtica com getter x sem getter ............ 35 Figura 15 Cdigos para avaliao da prtica static x static final....................... 37 Figura 16 Cdigo para avaliao de diversas sintaxes do for - exemplo 1 ..... 39 Figura 17 Cdigos para avaliao de diversas sintaxes do for - exemplo 2... 40 Figura 18 Cdigos para avaliao do impacto dos tipos de acesso................. 42 Figura 19 Cdigos para avaliao da escolha do tipo de dado .......................... 43 Figura 20 Avaliao do aplicativo Noiz2 ................................................................... 44 Figura 21 Mtodo reinit .................................................................................................. 45 Figura 22 Mtodo reinit alterado ................................................................................. 45 Figura 23 Avaliao do aplicativo OpenSudoku ..................................................... 46 Figura 24 Cdigo do Mtodo validate original ........................................................ 47 Figura 25 Mtodo validate alterado For sem length ........................................... 48 Figura 26 Mtodo validate alterado para uso do For-each .................................. 48 Figura 26 Mtodo validate alterado Getters e Setters........................................ 49
LISTA DE TABELAS Tabela 1 - Resultados OpenSudoku .............................................................................. 49 Tabela 2 - Resultados Static vs Virtual ......................................................................... 57 Tabela 3 - Resultados Com Getter vs Sem Getter ..................................................... 58 Tabela 4 - Resultados Static vs Static Final em inteiros.......................................... 59 Tabela 5 - Resultados Static vs Static Final em strings ........................................... 60 Tabela 6 - Resultados sintaxes For................................................................................ 61 Tabela 7 Resultados sintaxes For verso 2 ............................................................. 62 Tabela 8 - Resultados Package Acess vs Private ...................................................... 63 Tabela 9 - Resultados Int, Float e Double .................................................................... 64 Tabela 10 - Resultados mtodo reinit do jogo Noiz2 ................................................ 65 Tabela 11 - Resultados mtodo validate do jogo OpenSudoku ............................. 66 Tabela 12 - Resultados mtodo validate do jogo OpenSudoku, incluindo chamadas dos mtodos filhos ........................................................................................ 67
LISTA DE ABREVIATURAS E SIGLAS 2D 3D AAC ADB AMR API AVD BSD CPU DDMS FPU JIT JPG JVM MP3 MPEG4 OHA PNG RAM SMS SD SDK SOC UML VM Duas Dimenses Trs Dimenses Advanced Audio Coding Android Debug Bridge Adaptive Multi-Rate Application Programming Interface Android Virtual Device Berkeley Software Distribution Central Processing Unit Dalvik Debug Monitor Server Floating Point Unit Just in Time Joint Photographic Experts Group Java Virtual Machine MPEG 1 Layer-3 Moving Picture Experts Group 4 Open Handset Alliance Portable Network Graphics Random Access Memory Short Message Service Secure Digital Software Development Kit System On a Chip Unified Modeling Language Virtual Machine
SUMRIO 1. INTRODUO ...................................................................................................... 10 1.1 Objetivo ................................................................................................................. 12 1.2 Organizao do Trabalho ................................................................................. 12 2. FUNDAMENTAO TERICA ......................................................................... 13 2.1 Sistemas embarcados ....................................................................................... 13 2.2 Software embarcado .......................................................................................... 14 2.3 Instrumentao de Cdigo ............................................................................... 15 2.3.1 Instrumentao de Cdigo .................................................................................. 15 2.3.2 Profilling .................................................................................................................. 18 2.3.3 Tracing .................................................................................................................... 19 3. PLATAFORMA ANDROID.................................................................................. 20 3.1 O Android .............................................................................................................. 20 3.1.1 O Kernel .................................................................................................................. 20 3.1.2 Bibliotecas .............................................................................................................. 21 3.1.3 Android Runtime .................................................................................................... 21 3.1.4 Framework de Aplicaes ................................................................................... 22 3.1.5 Aplicaes .............................................................................................................. 23 3.2 O ambiente de desenvolvimento .................................................................... 23 3.2.1 Emulador ................................................................................................................ 23 3.2.2 DDMS...................................................................................................................... 24 3.2.2.1 Gerao de Perfis de Execuo e Traceview .............................................. 25 4. BOAS PRTICAS DE CODIFICAO PARA ANDROID ............................ 27 4.1 Uso de mtodos estticos e virtuais ............................................................. 27 4.2 Uso de Getters/Setters Internos ..................................................................... 27 4.3 Uso de Static Final para Constantes ............................................................. 28 4.4 Uso da Sintaxe Aprimorada do For ................................................................ 29 4.5 Acesso do tipo Pacote ao invs do acesso Privado em classe interna do tipo Privado .................................................................................................................... 30 4.6 Uso de operaes em ponto flutuante .......................................................... 32 5. EXPERIMENTOS.................................................................................................. 33 5.1 Metodologia .......................................................................................................... 33 5.2 Analisando as Boas Prticas........................................................................... 34 5.2.1 Uso de mtodos estticos e virtuais .................................................................. 34 5.2.2 Uso de Getters/Setters Internos ......................................................................... 35 5.2.3 Uso de Static Final para Constantes ................................................................. 36 5.2.4 Uso da Sintaxe Aprimorada do For .................................................................... 38 5.2.5 Acesso do tipo Pacote ao invs do acesso Privado em classe interna do tipo Privado ............................................................................................................................ 41 5.2.6 Uso de operaes em ponto flutuante ............................................................... 42 5.3 Aplicando as Boas Prticas em Aplicativos................................................ 43 5.3.1 Noiz2 ....................................................................................................................... 44 5.3.2 OpenSudoku .......................................................................................................... 46 5.4 Anlise dos Resultados .................................................................................... 50 6. CONCLUSO........................................................................................................ 52
10
1. INTRODUO O desenvolvimento tecnolgico das ltimas dcadas requer um intensivo uso de sistemas computacionais. Diversos dispositivos utilizam recursos computacionais para o seu controle. Tais sistemas computacionais, quando utilizados em sistemas ainda mais complexos, so chamados de sistemas embarcados (MATTOS, 2009). Atualmente, a complexidade do software embarcado vem aumentando medida que o avano tecnolgico permite integrar uma grande capacidade de processamento e armazenamento de dados em reduzida rea para as mais diversas reas de aplicao. Muitos produtos requerem o uso de aplicativos para as mais variadas tarefas, desde a execuo de vdeos, visualizao de imagens, dentre outras funcionalidades. Os sistemas embarcados apresentam restries de memria, processamento e geralmente devem consumir pouca energia, devido ao uso de uma bateria para seu funcionamento. Desta forma, o desenvolvimento de software para sistemas embarcados diferencia-se do desenvolvimento de software convencional, pois muitas das restries de projeto impostas ao software embarcado no so consideradas nos sistemas tradicionais, como aspectos temporais (tempo de resposta), tamanho de memria e consumo de potncia. Todos estes aspectos dependem fortemente da plataforma de hardware utilizada, cabendo ao
desenvolvedor de software embarcado preocupar-se com estes aspectos fsicos e gerenciar cuidadosamente o consumo de recursos limitados, tais como a capacidade da bateria, usualmente realizando um balano entre o desempenho e a vida til da bateria (THOMPSON, 2012) Nesse contexto, formas de avaliar a eficincia de um cdigo embarcado so requeridas, a fim de otimizar o cdigo de um software, fazendo com que consuma menos ciclos de processador e uso da memria, consequentemente consumindo menos energia. Esta etapa que avalia e otimiza cdigo por vezes chamada de explorao do espao de projeto, visto que vrias solues so exploradas e avaliadas a fim de encontrar a que melhor atende a especificao. H muitas maneiras de avaliar a eficincia de um cdigo ou de um algoritmo. Para algoritmos, podemos avaliar a complexidade do mesmo, por exemplo, e procurar por uma soluo de menor complexidade. Embora esta informao seja interessante, quando se deseja avaliar aspectos fsicos e eficincia de um cdigo
11
quando executado em uma dada arquitetura, precisa-se de um grau de preciso maior. Uma ferramenta de instrumentao de cdigo, ou profiler, pode ser usada, nestes casos, para fornecer informaes sobre a execuo do software. Estas ferramentas podem informar o nmero de instrues executadas pela mquina, ou ainda gerar um completo trace da execuo, informando cada instruo que foi executada e em que ordem. Este tipo de ferramenta til para identificar subrotinas no cdigo que consomem mais recursos, o que consequentemente indicar onde otimizaes obtero maior impacto. As ferramentas de instrumentao, combinadas com dados de custo das instrues (em ciclos, joules, etc) em uma dada arquitetura permitem estimar desempenho, consumo, dentre outros aspectos fsicos. Refatoraes, que tratam da reescrita de um cdigo sem alterar sua funcionalidade, podem ser aplicadas para melhorias em vrios aspectos do cdigo, dentre eles a eficincia. Em SILVA (2010) o impacto de algumas refatoraes de cdigo Java foi avaliado em termos de eficincia. A plataforma Android comum em diversos dispositivos mveis, tanto em smartphones quanto tablets, sendo considerado o lder de mercado na rea de sistemas operacionais para smartphones nos primeiros quatro meses de 2012 (PRWEB, 2012). Seus aplicativos so em grande maioria escritos na linguagem Java, porm sua execuo diferencia-se de cdigos Java tradicionais, pois a mquina virtual utilizada no a Java Virtual Machine (JVM), mas a Dalvik Virtual Machine. O cdigo no nvel de bytecodes tambm se difere, pois usado um bytecode especfico (DALVIKVM, 2012). Alm disso, o Java para Android no suporta uma srie de pacotes do Java padro (ZDNET, 2012) e utiliza bibliotecas prprias da plataforma Android. Visando o aumento de desempenho dos aplicativos para Android so sugeridas diversas boas prticas pelo fabricante do sistema operacional (GOOGLE, 2012a). As boas prticas so um conjunto de regras para aumentar o desempenho do cdigo a partir de alteraes no cdigo fonte. No entanto, no foi encontrado nenhum estudo que demostre o impacto destas refatoraes de cdigo, ou aplicao das boas prticas, na eficincia dos aplicativos Android. Muitos trabalhos acadmicos focam na explorao do espao de projeto de software embarcado, focando por vezes em nveis de abstrao diferentes. Oliveira props explorar modelos UML (OLIVEIRA, 2006). O trabalho proposto por Mattos
12
(MATTOS, 2007) se baseia em uma abordagem que utiliza uma ferramenta DESEJOS que instrumenta arquivos binrios de Java (.class) inserindo o cdigo responsvel por contabilizar os consumos dos recursos fsicos e permite a explorao do espao de projeto principalmente em otimizaes de mtodos e gerenciamento de objetos. Silva e Ferreira exploraram otimizaes em cdigo Java (FERREIRA, 2009) (SILVA, 2010). Porm, estes trabalhos baseiam-se no uso da plataforma Femtojava, desenvolvida no meio acadmico e, portanto sem uso em produtos comerciais. Este trabalho estuda melhorias na eficincia de cdigos executados na plataforma Android. As melhorias consideradas neste estudo se baseiam nas boas prticas indicadas pelo provedor da plataforma. Neste trabalho, experimentos foram conduzidos para a avaliao do impacto das boas prticas no desempenho de diversos aplicativos de cdigo aberto rodando no sistema operacional Android.
1.1
Objetivo
O objetivo geral deste trabalho avaliar o impacto das boas prticas no desempenho de aplicaes mveis reais quando executadas em dispositivos que utilizem o sistema operacional Android. 1.2 Organizao do Trabalho Esta monografia divide-se em 6 captulos. No segundo captulo so introduzidos conceitos tericos sobre o trabalho, especificando sistemas
embarcados, instrumentao de cdigo, profilling e trace. A plataforma para dispositivos mveis Android e seu kit de desenvolvimento so apresentados no terceiro captulo. O quarto captulo apresenta e exemplifica as boas prticas de codificao voltadas para desempenho no Android. Os experimentos realizados para avaliao das boas prticas so apresentados e discutidos no quinto captulo, incluindo a avaliao dessas prticas em aplicaes reais. No sexto captulo so apresentadas as concluses obtidas a partir do trabalho e so apontados trabalhos futuros.
13
2.
FUNDAMENTAO TERICA
2.1
Sistemas embarcados Os mais diversos tipos de aparelhos eletrnicos fazem uso de um sistema
computacional para o seu funcionamento, como aparelhos de msica, celulares, etc. Esses sistemas so conhecidos como sistemas embarcados. Os sistemas embarcados tm carter dedicado e possuem uma funcionalidade especfica dentro de um sistema mais complexo, porm a principal razo para comprar o produto no o sistema computacional para processamento das informaes (WOLF, 2001) (MARWEDEL, 2006). So sistemas que realizam uma tarefa especfica e possuem um sistema programvel, porm no se trata de um computador de uso geral, pois se diferenciam em diversos pontos (MATTOS, 2009): So sistemas dedicados: geralmente desenvolvidos para uma
finalidade especfica, os sistemas embarcados apresentam uma interface dedicada ao dispositivo que far o seu uso. Um exemplo disso so os televisores, que contm uma srie de menus para sua configurao, funcionalidades para troca de canais e de volume, entre outros atributos. O software embarcado pensado para cumprir as funcionalidades necessrias para o funcionamento do aparelho. Nesse ponto diferencia-se do software desenvolvido para computadores pessoais, que so desenvolvidos para rodar em diferentes arquiteturas; tempo de resposta: os sistemas embarcados geralmente esto
envolvidos em tarefas onde o tempo de resposta crtico; confiabilidade: em alguns sistemas considerados crticos, uma falha
pode causar acidentes tanto ao equipamento quanto pessoas, nestes casos a confiabilidade um requisito importante a ser atendido; tamanho de cdigo: tipicamente os sistemas embarcados no possuem
um disco rgido e so implementados em SoCs, onde a memria integrada ao chip, sendo o cdigo da aplicao armazenado no prprio sistema. Portanto software embarcado deve levar em considerao os recursos de armazenamento fornecidos pelo dispositivo, sendo compactos em aparelhos com pouca memria;
14
acordo com as necessidades requeridas para o seu funcionamento, sendo implementados recursos suficientes para suas funcionalidades, sem deixar estes recursos ociosos; baixo consumo de potncia e energia: em dispositivos portteis o
consumo de potncia/energia um problema crucial, pois muitos destes sistemas utilizam baterias para seu funcionamento. Portanto adequado que estes sistemas sejam projetados para consumir o mnimo de energia possvel; tempo e custo de projeto: com a competividade crescente,
principalmente na rea dos chamados gadgets , o tempo de lanamento de um dispositivo fator crucial para seu sucesso.
Essas caractersticas dos sistemas embarcados precisam ser levadas em considerao tanto no projeto do hardware quanto do software do sistema, porque alm dos componentes fsicos a interao entre o software e o hardware influencia o funcionamento e a eficincia do sistema.
2.2
Software embarcado
Software dito embarcado quando o mesmo desenvolvido para executar em um dispositivo ou plataforma especca e que ser distribudo como parte de um produto. Eletrnica de consumo, telecomunicaes, automao industrial e automotivo, so setores onde o software embarcado demandado. Conforme j foi destacado, limitaes e restries presentes nos dispositivos e plataformas impem exigncias ao projeto de software embarcado que so mais rgidas do que aquelas consideradas para o software tradicional (computadores de propsito geral). Sistemas embarcados so heterogneos e executam uma grande gama de algoritmos implementados tanto em software como em hardware. Devido evoluo do poder computacional presente nos dispositivos embarcados atuais, a criao de sistemas mais elaborados foi suportada, aumentando assim a complexidade do software. Atualmente o software de tais sistemas vm se tornando o principal fator de custo de um novo produto (GRAAF, 2003). Esses softwares costumavam ser desenvolvidos em linguagens de montagem, diretamente com o conjunto de instrues do processador utilizado, por precisar seguir restries de memria e
15
performance. Esta prtica est sendo modificada a medida que as plataformas tem maior poder computacional e que o software muito complexo para ser desenvolvido com linguagens de baixo nvel. No entanto, quando linguagens de mais alto nvel so usadas fica mais difcil fazer a avaliao da eficincia de um cdigo. Isso se deve a necessidade de traduzir os comandos de alto nvel para as instrues do processador para ter dados mais reais de eficincia. Atualmente, investigaes so realizadas para avaliar o custo, por exemplo, da execuo de um cdigo de alto nvel em uma plataforma embarcada (PEREIRA, 2010) (MATTOS, 2007). Porm, os trabalhos citados trabalham com uma plataforma no-comercial. 2.3 Instrumentao de Cdigo
2.3.1
Instrumentao de Cdigo Instrumentao de cdigo trata-se de uma tcnica que funciona a partir da
alterao de trechos do algoritmo, tanto adicionando como retirando instrues, classes, mtodos, variveis e constantes. Esta tcnica tem sido utilizada com as finalidades de traar o perl dinmico de um programa, otimizar e reutilizar cdigos e monitorar o acesso a recursos do sistema operacional (SURESH, 2003). A instrumentao facilita a obteno de informaes sobre o comportamento de um programa, pois insere instrues no cdigo responsveis por registrar as informaes sobre sua execuo que daro subsdios para a otimizao deste cdigo. Para isso, devem ser identificadas quais informaes so relevantes, os locais do programa em que elas se encontram e, ento, instrues que faam sua medio devem ser inseridas. No entanto, as instrues inseridas para observar o comportamento dinmico de um programa no podem alterar sua funcionalidade original, embora o deixe mais lento. Para evitar um grande aumento no tempo de execuo deve-se restringir a instrumentao a pores especcas do cdigo, focando nas partes que sejam alvo de estudo. A instrumentao de um cdigo gera um grafo dirigido onde cada n representa um bloco de comandos e cada aresta um fluxo do programa. Com o grafo pronto, a ferramenta de instrumentao insere cdigos especficos nos ns do
16
grafo. Quando o programa executado esses cdigos so os responsveis por armazenar, geralmente em um arquivo, que aquele ponto do programa foi percorrido. Na Figura 1 ilustrado o Grafo de Fluxo Controle gerado a partir do cdigo apresentado na Figura 2.
Segundo PIERCE (2011), a instrumentao de cdigo pode ser feita em trs momentos: Antes da compilao: Neste caso, a instrumentao feita no cdigo fonte. Portanto, embora considerada fcil de ser realizada, esta s possvel se o cdigo fonte estiver disponvel, o que no ocorre com programas de cdigo fechado. H tambm outras desvantagens, como a impossibilidade de acesso a bibliotecas que no possuam cdigo fonte aberto e o aumento no tempo da instrumentao. Durante a ligao: Neste caso, a instrumentao realizada durante a ligao, aps a gerao do cdigo objeto e antes que seja gerado o executvel. Os cdigos objeto so modificados e encaminhados de volta ao
17
ligador (ou linker) para que este gere o executvel. O processo manual e preciso ter acesso ao cdigo objeto para utilizar-se dessa tcnica. Aps a compilao: A instrumentao realizada feita no arquivo executvel, arquivo binrio ou cdigo intermedirio (bytecode e assembly). a mais vivel de ser feita, pois no requer o cdigo fonte ou cdigo objeto, porm mais complicada, pois so tratadas instrues de baixo nvel, sendo difcil o entendimento do programa. Inicialmente a instrumentao era feita manualmente, sendo trabalhosa, maante e propensa a erros. No intuito de automatizar este processo foram desenvolvidas ferramentas que abstraem complexidades de baixo nvel. A Figura 3 apresenta o fluxo de instrumentao em alto nvel utilizado pela maioria das ferramentas disponveis. Seguindo este fluxo, o cdigo fonte passa por um processo de instrumentao responsvel por gerar os fontes instrumentados. Aps isso, os fontes so compilados, gerando ento a aplicao utilizada na execuo dos casos de teste. Na execuo dos casos de teste, os cdigos exercitados so armazenados em um arquivo e posteriormente so apresentados no relatrio de cobertura (COSTA, 2011). So exemplos de ferramentas o Cantata++ (QASYSTEMS, 2012), para C, C++ e Java; Clover (ATLASSIAN, 2011) para Java; Testwell CTC++ (TESTWELL, 2011) para C e C++; BullseyeCoverage (BULLSEYE, 2011) para C e C++, dentre outras.
18
2.3.2
medio do tempo gasto nas rotinas crticas do software. Uma ferramenta de profilling (conhecida como profiler) gera um perfil de execuo, com dados como a proporo de tempo ou de ciclos de processamento gastos em cada subrotina, assim sendo possvel identificar as partes crticas do programa. A informao obtida por um profiler tambm apoia a avaliao do efeito de otimizaes realizadas no cdigo. Para este fim, a contagem de ciclos por subrotina deve ser realizada antes e aps uma modificao de forma a permitir a avaliao do impacto de uma modificao nos ciclos necessrios para a execuo de cada subrotina. Um exemplo de perfil de execuo ou profile ilustrado na Figura 4, no qual observa-se informaes das rotinas do programa, tais como a porcentagem de tempo de cada rotina comparado a execuo total do programa, o tempo total em segundos gasto pela funo e o tempo gasto na funo somado a suas funes descendentes e quantas vezes cada funo/rotina foi chamada. Alm disso, o perfil inclui a informao de quanto tempo foi gasto na chamada de cada funo e o total de tempo gasto na chamada da funo e de suas funes descendentes. So exemplos de ferramentas de profilling a GTKWave (GTKWave, 2011), KProf (KPROF, 2011), KCachegrind (KCACHE, 2011), JProfiler (EJ-TECHNOLOGIES, 2012), NetBeans Profiler (NETBEANS, 2012), dentre outras.
19
2.3.3
programa. As ferramentas, que suportam este mtodo, gravam pontos significativos durante a execuo de um programa/aplicativo e permitem observar a partir da o comportamento do sistema, que colhido em intervalos regulares. semelhante ao processo de depurao (ou debugging), mas somente permite a observao do sistema, no permitindo influenciar a execuo do programa (RATH, 2007). So exemplos desse tipo de ferramenta, especificamente para sistemas embarcados o SpyKer (LYNUXWORKS, 2011) e o Tracealyzer (PERCEPIO, 2011).
20
3. PLATAFORMA ANDROID Neste captulo apresentada a plataforma Android em detalhes, incluindo sua arquitetura, bem como principais recursos e ferramentas oferecidas pela plataforma. 3.1 O Android O Android consiste em uma plataforma aberta para dispositivos mveis desenvolvida pela Open Handset Alliance (OHA), que trata-se de um grupo formado em 2007 por gigantes do mercado de telefonia de celulares liderados pelo Google. Entre alguns integrantes do grupo esto nomes consagrados como a HTC, LG, Motorola, Samsung, Sony Ericsson, Toshiba, entre outras empresas (OHA, 2012) O sistema operacional Android tem sua arquitetura dividida em cinco partes: o kernel do Linux, o conjunto de bibliotecas, o Android runtime, o framework de aplicaes e finalmente as aplicaes, como ilustrado na Figura 5.
3.1.1
O Kernel O kernel do Linux utilizado no sistema operacional a verso 2.6 e tem como
21
no dispositivo. Esta camada responsvel pelo gerenciamento de memria, gerenciamento de processos, pilha de protocolos de rede, mdulo de segurana e diversos mdulos de infraestrutura.
3.1.2
diversos componentes do sistema. Essas funcionalidades so apresentadas ao desenvolvedor na camada de framework. Abaixo so apresentadas algumas dessas bibliotecas e suas funes:
System C library: uma implementao derivada da biblioteca padro do C (libc) do BSD (Berkeley Software Distribution) sintonizada para dispositivos rodando Linux; Media Libraries: baseado no PacketVideos OpenCORE ; as bibliotecas suportam os mais populares formatos de udio e vdeo, bem como imagens estticas como MPEG4, H.264, MP3, AAC, AMR, JPG e PNG; Surface Manager: gera o acesso ao subsistema de exibio bem como s mltiplas camadas de aplicaes 2D e 3D; LibWebCore: web browser engine utilizado tanto no AndroidBrowser quanto para exibies web; SGL: bibliotecas de grficos para construo em 2D; 3D libraries: implementao baseada no OpenGL ES 1.0 APIs; as bibliotecas utilizam acelerao 3D via hardware (quando disponvel) ou o software de renderizao 3D altamente otimizado includo no Android; FreeType: impresso de fontes vetoriais ou bitmap; SQLite: poderosa e leve ferramenta de banco de dados relacional disponvel para todas as aplicaes.
3.1.3
Libraries, que suporta grande parte das funcionalidades disponveis nas principais bibliotecas da linguagem Java. Alm disso, a Runtime inclui a VM Dalvik (VM, do
22
ingls, Virtual Machine) e as aplicaes Android rodam em seu prprio processo, com sua prpria instncia da Dalvik. A VM Dalvik baseada em registradores, ao contrrio da tradicional JVM (Java Virtual Machine) que utiliza o conceito de pilhas. Outra diferena que no se usa bytecodes do Java; os arquivos .class so compilados e transformadas em arquivos executveis .dex, atravs da ferramenta dx includa no Android SDK. A Dalvik foi projetada para que a sua execuo consuma o mnimo de memria possvel. A Dalvik foi escrita de forma que um dispositivo mvel pode executar vrias mquinas virtuais (VM - Virtual Machines) eficientemente. Ela tambm baseia-se no kernel do Linux para suas funcionalidades subjacentes como o encadeamento e a gesto de baixo nvel de memria. 3.1.4 Framework de Aplicaes O framework de aplicaes foi todo escrito em Java e todos aplicativos possuem acesso as mesmas APIs (Application Programming Interface) que so utilizadas pelos aplicativos padres do sistema operacional. A arquitetura dos aplicativos desenvolvida para simplificar a reutilizao de componentes. Abaixo so apresentadas algumas APIs presentes na camada de framework: Views: utilizados para a construo de telas de aplicativos, tais como: listas, grids, caixas de texto, botes e tambm um navegador web embutido; Content Providers: permite que aplicativos acessem dados de outros aplicativos do aparelho e tambm que compartilhem seus prprios dados; Resource Manager: prov o acesso a recursos como textos (strings), grficos e arquivos de leiaute. Cada aplicativo tem o seu organizador de recursos, o arquivo R.java; Notification Manager: permite que todos os aplicativos mostrem alertas customizados na barra de status; Activity Manager: gerencia o ciclo de vida dos aplicativos; Packet Manager: gerencia o local dos aplicativos e arquivos de dados armazenados.
23
3.1.5
aplicativos Android, como um cliente de e-mail, programa de envio de SMS, calendrios, mapas (Google Maps), jogos, navegador web, contatos, entre outros. Nessa camada tambm se incluem as aplicaes instaladas no sistema. Todas essas aplicaes so escritas na linguagem de programao Java.
3.2
fornece um SDK (Software Development Kit) com emulador e um conjunto de ferramentas chamado Dalvik Debug Monitor Server (DDMS) para depurao, medio de memria e desempenho, manipulao dos arquivos do dispositivo, entre outras funcionalidades. Alm disso, fornecido um plugin do Eclipse que faz a ligao entre as ferramentas fornecidas pelo SDK e a interface de desenvolvimento do Eclipse. 3.2.1 Emulador
O SDK permite criar um emulador que simula as configuraes de hardware e software encontradas normalmente em dispositivos mveis. Primeiramente, deve ser criado um dispositivo atravs do gerenciador AVD (Android Virtual Device Manager), escolhendo a verso do Android e o nvel de sua API que ser usada no emulador. Alm disso, outras configuraes de hardware devem ser informadas, como o tamanho da memria do dispositivo, a capacidade de memria do carto SD, simulao de cmera, uso de acelermetro, entre outras. O emulador tambm pode simular a CPU ARMv5, arquitetura comum em dispositivos mveis, e seu correspondente sistema de controle de memria. As configuraes do emulador (instalao de aplicativos, mudanas de configuraes, etc) so armazenadas no carto de memria e a cache no diretrio do AVD (GOOGLE,2012c), sendo possvel acessar o emulador com as ltimas configuraes vlidas. Na Figura 6 ilustrado o emulador em funcionamento.
24
3.2.2
desenvolvimento e prov diversas funes, como a captura de tela do dispositivo, informaes sobre a pilha do sistema (heap), monitoramento da alocao de objetos na memria, gerao e leitura de perfis de execuo dos aplicativos, entre diversas outras funcionalidades. Com o uso do plugin ADT para Eclipse, fornecido pela prpria Google, possvel utilizar essas funcionalidades no ambiente de desenvolvimento. Esta ferramenta de depurao (debugger) pode analisar um aplicativo que est rodando tanto no emulador quanto em um dispositivo conectado ao computador. No Android cada aplicao roda em seu prprio processo, sendo cada um destes executado em sua prpria mquina virtual (GOOGLE,2012d). Cada uma dessas VMs possui uma porta prpria, e por meio desta que o debugger faz a leitura do aplicativo. O Android Debug Bridge (adb), ferramenta provida pelo SDK,
25
responsvel por criar a ligao entre o dispositivo (virtual ou real) e o DDMS (GOOGLE, 2012e), permitindo que o DDMS execute suas anlises e depuraes.
3.2.2.1
Existem duas formas de se gerar um perfil de execuo de um aplicativo Android. A primeira utiliza um recurso do DDMS, que permite escolher um dos aplicativos que esto rodando no emulador e fazer o trace de seu funcionamento. Para tal, um boto na interface do Eclipse deve ser pressionado para iniciar o trace e aps para parar o trace. Aps a parada gerado um arquivo .trace com o resultado da leitura. Um dos problemas deste mtodo sua limitao de tamanho, pois gera arquivos de no mximo 8 MB. Execues de poucos segundos criam arquivos que atingem esse tamanho, o que um limitante para uso desta tcnica.
.A
segunda forma de se obter o perfil de execuo de um aplicativo usando startMethodTracing() e stopMethodTracing() da biblioteca
os
mtodos
android.os.Debug (GOOGLE, 2012f). Neste caso, deve-se indicar a funo start a partir de onde deseja-se rastrear o funcionamento do programa e a stop ou ponto de parada do trace. Esse mtodo tem como vantagens a criao de um arquivo de tamanho superior ao anterior (por volta de 40 MB, pois o Eclipse no suporta a abertura de arquivos de tamanho superior) e tambm de fornecer um controle de execuo de trechos especficos do cdigo. Uma dificuldade apresentada pela tcnica a leitura da execuo do aplicativo, que simples no mtodo anterior e neste mtodo requer algum conhecimento do funcionamento do cdigo. Outra desvantagem que essa tcnica requer acesso ao cdigo fonte do programa, enquanto a anterior pode ser aplicada para avaliar qualquer aplicativo instalado no sistema. A partir dos arquivos .trace gerados por qualquer uma das tcnicas mencionadas, a ferramenta Traceview, disponvel no DDMS, responsvel por fornecer a visualizao dos dados obtidos pelo trace. A Figura 7 ilustra como um arquivo .trace pode ser visualizado no Traceview. Na parte superior da Figura 7, h uma linha do tempo que mostra mtodos e threads executadas no tempo de leitura. Na parte inferior encontram-se todos os mtodos chamados e o tempo gasto somente na sua prpria execuo (Excl Time), e na sua execuo somada a execuo de mtodos chamados dentro do mtodo ( Incl Time). Elas so separadas por CPU time e Real time. Outra informao o nmero de chamadas de cada
26
mtodo somado com o nmero de chamadas recursivas e o tempo gasto nessas chamadas.
27
4.
O conceito de boas prticas segundo Williams (2008) Uma prtica de desenvolvimento de software que, atravs da experincia e investigao, provou fiavelmente conduzir a um resultado desejado e considerado ser prudente e aconselhvel ser usada em uma variedade de contextos. Boas prticas so usualmente referenciadas como um mtodo de padronizao para facilitar o entendimento e clareza de um cdigo, portanto visando melhorar sua qualidade. Porm, existem outros aspectos de qualidade tambm importantes para um software, dentre eles a eficincia, reusabilidade, entre outras. Portanto, boas prticas podem ser definidas visando os mais variados objetivos. A desenvolvedora do Android sugere uma srie de boas prticas para melhorar o desempenho dos aplicativos Android (GOOGLE, 2012a), as quais so apresentadas neste captulo e representam o foco deste trabalho. O conjunto de boas prticas avaliadas neste trabalho so descritas nesta seo. 4.1 Uso de mtodos estticos e virtuais Esta prtica indica que quando no preciso ter acesso aos campos de um objeto, recomendado o uso de mtodos estticos, ao invs de virtuais. As invocaes estticas sero aproximadamente de 15% a 20% mais rpidas, segundo (GOOGLE, 2012a).
4.2
Em linguagens orientadas a objetos comum o uso de getters (como i = getCount()) ao invs de acessar um atributo interno diretamente (i = mCount). Em C++ isto no apresenta problemas, pois o compilador torna o acesso inline (fazendo uma cpia do cdigo da funo diretamente para o trecho em que esta utilizada). No Android, isso no indicado, pois uma chamada de mtodo do tipo virtual mais custosa do que o acesso direto ao atributo. Sem recurso de JIT (do ingls, Just in Time), o acesso direto trs vezes mais rpido que o uso de getters e setters (GOOGLE, 2012a). Com o JIT, esta
28
diferena pode ser at maior, aproximadamente sete vezes, visto que neste caso o acesso direto to rpido quanto o acesso um local. Isto fato para Froyo (Android 2.2), mas futuramente haver mtodos inline para os getters no JIT.
4.3
Considere a declarao, apresentada na Figura 8, onde duas variveis so usadas para representar dois valores constantes de tipos diferentes. Neste caso, o compilador gera um mtodo inicializador de classe, chamado <clinit>, que executado quando a classe usada pela primeira vez. O mtodo guarda o valor 42 em intVal e extrai a referncia do arquivo de classe de String da tabela de constantes do strlVal. Quando esse valor referenciado posteriormente, eles so acessados com uma pesquisa por campo/atributo, conhecida como field lookup na constant pool .
Se usarmos a palavra "final" na definio, como exemplifica a Figura 9, os acessos sero mais rpidos, pois a classe no requer o mtodo <clinit>, visto que constantes so armazenadas em um campo inicializador de statics no arquivo .dex. Desta forma, o cdigo que refere-se intVal usar o valor inteiro 42 diretamente, e os acessos a strVal usaro uma instruo string constante (mais eficiente) ao invs de uma field lookup. Os criadores destas prticas ressaltam porm que essa otimizao s vlida para tipos primitivos e String constantes, no para tipos de referncia arbitrria.
29
4.4
O lao for aprimorado pode ser usado para colees que implementem uma interface iterativa e para arranjos (conhecidos tambm como arrays). Com as colees, um iterador alocado para criar as chamadas para hasNext() e next(). Segundo GOOGLE (2012a), em arrays com fors escritos a mo, resultados at trs vezes melhores podem ser obtidos (com ou sem JIT) pelo for aprimorado, mas para outras colees este uso ser equivalente ao uso explcito de um iterador. Existem vrias alternativas para iterao em arrays. A Figura 10 mostra a codificao de trs formas de iterao, nos mtodos zero(), one() e two(). A forma usada no mtodo zero() a mais lenta, pois o JIT no otimiza o custo de receber o tamanho do array a cada lao. J a forma implementada em one() um pouco mais rpida, pois usa variveis locais, evitando lookups (busca e acesso de uma varivel de outra classe). A forma adotada no mtodo two() utiliza a sintaxe aprimorada do lao for, introduzida pelo Java 5. Dentre as trs formas analisadas, segundo (GOOGLE, 2012a), a usada no mtodo two() a mais rpida para dispositivos sem JIT, e parecida com one() para dispositivos com JIT.
30
4.5
do tipo Privado
Esta boa prtica se aplica quando uma classe interna outra, o que chamamos de inner class, precisa acessar atributos da classe externa. Na Figura 11, a classe externa Foo est ilustrada, a qual possui uma classe interna privada chamada Inner (Foo$Inner) que acessa diretamente um mtodo privado e um atributo privado da classe externa. Isso vlido e o cdigo imprime "Value is 27", como esperado.
31
O problema que a VM considera o acesso direto aos membros privados de Foo a partir de Foo$Inner ilegais, pois Foo e Foo$Inner so classes diferentes, embora Java permita o acesso aos membros privados (ou private) de uma classe externa. Para contornar esse problema o compilador gera dois mtodos de sntese, que so ilustrados na Figura 12. O cdigo da classe interna chama os mtodos estticos toda vez que precisa acessar o campo mValue ou invocar o mtodo doStuff da classe externa.
32
Para evitar este overhead, mtodos e variveis que so acessados por classes internas devem ser definidos com a visibilidade de pacote (package access), permitindo que estes sejam acessados por outras classes pertencentes ao mesmo pacote. Para que mtodos e variveis tenham visibilidade de pacote deve-se utilizar o modificador public, protected ou nenhum modificador (ORACLE, 2012).
4.6
Por causa do Thumb, um conjunto especial de instrues dos processadores ARM, o ponto flutuante consegue ser por volta de duas vezes mais lento do que inteiros em dispositivos Android, segundo pesquisa da Google (2012a). Isto vlido em dispositivos sem uma unidade de ponto flutuante (FPU), sem JIT G1 e no Nexus One com FPU e JIT. O mesmo estudo apontou que em termos de desempenho, no h diferenas entre double e float, porm o tipo double ocupa duas vezes mais memria e portanto deve ser usando quando no h limitao de memria.
33
5.
para a plataforma Android. Primeiramente, apresentada a metodologia (seo 5.1) adotada nos experimentos, seguida de uma demonstrao e anlise de cada prtica estudada (seo 5.2) e na seo 5.3, a anlise do impacto da aplicao das prticas em uma aplicao apresentada. 5.1 Metodologia Para todos experimentos, foi utilizado o emulador fornecido pela fabricante do sistema operacional junto ao kit de desenvolvimento para Android, o Android SDK. O emulador foi configurado para rodar na verso 4.0.4 do sistema operacional Android utilizando a API 15. O computador utilizado nos testes possui processador Core i5 2.80 GHz e 3,9 GB de memria RAM. O sistema operacional do computador utilizado foi o Ubuntu verso 11.10 verso 32 bits. A biblioteca android.os.Debug (GOOGLE, 2012f) foi utilizada para gerar os arquivos de trace das instrues executadas pelo emulador. Os mtodos startMethodTracing() e stopMethodTracing() presentes nesta biblioteca foram usados nas estimativas de desempenho dos cdigos, indicando incio e trmino do trace (Figura 13). Foram realizadas 30 execues em cada experimento, sendo considerados o CPU time dos cdigos analisados. As tabelas completas de execuo podem ser encontradas no Apndice A. Valores mdios de tempo de execuo foram comparados utilizando o teste estatstico t-student (com 95% de confiana) para verificar a significncia da diferena entre as mdias. Primeiramente foram analisadas as boas prticas fornecidas pelo fabricante do sistema operacional Android (GOOGLE, 2012a). Aps este processo foram selecionados uma srie de aplicativos, analisando sua execuo, procurando por trechos do cdigo que apresentem uso considervel de processamento e a aplicao das boas prticas seja vivel. Ento foram realizadas mudanas nos cdigos dos aplicativos baseadas nas boas prticas e novamente avaliaram-se os resultados, verificando assim o impacto da aplicao das boas prticas na execuo destes aplicativos.
34
5.2
Analisando as Boas Prticas Tomando como base as boas prticas fornecidas pela Google (2012a)
explanadas no captulo anterior foram desenvolvidos cdigos fim de testar seus resultados. importante lembrar que nos testes realizados na pesquisa da Google (2012a) no foram detalhados, nem a verso do Android utilizada e no foi exposto o cdigo que serviu como base para os resultados atingidos. Desse modo foram criados testes simples seguindo as recomendaes descritas no texto.
5.2.1
Uso de mtodos estticos e virtuais A primeira boa prtica avaliada sugere o uso de mtodos estticos ao invs
de mtodos virtuais. Para avaliar o impacto desta boa prtica foi utilizada a codificao apresentada na Figura 13, na qual um mesmo trecho de cdigo que realiza operaes matemticas bsicas (adio, subtrao, multiplicao e diviso) sobre inteiros encapsulado em um mtodo esttico (chamado overStatic) e em um mtodo virtual (overVirtual ). A anlise do tempo de execuo para as duas verses do cdigo foram realizadas usando o mtodo de trace explicado na seo 5.1. Ambos os mtodos foram chamados dez mil vezes em cada execuo dos cdigos e foram feitas 30 execues do cdigo.
35
Os experimentos usando o mtodo esttico (static) obtiveram o tempo mdio de execuo de 194,24 milissegundos (ms), apresentando um desvio padro de 4,84 ms, enquanto os experimentos com o mtodo virtual obtiveram tempo mdio de 193,52 ms com um desvio padro de 6,02 ms. A diferena de desempenho entre os dois mtodos foi inferior a 1%. A diferena entre estas mdias no tem diferena significncia estatstica, portanto no podemos dizer que a aplicao da prtica traz melhoria para o desempenho. 5.2.2 Uso de Getters/Setters Internos Em programao orientado a objetos, para garantir o princpio de encapsulamento mtodos do tipo Getters e Setters devem ser usados para acessar atributos das classes e o acesso direto ao atributo no indicado. Porm, h um custo associado a chamada de um mtodo, motivando a definio de uma boa prtica para Android que sugere que mtodos do tipo Getters as Setters sejam evitados. A Figura 14 apresenta o cdigo utilizado para testar o uso de getters no Android. Neste cdigo, h uma classe chamada Getter com um atributo inteiro e um mtodo getGetter de retono desse atributo. O mtodo semGetter acessa diretamente o atributo enquanto o comGetter utiliza o mtodo getGetter para retornar o valor do mesmo. Os dois mtodos foram chamados dez mil vezes em cada uma das execues realizadas nas 30 execues efetuadas.
36
mdio de
execuo 187,156 ms tendo como desvio padro 5,507 ms, enquanto os experimentos com o mtodo comGetter apresentaram tempo mdio de 547,435 ms com um desvio padro de 3,882 ms. Os experimentos demonstraram que o mtodo semGetter 66% mais rpido do que o comGetter, o que pode representar um impacto significativo no desempenho do cdigo. A diferena entre as mdias neste caso estatisticamente significativa, o que indica que a aplicao desta prtica melhorou o desempenho do cdigo. 5.2.3 Uso de Static Final para Constantes A boa prtica avaliada nesta seo dedica-se a definio de constantes e indica que as mesmas devem ser declaradas usando static final . O impacto gerado pelo uso desta prtica foi avaliado com base no cdigo mostrado na Figura 15, considerando valores inteiros constantes e cadeias de caracteres constantes. Cada mtodo foi chamado dez mil vezes em cada execuo e todos mtodos foram executados 30 vezes. O mtodo semStaticFinal ficou encarregado de testar o uso de um inteiro esttico fazendo com que a varivel semSF seja acessada para um soma com a varivel staticsum, enquanto o comStaticFinal testou um inteiro declarado como Static final fazendo com que a varivel comSF seja acessada para uma soma com a varivel finalsum. Os mtodos semSFString e comSFString fizeram o teste para cadeia de caracteres apenas fazendo com que a varivel recebe de cada mtodo atribui-se o valor Teste de seu respectivo tipo.
37
Na avaliao com valores inteiros, os experimentos demonstraram que quando estes so declarados com static apenas, tempos mdios de 191,514 ms foram obtidos, com desvio padro de 5,354 ms. Enquanto, os testes com inteiros estticos declarados com final obtiveram tempo mdio de 188,983 ms, com desvio padro de 5,140 ms. Assim, o mtodo static final foi apenas 1% mais rpido do que o static nos testes. As mdias resultantes deste experimentos no so significativas. J os testes com cadeias de caracteres estticas obtiveram tempo mdio de execuo de 187,581 ms, com desvio padro de 5,234, enquanto os testes com cadeias de caracteres estticas declaradas com final obtiveram mdia de 187,363 ms , com desvio padro de 5,187. O mtodo static final foi menos de 1% mais rpido do que o static nos testes. O teste estatstico indicou que as mdias no tem diferena significativa, portanto, no podemos afirmar que esta boa prtica trouxe melhorias para o cdigo. Contudo, devemos salientar que devido a caracterstica da metodologia empregada no foi possvel avaliar (considerar) a carga do mtodo de inicializao <clinit> que realizado na carga da classe, desta forma nos dados obtidos no consideram este tempo de sobrecarga.
38
5.2.4
Uso da Sintaxe Aprimorada do For Esta boa prtica indica que seja analisada a sintaxe do lao for que for
utilizada no cdigo. Para avaliar esta prtica, testes foram realizados com trs diferentes sintaxes do for usadas para manipulao de um arranjo, usando as codificaes ilustradas pelas Figuras 16 e 17. No cdigo da Figura 16, um vetor de dez mil posies da classe Foo, que contm como contedo um inteiro usado e um mtodo povoa responsvel por preencher esse vetor. Neste mesmo cdigo, os mtodos zero, one e two fazem a mesma tarefa, somar as variveis inteiras de cada posio do vetor mArray, porm cada um utiliza uma sintaxe diferente. O mtodo zero procura o tamanho do vetor em cada iterao do lao, j one recebe apenas uma vez o tamanho do vetor antes de entrar no lao e two usa a sintaxe aprimorada do for, o chamado For-each, adicionado no Java 5.0. Este algoritmo baseou-se no cdigo encontrado em (Google, 2012a), com algumas pequenas alteraes. O cdigo da Figura 17 funciona de forma semelhante, porm passa o vetor mArray por argumento para cada mtodo. Cada mtodo foi executado 30 vezes.
39
40
No primeiro exemplo (Fig. 16), o mtodo zero executou em um tempo mdio de 4,551 ms, com desvio padro de 0,8615 ms. O mtodo one executou em um tempo mdio de 3,0118 ms e desvio padro de 0,429 ms. J o mtodo two executou em um tempo mdio de 2,839 ms e desvio padro de 0,253 ms. Nos experimentos, observa-se que o mtodo two foi 38% mais rpido que zero (sendo estaticamente significante) e 6% mais rpido que one (uma diferena pouco significativa), enquanto o mtodo one foi 34% mais rpido que zero (estaticamente significativo). J no segundo exemplo (Fig. 17), o mtodo zero executou com mdia de 4,171 ms e desvio padro de 1,362 ms, enquanto o mtodo one executou com mdia 3,4974 ms e desvio padro de 1,062 ms e o mtodo two executou com mdia 3,322 ms e desvio padro de 0,810 ms. Analisando os resultados, observa-se que two foi 20% mais rpido que zero (considerada estaticamente relevantes) e 5% mais
41
rpido que one (no relevante estaticamente). O mtodo one foi 16% mais rpido que o mtodo zero (estaticamente relevante). Comparando os resultados obtidos nas duas codificaes, observa-se que a codificao ilustrada na Figura 17, o tempo de execuo mdio do mtodo zero foi reduzido, enquanto os tempos dos outros mtodos aumentaram. Esta variao responsvel pela queda no impacto da aplicao da prtica quando comparados os dois exemplos analisados. 5.2.5 Acesso do tipo Pacote ao invs do acesso Privado em classe
interna do tipo Privado O uso de acesso do tipo Pacote ao invs de Privado em classes internas sugerido por esta boa prtica. O cdigo utilizado para testar essa boa prtica baseiase no cdigo disponibilizado em (Google, 2012a). Neste cdigo, o mtodo run chamado, o qual cria um objeto da classe interna Inner chamado in, faz o atributo mValue da classe Foo receber um valor e chama o mtodo stuff do objeto in. Esse mtodo por sua vez chama outro, doStuff da classe Foo e imprime Value is e o valor do atributo mValue. Para avaliar o impacto do tipo de acesso, pequenas modificaes no cdigo foram realizadas, o que originou a classe Foo2. Neste cdigo alterado, o atributo mValue e o mtodo doStuff foram alterados de privados para pblicos, como sugerido em (Google, 2012a) e adicionou-se um 2 no final de cada mtodo e varivel a fim de diferenciar este cdigo do primeiro teste. Neste experimento, cada mtodo foi executado 30 vezes.
42
A execuo do mtodo run, que utiliza-se das variveis mValue e do mtodo doStuff privados, apresentou um tempo mdio de 4,539 ms com desvio padro de 0,284 ms. J o mtodo run2, que utiliza mValue2 e doStuff2 como pblicos, apresentou tempo mdio de 4,377 ms com desvio padro de 0,288 ms. A diferena entre estas mdias estatisticamente significativa. Desta forma, observa-se que o mtodo run2, o qual representa a aplicao da prtica sugerida, apresentou desempenho 4% melhor do que o mtodo run. 5.2.6 Uso de operaes em ponto flutuante O guia de boas prticas para desempenho inclui a boa prtica que sugere que dados do tipo ponto flutuante sejam usados com moderao, uma vez que a manipulao dos mesmos mais custosa. Para avaliar o custo da deciso do tipo de
43
dado entre int, double e float, foi utilizado o cdigo ilustrado na Figura 19. Neste cdigo, foram implementados trs mtodos (comInt, comFloat e comDouble), os quais realizam as quatro operaes matemticas bsicas dez mil vezes, cada um deles operando com um tipo de dado diferente, sendo cada mtodo executado 30 vezes.
O mtodo comFloat obteve tempo mdio de execuo de 197,645 ms com desvio padro 5,098 ms, enquanto o mtodo comDouble obteve tempo mdio de 200,146 ms com desvio padro de 5,703 ms e o mtodo comInt obteve tempo mdio de 198,413 ms com desvio padro de 5,269 ms. Porm, estas mdias no so significativamente diferentes, demonstrando que no podemos considerar que nenhum dos cdigos mais eficiente que os outros dois. 5.3 Aplicando as Boas Prticas em Aplicativos Com intuito de estender a anlise do impacto das boas prticas, uma srie de aplicativos com cdigo aberto foram analisados a procura de trechos crticos quanto ao desempenho e onde as boas prticas pudessem se aplicadas. Nas sees a seguir so apresentados experimentos com dois aplicativos diferentes, incluindo
44
anlise de desempenho do aplicativo original, aplicao das boas prticas e resultados obtidos.
5.3.1
Primeiramente, foi feita uma anlise do desempenho do aplicativo durante um minuto com o objetivo de observar trechos crticos no seu desempenho. A Figura 20 mostra o resultado deste teste.
Esta
primeira
avaliao
indicou
que
mtodo
reinit
da
classe
BulletmlManager o segundo mtodo que mais consume recursos. Com a anlise do cdigo deste mtodo, ilustrado na Figura 21, observou-se que a boa prtica que sugere uso do for aprimorado poderia ser aplicada neste trecho de cdigo.
45
Primeiramente, o aplicativo foi executado trinta vezes, fazendo com que o mtodo reinit fosse chamado cento e ci nquenta vezes em cada execuo. Aps, o mtodo foi modificado, utilizando a sintaxe de laos introduzida no Java 5.0, o que resultou no cdigo ilustrado na Figura 22. A nova verso do mtodo tambm foi invocado cento e cinquenta vezes para permitir a comparao entre as duas verses do cdigo.
O mtodo reinit original obteve tempo mdio de execuo de 2607,241 ms com desvio padro de 32,575 ms, enquanto o mtodo modificado obteve tempo mdio de 2554,456 ms com desvio padro de 17,953 ms. A anlise das mdias estatisticamente significativa, desta forma, a aplicao da boa prtica do for neste mtodo, tornou o mesmo 2% mais eficaz em desempenho, se comparado ao original,.
46
5.3.2
Primeiramente, foi feita uma anlise do desempenho do aplicativo durante um minuto com o objetivo de observar trechos crticos no seu desempenho. A Figura 23 apresenta o resultado deste teste.
Esta primeira avaliao de desempenho indicou que o mtodo validate da classe CellGroup o segundo mtodo que mais consume recursos. Analisando o cdigo deste mtodo, ilustrado na Figura 24, observou-se que tanto a boa prtica que sugere uso do for aprimorado quanto a boa prtica de evitar o uso de getters e setters poderiam ser aplicadas neste trecho de cdigo.
47
De forma a limitar a durao da anlise de desempenho realizada sobre o cdigo deste aplicativo, uma varivel contadora (contvalidate) foi adicionada a classe CellGroup, a qual incrementada e testada no mtodo validate, como pode ser observado na Figura 24. Desta forma, quando o jogador preencher 50 espaos em branco (todas lacunas disponveis no tabuleiro testado) a leitura ser encerada. Em todos os testes realizados com o cdigo original e cdigos alterados, o mtodo validate teve 1324 chamadas. A primeira alterao, ilustrada na Figura 25, foi a retirada da chamada de mCells.length do controle do lao for, fazendo com que a varivel auxiliar len recebesse seu valor. A segunda alterao, mostrada na Figura 26, foi a mudana do for tradicional para o chamado for-each, fazendo as adaptaes necessrias para seu funcionamento. A terceira e ltima alterao foi a retirada da chamada dos mtodos getValue e setValid, fazendo com que as variveis mValue e mValid fossem diretamente buscadas da classe Cell, sem o uso de getters e setters. Para que este acesso direto fosse possvel, a visibilidade destas variveis foram transformadas de private para public.
48
49
A comparao de desempenho dos mtodos foi resumida na Tabela 1. O mtodo validate original obteve tempo mdio de execuo de 1742,862 ms com desvio padro de 35,410 ms, enquanto o mtodo com for sem length obteve tempo mdio de 1774,738 ms com desvio padro de 17,128 ms, o mtodo do for-each alcanou mdia de 1748,479 ms com desvio padro de 22,936 ms e o mtodo sem getters e setters teve mdia 1059,168 ms com desvio padro de 68,387 ms. Comparando com o mtodo original, o mtodo sem o length foi 2% mais lento (considerado estaticamente significativo), o que utiliza o for-each foi menos de 1% mais lento (considerado no significativo) e o que no utiliza get e set foi 39% mais rpido (considerado estaticamente significativo).
50
A comparao baseada nos dados da Tabela 1 considera apenas as invocaes do prprio mtodo validate sem considerar subchamadas realizadas por este mtodo. Um segundo comparativo foi realizado considerando as subchamadas realizadas pelo mtodo validate, j que na verso sem getters e setters foram eliminadas as chamadas dos mtodos getValue e setValid. Nesse caso a chamada do mtodo original somada as subchamadas por este executadas obtiveram tempo mdio de 6785,547 ms com desvio padro de 149,772 ms, enquanto o mtodo sem getters e setters apresentou tempo mdio de 4027,932 ms com desvio padro de 123,421 ms. Estas mdias so significativamente diferentes e portanto, podemos concluir que nos experimentos realizados, a chamada do mtodo sem get e set foi 41% mais rpida se comparada a do mtodo original.
5.4
Anlise dos Resultados Em boa parte dos experimentos no se obteve significativa diferena entre as
formas avaliadas, com exceo de duas das boas prticas, a primeira que no recomenda o uso de getter e setters (diferena de 66%) e a segunda que sugere uma anlise do lao de iterao usado (diferena de at 38%, dependendo do experimento). Tendo como base essas duas boas prticas passou-se para os testes em aplicativos reais, onde somente o no uso de getters e setters obteve bons resultados. O aplicativo Noiz2, que apresentava originalmente um lao semelhante ao o do mtodo one dos experimentos, obteve apenas 2% de diferena, menor do que a diferena obtida no experimentos entre os mtodos one e two (6% e 5% nos dois experimentos com lao for). Deve-se avaliar que uma aplicao completa possui uma grande quantidade de instrues executadas, e pode acontecer que mesmo uma modificao no provoque diferenas significativas no tempo total de execuo da aplicao. Os testes em OpenSudoku considerando o lao for tambm obtiveram pouca diferena. A sintaxe do lao do cdigo original era semelhante a do mtodo zero dos experimentos. A mudana para um lao semelhante ao do mtodo one dos experimentos obteve uma performance 2% inferior ao cdigo original (onde nos experimentos obteve desempenhos superiores em 34% e 16%). A mudana
51
baseada no mtodo two apresentou um desempenho menos de 1% inferior a original (38% e 20% superiores nos experimentos). Do mesmo modo que a aplicao Noiz2 esta melhoria (diminuio no tempo de execuo) pode ser mascarada pela quantidade de instrues executadas pela aplicao. J o teste com o mesmo OpenSudoku baseando-se em no utilizar getters e setters apresentou uma diferena de 38% melhor que o cdigo original. No experimento desta boa prtica houve uma diferena de 66%. Como j relatado, a diferena entre as porcentagens dos testes dos experimentos iniciais e o dos que envolveram aplicativos basea-se no fato de que os mtodos dos experimentos utilizam cdigos desenvolvidos especificamente para o teste de cada boa prtica enquanto o dos aplicativos possuem de outras linhas de cdigo necessrias para o funcionamento do mtodo que acabam sendo considerados na leitura do desempenho. No foi possvel comparar o presente estudo apresentado neste trabalho com o apresentado em Google (2012a), j que no foi encontrado detalhes sobre como os autores do estudo realizaram tal avaliao. Detalhes como a metodologia utilizada nos testes realizados pela Google, assim como verso do Android utilizada e a codificao utilizada para tais testes no foram divulgados.
52
6.
ou energtico,sobretudo de aplicaes embarcadas que executam em dispositivos mveis, como smartphones, GPS, entre outros equipamentos, sendo que muitos destes equipamentos utilizam a plataforma Android. So sugeridas pelo provedor da plataforma um conjunto de boas prticas visando desempenho, portanto a eficincia destas otimizaes no havia sido avaliada em trabalhos cientficos. Este trabalho apresenta um estudo e avaliao de boas prticas de codificao visando a melhoria de desempenho de aplicativos Android.
Experimentos foram conduzidos em cdigos criados especificamente para avaliar as boas prticas sugeridas pelo fabricante do Android. Nos experimentos isolados, apenas duas das seis prticas sugeridas resultaram em melhora no tempo de execuo dos mtodos, a anlise do tipo de lao for a ser utilizado (com diferena de desempenho de at 38%) e evitar o uso de getters e setters (com diferena de desempenho de 66%). Essas duas boas prticas foram testadas nos aplicativos Noiz2 e OpenSudoku, com intuito de analisar o impacto dessas boas prticas na eficincia de um aplicativo real. Noiz2 testou somente a boa prtica do lao for, onde no obteve diferena relevante. OpenSudoku testou ambas, no apresentando mudana significativa nos laos for e apresentando uma taxa bastante significativa evitando o uso de getters e setters (38% de impacto) . Os dados do estudo contrastaram com os apresentados por Google (2012a), porm como a referncia no apresentou a metodologia utilizada no foi possvel fazer um comparativo entre os dois estudos. Como trabalhos futuros pretende-se testar todas boas prticas em aplicativos e criar variantes dos cdigos de teste. Outra possibilidade avaliar a diferena no consumo de energia e de memria apresentados com a utilizao das boas prticas.
53
REFERNCIAS
ATLASSIAN .
Clover
Code
Coverage
for
Java.
Disponvel
em
<http://www.atlassian.com/software/clover/>. Acessado em 13 julho de 2011. BULLSEYE. Bullseye Code Coverage Analyzer for C++ and C . Disponvel em <http://www.bullseye.com/>. Acessado em 13 julho de 2011. COSTA H. T. P. Tcnicas de Instrumentao e Coleta de Rastros de Execuo. Universidade de So Paulo, So Carlos SP Brasil Disponvel em <http://moodle.stoa.usp.br/mod/resource/view.php?id=13424>. julho de 2011. DALVIKVM. Dalvik Virtual Machine. Disponvel em < http://www.dalvikvm.com/>. Acessado em 26 julho de 2012. EJ-TECHNOLOGIES. JProfiler. Disponvel em: <http://www.ejAcessado em 13
technologies.com/products/jprofiler/overview.html> em 18 junho de 2012 FERREIRA, R.; BRISOLARA, L.; SPECHT, E.; MATTOS, J.; COTA, E.; CARRO, L. Explorao do Espao de Projeto e Sntese de Software Embarcado a partir de Modelos Alloy. XXXV Conferencia Latinoamericana de Informtica (XXXV CLEI) set. 2009, Pelotas 2009. GOOGLE. Designing for Performance. Disponvel em
Acessado
em
<http://developer.android.com/about/versions/index.html>. Acessado em 18 junho de 2012b. GOOGLE. Using the Android Emulator Disponvel em
54
GOOGLE,
Using
DDMS
Disponvel
em
<http://developer.android.com/reference/android/os/Debug.html>. Acessado em 27 junho de 2012f. GRAAF, B.; LORMANS, M.; TOETENEL, H. Embedded Software Engineering: the State of the Practice. IEEE Software, v. 20, n. 6, p. 61- 69, nov/dez. 2003. GTKWave. GTKWave 3.3 Wave Analyzer. Disponvel em
<http://gtkwave.sourceforge.net/>. Acessado em 14 julho de 2011. KCACHE . KCachegrind Profile Data Visualization. Disponvel em
<http://kcachegrind.sourceforge.net/html/Home.html>. Acessado em 14 julho de 2011. KPROF. KProf Profile Visual Tool. Disponvel em < http://kprof.sourceforge.net/ >. Acessado em 14 julho de 2011. LYNUXWORKS . SpyKer: Embedded System Trace Tool. Disponvel em
<http://www.lynuxworks.com/products/spyker/spyker.php3 >. Acessado em de 15 julho de 2011. MARWEDEL, P. Embedded System Design. Springer:, 2006. MASEK, R. OpenSudoku. Disponvel em < http://code.google.com/p/opensudokuandroid/>. Acessado em 14 setembro de 2012. MATTOS, J. C. B., BRISOLARA, L. B. Desaos no Projeto de Sistemas Embarcados. Em: MATTOS, J. C. B.; ROSA Jr, L. S.; PILLA, M. L. (Org.). Desafios e Avanos em Computao: O Estado da Arte Ed. da Universidade Federal de Pelotas, 2009 Captulo 7.
55
MATTOS, J.C.B., CARRO, L. Object and Method Exploration for Embedded Systems Applications. In Proc. of the Symposium on Integrated Circuits and Systems Design, SBCCI, Rio de Janeiro, Brazil, 2007. New York: ACM Press, 2007. NETBEANS. Netbeans Profiler. Disponvel em:
<http://www.openhandsetalliance.com/oha_members.html>. Acessado em de 18 junho de 2012. OLIVEIRA, M. F. S.; BRISOLARA, L. B.; CARRO, L.; WAGNER, F. R. Early Embedded Software Design Space Exploration using UML-Based Estimation, RSP, pp. 24-30, Seventeenth IEEE International Workshop on Rapid System Prototyping (RSP'06), 2006. Chania, 2006. ORACLE. Controlling Access to Members of a Class. Disponvel em Acessado
Disponvel
em
<http://www.tracealyzer.se/ >. Acessado em 15 julho de 2011. PEREIRA, Rafael L. Ferramenta de Anlise de Bytecodes Java para Aplicaes Embarcadas. 2011. Trabalho acadmico (Graduao) - Bacharelado em Cincia da Computao. Universidade Federal de Pelotas, Pelotas. PIERCE, J.; SMITHY, M. D.; MUDGE, T. Instrumentation tools. In: Fast Simulation of Computer Architectures. Kluwer Academic Publishers, 1995. Disponvel em: <http://www.eecs.umich.edu/~tnm/papers/fastsim.pdf>. Acesso em: 10 jul. 2011. PRWEB. Android Smartphone Activations Reached 331 Million in Q1'2012 Reveals New Device Tracking Database from Signals and Systems Telecom. Disponvel em <http://www.prweb.com/releases/2012/5/prweb9514037.htm>.
56
QASYSTEMS .
Cantata++
Testing
Tool.
Disponvel
em
<http://www.qa-
systems.com/cantata.html >. Acessado em 13 julho de 2011. RATH, D. Embedded Systems Trace Solutions - Analysis and Implementation of Embedded Systems Trace Solutions, 2007. 127f. Tese (Mestrado em Cincia da Computao)-Departamento de Cincia da ComputaoUniversity of Applied Sciences Augsburg, Augusburgo, Dinamarca RUTHERFORD, A. Noiz2. Disponvel em < http://code.google.com/p/noiz2-droid/>. Acessado em 12 setembro de 2012. SILVA, W.G. P.; CORREA; U. B.; BRISOLARA, L.B.; CARRO, L. Evaluation of the impact of code refactoring on embedded software efficiency. WSE, 2010. SURESH, D. C. et al. Proling tools for hardware/software partitioning of embedded applications. ACM SIGPLAN Conf. on Languages, Compilers and Tools for Embedded Systens, San Diego, California, USA, 2003. TESTWELL. Testwell Test Coverage Analyzer for C/C++. <http://www.testwell.fi/>. Acessado em 6 de agosto de 2012. THOMPSON C.; WHITE J., DOUGHERTY B.; SCHMIDT D. C., Optimizing Mobile Application Performance with Model-Driven Engineering , Proceedings of the 7th IFIP Workshop on Software Technologies for Future Embedded and Ubiquitous Systems (SEUS 2009), nov. 2009, Newport Beach, California WOLF, W. Computer as Components: Principles of Embedded Computer Systems Design. San Francisco: Morgan Kaufmann Publishers, 2001. ZDNET. Java vs. Android APIs. Disponvel em Disponvel em:
57
58
59
60
61
62
63
-4%
64
65
66
Diferena Desempenho Original-Sem Length Original - For-each Original - Sem Get e Set
-2% 0% 39%
67
Tabela 12 - Resultados mtodo validate do jogo OpenSudoku, incluindo chamadas dos mtodos filhos
T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 T13 T14 T15 T16 T17 T18 T19 T20 T21 T22 T23 T24 T25 T26 T27 T28 T29 T30 Mdia Desvio Padro Incl Original Incl Sem Get e Set 6612,71 ms 3964,527 ms 6789,058 ms 3985,373 ms 6614,263 ms 4008,048 ms 6606,078 ms 3986,725 ms 6588,835 ms 4037,602 ms 7167,786 ms 4104,346 ms 6941,106 ms 4019,363 ms 6972,998 ms 4111,129 ms 6972,031 ms 3983,568 ms 6951,468 ms 3990,197 ms 6954,753 ms 4027,246 ms 6950,286 ms 4320,907 ms 6942,922 ms 3987,012 ms 6933,174 ms 3961,604 ms 6932,237 ms 4565,095 ms 6649,46 ms 3962,573 ms 6626,985 ms 3980,886 ms 6650,105 ms 3978,946 ms 6675,818 ms 3992,175 ms 6678,153 ms 3960,251 ms 6672,375 ms 3988,031 ms 6800,424 ms 3985,09 ms 6777,876 ms 3990,627 ms 6788,522 ms 3966,188 ms 6733,974 ms 3979,362 ms 6756,051 ms 3970,909 ms 6700,186 ms 3988,417 ms 6675,351 ms 4076,671 ms 6726,749 ms 3980,103 ms 6724,688 ms 3985,017 ms 6785,5474 ms 149,7725526 ms 4027,932933 ms 123,4210529 ms
41%