Universidade Federal do Rio de Janeiro

Escola Politécnica

MBA em Engenharia de Computação e Sistemas

Minimização do Consumo de Bateria para Aplicativos deGeolocalização

Autor:

_________________________________________________Leonardo da Silva Oliveira

Orientador:

_________________________________________________Flávio Luis de Mello, PhD

Examinador:

_________________________________________________

Edilberto Strauss, PhD

Examinador:

_________________________________________________

Andressa dos Santos Nicolau, DSc

Examinador:

_________________________________________________Claudio Luiz Latta de Souza, MSc

Examinador:

_________________________________________________

i

Manoel Villas-Bôas Junior, MSc

Examinador:

_________________________________________________Paulo Fernando Peixoto da Costa Fazzioni, MSc

MBCA

Agosto de 2016

ii

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO

Escola Politécnica – Departamento de Eletrônica e de Computação

MBA em Engenharia de Computação Avançada

Centro de Tecnologia, bloco H, sala H-212B, Cidade Universitária

Rio de Janeiro – RJ CEP 21949-900

Este exemplar é de propriedade da Universidade Federal do Rio de Janeiro, que

poderá incluí-lo em base de dados, armazenar em computador, microfilmar ou adotar

qualquer forma de arquivamento.

É permitida a menção, reprodução parcial ou integral e a transmissão entre

bibliotecas deste trabalho, sem modificação de seu texto, em qualquer meio que esteja

ou venha a ser fixado, para pesquisa acadêmica, comentários e citações, desde que sem

finalidade comercial e que seja feita a referência bibliográfica completa.

Os conceitos expressos neste trabalho são de responsabilidade do(s) autor(es).

iii

iv

AGRADECIMENTO

Dedico este trabalho ao povo brasileiro que contribuiu de forma significativa à

minha formação e estada nesta Universidade. Este projeto é uma pequena forma de

retribuir o investimento e confiança em mim depositados.

v

RESUMO

Aplicativos baseados em localização devem fazer uso constante dos sensores de

smartphones para obter a localização precisa do aparelho. No entanto, o uso não

gerenciado desses sensores consumiria muita energia da bateria tornano o aplicativo

inviável para uso. Portanto esse trabalho visa sugerir boas práticas a fim de reduzir a

demanda por energia dos principais sensores envolvidos no processo de obtenção de

localização, GPS e Wifi, através da especificação dos valores mais apropriados para os

filtros de restrição de uso do GPS e da adoção da técnica do atraso de rede para o Wifi.

Foram realizados experimentos para se obter os valores ideais para restrição de

uso dos dois sensores e apresentada a relação do consumo de energia por parte da

aplicação em dois cenários distintos: (1) cenário de consumo normal, o qual não foram

aplicadas as técnicas de redução de energia e (2) cenário de consumo econômico, em

que foram aplicadas as técnicas de redução do consumo de energia pelo GPS e Wifi.

A partir da relação obtida pela execução dos cenários 1 e 2 foi comprovado um

ganho considerável de economia de energia na aplicação ao adotar as estratégias de

redução de consumo de energia.

Palavras-Chave: smartphone, apps, geolocalização, google-maps

vi

ABSTRACT

Location-based applications must constantly use the sensors of the smartphoneto receive periodic position coordinates updates. However, the smartphone's sensorsused to obtain the user location require a lot of energy from the battery and therefore itmust be managed. Thus, this paper aims to propose a method for reducing the energydemand by the sensors used in the process of obtaining the user location, such as GPSand Wifi. It, specifies filters to restrict the use of the GPS and uses network delaystrategy to reduce the Wifi usage in order to reduce the energy consumption.

Experiments were performed to obtain the threshold values used to restrict thesensors and to compare the energy consumption by the application on two distinctscenarios: (1) normal consumption, where the application was executed withoutadopting any the strategies that would restrict the sensors and (2) low consumption,where the application was executed by applying the strategies used reduced the demandfor energy on the GPS and Wifi sensors.

By using the data acquired from the execution of both scenarios, it wasconfirmed that the stategies used to reduce the demand for energy on both sensors,significantly reduced the overall energy consumed by the application as a whole.

Key-word: smartphone, apps, geolocalization, google-maps

vii

SIGLAS

A-GPS – Assisted Global Positioning System

CPU – Central Processing Unit

DCH – Dedicated Transport Channel

FACH – Forward Access Channel

GPS – Global Positioning System

HTTP – Hyper Text Transfer Protocol

IDE – Integrated Development Environment

LBA – Location Based App

LCD – Liquid Crystal Display

OO – Orientação a Objeto

RAM – Random Access Memory

SDK – Software Development Kit

SO – Sistema Operacional

UFRJ – Universidade Federal do Rio de Janeiro

UML – Unified Modeling Language

UX – User Experience

viii

Sumário

1 Introdução 1

1.1 - Tema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.2 - Delimitação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.3 - Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.4 - Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.5 - Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Gerência do Consumo de Bateria 15

2.1 - Consumo no nível de hardware . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 .1 - Wifi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.1.1 - Consumo energético: tamanho do pacote vs tempo entre transferências 17

2.2.2 - GPS VS A-GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3 - Gerenciamento de consumo no nível de Software . . . . . . . . . . . 19

2.3.1 - Cinder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3.2 - Gerenciamento do consumo no nível da aplicação . . . . . . . . . 19

2.3.2.1 - Atraso e Prefetching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3.2.2 - Mapeamento energético . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3 Estratégia proposta de consumo de energia orientado pelo código-fonte 23

3.1 - Orientação a objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2 - Controle de uso do GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3 - Controle de uso do Wifi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.3.1 - Implementando a classe para gerenciar o Wifi . . . . . . . . . . . . 28

ix

3.4 - Resultados obtidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4 Conclusão 37

Anexo A 38

Anexo B 40

Anexo C 41

Anexo D 42

Anexo E 43

Referências Bibliográficas 44

x

Lista de Figuras

2.1 – Relação entre do tamanho do pacote vs intervalo entre as transferências . . . 19

2.2 – GPS assistido por uma cloud utilizando o modelo LEAP . . . . . . . . . . . . . . . 20

3.1 – Definição da classe DeviceLocation em notação UML . . . . . . . . . . . . . . . 30

3.2 – Diagrama de fluxo para o método start . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.3 – Relação do consumo de energia em função do tempo e do atraso . . . . . . . . . 35

3.4 – Diagrama de sequência para a classe NetworkScheduler . . . . . . . . . . . . . . . 36

