Você está na página 1de 67

UNIVERSIDADE FEDERAL DE PELOTAS

Centro de Desenvolvimento Tecnolgico Curso de Cincia da Computao

Trabalho Acadmico

Avaliao das Boas Prticas de Codificao para Plataforma Android

Marco Beckmann

Pelotas, 2012

MARCO BECKMANN

AVALIAO DAS BOAS PRTICAS DE CODIFICAO PARA PLATAFORMA ANDROID

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)

................................................................................................ Prof. Dr. Felipe de Souza Marques

................................................................................................ Prof. Dr. Paulo Roberto Ferreira Jr.

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.

Palavras-chave: Android, otimizao, eficincia

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

desempenho: o hardware de sistemas embarcados projetado de

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.

Figura 1 Exemplo de Grafo de Fluxo de Controle (COSTA, 2011).

Figura 2 Programa Exemplo (COSTA, 2011).

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.

Figura 3 Representao de Alto Nvel da Instrumentao (COSTA, 2011).

18

2.3.2

Profilling O primeiro estgio de qualquer processo de otimizao a identificao e

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.

Figura 4 Exemplo de Profile

19

2.3.3

Tracing O Tracing um mtodo para registrar informaes sobre a execuo de um

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.

Figura 5 Arquitetura Android (GOOGLE, 2012b)

3.1.1

O Kernel O kernel do Linux utilizado no sistema operacional a verso 2.6 e tem como

objetivo criar uma camada de abstrao entre o hardware e os aplicativos presentes

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

Bibliotecas O Android possui um conjunto de bibliotecas de C/C++, que so utilizadas por

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

Android Runtime A camada de Runtime inclui um grupo de bibliotecas, chamado Core

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

Aplicaes Junto com o sistema operacional Android, fornecido um conjunto de

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

O ambiente de desenvolvimento Pra facilitar o desenvolvimento de aplicativos para o Android, a Google

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

Figura 6 Emulador do Android

3.2.2

DDMS O DDMS (Dalvik Debug Monitor Server) fornecido junto ao kit de

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

Gerao de Perfis de Execuo e Traceview

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.

Figura 7 Arquivo Aberto no Traceview

27

4.

BOAS PRTICAS DE CODIFICAO PARA ANDROID

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

Uso de Getters/Setters Internos

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

Uso de Static Final para Constantes

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 .

Figura 8 Declarao Static

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.

Figura 9 Declarao Final Static

29

4.4

Uso da Sintaxe Aprimorada do For

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

Figura 10 Codificaes alternativas para uma iterao

4.5

Acesso do tipo Pacote ao invs do acesso Privado em classe interna

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

Figura 11 Classe Exemplo

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.

Figura 12 Mtodos de sntese gerados pelo compilador

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

Uso de operaes em ponto flutuante

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.

EXPERIMENTOS Este captulo apresenta os experimentos realizados com as boas prticas

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.

Figura 13 Cdigos para avaliao da prtica esttico x virtual

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.

Figura 14 Cdigos para avaliao da prtica com getter x sem getter

36

A chamadas do mtodo semGetter obtiveram como tempo

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

Figura 15 Cdigos para avaliao da prtica static x static final

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

Figura 16 Cdigo para avaliao de diversas sintaxes do for - exemplo 1

40

Figura 17 Cdigos para avaliao de diversas sintaxes do for - exemplo 2

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

Figura 18 Cdigos para avaliao do impacto dos tipos de acesso

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.

Figura 19 Cdigos para avaliao da escolha do tipo de dado

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

Noiz2 O aplicativo Noiz2 (RUTHERFORD, 2012) trata-se de um jogo de naves.

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.

Figura 20 Avaliao do aplicativo Noiz2

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

Figura 21 Mtodo reinit

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.

Figura 22 Mtodo reinit alterado

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

OpenSudoku OpenSudoku (MASEK, 2012) trata-se de um jogo de sudoku tradicional.

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.

Figura 23 Avaliao do aplicativo OpenSudoku

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

