Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
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