3.5 – Diagrama UML de uma subclasse de NetworkScheduler . . . . . . . . . . . . . 37

3.6 – Diagrama de sequência que representa a troca de mensagens entre duas classes . . . 38

3.7 – Relação do consumo total de bateria no cenário 1 (modo normal) em cada uma das 10 medições

40

3.8 – Relação do consumo total de bateria no cenário 1 (modo econômico) em cada uma das 10 medições

40

3.9 – Comparativo do consumo de energia entre os cenários 1 (modo normal) e 2 (modo econômico)

41

xi

Lista de Tabelas

2.1 – Relação da taxa de consumo de energia dos componentes de smartphones 17

2.2 – Relação entre categorias de software e sensibilidade ao atraso de rede 22

2.3 – Relação entre componentes e seus respectivos coeficientes considerados 24

3.1 – Relação classes abstratas vs interfaces 26

3.2 – Relação de consumo para o parâmetro de tempo para o GPS 27

3.3 – Consumo de energia em função do tempo ao alterar o valor de threshold 29

3.4 – Comparativo da economia no consumo de bateria 39

3.5 – Relação das médias e do desvio padrão calculados para os cenários 1 (modo normal) e 2 (modo econômico)

41

xii

Capítulo 1

Introdução

1.1 – Tema

O tema do trabalho é maximizar o tempo útil da bateria de smartphones ao

utilizarem aplicativos baseados em geolocalização através da redução da demanda por

energia dos sensores de GPS e Wifi.

1.2 – Delimitação

Este trabalho se destina à desenvolvedores de aplicativos para plataformas

móveis que desejam minimizar o consumo de bateria de seus aplicativos ao definir

intervalos regulares para uso dos sensores de Wifi e GPS do aparelho.

1.3 – Justificativa

Dispositivos móveis vêm, ao longo dos anos, se tornando mais comuns em

nossas vidas. A evolução de suas especificações técnicas, como processadores mais

potentes, maiores quantidades de memória RAM, sistemas operacionais e sensores

viabilizou que eles se tornassem aparelhos multi-tarefas. Uma pesquisa realizada pela

empresa Nielsen Ibope [1] indica que 68,4 milhões de brasileiros estavam utilizando

smartphones para acessar a internet no primeiro semestre de 2015. Porém os usuários

desses aparelhos não estão restringindo seu uso para apenas navegação pela internet.

Nos sites de repositórios de aplicativos (“apps”), como o Google Play ou a Apple Store,

há diversas apps submetidas, algumas possuindo milhões de downloads.

Isso indica uma forte tendência dos usuários de smartphones em utilizar estes

aplicativos como meios para a realização de tarefas diversas. Dentre as categorias de

apps existente, uma vem adquirindo bastante notoriedade ao longo do tempo:

aplicativos baseados em localização.

1

A Comissão Européia [2] em seu artigo, menciona a importância de dados

geográficos na tomada de decisão e a forma como os mesmos podem ser associados a

diversos outros tipos de informações, como financeiras, comportamentais e de saúde

pública. No entando, para que os aplicativos possam estar cientes da localização do

aparelho, eles necessitam de informações captadas por sensores específicos, como o

GPS ou Wifi. De modo a conseguir maior precisão nas informações obtidas, há a

necessidade de se manter um canal de comunicação constante utilizando estes sensores.

Carrol e Heiser [3] realizaram uma bateria de testes de exaustão de modo a traçar o

consumo de energia dos componentes de smartphones quando submetidos a

determinadas tarefas. Em praticamente todos os cenários, os componentes CPU, LCD,

Wifi e GPS foram os que obtiveram maior consumo de energia. Caso o uso desses

componentes não seja devidamente controlado, o aplicativo irá consumir rapidamente a

bateria do aparelho. Naturalmente, o próprio sistema operacional já inclui mecanismos

para redução do consumo de energia do dispositivo. Porém, como apontam Li e Halfond

em seu artigo [4], gerir o consumo de energia dos aplicativos também é

responsabilidade de seus desenvolvedores. O autores mencionam que a classificação

que o usuários fornecem aos aplicativos também está ligada ao quanto de energia que o

o aplicativo consome. Portanto torna-se necessário a adoção de técnicas que auxiliem a

aplicação a minimizar o consumo de energia do aparelho. Essas técnicas variam desde

alterar a forma como determinados tipos de dados são criados e acessados durante o

código até a restrição da quantidade de acessos a determinados sensores.

Aplicativos de geolocalização em tempo real necessitam de uso recorrente de

sensores específicos (como GPS e Wifi). Embora o uso constante desses sensores fosse

o ideal para uma coleta de dados mais precisa, essa idéia traz complicações quanto ao

consumo de bateria do aparelho. O uso simultâneo desses recursos consumiria

rapidamente a bateria tornando o aparelho inutilizável em pouco tempo. Esse trabalho,

portanto, visa apresentar meios de realizar uso consciente de tais sensores de modo a

minimizar a taxa de consumo de bateria enquanto preserva a experiência do usuário.

1.4 – Objetivos

O objetivo desse trabalho é propor um modo de minimizar o consumo de bateria

para aplicativo de geolocalização em tempo real definindo intervalos regulares para uso

dos sensores de GPS e Wifi. Nesse sentido os objetivos específicos são:

2

Desenvolver uma classe base para gerenciamento do uso dos sensores,

utilizando os princípios de orientação a objetos (OO)

Definir intervalos regulares para uso dos sensores.

Estipular regras, como tempo e distância, para definir a taxa de atualização dos

dados de GPS.

Selecionar o provedor de dados de localização mais apropriado.

1.5 – Metodologia

Para a realização desse trabalho foram utilizadas diversas fontes de pesquisa,

nacionais e internacionais, sobre smartphones, sensores e consumo e gerenciamento de

energia. O aplicativo utilizado como base para o trabalho, “FriendsLocator”, foi

desenvolvido utilizando as seguintes tecnologias:

Linguagem de programação: Java

IDE: Android Studio [5]

Testes unitários [6, 7, 8]

3

Capítulo 2

Gerência do consumo de bateriaO tempo de vida útil da bateria de smartphones é uma constante preocupação,

tanto para seus usuários quanto para os fabricantes. Os fabricantes de baterias e circuitos

vêm oferecendo uma atenção especial durante a projeção de suas peças, de modo a

reduzir a demanda por energia pelas mesmas [15]. Os projetistas de Sistemas

Operacionais também vêm se preocupando com o gerenciamento do consumo de

energia para S.Os nativos em dispositivos móveis [11].

A pesquisa realizada por Rodriguez et. al [9], aponta a importância de uma