Figura 24 Cdigo do Mtodo validate original

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

Figura 25 Mtodo validate alterado For sem length

Figura 26 Mtodo validate alterado para uso do For-each

49

Figura 26 Mtodo validate alterado Getters e Setters

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).

Tabela 1 - Resultados OpenSudoku


Mdia 1742,862 ms 1774,738 ms 1748,479ms 1059,168 ms Desvio Padro 35,410 ms 17,128 ms 22,936 ms 68,387 ms Diferena desempenho (em relao ao original) -2% 0% 39%

Original For sem length For-each Sem get e set

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.

CONCLUSO constante a preocupao com eficincia, seja em termos de desempenho

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

<http://developer.android.com/guide/practices/design/performance.html>. em 18 junho de 2012a. GOOGLE. App Framework Disponvel

Acessado

em

<http://developer.android.com/about/versions/index.html>. Acessado em 18 junho de 2012b. GOOGLE. Using the Android Emulator Disponvel em

<http://developer.android.com/tools/devices/emulator.html>. Acessado em 26 junho de 2012c.

54

GOOGLE,

Using

DDMS

Disponvel

em

<http://developer.android.com/tools/debugging/ddms.html>. Acessado em 27 junho de 2012d. GOOGLE, Android Debug Bridge Disponvel em

<http://developer.android.com/tools/help/adb.html>. Acessado em 26 junho de 2012e. GOOGLE, Debug 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://netbeans.org/features/java/profiler.html> em 18 junho de 2012. OHA. Open Handset Alliance. 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

<http://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html>. em de 27 julho de 2012. PERCEPIO. Trace Visualizer for Embedded Systems.

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>.

Acessado em de 18 junho de 2012.

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:

<http://www.zdnet.com/blog/burnette/java-vs-android-apis/504>. Acessado em 18 junho de 2012.

57

APNDICE A LISTA DE TABELAS Tabela 2 - Resultados Static vs Virtual


Static T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 T13 T14 T15 1T6 T17 T18 T19 T20 T21 T22 T23 T24 T25 T26 T27 T28 T29 T30 197,86 ms 191,624 ms 200,663 ms 198,922 ms 198,739 ms 200,217 ms 195,813 ms 190,267 ms 194,396 ms 189,327 ms 197,171 ms 199,698 ms 197,262 ms 195,562 ms 198,618 ms 201,996 ms 188,742 ms 189,578 ms 189,036 ms 189,644 ms 189,969 ms 188,265 ms 188,564 ms 184,597 ms 192,107 ms 192,235 ms 202,915 ms 196,766 ms 194,002 ms 192,691 ms Virtual 203,829 ms 195,214 ms 199,86 ms 202,732 ms 195,422 ms 199,696 ms 189,223 ms 190,161 ms 188,824 ms 187,504 ms 196,327 ms 202,345 ms 199,316 ms 195,858 ms 202,432 ms 203,441 ms 185,987 ms 185,309 ms 187,122 ms 188,953 ms 190,42 ms 185,901 ms 184,215 ms 189,549 ms 191,378 ms 192,275 ms 193,74 ms 195,287 ms 189,13 ms 194,238 ms 193,5229333 ms 6,022055715 ms

Mdia 194,2415333 ms Desvio Padro 4,849703423 ms Diferena Desempenho Static/Virtual 0%

58

Tabela 3 - Resultados Com Getter vs Sem Getter


T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 T13 T14 T15 1T6 T17 T18 T19 T20 T21 T22 T23 T24 T25 T26 T27 T28 T29 T30 Mdia Desvio Padro Com Getter Sem Getter 542,711 ms 189,466 ms 547,924 ms 183,169 ms 548,021 ms 192,071 ms 547,487 ms 191,216 ms 546,8 ms 192,145 ms 547,002 ms 188,783 ms 549,314 ms 188,179 ms 540,91 ms 183,32 ms 545,867 ms 181,618 ms 541,367 ms 183,107 ms 547,109 ms 187,575 ms 545,786 ms 202,913 ms 555,679 ms 198,304 ms 545,936 ms 192,171 ms 542,389 ms 189,498 ms 543,981 ms 191,348 ms 547,757 ms 181,389 ms 557,595 ms 182,594 ms 548,599 ms 181,681 ms 545,679 ms 178,96 ms 548,242 ms 180,945 ms 549,038 ms 180,382 ms 543,93 ms 183,605 ms 555,506 ms 190,996 ms 552,222 ms 184,556 ms 548,996 ms 184,199 ms 547,102 ms 185,07 ms 545,508 ms 191,788 ms 547 ms 187,764 ms 547,61 ms 185,871 ms 547,4355667 ms 3,882394655 ms 187,1561 ms 5,507207537 ms

Diferena Desempenho ComGetter/SemGetter 66%

59

Tabela 4 - Resultados Static vs Static Final em inteiros


Static T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 T13 T14 T15 1T6 T17 T18 T19 T20 T21 T22 T23 T24 T25 T26 T27 T28 T29 T30 Mdia Desvio Padro 199,953 ms 191,689 ms 199,119 ms 196,108 ms 202,009 ms 195,66 ms 188,96 ms 186,158 ms 189,76 ms 188,441 ms 196,481 ms 198,94 ms 199,558 ms 192,336 ms 193,559 ms 198,384 ms 187,418 ms 184,634 ms 187,448 ms 188,029 ms 181,661 ms 186,582 ms 186,272 ms 186,278 ms 188,002 ms 186,779 ms 190,415 ms 193,183 ms 191,384 ms 190,24 ms 191,5146667 ms 5,35403985 ms Static Final 191,129 ms 192,676 ms 193,19 ms 197,801 ms 194,342 ms 190,48 ms 186,852 ms 195,303 ms 183,792 ms 186,326 ms 192,477 ms 196,031 ms 192,633 ms 194,626 ms 196,359 ms 196,332 ms 180,785 ms 182,926 ms 184,251 ms 182,587 ms 183,39 ms 182,406 ms 183,249 ms 188,885 ms 184,35 ms 184,618 ms 189,384 ms 188,979 ms 187,556 ms 185,779 ms 188,9831333 ms 5,14015058 ms

Diferena Desempenho Static-Static Final 1%

60

Tabela 5 - Resultados Static vs Static Final em strings


Static T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 T13 T14 T15 1T6 T17 T18 T19 T20 T21 T22 T23 T24 T25 T26 T27 T28 T29 T30 Mdia Desvio Padro 189,81 ms 183,922 ms 197,508 ms 191,745 ms 190,73 ms 193,226 ms 181,196 ms 182,515 ms 180,964 ms 182,913 ms 194,026 ms 193,727 ms 195,591 ms 194,612 ms 193,144 ms 194,874 ms 186,107 ms 183,78 ms 188,258 ms 183,333 ms 187,518 ms 181,514 ms 180,489 ms 182,468 ms 184,78 ms 183,682 ms 184,675 ms 182,844 ms 187,244 ms 190,243 ms 187,5812667 ms 5,234432769 ms Static Final 189,558 ms 186,879 ms 199,806 ms 189,499 ms 191,853 ms 192,217 ms 174,932 ms 184,693 ms 183,948 ms 183,764 ms 192,252 ms 193,552 ms 189,708 ms 191,844 ms 192,962 ms 195,353 ms 179,949 ms 181,478 ms 182,008 ms 179,914 ms 182,573 ms 181,85 ms 180,066 ms 187,192 ms 183,098 ms 184,965 ms 191,925 ms 185,581 ms 188,58 ms 186,476 ms 187,3635517 ms 5,187397191 ms

Diferena Desempenho Static-Static Final 0%

61

Tabela 6 - Resultados sintaxes For