análise do consumo de energia tanto no hardware quanto no software. Os autores

consideraram em sua pesquisa os seguintes dados:

Sistemas operacionais

Interfaces de redes e otimização de protocolos

Otimização de sensores

Comportamento dos usuários enquanto utilizam os smartphones

A seguir, será realizado um breve levantamento da demanda por energia em dois

níveis: hardware e software.

2.1 – Consumo no nível de hardware

Naik & Chavan [10] realizaram em seu trabalho uma análise detalhada da taxa

de consumo de determinados componentes de smartphones. A tabela a seguir apresenta

essa relação:

Tabela 2.1: Relação da taxa de consumo de energia dos componentes de smartphones

4

[10,16]

5

Componente Ação Consumo (mW)

GPS Em uso 400

CPU 50% 462

WIFI Conectado 868

Idle 58

Baixando a 4.5 Mbps 1450

Tela Luz de background a 20%de intensidade

63

Luz de background a 100%de intensidade

527.65

Memória Escrevendo 1Mb 587.7

Voz Realizando uma chamadade voz (3G)

1265.7

Vídeo Realizando uma chamadade vídeo (3G)

2210

Bluetooth Ligado 15

Enviando 432

Através dos dados apresentados na Tabela 2.1 é possível notar que, dos

componentes analisados, aqueles que necessitam de maiores quantidades de energia são

os que estão relacionados com streams de dados(Wifi, 3G). A taxa de energia consumida

pelo sensor do Wifi quando está em uso é a mais preocupante para o contexto desse

trabalho, uma vez que a natureza das aplicações de localização requerem uso constante

desse sensor em conjunto com o sensor de GPS.

2.1.1 – Wifi

Muitos modelos recentes foram propostos para analisar a taxa de consumo de

energia do hardware de Wifi em smartphones. Alguns desses modelos analisam o

consumo energético no nível de circuito que, apesar de oferecer uma boa precisão, uma

análise em nível tão baixo requer conhecimento prévio do firmware de rede o que acaba

inviabilizando uma análise genérica por parte dos desenvolvedores de apps que não

possuirão essa informação em mãos. Outros modelos utilizam uma abordagem

matemática, onde a taxa de transferência é vista como uma função linear.

Apesar da grande variedade de modelos propostos, todos assumem o constante

consumo de energia nos diferentes estados no Wifi (idle, em uso, buscando por pontos

6

de acesso, etc). A seguir serão apresentados alguns dos modelos propostos para

mensurar a taxa de consumo da Wifi. É necessário mencionar que esses modelos não

consideram o gasto de energia extra demandado pela retransmissão de pacotes na rede,

o que acaba gerando uma imprecisão na análise final.

2.1.1.1 – Consumo energético: tamanho do pacote vs tempo entre transferências

Em uma das análises realizadas por Balasubramanian et al. [21], foi apresentada

uma relação da taxa de consumo de energia da Wifi em função do tamanho do pacote

transmitido com o intervalo entre as transferências. A figura 2.1 apresenta essa relação.

É possível notar que o consumo de energia aumenta de acordo com o tamanho do

pacote transmitido.

Figura 2.1 Relação entre do tamanho do pacote vs intervalo entre as transferências

[14]

7

2.2 – GPS vs A-GPS

Para aplicações que requerem precisão quanto à localização do usuário e

necessitam de atualizações frequentes da mesma, torna-se necessário o uso constante do

sensor de GPS. No entanto, como apontam Ramos et al. [22], o uso contínuo do GPS

consumiria totalmente a energia da bateria em menos de 6 horas. Para mitigar esse

problema e viabilizar o uso dessas aplicações, alguns modelos foram propostos. Um

modelo relevante para o contexto desse trabalho é o LEAP [16].

Esse modelo atua como um GPS assistido por uma cloud, de modo que os

cálculos de posicionamento são realizados pela cloud e a única responsabilidade do

sensor de GPS é obter os sinais dos satélites de GPS. Para obter uma maior precisão no

cálculo de posicionamento, a cloud utiliza a localização de objetos conhecidos como

referência, como torres de celulares. Essa estratégia, segundo os autores, permitiu uma

economia de energia de até 80% em comparação com o modelo tradicional de

posicionamento. A Figura 2.2 representa esse trabalho colaborativo entre o GPS e a

cloud.

Figura 2.2 GPS assistido por uma cloud utlizando o modelo LEAP

[22]

8

2.3 – Gerenciamento de consumo no nível de software

O gerenciamento do consumo de energia na camada do software pode ser

realizado tanto pelo sistema operacional quanto pelos aplicativos. Na camada do sistema

operacional é possível destacar o S.O “Cinder” [11], projetado exclusivamente para ser

executado em dispositivos com limitações de recursos, como smartphones.

2.3.1 – Cinder

Roy et al. [11] realizaram um trabalho detalhado acerca do sistema operacional

Cinder. Segundo os autores, esse S.O oferece abstrações acerca do gerenciamento de

energia que o auxilia a restringir o consumo de energia e gerir os recursos disponíveis

no aparelho em função da demanda. Para tal, o Cinder utiliza duas abstrações: reservas e

taps. Devido ao fato de o Cinder ser um sistema operacional recente, ele ainda não está

disponível em muitas plataformas. Até o momento apenas os dispositivos HTC Dream

(Google G1) estão executando o Cinder.

Reservas

As “reservas” são a maneira pela qual o Cinder consegue gerenciar o consumo

dos recursos do aparelho. O kernel acaba se tornando, então, o responsável por impedir

que uma determinada aplicação tente utilizar mais recursos do que aqueles que foram

alocados previamente a ela.

Taps

No Cinder o conceito de “taps” está associado com uma thread específica que

existe exclusivamente para viabilizar a transferência de energia por entre as reservas do

aparelho e estabelecer um limite de consumo dos recursos alocados. Através desse

conceito, torna-se possível a redistribuição e reaproveitamento de recursos.

2.3.2 – Gerenciamento de consumo no nível de aplicação

Nas próximas seções serão apresentadas algumas das técnicas que podem ser

utilizadas para permitir um gerenciamento de energia por parte das aplicações, baseado

em sua natureza.

2.3.2.1 – Atraso e PreFetching

9

Balasubramanian et al. [21] segmentam os aplicativos de smartphones em duas

categorias: (1) aplicativos tolerantes a atrasos e (2) aplicativos que podem se beneficiar

de prefetching.

Aplicativos que não são sensíveis ao atraso, como clientes de e-mail, podem se