Zero T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 T13 T14 T15 1T6 T17 T18 T19 T20 T21 T22 T23 T24 T25 T26 T27 T28 T29 T30 Mdia Desvio Padro 5,915 ms 4,073 ms 4,665 ms 4,608 ms 3,992 ms 4,699 ms 4,519 ms 3,937 ms 4,476 ms 4,402 ms 5,265 ms 3,918 ms 7,174 ms 3,883 ms 4,478 ms 3,92 ms 5,392 ms 3,867 ms 4,589 ms 4,059 ms 3,815 ms 4,04 ms 4,047 ms 5,334 ms 3,901 ms 3,907 ms 6,926 ms 4,604 ms 3,988 ms 4,162 ms 4,551833333 ms 0,861500098 ms One 3,506 ms 2,871 ms 3,193 ms 3,19 ms 2,645 ms 3,33 ms 2,667 ms 2,761 ms 4,801 ms 3,258 ms 2,747 ms 2,691 ms 2,955 ms 2,644 ms 2,659 ms 2,624 ms 3,157 ms 2,785 ms 2,866 ms 2,779 ms 3,307 ms 2,714 ms 3,419 ms 2,781 ms 2,855 ms 2,812 ms 2,835 ms 3,113 ms 3,355 ms 3,034 ms 3,0118 ms 0,429981507 ms Two 2,703 ms 2,629 ms 2,645 ms 2,731 ms 3,258 ms 2,708 ms 2,773 ms 2,631 ms 2,707 ms 2,737 ms 2,666 ms 2,749 ms 2,708 ms 2,747 ms 2,626 ms 2,619 ms 2,778 ms 2,65 ms 2,672 ms 3,154 ms 2,709 ms 2,881 ms 2,962 ms 2,83 ms 3,526 ms 2,968 ms 2,781 ms 2,879 ms 3,549 ms 3,206 ms 2,8394 ms 0,253953376 ms

Diferena de Desempenho Zero-Two 34% Zero-Three 38% Two-Three 6%

62

Tabela 7 Resultados sintaxes For verso 2


Zero T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 T13 T14 T15 1T6 T17 T18 T19 T20 T21 T22 T23 T24 T25 T26 T27 T28 T29 T30 Mdia Desvio Padro 3,338 ms 3,385 ms 3,868 ms 3,575 ms 3,554 ms 3,347 ms 3,276 ms 6,135 ms 2,994 ms 6,544 ms 3,24 ms 7,301 ms 2,967 ms 4,229 ms 5,377 ms 3,348 ms 3,233 ms 3,811 ms 3,247 ms 3,617 ms 3,651 ms 3,038 ms 3,642 ms 3,033 ms 3,65 ms 6,501 ms 4,228 ms 3,486 ms 7,042 ms 6,495 ms 4,171733333 ms 1,362769567 One 2,9 ms 3,121 ms 2,89 ms 6,698 ms 3,809 ms 2,827 ms 3,443 ms 4,076 ms 2,865 ms 5,175 ms 2,852 ms 3,553 ms 3,678 ms 6,512 ms 2,798 ms 2,977 ms 2,918 ms 4,91 ms 2,75 ms 3,297 ms 2,605 ms 3,712 ms 2,625 ms 2,91 ms 2,675 ms 2,683 ms 3,281 ms 3,622 ms 4,051 ms 2,709 ms 3,4974 ms 1,062176834 Two 2,883 ms 3,361 ms 2,899 ms 4,156 ms 3,168 ms 3,047 ms 2,774 ms 2,969 ms 2,76 ms 4,081 ms 3,96 ms 4,167 ms 2,836 ms 2,971 ms 2,793 ms 2,66 ms 3,88 ms 4,971 ms 2,817 ms 2,992 ms 2,762 ms 6,152 ms 4,048 ms 2,689 ms 3,891 ms 2,843 ms 2,882 ms 2,772 ms 2,748 ms 2,747 ms 3,322633333 ms 0,810227788

Diferena Desempenho Zero-Two 16% Zero-Three 20% Two-Three 5%

63