beneficiar da estratégia do atraso e ajudar a aumentar o tempo de vida da bateria. Essa

abordagem considera o gasto de energia consumido pela interface de rede quando

transita entre os estados “idle” para “em uso” e vice-versa, de modo que ela tenta

minimizar a quantidade de vezes que as transições devem ocorrer.

Normalmente, ao criar um e-mail, ele será enviado imediatamente. Para se

iniciar o processo de envio do e-mail, a interface de rede deve transitar do estado “idle”

para o estado “em uso”. Após o envio a interface de rede deixará o estado “em uso” e

transitará para o estado “idle”. O mesmo processo irá ocorrer para o envio de e-mails

subsequentes.

Através da estratégia do atraso torna-se possível a criação de uma fila de e-mails

a serem enviados. Assim, quando chegar o momento de utilizar a interface de rede,

todos os e-mails que estiverem na fila serão enviados sequencialmente. Essa estratégia

limitará, portanto, a quantidade de vezes que o Wifi deverá transitar entre estados. Essa

abordagem, porém, acaba não sendo eficaz para determinadas categorias de software,

por serem considerados sensíveis ao atraso, causando um impacto significativo na

experiência do usuário. A Tabela 2.2 apresenta uma relação entre algumas categorias de

software e as respectivas sensibilidades ao atraso.

Tabela 2.3: Relação entre categorias de software e sensibilidade ao atraso de rede

[13]

TIPO DE APLICAÇÃO SENSIBILIDADE AO ATRASO

Transferência de arquivos Baixa

Tráfego da Web Moderada

Baseada em transação Moderada

Voz Alta

Vídeo em tempo real Alta

10

A estratégia do prefetching tenta reduzir o consumo de energia e a latência ao

realizar o download de determinados dados antes mesmo de o usuário manifestar o

interesse em baixá-los. No contexto de uma página web, por exemplo, através do

prefetching torna-se possível efetuar o download prévio de objetos de dados contidos na

página e armazená-los localmente para uso posterior [14]. Desse modo, quando o

usuário tentar acessar esses objetos, as informações poderão ser obtidas diretamente do

cache local, reduzindo o tempo de navegação e aprimorando a experiência do usuário.

Quando o prefeching efetuar o download de dados que o usuário não venha a

utilizar, acaba-se por gerar um desperdício tanto de largura de banda quanto de energia.

Para ajudar a reduzir os desperdícios que possam ocorrer utilizando a abordagem

do prefeching, algumas estratégias podem ser adotadas. Balasubramanian et al. [21]

apontam que para se obter um prefeching efetivo torna-se necessário prever o

comportamento do usuário. Os autores utilizam dados estatísticos de navegação do

usuário para atingir maior taxa de acertividade ao realizar o prefeching.

2.3.2.2 – Mapeamento energético

Carção et al. [15] apresentam em seu trabalho um modelo para mapeamento do

consumo energético dos componentes de smartphones em seus diferentes estados de

consumo. O modelo utiliza como base o uso de aplicativos de treinamento que avaliam

o consumo de energia de cada componente, individualmente, em cada um de seus

estados de consumo. A Tabela 2.3 apresenta a relação dos componentes avaliados e seus

respectivos estados de consumo. Os dados obtidos após o treinamento podem ser

utilizados posteriormente para avaliar a taxa de consumo de qualquer aplicativo em uso

no aparelho.

Tabela 2.3: Relação entre componentes seus respectivos coeficientes considerados

[15]

11

COMPONENTE COEFICIENTE CONSIDERADO

CPU Variavel em função da frequência de uso (variando de 1% até100%)

LCD Nível do brilho (variando em até 10 níveis)

GPS Três estados

Ativo Em descanso Desligado

WIFI Quatro estados

Baixo consumo Alto consumo Baixa taxa detransmissão

Alta taxa detransmissão

3G Três estados

DCH FACH Inativo

Áudio Coeficiente considera apenas se o componente está em uso

O principal benefício desse modelo é que ele permite a criação de um

mapeamento de consumo energético genérico, viável para qualquer smartphone

executando o S.O Android.

12

Capítulo 3

Estratégia proposta de consumo de

energia orientado pelo código-fonteNeste capítulo serão apresentadas as estratégias utilizadas no código-fonte de

aplicações para redução da taxa de uso dos sensores de Wifi e GPS. Todas as

abordagens foram implementadas na linguagem de programação Java e utilizam

conceitos de orientação a objetos. Portanto, antes de apresentar a solução faz-se

necessária uma breve explicação dos conceitos utilizados.

3.1 – Orientação a Objetos

Rumbaugh et al [17] define o paradigma de orientação a objetos como uma

forma de pensar não estando, portanto, restrito a linguagens de programação. Esse

paradigma permite melhor organização e reuso de código. Através do conceito de

“herança”, duas ou mais entidades podem ter suas características comuns extraídas e

implementadas em uma classe genérica, chamada de classe pai ou superclasse.

A linguagem de programação Java permite a criação de uma classe abstrata, que

será base para a implementação da solução do “atraso” no uso do Wifi. Conceitualmente

classes abstratas são muito parecidas com interfaces mas há algumas características

chave que as diferenciam. A Tabela 3.1 apresenta essas diferenças.

13

Tabela 3.1: Relação classes abstratas vs interfaces

AÇÃO CLASSE ABSTRATA INTERFACE

Pode ser instanciada ? Não Não

Visibilidade de atributos Mesmas regras atribuídas aclasses não-abstratas

São considerados:Públicos, estáticos,

constantes

Visibilidade de métodos Mesmas regras atribuídas aclasses não-abstratas

São considerados Públicos

Permite múltiplasheranças /

implementações ?

Não Sim

Há um conjunto de premissas que podem ser utilizadas para se definir se é

preciso utilizar uma classe abstrata ou uma interface para modelar um determinado

problema [20]. Uma dessas premissas dita que deve-se utilizar uma classe abstrata

quando houver uma ou mais classes que possuirão atributos e/ou métodos em comum.

Outra premissa determina que deve-se utilizar classes abstratas ao invés de uma

interface quando for preciso declarar atributos que não sejam estáticos ou finais.

3.2 – Controle de uso do GPS

A SDK oficial do Android oferece uma classe responsável por inicializar o

sensor de GPS, chamada “LocationManager”. Após se obter um objeto dessa classe,

tonar-se possível iniciar as chamadas ao GPS através do método

“requestLocationUpdates”. Através desse método é possível especificar os parâmetros

de distância e tempo que irão impactar diretamente em sua frequência de uso e,

consequentemente, em seu consumo de energia.

Uma forma de implementação de uma classe capaz de obter atualizações do

sensor de GPS enquando implementa mecanismos para preservar o consumo de bateria

encontra-se no “ANEXO A”. Os métodos mais relevantes para o contexto desse trabalho

são: stopLowerConsumption, switchToLowerConsumption e isLowerConsumption.

Como seus nomes sugerem, suas responsabilidades estão ligadas diretamente com a taxa

de uso GPS. Suas implementações fazem uso de cinco variáveis criadas exclusivamente

14

para gerenciar o consumo de energia: TIME_FREQ, LC_TIME_FREQ, DIST_FREQ,

LC_DIST_FREQ, lowerConsumption.

As variáveis inteiras, TIME_FREQ, DIST_FREQ, indicam as regras de tempo e

distância mínimas entre as atualizações, respectivamente. Suas variantes,

LC_TIME_FREQ e LC_DIST_FREQ, possuem as mesmas responsabilidades porém

elas representam o modo de operação de baixo consumo de energia. Seus valores devem

ser alterados para refletir o contexto de cada aplicação. Para a definição dos valores

ideais para o filtro de tempo, foram realizados experimentos considerando o consumo de

energia em função do intervalo entre atualizações e do tempo decorrido. Durante o

experimento foram realizadas quatro medições a cada dois minutos em que a aplicação

esteve em execução, para as taxas de atualização de um a oito segundos. A Tabela 3.2 e a

Figura 3.1 apresentam o resultado dos experimentos realizados. Naturalmente o consumo

de energia foi inversamente proporcional ao valor atribuido a taxa de atualização do

sensor.

Tabela 3.2: Relação de consumo para o parâmetro de tempo para o GPS

ATUALIZAÇÃO (s) TEMPO (min) CONSUMO (j)

1

2 2.2

4 4.5

6 6.9

8 9.3

2

2 1.5

4 3.3

6 5.6

8 7.8

3

2 0.829

4 1.8

6 2.6

8 3.3

4

2 0.571

4 1.5

6 2.3

8 3.3

2 0.841

4 1.6

15

5 6 2.3

8 3.1

6

2 0.824

4 1.7

6 2.4

8 3.3

7

2 0.759

4 1.4

6 2.1

8 2.8

8

2 0.738

4 1.5

6 2.4

8 3.2

Figura 3.1 Relação do consumo de energia do sensor GPS

em relação a sua taxa de atualização

Atribuir um valor baixo para as atualizações implicaria em atualizações mais

frequentes ao custo de maior consumo de energia, Por outro lado, especificar valores

muito altos reduziria a demanda por energia pelo sensor ao custo de causar um impacto

16

significativo à experiência do usuário. Portanto, uma vez que a experiência do usuário é

um fator importante, a mesma também foi levada em consideração. Para medir esse fator

foi analisado o impacto da variação das taxas de atualização do GPS de um usuário pela

perspectiva de sua rede de contatos. A Tabela 3.3 apresenta a relação entre as taxas de

atualização do GPS juntamente com a percepção do impacto causado na rede aos seus

contatos utilizando a aplicação.

Tabela 3.3 Relação entre taxa de atualização do GPS

vs

percepção do impacto na UX

TAXA DE ATUALIZAÇÃO (s) PERCEPÇÃO DO IMPACTO NA UX

1, 2, 3 Baixo – Percepção de movimento do usuário comfluidez.

4. 5, 6

Moderado– Houve atrasos para se obter alocalização corrente do usuário, porém a diferença

entre sua última localização conhecida e sualocalização corrente não era alta.

7, 8

Alto – Os atrasos começaram a ficar significativose os usuários perceberam que a aplicação estavalevando muito tempo para atualizar a localização

de seus contatos no mapa.

Considerando a relação apresentada pela Tabela 3.3, o valor ideial para a taxa de

atualização estaria, portanto, entre os valores 4, 5 e 6 segundos. Uma vez que a diferença

do consumo de energia para estes valores não possuiu muita variação, como apresentado

na Tabela 3.2, foi definido que a a taxa de atualização ideal para o GPS seria de 4

segundos.

Uma vez que no Android o filtro de tempo possui precedência em relação ao

filtro de distância, e portanto a atualização nunca ocorrerá antes do tempo especificado

independentemente da distância percorrida, apenas o filtro de tempo foi levado em

consideração durante a realização dos experimentos. [23]

No contexto do código, o método start, como o nome sugere, é responsável por

iniciar o sensor de GPS utilizando os devidos filtros de tempo e distância baseado no

modo de operação da classe. Os métodos da interface LocationListener não foram

implementados por questões de simplicidade. As Figuras 3.1, 3.2 apresentam a criação

17

da classe DeviceLocation em notação UML e o diagrama de fluxo para o método start,

respectivamente. Uma maneira de implementar essa classe pode ser encontrado no

ANEXO A.

Figura 3.1 Definição da classe DeviceLocation em notação UML

Figura 3.2 Diagrama de fluxo para o método start

Como mencionado no método “getProvider”, o Android oferece três tipos de

provedores distintos. O provedor “GPS” oferece a melhor precisão, porém sua aquisição

de localização é mais lenta e seu consumo de energia é maior [23]. O provedor “rede”

infere a localização do aparelho baseada na área de cobertura das torres de telefonia as

quais o aparelho está se comunicando e pontos de acesso Wifi que estiverem ao alcance.

Seu consumo de energia é inferior comparado ao “GPS” porém a localização obtida é

18

mais imprecisa. O provedor “passivo” é o mais econômico, uma vez que ele não obtém

a localização de maneira direta. Ao invés disso ele aguarda que a localização seja obtida

por uma fonte externamente (ex: por outro aplicativo no mesmo aparelho) e reaproveita

essa informação para que seja utilizada no aplicativo em questão. A precisão da

localização obtida irá variar, portanto, de acordo com o provedor utilizado pela fonte

que proveu a informação.

3.3 – Controle de uso do Wifi

De modo a reduzir os ciclos de transição de estados do Wifi, e

consequentemente sua demanda por energia a longo prazo, decidiu-se utilizar a

estratégia do “atraso”. Para se definir o valor ideal no algoritmo foram realizadas uma

bateria de experimentos considerando o tempo de execução da aplicação bem como o

valor da variável threshold, responsável pelo atraso. Os resultados dos experimentos

podem ser vistos na Tabela 3.3 e Figura 3.3. É possível notar que quanto maior o valor

de threshold, maior será a economia de energia por parte do sensor. Porém valores altos