Tabela 8 - Resultados Package Acess vs Private


Public T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 T13 T14 T15 1T6 T17 T18 T19 T20 T21 T22 T23 T24 T25 T26 T27 T28 T29 T30 Mdia Desvio Padro Diferena Desempenho Public-Private 4,386 ms 4,206 ms 5,032 ms 4,148 ms 4,277 ms 4,137 ms 4,19 ms 4,095 ms 4,194 ms 4,331 ms 4,207 ms 4,383 ms 4,373 ms 4,345 ms 4,783 ms 4,299 ms 4,301 ms 4,208 ms 4,785 ms 4,122 ms 4,235 ms 4,119 ms 4,158 ms 4,879 ms 4,14 ms 4,172 ms 4,294 ms 4,633 ms 4,948 ms 4,951 ms 4,3777 ms 0,28815838 ms Private 4,994 ms 4,266 ms 4,222 ms 4,757 ms 4,676 ms 4,58 ms 4,171 ms 4,137 ms 4,343 ms 4,721 ms 4,62 ms 4,314 ms 4,244 ms 5,003 ms 4,336 ms 4,734 ms 5,024 ms 4,884 ms 4,252 ms 4,196 ms 4,265 ms 4,731 ms 4,899 ms 4,433 ms 4,645 ms 4,398 ms 4,847 ms 4,367 ms 4,307 ms 4,817 ms 4,539433333 ms 0,284728386 ms

-4%

64

Tabela 9 - Resultados Int, Float e Double


Int T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 T13 T14 T15 1T6 T17 T18 T19 T20 T21 T22 T23 T24 T25 T26 T27 T28 T29 T30 Mdia Desvio Padro 202,63 ms 198,187 ms 204,13 ms 205,084 ms 199,261 ms 204,174 ms 193,508 ms 197,167 ms 194,946 ms 190,465 ms 205,241 ms 207,732 ms 207,5 ms 208,516 ms 200,545 ms 199,365 ms 194,193 ms 199,132 ms 191,066 ms 193,592 ms 192,902 ms 195,254 ms 193,003 ms 193,348 ms 202,8 ms 196,071 ms 195,767 ms 195,874 ms 197,141 ms 193,806 ms 198,4133333 ms 5,269076483 ms Float 199,455 ms 198,948 ms 201,841 ms 200,362 ms 201,671 ms 197,504 ms 190,328 ms 195,142 ms 189,516 ms 189,363 ms 207,968 ms 205,212 ms 206,018 ms 203,218 ms 205,627 ms 197,593 ms 193,306 ms 194,356 ms 195,989 ms 192,869 ms 197,437 ms 199,793 ms 199,968 ms 194,154 ms 191,215 ms 202,469 ms 193,733 ms 194,891 ms 195,793 ms 193,615 ms 197,6451333 ms 5,098963416 ms Double 202,717 ms 201,443 ms 205,419 ms 209,205 ms 202,966 ms 201,115 ms 191,077 ms 203,882 ms 193,723 ms 193,807 ms 213,167 ms 208,011 ms 205,43 ms 207,454 ms 208,262 ms 201,248 ms 201,238 ms 196,399 ms 195,93 ms 198,591 ms 194,452 ms 195,601 ms 195,825 ms 189,798 ms 197,917 ms 198,318 ms 198,831 ms 200,428 ms 196,89 ms 195,265 ms 200,1469667 ms 5,703333499 ms

Diferena Desempenho Int-Float 0% Int-Double -1% Float-Double -1%

65

Tabela 10 - Resultados mtodo reinit do jogo Noiz2