implicam em um atraso significativo no uso do Wifi, impactando na experiência do

usuário. Portanto foi extipulado o valor de 6 segundos para o atraso, que representa um

meio termo entre economia de energia vs experiência do usuário.

Tabela 3.3: Consumo de energia em função do tempo ao alterar o valor de threshold

THRESHOLD (seg) TEMPO (min) CONSUMO (J)

2

5 4,2

10 8,6

1512,9

2017,2

25 21,7

3026,3

3531

40 35,8

4540,5

19

5045,1

5549,5

6054

4

5 3,7

10 7,7

15 11,6

20 15,1

25 19,1

30 22,9

35 26,7

40 30

45 33

50 36,7

55 40,3

60 43,9

6

5 3,3

10 6,5

15 10,4

20 14,1

25 17,7

30 21,6

35 25,4

20

40 29,7

45 33,1

50 37

55 40,4

60 43,5

8

5 3,5

10 7,1

15 10,7

20 14,2

25 17,8

30 21,4

35 25,3

40 28,9

45 32,4

50 35,9

55 39,6

60 42,7

10

5 2,6

10 5,1

15 6,8

20 8,8

25 11,0

30 13,2

35 15,3

21

40 17,5

45 19,9

50 22

55 24,2

60 26,7

Figura 3.3 Relação do consumo de energia em função do tempo e do atraso

Foi construída uma classe abstrata responsável por realizar as requisições de

rede. Essa classe atua como um intermediário para realizar o controle de acesso ao

sensor e restringir seu uso. Sua implementação, bem como sua representação em um

diagrama de sequência, encontram-se no “ANEXO B” e na Figura 3.4, respectivamente.

É possível notar que sua implementação está fazendo uso da estratégia do “atraso” para

minimizar a quantidade de vezes que o sensor precisará ser ligado/desligado entre as

transmissões. Foi estipulado um intervalo de 6 segundos de limite (threshold). Isso

significa que ao realizar uma transferência utilizando o Wifi, essa requisição irá

aguardar 6 segundos antes de utilizar o sensor, e toda requisição realizada nesse

intervalo será agendada para ser executada paralelamente à primeira requisição.

22

Figura 3.4 Diagrama de sequência para a classe NetworkScheduler

Ao final da implementação do método “schedule” é possível notar a criação de

uma thread. Por padrão, para evitar que serviços rede causem danos a experiência do

usuário, o S.O Android não permite que os mesmos possam ser executados na thread

principal. Essa regra é válida para os aplicativos que estejam utilizando a versão da

SDK Honeycomb ou superior. [15]

23

Caso o desenvolvedor tente executar os serviços de rede na thread principal, será

lançada a exceção “NetworkOnMainThreadException”. Para evitar esse problema, a

chamada no método “run”, implementado pelas subclasses, é realizada dentro de uma

nova thread. Para garantir a consistência de que os serviços irão executar dentro de sua

respectiva faixa de tempo, foi utilizada a função “sleep”. Essa função pausa o fluxo de

execução na thread em que foi chamada em função do valor do parâmetro especificado

(em milisegundos).

O código apresentado no “ANEXO C” representa um exemplo de como uma

subclasse dessa classe pode ser implementada para se beneficiar da estratégia do atraso.

O método mais importante das subclasses de “NetworkScheduler” é o método “run”,

pois é nele onde as requisições de rede serão realizadas. Em sua implementação é

possível notar que será realizado o download de uma página web utilizando o protocolo

de transferência de hipertexto (HTTP). A Figura 3.5 apresenta um diagrama UML dessa

subclasse.

Figura 3.5: Diagrama UML de uma subclasse de NetworkScheduler

Normalmente, após a conclusão da execução de um serviço de rede, é preciso

enviar os dados baixados para outro segmento da aplicação. Uma maneira de

implementar essa “ponte” de comunicação entre diferentes partes da aplicação, que

podem estar executando em diferentes threads, é utilizando a classe Handler [16]. A

figura 3.6 apresenta o diagrama de sequência que representa essa comunicação e os

ANEXOS D e E representam duas classes construídas para esse propósito.

24

Figura 3.6: Diagrama de sequência que representa a troca de mensagens

entre duas classes

3.4 Confrontação entre os cenários de consumo de energia

Para permitir a mensuração do ganho na redução do consumo de energia por

parte da aplicação, foram elaborados dois cenários: (1) o cenário no qual o aplicativo

não utiliza as técnicas de minimização de consumo de energia e (2) o segundo cenário,

no qual a aplicação é utilizada juntamente com as técnicas mencionadas nesse trabalho.

Para obter os valores de consumo de energia foi utilizado o aplicativo “PowerTutor”

[24]. Essa aplicação permite a mensuração do consumo de energia de todas as apps

instaladas no aparelho em função do tempo decorrido.

Em cada um dos cenários foram realizadas 10 medições iniciadas com a bateria

completamente carregada e concluindo quando a bateria descarregou por completo. A

25

relação dos resultados obtidos podem ser vistos na Tabela 3.4 e nas Figuras 3.7, 3.8 e

3.9.

Tabela 3.4: Comparativo da economia no consumo de bateria

CENÁRIO 1 – Uso normal da bateria CENÁRIO 2 – Uso com economia debateria

# da iteração Consumo (J) # da iteração Consumo (J)

1 4743 1 704

2 4829 2 811

3 5124 3 1075

4 5733 4 907

5 6062 5 841

6 4354 6 685

7 4790 7 1014

8 5378 8 1022

9 4619 9 639

10 5080 10 611

Figura 3.7 Relação do consumo total de bateria no cenário 1 (modo normal)

26

em cada uma das 10 medições

Figura 3.8 Relação do consumo total de energia no cenário 2 (modo econômico)

em cada uma das 10 medições

Figura 3.9 Comparativo do consumo de energia

entre os cenários 1 (modo normal) e 2 (modo econômico)

27

A Tabela 3.5 apresenta a relação das médias e do desvio padrão calculados para

os cenários 1 (modo normal) e 2 (modo econômico).

CENÁRIO 1 – modo normal (J) CENÁRIO 2 – modo econômico (J)

Média 5071,21 Média 830,90

Desvio padrão 525,03 Desvio padrão 169,47

A comparação direta entre os valores médios de consumo entre os cenários 1

(modo normal) e 2 (modo econômico) apontam uma vantagem significativa para o

modo econômico. O consumo em modo econômico corresponde à 16,38% do consumo

em modo normal, o que reflete em um aumento de tempo de autonomia do dispositivo

móvel. Além disto, a maior disponibilidade de energia também pode ser aproveitada

para alimentar o aumento da frequencia de clock dos processadores dos dispositivos

móveis. Desta forma, o consumo controlado de energia por parte das aplicações pode

suportar um aumento da autosuficiência de energia dos dispositivos móveis e um

incremento na velocidade de processamento.

O desvio padrão do consumo de energia no modo normal também é maior que

aquele em modo econômico. Contudo, ao se analisar estes dados em valores relativos às

suas respectivas médias, tem-se que o desvio padrão do modo normal corresponde à

10,35% de sua média, enquanto o desvio padrão do modo econômico corresponde à

20,39% de sua média. Torna-se importante mencionar que a há uma variação nos

valores calculados uma vez que outros aplicativos e serviços padrão do Android

estavam em execução no aparelho durante as medições. A quantidade de energia

consumida por estes aplicativos nativo independe do modo de gerência de consumo

empregado pela aplicação aqui proposta, e deste modo, contribuem para a diferença

entre os desvios padrões.

28

Capítulo 4

4.1 Conclusões

Neste trabalho foram apresentadas, em detalhes, a implementação de estratégias

para redução do consumo de energia para aplicativo baseado em geolocalização para

Android. Essas estratégias visam reduzir a demanda por energia dos sensores de Wifi e

GPS considerando o impacto com a experiência do usuário como um fator importante.

29

Através de experimentos realizados foi provado que a estratégia do atraso

permitiu a redução do consumo de energia e o controle do uso de uso do sensor

permitindo, também, a escolha do valor mais apropriado para o tempo de atraso entre as

requisições. Um segundo experimento foi realizado de modo a traçar o consumo de

energia por parte do GPS e definir o valor ideal para sua taxa de atualização em função

do tempo de uso da aplicação pelo seu consumo.

Foram definidos dois cenários de uso da aplicação para avaliar a eficiência das

estratégias propostas neste trabalho e permitir a realização de um comparativo dos

resultados. Através dos dados obtidos foi possível notar um ganho significativo na

redução do consumo de energia por parte da aplicação após a adoção das estratégias do

atraso para uso do sensor de Wifi e da definição de intervalos para uso do GPS.

4.2 Trabalhos Futuros

A taxa de atualização do sensor de GPS foi definida considerando uma relação

de consumo de energia pelo sensor em relação ao impacto na experiência do usuário. Os

valores de percepção da experiência do usuário são subjetivos e, portanto, imprecisos.

Uma proposta para trabalho futuro poderia visar o aumento da confiança dos dados

adquiridos acerca da percepção do usuário e quantificá-los utilizando metodologias

formais, como a lógica nebulosa, resultando em maior precisão na classificação dos

valores da taxa de atualização de acordo com as três categorias de percepção do usuário

listadas na Tabela 3.3 (baixo, moderado, alto).

No contexto do desenvolvedor de aplicações para dispositivos móveis há uma

grande variedade de certificações que validam seus conhecimentos acerca de diversos

parâmetros, tais como o sistema operacional e suas particularidades, a construção de

interfaces intuitivas e a segurança do armazenamento e manipulação dos dados do

usuário. No entanto, as certificações não avaliam o consumo de bateria por parte das

aplicações como um fator relevante e, portanto, o mesmo tende a ser deixado de lado.

Os resultados obtidos por esse trabalho demonstram que a preocupação em relação ao

consumo de energia de aplicativos durante o processo de desenvolvimento irá auxiliar

na preservação do tempo de vida útil da bateria a longo prazo.

30

Referências Bibliográficas[1] Exame, 68 milhões navegam na internet utilizando smartphones no Brasil,

Junho de 2015, Acesso em: 05 de junho de 2016, Disponível em

<http://exame.abril.com.br/tecnologia/noticias/68-milhoes-navegam-na-internet-com-

smartphone-no-brasil>

[2] Comissão Européia, Opinion 13/2011 on Geolocation services on smart mobile

devices, Acesso em: 07 de junho de 2016, Disponível em

<http://ec.europa.eu/justice/policies/privacy/docs/wpdocs/2011/wp185_en.pdf>

[3] CARROL, A., HEISER, G., An analysis of Power Consuption on Smartphones.

USENIXATC'10 Proceedings of the 2010 USENIX conference on USENIX annual

technical conference, p. 21-21, junho/2010.

[4] LI, Ding., HALFOND, Wiliam, An investigation into Energy-Saving

programming practices for Android Smartphone App Development, NGREENS

2014 Proceedings of the 3rd International Workshop on Green and Sustainable

Software, p. 46-53, junho/2014.

[5] Android Studio: The Oficial IDE for Android, Acesso em: 10 de junho de 2016,

Disponível em <https://developer.android.com/studio/index.html>

[6] Tasty mocking framework for unit tests in Android, Acesso em: 14 de junho de

2016, Disponível em <http://mockito.org/>

[7] Robolectric: Test drive your android code, Acesso em: 15 de junho de 2016,

Disponível em <http://robolectric.org/>

[8] JUnit, Acesso em: 15 de junho de 2016, Disponível em <http://junit.org/junit4/>

[9] RODRIGUES, N., CROWCROFT, J.,.Energy Management Techniques for

Mobile Handsets, IEEE Communications Surveys & Tutorials, v.15, n.1, 179-198,

fevereiro/2012.

[10] NAIK, B., CHAVAN, R., Optimization in Power Usage of Smartphones,

International Journal of Computer Applications, v. 119, n. 18, p. 7-13, junho/2015.

[11] ROY, A., RUMBLE, S., STUTSMAN, R., LEVIS, P., MAZIERES, D., Energy

Management in Mobile Devices with the Cinder Operating System, EuroSys '11

Proceedings of the sixth conference on Computer systems, 139-152, abril/2011.

31

[12] FLINN, J., SATYANARAYANA, M., Energy-Aware Adaptation for Mobile

Applications, SOSP '99 Proceedings of the seventeenth ACM symposium on Operating

systems principles, 48-63, dezembro/1999.

[13] PODLESNY, M., Networking Mechanisms for Delay-Sensitive Applications,

janeiro/2009, 136 f., PhD, University of Washington, St. Louis, 2009.

[14] KULKARNI, P., JAINI, P., Energy Consumption on Android Phone Web

Browsing in 3G Network, International Journal on Recent and Innovation Trends in

Computing and Communication, 2014.

[15] CARÇÃO, T., COUTO, M., CUNHA, J., FERNANDES, J., SARAIVA, J.,