T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 T13 T14 T15 1T6 T17 T18 T19 T20 T21 T22 T23 T24 T25 T26 T27 T28 T29 T30 Mdia Desvio Padro Sem Mudana Com Mudana 2653,301 ms 2557,173 ms 2669,943 ms 2516,385 ms 2620,62 ms 2577,832 ms 2612,688 ms 2596,385 ms 2632,118 ms 2547,47 ms 2626,1 ms 2599,419 ms 2678,683 ms 2551,309 ms 2622,667 ms 2529,809 ms 2626,354 ms 2567,663 ms 2635,32 ms 2546,588 ms 2628,113 ms 2563,529 ms 2635,246 ms 2556,485 ms 2593,067 ms 2565,145 ms 2614,934 ms 2536,145 ms 2567,474 ms 2553,656 ms 2574,346 ms 2552,883 ms 2566,108 ms 2551,72 ms 2561,202 ms 2535,242 ms 2573,619 ms 2545,063 ms 2576,239 ms 2553,178 ms 2572,744 ms 2548,637 ms 2587,391 ms 2569,811 ms 2631,07 ms 2528,531 ms 2572,139 ms 2550,304 ms 2609,104 ms 2536,713 ms 2570,47 ms 2561,302 ms 2629,602 ms 2558,108 ms 2594,252 ms 2553,813 ms 2568,032 ms 2551,272 ms 2614,287 ms 2572,128 ms 2607,2411 ms 32,5755502 ms 2554,4566 ms 17,95388732 ms

Diferena Desempenho Com-Sem 2%

66

Tabela 11 - Resultados mtodo validate do jogo OpenSudoku


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 Original For Sem Length For Each Sem Get Set 1703,262 ms 1776,719 ms 1727,537 ms 1038,955 ms 1741,221 ms 1772,935 ms 1699,558 ms 1038,744 ms 1700,442 ms 1751,586 ms 1754,599 ms 1044,221 ms 1695,663 ms 1783,178 ms 1706,043 ms 1045,15 ms 1691,053 ms 1768,009 ms 1719,156 ms 1052,999 ms 1843,812 ms 1790,125 ms 1727,48 ms 1087,388 ms 1776,611 ms 1763,781 ms 1729,542 ms 1055,892 ms 1782,184 ms 1799,547 ms 1722,889 ms 1078,231 ms 1780,73 ms 1771,382 ms 1749,75 ms 1039,694 ms 1782,426 ms 1811,382 ms 1738,925 ms 1046,354 ms 1778,952 ms 1772,469 ms 1725,154 ms 1044,77 ms 1773,044 ms 1767,797 ms 1722,001 ms 1041,204 ms 1773,46 ms 1757,821 ms 1750,454 ms 1044,456 ms 1782,972 ms 1761,814 ms 1734,235 ms 1036,314 ms 1770,716 ms 1771,434 ms 1754,618 ms 1415,756 ms 1709,158 ms 1775,633 ms 1763,687 ms 1036,751 ms 1708,084 ms 1779,233 ms 1753,311 ms 1038,386 ms 1710,056 ms 1766,932 ms 1762,731 ms 1042,508 ms 1727,534 ms 1793,83 ms 1774,502 ms 1050,916 ms 1709,765 ms 1764,801 ms 1759,534 ms 1038,11 ms 1731,741 ms 1786,767 ms 1757,71 ms 1041,911 ms 1742,784 ms 1775,612 ms 1766,837 ms 1053,757 ms 1748,433 ms 1766,356 ms 1755,31 ms 1042,881 ms 1752,347 ms 1782,878 ms 1749,483 ms 1038,048 ms 1736,718 ms 1781,012 ms 1770,442 ms 1054,847 ms 1723,767 ms 1788,643 ms 1788,308 ms 1041,376 ms 1726,341 ms 1783,435 ms 1763,122 ms 1043,138 ms 1715,403 ms 1772,922 ms 1782,005 ms 1064,529 ms 1739,636 ms 1789,734 ms 1758,957 ms 1040,196 ms 1727,568 ms 1714,398 ms 1786,505 ms 1037,57 ms 1742,862767 ms 1774,738833 ms 1748,4795 ms 1059,1684 ms 35,41008195 ms 17,12843726 ms 22,93681349 ms 68,38799448 ms

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

Diferena Desempenho Original-Sem Length

41%

Você também pode gostar