Detecting Anomalous Energy Consumption in Android Application, Springer

International Publishing, vol. 8771, p. 77-91, outubro/2014.

[16] XIA, F., ZHANG, WEI., DING, F., HAO, F., A-GPS Assisted Wifi Access Point

Discovery on Mobile Devices for Energy Saving, Proceedings of the 4th ACM

international workshop on Experimental evaluation and characterization, p. 67-76,

setembro/2009.

[17] RUMBAUGH, James et al., Modelagem e projetos baseados em objetos. Rio de

Janeiro: Campus, 1994

[18] NetworkOnMainThreadException, Acesso em 20 de junho de 2016, Disponível

em

<https://developer.android.com/reference/android/os/NetworkOnMainThreadException.

html>

[19] Handler, Acesso em: 20 de junho de 2016, Disponível em

<https://developer.android.com/reference/android/os/Handler.html>

[20] Abstract Method and Classes, Acesso em: 21 de junho de 2016, Disponível em

<https://docs.oracle.com/javase/tutorial/java/IandI/abstract.html>

[21] BALASUBRAMANIAN, N., BALASUBRAMANIAN, A., VENKATARAMANI,

A., Energy Consumption in Mobile Phones: A Measurement Study and

Implications for Network Applications, Proceedings of the 9th ACM SIGCOMM

conference on Internet measurement conference, Nova Iorque, p. 280-293, 2009.

[22] RAMOS., H et al, Energy Efficient GPS Sensing with Cloud Offloading, ACM

Conference on Embedded Networked Sensor Systems, p. 85-98, setembro/2012.

[23] LocationManager, Acesso em: 20 de junho de 2016, Disponível em

<https://developer.android.com/reference/android/location/LocationManager.html>

32

[24] PowerTutor, Acesso em: 22 de junho de 2016, Disponível em:

<https://play.google.com/store/apps/details?id=edu.umich.PowerTutor>

33

Anexo A – DeviceLocationpublic class DeviceLocation implements LocationListener { private final int TIME_FREQ = 1 * 1000; // 1 segundo private final int DIST_FREQ = 3; // 3 metros private final int LC_TIME_FREQ = 5 * 1000; // 5 segundos private final int LC_DIST_FREQ = 6; // 6 metros private boolean lowerConsuption = false; private LocationManager locationManager;

public DeviceLocation(Context context) { this.context = context; }

@Override public void onLocationChanged(Location location) { /* Callback chamado a cada atualização da localização */ }

@Override public void onStatusChanged(String provider, int status, Bundle extras) { /* Atualização do status do provedor de serviço */ }

protected LocationManager getLocationManager(Context context) { /* Deve retornar um objeto da classe LocationManager */ }

protected LocationProvider getProvider(LocationManager locationManager) { /*

Esse método deve retornar um dos possíveis provedores de localização.

Normalmente, o momento da escolha de um provedor representa um trade-off entre

precisão e consumo de energia. O Android especifica três categorias para provedores de

localização: GPS, rede, passivo.

*/ }

public void stopLowerConsumption() { lowerConsuption = false; restart(); }

public void switchToLowerConsumption() { lowerConsuption = true; restart(); }

public boolean isLowerConsumption() { return lowerConsuption; }

public void start() { /* Taxa de consumo de energia será verificada nesse método.

34

* Caso a instância dessa classe esteja programada para * operar em baixo consumo de energia, então serão * utilizadas as variáveis LC_TIME_FREQ, LC_DIST_FREQ. */ LocationManager locationManager; locationManager = getLocationManager(context); if(isLowerConsuption()) locationManager.requestLocationUpdates( provider.getName(), LC_TIME_FREQ, LC_DIST_FREQ, this);

else locationManager.requestLocationUpdates( provider.getName(), TIME_FREQ, DIST_FREQ, this); }

public void stop() { locationManager.removeUpdates(this); }

public void restart() { /* Método utilizado para reiniciar o serviço. Útil quando o * objeto precisa alterar seu modo de operação de consumo. */ stop(); start(); }}

35

Anexo B – NetworkScheduler

public abstract class NetworkScheduler implements Runnable { private static int THRESHOLD = 6000; private long t0 = 0;

public void schedule(final Runnable r) { final long scheduleAt; long currentTime = System.currentTimeMillis();

if(t0 == 0) { t0 = currentTime; scheduleAt = THRESHOLD; } else if(currentTime - t0 < THRESHOLD) { scheduleAt = THRESHOLD - (currentTime - t0); } else { t0 = currentTime; scheduleAt = THRESHOLD; }

Thread thread = new Thread() { @Override public void run() { try { sleep(scheduleAt); r.run(); } catch(InterruptedException iE) { } } }; thread.start(); }}

36

Anexo C – DownloadPage

import org.apache.http.HttpResponse;import org.apache.http.client.HttpClient;import org.apache.http.client.methods.HttpGet;import org.apache.http.client.methods.HttpPost;import org.apache.http.impl.client.DefaultHttpClient;

public class DownloadPage extends NetworkScheduler { private String pageUrl;

public DownloadPage(String pageUrl) { this.pageUrl = pageUrl; }

public void schedule() { super.schedule(this); }

/* * Esse método será chamado pela superclasse quando chegar o momento de * de ativar a Wifi */ public void run() { HttpClient client = new DefaultHttpClient(); HttpResponse response = client.execute(new HttpGet(this.pageUrl)); /* Download da página concluído... */ }}

37

Anexo D – HandlerReceiver

import android.os.Bundle;import android.os.Handler;import android.os.Message;import android.util.Log;

public class HandlerReceiver implements Handler.Callback { private int a; private int b; public HandlerReceiver(int a, int b) { this.a = a; this.b = b; }

@Override public boolean handleMessage(Message message) { /* * Cálculo foi realizado pela classe HandlerSender e enviado * para HandlerReceiver através do método sendMessage */ Bundle bundle = message.getData(); int result = bundle.getInt( "result" ); Log.d("HandlerReceiver", String.format("%d + %d = %d", a, b, result)); }}

38

Anexo E – HandlerSender

import android.os.Bundle;import android.os.Handler;import android.os.Message;

public class HandlerSender { private int a; private int b; private Handler receiver;

public HandlerSender(int a, int b, Handler receiver) { this.a = a; this.b = b; this.receiver = receiver; }

public void run() { /* Irá somar dois números inteiros e enviar o resultado * para o Handler destinatário */ Message message = new Message(); Bundle bundle = new Bundle();

bundle.putInt("result", a+b); message.setData( bundle ); receiver.sendMessage( message ); }}

39