Universidad Nacional del Centro de la Provincia De Buenos Aires

Facultad de Ciencias Exactas - Departamento de Computación y Sistemas

Ingeniería de Sistemas

Alternativas para el desarrollo deaplicaciones móviles energéticamentee�cientes con conexión a datos y

servicios de ubicación

por

Facundo Agustín Martin

Director: Dr. Alejandro Zunino

Co-Director: Ing. Ana Victoria Rodríguez

Trabajo �nal de carrera presentado como requisito parcial

para optar por el título de

Ingeniero de Sistemas

Resumen

Es un hecho que las capacidades de los dispositivos móviles actuales ta-

les como smartphones y tablets se han incrementado signi�cativamente en

la última década. Los smartphones modernos han logrado suplantar a varios

dispositivos, tales como reproductores MP3, cámaras digitales o incluso, en

algunos casos, a computadoras portátiles. El número de smartphones crece

año a año a nivel global gracias a las prestaciones que ofrecen. Además de ser

los principales encargados de la comunicación vía red telefónica, hoy en día

las capacidades de los smartphones permiten desde transmitir video conferen-

cias en tiempo real, hasta compartir información mediante almacenamiento

Cloud. Estas posibilidades son producto de varios factores: las investigacio-

nes en redes inalambricas, que permitieron el intercambio de información a

mejores velocidades; de la misma forma, también se considera el hardware

más potente y los nuevos sistemas operativos con características similares a

los de una computadora de escritorio, lo que permite a los usuarios instalar

aplicaciones en los smartphones con el �n de aumentar sus funcionalidades.

Los smartphones cuentan con la opción de personalizar cada dispositivo,

lo que los convierte en uno de los objetos que mejor satisfacen las necesi-

dades de los usuarios. Es decir, los Smartphones permiten la instalación de

aplicaciones para diversos ámbitos y objetivos, como por ejemplo ámbitos la-

borales, de estudio, de uso cotidiano, etc. Estas ayudan a los usuarios en sus

tareas en todo momento creando una dependencia por parte de estos hacia

el dispositivo. Sin embargo, si bien estos cambios mencionados constituyen

interesantes novedades, por otro lado han producido un impacto negativo en

los dispositivos, ya que estos cuentan con recursos limitados y el consumo

de batería es un factor importante a considerar. La duración de esta es el

elemento fundamental para alargar el tiempo de funcionamiento del disposi-

tivo y le permite mejorar su autonomía. El aumento de las capacidades de

los smartphones da la posibilidad de tener mayor cantidad de aplicaciones

ejecutándose al mismo tiempo. En consecuencia, el uso correcto de la energía

del dispositivo pasa a ser un aspecto de suma importancia. El principal ob-

jetivo del presente trabajo es cuanti�car algunos aspectos importantes en el

desarrollo de aplicaciones móviles que afectan el consumo de batería. De esta

forma, se analizan aplicaciones que realizan consumo de datos vía redes wi-�

y aplicaciones de geolocalización con el �n de analizar su consumo de energía.

Para esto, se analizan las diferentes propuestas de desarrollo que existen para

cada uno de los tipos de aplicaciones mencionadas en smartphones bajo el

sistema operativo Android.

Los principales resultados de este trabajo son consejos y recomendaciones

a tener en cuenta para el desarrollo de aplicaciones que consumen datos o

se basan en servicios de geolocalización, enfocado en cómo lograr un uso

energético e�ciente.

3

Agradecimientos

Este trabajo es el resultado de los conocimientos adquiridos a lo largo de

los años en la carrera. Paciencia y dedicación constante fueron las caracterís-

ticas mas importantes necesarias, apoyadas por un grupo de seres queridos a

lo largo de años. El agradecimiento es para todas las personas que ayudaron

de manera directa o indirectamente a la �nalización de un ciclo como perso-

na. Familiares, amigos y profesores, que aportaron el conocimiento necesario

e indispensable que me acompañará el resto de mi vida profesional. Muchas

gracias.

Índice general

1. Introducción 1

1.1. Problemática . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2. Descripción del Trabajo . . . . . . . . . . . . . . . . . . . . . 11

1.3. Organización . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2. Entorno de Trabajo 15

2.1. Smartphones . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2. Android en Smartphones . . . . . . . . . . . . . . . . . . . . . 18

2.2.1. Consumo de batería . . . . . . . . . . . . . . . . . . . 26

2.3. Trabajos Relacionados . . . . . . . . . . . . . . . . . . . . . . 29

2.3.1. Who Killed My Battery . . . . . . . . . . . . . . . . . 30

2.3.2. Evaluating Android best practices for performance . . 30

2.3.3. Refactorizaciones para kernels computacionales cientí-

�cos en dispositivos móviles . . . . . . . . . . . . . . . 31

2.3.4. Measuring mobile phone energy consumption for 802.11

wireless networking . . . . . . . . . . . . . . . . . . . . 32

2.3.5. An Automatic Detector of Energy Leaks for Smartp-

hone Applications (ADEL) . . . . . . . . . . . . . . . . 33

2.3.6. Analysis of Di�erential Synchronisation's Energy Con-

sumption on Mobile Devices . . . . . . . . . . . . . . . 34

2.3.7. Reducing Battery Consumption of Data Polling and

Pushing Techniques on Android using Gripe . . . . . . 35

2.3.8. An Investigation into Energy-Saving Programming Prac-

tices for Android Smartphone App Development . . . . 36

2.3.9. eDoctor: Automatically Diagnosing Abnormal Battery

Drain Issues on Smartphones . . . . . . . . . . . . . . 37

2.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3. Análisis y diseño de aplicaciones 40

3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.1.1. Polling . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.1.2. Push . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.1.3. GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.1.4. Localización por red telefónica . . . . . . . . . . . . . . 46

3.2. Implementación de Tácticas . . . . . . . . . . . . . . . . . . . 47

3.2.1. Servicios Web . . . . . . . . . . . . . . . . . . . . . . 47

3.2.2. Polling . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.2.3. Mensajes Push . . . . . . . . . . . . . . . . . . . . . . 51

3.2.4. Localización GPS . . . . . . . . . . . . . . . . . . . . 56

3.2.5. Localización por Triangulación de Antena . . . . . . . 59

3.3. Metodología de medición . . . . . . . . . . . . . . . . . . . . 60

3.3.1. Mensajería Push y Poll . . . . . . . . . . . . . . . . . 61

3.3.2. Geolocalización . . . . . . . . . . . . . . . . . . . . . . 63

4. Experimentos 65

4.1. Consideraciones de los experimentos . . . . . . . . . . . . . . . 65

4.2. Propuestas Push y Polling . . . . . . . . . . . . . . . . . . . . 66

4.3. Geolocalización . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5. Conclusiones 76

Bibliografía 81

Índice de �guras

1.1. Componentes en Smartphones . . . . . . . . . . . . . . . . . . 2

1.2. Evolución de los Smartphones . . . . . . . . . . . . . . . . . . 4

1.3. Cantidad de ventas por fabricante 2015 . . . . . . . . . . . . . 6

1.4. Mercado de aplicaciones de Google . . . . . . . . . . . . . . . 8

1.5. Porcentaje de S.O. en Smartphones . . . . . . . . . . . . . . . 12

2.1. Aplicaciones Android . . . . . . . . . . . . . . . . . . . . . . . 17

2.2. S.O. Android Arquitectura . . . . . . . . . . . . . . . . . . . . 19

2.3. Eclipse con SDK y ADT . . . . . . . . . . . . . . . . . . . . . 20

2.4. Ciclo de vida Activity . . . . . . . . . . . . . . . . . . . . . . 22

2.5. Empleo Intents . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.6. Ciclo de Vida Service . . . . . . . . . . . . . . . . . . . . . . . 24

2.7. Content Provider . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.8. Android Manifest . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.9. AVG Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1. Esquema de Polling . . . . . . . . . . . . . . . . . . . . . . . . 42

3.2. Esquema Push . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.3. Esquema GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.4. Esquema de geolocalización por antenas . . . . . . . . . . . . 46

3.5. Diagrama de Clases Poll . . . . . . . . . . . . . . . . . . . . . 51

3.6. Conexión al servidor . . . . . . . . . . . . . . . . . . . . . . . 51

3.7. Esquema GCM . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.8. Diagrama de clases Push . . . . . . . . . . . . . . . . . . . . . 54

3.9. Registro en servidor de aplicaciones . . . . . . . . . . . . . . . 54

3.10. GCMBroadcastReceiver . . . . . . . . . . . . . . . . . . . . . 55

3.11. Permisos GCM . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.12. Diagrama de clase Geolocalización . . . . . . . . . . . . . . . . 57

3.13. Subscripción location listener . . . . . . . . . . . . . . . . . . 58

3.14. Receiver de batería . . . . . . . . . . . . . . . . . . . . . . . . 59

3.15. Escritura de datos . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.16. Conexión power monitor . . . . . . . . . . . . . . . . . . . . . 62

3.17. Software de medición . . . . . . . . . . . . . . . . . . . . . . . 62

4.1. Consumo Promedio Push/Poll . . . . . . . . . . . . . . . . . . 68

4.2. Consumo Promedio GPS/Triangulación de Antena . . . . . . 72

Índice de cuadros

4.1. Detalle Consumo de las Alternativas Push y Poll . . . . . . . . 68

4.2. Detalle Consumo Promedio Registro GCM . . . . . . . . . . . 69

4.3. Detalle Consumo Geolocalización . . . . . . . . . . . . . . . . 72

4.4. Cantidad de Lecturas . . . . . . . . . . . . . . . . . . . . . . . 73

Capítulo 1

Introducción

En este primer Capítulo se explicarán la motivación y el propósito del

presente trabajo junto con la información del entorno en el que se desarrolla.

Adicionalmente, esta introducción cuenta con una descripción histórica de

la problemática, necesaria para la comprensión general del documento y del

trabajo en sí.

1.1. Problemática

En la actualidad la tecnología móvil junto con una gran cantidad de in-

formación pasan a través de las manos de las personas de manera rápida y

diversa. Particularmente, en nuestras manos se halla el dispositivo elegido

por excelencia como principal medio de comunicación y de conexión con el

mundo, el smartphone Rice and Hay [2010]. Los smartphones, se han conver-

tido en las nuevas computadoras personales cuyos propietarios utilizan para

enviar y recibir miles de datos: llamadas, mensajes de texto, e-mails, foto-

grafías, música, etc. El smartphone es un tipo de dispositivo que se utiliza

de forma constante ya que es útil en el trabajo, la vida social y por supuesto

en el entretenimiento. Básicamente, los smartphones son minicomputadoras

diseñadas para realizar las funciones de un teléfono celular y, a su vez, pa-

ra permitir a sus usuarios disfrutar de las posibilidades que brinda internet.

Asimismo, los smartphones poseen sensores que los diferencian de las PC o

1

1.1. PROBLEMÁTICA

Figura 1.1: Componentes en Smartphones

notebooks, por ejemplo: acelerómetro (sensores que detectan el movimiento

en el equipo), sistema de posicionamiento global, etc. Para poder utilizar

estas características sólo es necesario poseer las aplicaciones correspondien-

tes para su uso o algún tipo de aplicación que utilice la propiedad deseada.

Sin embrago, es importante tener en cuenta que la principal característica de

estos dispositivos es su movilidad, la cual puede verse afectada si las aplicacio-

nes consumen rápidamente la batería de los dispositivos ya que los mismos

basan en su batería su suministro energético. Entonces, es de gran impor-

tancia tener en cuenta que toda funcionalidad in�uye en la autonomía del

dispositivo. Si bien se han logrado grandes avances en el poder de cómputo y

en las redes inalámbricas, la batería de los smartphones no ha evolucionado

en igual medida Alejandro Zunino [2013]. Esta evolución puede observarse

en la Figura 1.1. Si bien la evolución de CPU aparenta no ser exponencial

es importante remarcar que en este componente la principal evolución se da

en el uso de múltiples componentes en el mismo dispositivo. Por lo tanto,

este recurso se convierte en un factor clave a tener en cuenta a la hora de

desarrollar aplicaciones móviles.

Son diversas las causas por las que un Smartphone no cumple con la

2

1.1. PROBLEMÁTICA

autonomía deseada por los usuarios o lo especi�cado por los fabricantes.

Además, las baterías poseen una vida útil corta que atenta contra el uso

prolongado de los mismos. Esto último se debe a que los materiales con

los que se fabrica una batería poseen propiedades físicas que con el paso

del tiempo implican una perdida en la capacidad de carga, disminuyendo el

tiempo de uso del smartphone. No obstante, no es fácil evaluar y mucho menos

predecir el consumo de energía de una aplicación debido a la gran cantidad

de variables involucradas tales como la gran diversidad de dispositivos que

existen, los componentes que son parte de estos y el uso especí�co por parte

de cada usuario. Sin embargo, existen formas de obtener las características

que más inciden en la batería mediante software o hardware y, con estas

herramientas, así analizar el consumo de energía de los dispositivos en tiempo

de reposo, el consumo de una aplicación determinada, etc; siendo la segunda

alternativa (por hardware) más precisa que la primera. La di�cultad de medir

el consumo energético está en aislar el consumo que se desea medir del resto

del funcionamiento del dispositivo móvil. Una de las principales causas de

la disminución en el tiempo de duración de batería es la cantidad de tareas

simultáneas que los smartphones actuales realizan.

Hace algunos años, los primeros dispositivos móviles contaban con bajos

recursos y realizaban menor cantidad de tareas. Procesadores de texto, hojas

de calculo y la agenda como las principales aplicaciones utilizadas, fueron

suplantadas por juegos 3D, redes sociales o mapas en tiempo real, obviamen-

te apoyados en una mejora evidente en los componentes de hardware que

componen a los dispositivos Figura 1.1. Para apreciar la evolución del poder

computacional de los dispositivos móviles podemos observar que los prime-

ros dispositivos móviles se abrían paso no hace muchos años para generar

un nuevo mundo de comunicación e intercambio de información. En 1981 se

presentaba la Osborne 1 como la primer notebook. Pesaba cerca de 11 kilos y

poseía una autonomía máxima de 1 hora. Como software poseía: un paquete

creado por Windows, procesador de texto, hoja de cálculo y base de datos.

Esta computadora poco tiene que ver con las notebooks de hoy en día pero

fue pionera en su campo y generó miles de investigaciones posteriores hasta

lograr lo que actualmente se conoce como laptops portátiles. Algo similar

3

1.1. PROBLEMÁTICA

pasó con los celulares en la década de los 90s: IBM creó el primer teléfono

inteligente al que llamó Simón. En ese entonces el dispositivo permitía recibir

y realizar llamadas, contenía un calendario, una libreta de direcciones, una

libreta de anotaciones, etc. Más adelante, la nueva generación de smartpho-

nes logró una comunicación más e�caz para los usuarios adicionando también

calculadoras, linternas y entretenimiento ya que poseían los más diversos jue-

gos. Otra característica importante es el tamaño de los mismos el cual fue

disminuyendo a través de los años (Figura 1.2). Pero, además de la nueva

funcionalidad, el tamaño de las pantallas de los nuevos dispositivos creció en

dimensiones y prestaciones. También aumentaron las resoluciones de panta-

llas, la cantidad de colores, etc.; logrando que el mayor consumo de batería

se acentué sobre las mismas.

Figura 1.2: Evolución de los Smartphones

Más detalladamente podemos ver que los primeros dispositivos cumplie-

ron muy bien la función para la que fueron creados (comunicación) y es por

esto que tuvieron tanto éxito en el mercado. Por ejemplo, el mítico celular

Nokia 1100 poseía todas las características básicas de un celular mencionadas

anteriormente sumándole por un lado una obtención de señal en casi cual-

quier punto geográ�co y, por otro, un consumo de batería muy bajo, dado

que podía pasar varios días encendido antes de tener que conectarlo a la

red eléctrica. Tal vez estas dos características fueron las que más quedaron

4

1.1. PROBLEMÁTICA

grabadas en la memoria de los usuarios y es por eso que a la hora de te-

ner un dispositivo que ofrece prestaciones muy parecidas se anhele el mismo

funcionamiento. En la mayoría de los foros de discusión sobre consumo de

batería se recuerda a este dispositivo como una especie de leyenda. Sin duda,

para su época aquel dispositivo fue una novedad que creó un mercado donde

tanto las compañías fabricantes como las de telefonía congeniaron para con-

tinuar explotándolo y creando nuevas tecnologías para aumentar el mercado

como puede observarse en la Figura 1.3. Aquí se puede resaltar que en el

año 2015 se lograron vender más de mil millones de unidades de teléfonos

inteligentes1, demostrando que estos dispositivos se han convertido en una

parte importante para la vida cotidiana de las personas. Un teléfono inte-

ligente o smartphone es un teléfono celular que incorpora característias de

una computadora personal. Estos presentan un software más avanzado que

los celulares comunes y, un hardware lo su�cientemente �exible para sopor-

tar las nuevas funcionalidades, escencialmente el procesador y la memoria

interna. El dispositivo de Nokia 1100 no poseía conectividad WiFi o blue-

tooth, el procesador era pequeño y la memoria interna alcanzaba los 100 Kb,

entre otras características. Los smartphones modernos suman a los tipos de

conectividad anteriormente mencionadas, las redes móviles como 3G o 4G,

procesadores con hasta 10 núcleos de hasta 2 GHz, y memoria interna de va-

rios Gb, además de nuevos sensores (GPS, acelerometro), pantallas con una

gran cantidad de colores, resistentes al agua, brújulas, etc.

1IDC Analize the Future, Framingham, Mass. January 27, 2016

5

1.1. PROBLEMÁTICA

Figura 1.3: Cantidad de ventas por fabricante 2015

Los smartphones han tenido un crecimiento de sus capacidades exponen-

cial en el corto tiempo de desarrollo que tienen. Además, el crecimiento del

mercado de dispositivos móviles ha atraído a miles de inversores permitien-

do la investigación de diversa índole que le ofrece a un fabricante contar con

nuevas y mejores unidades año tras año. Por ejemplo, Samsung vende más de

300 millones de unidades al año (Figura 1.3) y es el líder indiscutible en ven-

tas2. Samsung introduce desde hace más de una década nuevos dispositivos

con mejoras atractivas para los usuarios. En el 2010, lanzó el primer mode-

lo Galaxy S de la familia de dispositivos más importante y vendida por el

fabricante. Este dispositivo constaba de un procesador de 1 GHZ "Humming-

bird", 8 Gb de almacenamiento interno, 512 Mb de memoria RAM, sistema

operativo Android 2.2 (Froyo), tiempo de conversación estimado de 6 horas

(1500 mAh), entre otras características. Luego de un año, el fabricante pre-

sentó el Samsung Galaxy SII que contaba con procesador de 1,2 GHz doble

núcleo, 1 GB de RAM, una cámara de 8 megapíxeles que podía grabar vídeos

en 1080p de alta de�ción, una tarjeta grá�ca o (GPU) ARM, una batería de

capacidad de 1650 mAh, cuyo fabricante estimaba una duración de conver-

sación de poco más de 8 horas. En 2015, la misma empresa lanzó al mercado

2IDC Analize the Future, Framingham, Mass. January 27, 2016

6

1.1. PROBLEMÁTICA

el Samsung Galaxy S6 con un procesador Samsung Exynos 7420 de 8 núcleos

4x1.5/4x2.0 GHZ, 3 Gb de memoria RAM, 128 Gb de memoria interna, sis-

tema operativo 5.0.2 de Android y unas 17 horas de tiempo de conversación

según el fabricante (2550 mAh). Además de las características mencionadas,

estos dispositivos mejoraron el sistema operativo, asemejándolo al de una

computadora, por ejemplo incorporando multi-tarea y multi-ventana. Si bien

las mejoras son evidentes a lo largo de los años, aún las características de

hardware en los smartphones siguen siendo limitadas en comparación a una

computadora portátil (memoria RAM, procesador, etc).

Teniendo en cuenta lo mencionado anteriormente, se observa que el po-

der de procesamiento de estos dispositivos es considerablemente mayor al de

hace algunos años y crece año tras año de manera exponencial. Mas allá de

sus nuevas capacidades, los usuarios exigen también mayor autonomía por

parte de estos dispositivos. Al compararlos con los celulares en los que po-

dían pasar varios días sin tener que cargarse, los smartphones apenas pueden

soportar una jornada diaria ante un uso moderado de sus capacidades. Es

decir, la característica más importante que hace a un dispositivo móvil se ve

claramente afectada en un smartphone por el crecimiento de sus capacidades.

La batería se ha convertido en un recurso tan importante como la memoria o

el procesamiento y, como todo recurso de un dispositivo móvil, debe ser bien

administrado. Una de las razones de esta disminución en la autonomía de

los smartphones es la ejecución de nuevas aplicaciones cada vez más potentes

que generan un gasto adicional en el consumo de energía que antes no existía.

Por otro lado, la integración de los dispositivos móviles, internet y la

conectividad inalámbrica ofrecen la posibilidad de extender la información y

los servicios a los usuarios. En la actualidad, los smartphones brindan nuevas

características haciendo uso de todos los nuevos componentes que poseen. Su

funcionalidad ha crecido año tras año y se ha convertido en una herramien-

ta indispensable. Todas o la mayoría de estas funciones fueron desarrolladas

por medio de investigaciones de las redes inalámbricas, las cuales posibili-

taron a estos dispositivos crecer en prestaciones permitiendo el intercambio

de información y realización de tareas en forma móvil. El aumento de la

transferencia de datos vía móvil, como e-mails, archivos, juegos, búsqueda en

7

1.1. PROBLEMÁTICA

Figura 1.4: Mercado de aplicaciones de Google

internet, etc., ha impulsado a la industria de telecomunicaciones a desarro-

llar redes para el intercambio de información como el 3G. Estas importantes

mejoras, también han requerido el uso de tecnologías más complejas que ne-

cesitan mayor cantidad de energía para conectar los dispositivos con la red

móvil. Tecnología como el 3G permiten a los smartphones alcanzar una bue-

na velocidad de transferencia posibilitando a los usuarios reproducir vídeos,

música, disfrutar de juegos o participar de conferencias en tiempo real. Con

este tipo de redes los alcances de los dispositivos móviles han crecido consi-

derablemente. Aunque la velocidad de transferencia no es la misma que la

obtenida a través de una conexión wi-�, el 3G posibilita un ancho de banda

útil y proporciona al mundo móvil mayor importancia. La gran desventaja

de este tipo de conexión es que posee una cobertura limitada dependiente

de la localización del dispositivo, aunque ya esté implementando el 4G que

promete tasas de transferencia mayor así como una mejora en la calidad del

servicio la conexión a una red wi-� sigue proporcionando mayor transferencia

y �abilidad. De esta manera los continuos avances en las redes inalámbricas

dotan a los dispositivos móviles como los smartphones de la posibilidad de

seguir creciendo en prestaciones.

Otra característica importante de los smartphones actuales es que ofrecen

8

1.1. PROBLEMÁTICA

la posibilidad de instalar o desinstalar aplicaciones de manera sencilla, gene-

rando así un gran mercado para desarrolladores y empresas. Adicionalmente,

las mejoras en las redes permiten a las aplicaciones realizar intercambio de in-

formación para proveer sus servicios. Con estas nuevas características se han

creado mercados donde los usuarios ingresan y descargan aplicaciones tales

como juegos, aplicaciones de edición de fotografía, redes sociales y sincroni-

zación de datos en la nube para sus dispositivos. Estos mercados posibilitan

a los desarrolladores de aplicaciones compartir sus aplicaciones con otros,

fomentando el crecimiento tanto del sector privado como de programadores

entusiastas en el área. Esto también permite al usuario personalizar su dis-

positivo móvil obteniendo las aplicaciones de su interés. Como se ve en la

Figura 1.4 el crecimiento a lo largo de los últimos años del mercado de apli-

caciones de Android es evidente y ha alcanzado niveles mundiales. Aunque

el mercado de Google no es el único que existe es el más importante3.

Sin embargo, poder expandir las capacidades de un dispositivo tiene sus

desventajas. No siempre las aplicaciones tienen en cuenta el consumo de

batería a la hora de realizar sus tareas. Los diseños de las aplicaciones gene-

ralmente contemplan los requisitos funcionales de las mismas y olvidan que

el consumo de recursos en un dispositivo móvil debe ser realizado de forma

controlada. El objetivo de los programadores es lograr que el desarrollo de

su aplicación se pueda ejecutar en la mayor cantidad de dispositivos posibles

(smartphones, tablets, etc.), y es bien sabido que hay una gran diversidad

de los mismos. A su vez, numerosas aplicaciones necesitan una conexión a

datos para poder funcionar y es allí donde radica un gran inconveniente:

mantener encendido el receptor wi-� o el 3G para el smartphone involucra

un gran costo energético, sumado a todos los procesos y servicios que deben

ejecutarse cada vez que la conexión con Internet es detectada. Hoy en día,

un desarrollador de aplicaciones debe considerar al consumo de energía como

un factor importante, tanto para poder competir en el mercado como para

generar satisfacción en los usuarios pues si la batería se agota rápidamen-

te nadie estará satisfecho al utilizar su aplicación. Se puede inferir que un

correcto uso de energía en las aplicaciones alargará el tiempo de autonomía

3App Annie, Business intelligence company, San Francisco, California, April 15, 2015

9

1.1. PROBLEMÁTICA

de un smartphone y así se logrará un mejor uso del mismo. El correcto uso

de la energía en esta clase de dispositivos permite que todas las aplicaciones

se bene�cien compartiendo correctamente el recurso más importante de un

dispositivo móvil. Esto signi�ca que un desarrollador de aplicaciones para

dispositivos móviles, debe pensar y diseñar correctamente su aplicación, da-

do que un error en el código de esta o en la táctica utilizada para resolver

un problema funcional puede afectar en gran medida el consumo de energía,

como por ejemplo la creación innecesaria de objetos o la forma de recorrer

una matriz (por columna o por �la). En este sentido, es importante tener en

cuenta que una pequeña decisión puede tener un impacto signi�cante en el

consumo de energía Rice and Hay [2010]. En conclusión, el poder de cómputo

de los dispositivos móviles no sirve si sólo se puede usar por una fracción de

tiempo y no es utilizable cuando más se lo necesita. En la actualidad el mo-

delo de e�ciencia energética no es el mejor, o incluso peor, está ausente en el

diseño de numerosas aplicaciones. Es decir que, las aplicaciones que los usua-

rio descargan e instalan en sus dispositivos no siempre utilizan e�cientemente

la batería o no fueron pensadas correctamente para minimizar el uso de esta,

y es por eso que es importante generar conciencia en el mundo móvil sobre

los problemas que trae el desarrollo de aplicaciones sin tener en cuenta el

consumo de energía, sobre todo en el universo de los smartphones. Se puede

mejorar el modelo que existe actualmente de desarrollo mediante la utiliza-

ción de tácticas e�cientes en el consumo de energía y lograr buenos resultados

debido a que existen diversas herramientas para lograr objetivos como la ob-

tención de mayor satisfacción con el usuario o mejor uso de los recursos del

sistema para bene�cio de todas las aplicaciones en el dispositivo, teniendo en

cuenta estos nuevos requerimientos no funcionales. Las constantes investiga-

ciones y el seguimiento continuo de una problemática tan importante pueden

ayudar a mejorar el paradigma actual y generar una mejora en el desarrollo

de aplicaciones móviles.

10

1.2. DESCRIPCIÓN DEL TRABAJO

1.2. Descripción del Trabajo

Por lo mencionado en la Sección anterior, es importante mejorar el pa-

radigma de e�ciencia energética actual y el uso de los recursos limitados del

smartphones. Entonces, el objetivo principal del presente trabajo es analizar

la forma en que actualmente una aplicación móvil intercambia información

por medio de las diferentes redes inalámbricas y cómo esto in�uye en el con-

sumo de energía. De esta forma, se comparan las distintas alternativas de

desarrollo que existen para realizar una operación tan importante como el

intercambio de información y guiar a los programadores hacia el uso conscien-

te del consumo de batería además de proporcionar resultados cuantitativos

y comparativos para cada tipo de operación. Para lograr esto, el trabajo está

basado en la utilización de las distintas tácticas disponibles para la obtención

de diferentes tipos de datos que un usuario posee en su smartphone.

Esas tácticas son conocidas en el ambiente de desarrollo móvil, pero no

así su consumo de energía aislado de las tareas propias de la aplicación. Es

decir, el intercambio de información entre el dispositivo y un servidor, por

ejemplo, es una parte fundamental para el funcionamiento de la aplicación

pero el consumo energético de esta tarea en particular no es conocido. Sin

embargo, la conexión y obtención de información no sólo son utilizadas para

el funcionamiento base de la aplicación. Otro uso de este tipo de conexión es,

por ejemplo, la descarga de publicidad que es utilizada mayormente por las

aplicaciones gratuitas y que sirve para obtener un bene�cio económico para

sus desarrolladores. Además de estos usos, el intercambio de datos se puede

dar en una aplicación de posicionamiento global para obtener información de

la ubicación actual del dispositivo. Este tipo de aplicaciones suelen conectarse

a los satélites o antenas de telefonía para ubicar el dispositivo móvil y, de esta

forma, brindar la posición en la que se encuentra el usuario. Este último tipo

de aplicaciones suelen ser catalogadas como las que mas energía consumen

cuando se encuentran activas.

En este trabajo se desarrollarán aplicaciones con diferentes estrategias de

conexión a datos (intercambio de información y posicionamiento del dispositi-

vo) como las que utilizan aplicaciones como Gmail, Whatsapp, Google Maps,

11

1.2. DESCRIPCIÓN DEL TRABAJO

Facebook, etc., para así poder realizar mediciones del consumo de energía de

las diferentes estrategias y de esta forma poder evaluar cuál de ellas es más

e�ciente de acuerdo a los distintos contextos. Luego de la obtención de los

resultados y su correspondiente análisis, se planteará una conclusión a forma

de guía para proveer a los desarrolladores información sobre las implican-

cias de las decisiones de diseño y desarrollo en las aplicaciones móviles de

este tipo en el consumo de energía. Así, se espera que con esta información,

los desarrolladores puedan realizar software que hace un uso más e�ciente

de la energía y consecuentemente se mejore el tiempo de vida de batería de

smartphones.

Figura 1.5: Porcentaje de S.O. en Smartphones

Para realizar los experimentos se ha optado por Android como sistema

operativo puesto que es el más usado a nivel mundial por los usuarios y por

los desarrolladores, como se observa en la Figura 1.5. Durante el año 2015,

los distintos fabricantes cuyas unidades poseían el sistema operativo, logra-

ron acaparar mas del 80% del mercado logrando también que el desarrollo

de aplicaciones sobre este creciera. El S.O. provee la característica de open-

source (está basado en el núcleo de Linux) y es una plataforma que permite

crear aplicaciones con el uso de todas sus características pudiendo combinar

cualquier tipo de estas. Este será detallado en mayor profundidad, junto con

12

1.3. ORGANIZACIÓN

su diseño y estructura, más adelante en el documento.También cuenta con

la comunidad mundial de desarrolladores más grande y el mayor movimiento

de estos con multitud de eventos, concursos, competiciones y reuniones; así

como múltiples vías de comunicación tales como foros y chats para fomen-

tar la participación y la colaboración para encontrar mejoras e ideas para

futuras versiones. En cuanto al lenguaje de desarrollo, las aplicaciones se

desarrollarán en Java que es el lenguaje de alto nivel de Android y es un

lenguaje con interesantes características y popular entre los desarrolladores

actualmente. Es el lenguaje de programación mas utilizado en el mundo Ali-

ne Rodrigues Tonini [2013] y, contrariamente a algunas creencias, Java es

bastante e�ciente en cuanto a energía en comparación a otros lenguajes de

programación Adel Noureddine [2012]. Además, es el lenguaje que ofrece o�-

cialmente Google para sus desarrollos, del cual existe información completa

y actualizada; y cuyas actualizaciones están al día. Se optó por no trabajar

con ningún tipo de framework debido a que la mayoría de estos poseen op-

timizaciones que pueden degradar la calidad de los resultados obtenidos. De

esta forma, los resultados que se obtendrán mostrarán el consumo energético

de las diferentes tácticas sin ningún tipo tipo de interferencia u optimización.

1.3. Organización

Para �nalizar este capítulo se procede a describir la organización del pre-

sente trabajo. En primer lugar, en el Capítulo 2, se explicará una breve intro-

ducción sobre el contexto de desarrollo móvil teniendo en cuenta el mercado

existente de smartphones y aplicaciones en conjunto con el sistema operativo

seleccionado (Android). A su vez, se presentarán y desarrollarán trabajos de

investigación relacionados al consumo de batería.

En el Capítulo 3, se explicará cómo fueron desarrolladas las distintas tác-

ticas para luego ser medidas. Es decir que se desarrollarán sus características,

sus diversas problemáticas y limitaciones, bajo qué red de datos serán pro-

badas, etc. También, se presentarán los dispositivos a ser utilizados para las

mediciones y la metodología seleccionada para realizar los test de las distintas

tácticas.

13

1.3. ORGANIZACIÓN

Luego se ofrecerán los resultados de las mediciones en conjunto con los

problemas encontrados para realizar las mismas en el Capitulo 4. Adicional-

mente, se añadirán algunas explicaciones sobre los valores obtenidos y ,con-

juntamente con estas, se plantearán nuevas hipótesis a ser analizadas para

complementar el entendimiento de los resultados.Por último, en el Capitulo 5

se desarrollarán las conclusiones globales del documento, trabajos futuros y,

a modo de resumen, las observaciones de los puntos más importantes.

14

Capítulo 2

Entorno de Trabajo

En este Capítulo se presentará el contexto necesario para comprender el

presente trabajo. Como paso inicial, se desarrollará la información relaciona-

da con los dispositivos móviles haciendo especial hincapié en los equipos, el

mercado de aplicaciones y el sistema operativo Android; para luego dar lugar

a la presentación de algunos trabajos relacionados sobre el consumo de ba-

tería en smartphones que motivaron, guiaron y favorecieron la investigación.

2.1. Smartphones

Los smartphones se han convertido en el dispositivo móvil más impor-

tante y popular a nivel mundial debido a dos características: su tamaño, ya

que son fácilmente transportables, y su autonomía, que se basa en una ali-

mentación energética por medio de una batería. A su vez, sus capacidades

computacionales han crecido considerablemente logrando que se expanda su

dominio, es decir que a la principal característica de comunicación se le agre-

ga la posibilidad de enviar y recibir datos, entre otras. Hablar por teléfono

o acceder a los emails era primordial hace algunos años pero hoy otras fun-

cionalidades también son importantes en estos dispositivos: el Smartphone

permite al usuario sacar fotos, vídeos, etc., y compartirlo vía redes sociales

o mensajería instantánea; también permite utilizar distintas aplicaciones de

entretenimiento o trabajo como juegos y editores de texto. De esta forma, el

15

2.1. SMARTPHONES

Smartphone se convierte en una computadora personal y portátil con carac-

terísticas especiales haciendo que en el año 2015 se hayan vendido más de

1.000 millones de dispositivos a nivel mundial.

Como consecuencia de este fenómeno, el mercado de aplicaciones para

los smartphones ha crecido masivamente y ha fomentado el desarrollo mó-

vil de incontables tipos de aplicaciones. Esto se da gracias a la posibilidad

que brindan los smartphones de instalar y desinstalar las aplicaciones para

aumentar sus capacidades de manera sencilla, logrando de esta manera que

se reinvente el mercado día a día, generando nuevas oportunidades para los

programadores independientes o las empresas dedicadas al desarrollo móvil.

Además, los usuarios se han vuelto cada vez más exigentes, buscando nuevas

y mejores aplicaciones para aumentar las capacidades de sus dispositivos. Así

mismo, las aplicaciones proveen una cantidad de funcionalidad que las hace

indispensables en muchos casos. Tal vez, las más populares se han concentra-

do en un selecto grupo tal como la mensajería instantánea, las redes sociales,

los juegos, etc., pero también aplicaciones no sólo para el entretenimiento de

los usuarios sino otras como las de posicionamiento global, compras online,

búsqueda de información y hasta aplicaciones con �nes médicos, etc., se han

vuelto populares e indispensables en muchos casos. Aplicaciones como What-

sapp, Maps, Gmail, Facebook, etc., han logrado superar las 1.000 millones de

descargas en pocos años (Figura 2.1), y se había previsto que sólo para el año

2015 se logrará una cantidad de descargas cercanas a los 200 millones para la

totalidad de las aplicaciones en Google Play y un continuo crecimiento para

los años venideros. La Play Store de Google para el sistema operativo An-

droid es el mercado de aplicaciones que más descargas tiene a nivel mundial,

incluso por delante de la App Store de Apple1.

Google Play posee más de 1.000 millones de distintas aplicaciones, la

mayoría de ellas gratuitas, que le permiten a un usuario aumentar las ca-

pacidades de su dispositivo. En dicho mercado no solamente las empresas

de software presentan sus servicios, sino que también muchos programadores

independientes suben allí sus propuestas gracias a que Google provee un con-

junto de herramientas gratuitas para desarrolladores. Además, Google ofrece

1App Annie, Business intelligence company, San Francisco, California, April 15, 2015

16

2.1. SMARTPHONES

una web donde explica paso a paso cómo desarrollar una aplicación para An-

droid y provee un paquete de desarrollo (SDK) con su correspondiente IDE

(Eclipse) para Java. Este no es el único IDE que existe pero está diseñado

especialmente para este tipo de desarrollo y ofrece varias herramientas co-

mo ADT (Android Developer Tools) que simpli�can la tarea de desarrollo. Si

bien estas son algunas de las herramientas que provee Google, existen un gran

número de frameworks de distintas características. Entre los mas populares

se encuentran Appcelerator, Xamarin, etc, que además de proveer la posibi-

lidad de desarrollo para Android, en distintos lenguajes, también poseen la

capacidad de compilar sus soluciones para distintas plataformas como iOS o

Windows Phone con un mínimo de ajustes en el código fuente. Estos también

son muy utilizados por la comunidad de desarrolladores aunque escapan al

presente trabajo, se deben mencionar para conocer todas las alternativas que

se tuvieron en cuenta.

Figura 2.1: Aplicaciones Android

Este gran crecimiento de los mercados es en parte apoyado por una mejora

sustancial en las redes inalámbricas ya que es indispensable que los teléfonos

inteligentes posean una conexión a Internet que sea rápida y segura. Nuevas

tecnologías como el 4G, que ofrece una velocidad máxima de transferencias

de 100 Mbit/s en movimiento del dispositivo, facilitan la funcionalidad de las

distintas aplicaciones. Es un hecho que la mayoría de las personas navega por

Internet con su Smartphone o Tablet más que con su computadora personal.

La posibilidad de estar en línea sin depender de una red wi-�, ha provisto a

los teléfonos inteligentes de una gran ventaja sobre otros tipos de dispositivos.

17

2.2. ANDROID EN SMARTPHONES

Aún con todas las características mencionadas anteriormente, antes de

desarrollar una aplicación es de gran importancia comprender que los dis-

positivos móviles poseen limitaciones. Su parecido con las PC portátiles o

de escritorio se da solo en el funcionamiento, pero en cuanto a hardware no

son lo mismo, aunque los usuarios esperen obtener la misma performance en

un dispositivo móvil que en una computadora personal. Los componentes de

un teléfono inteligente son limitados y el uso de una batería como fuente de

energía no se debe menospreciar ya que el agotamiento de la batería deja sin

posible uso el dispositivo, generando un efecto negativo en la experiencia del

usuario.

2.2. Android en Smartphones

En este apartado se pretende dar una introducción sobre el sistema ope-

rativo Android seleccionado para realizar el presente trabajo. En general, se

hace un repaso de sus comienzos y evolución, pasando por la estructura del

mismo y las características mas importantes.

En el año 2008, se lanzaba al mercado el primer smartphone con Android:

el HTC Dream fue el primer dispositivo móvil con el sistema operativo de

Google. Este incorporaba la primera versión del sistema operativo (Android

1.0) y constaba con las novedades de acceso directo a todas las aplicaciones

de Google tales como Gmail y Google maps.

En la actualidad, Android es el sistema operativo más elegido por los

usuarios en el mundo y maneja más del 80% del mercado, con una gran di-

ferencia con su inmediato competidor. Una de las razones por las que esta

plataforma móvil es tan utilizada es por su característica de open-sourse. Su

composición está basada en un kernel de Linux, que actúa como capa de

abstracción con el hardware y provee los servicios base del sistema; en un

conjunto de bibliotecas, que proporcionan la mayor parte de las funcionali-

dades disponibles a las aplicaciones; en una máquina virtual (Dalvik) como

entorno de ejecución optimizada para funcionar con bajo poder de cómputo

y memoria escasa; en un framework para las aplicaciones que está orientado

como herramienta de desarrollo; y en una serie de aplicaciones base a las

18

2.2. ANDROID EN SMARTPHONES

que un usuario puede agregar las que desee (correo electrónico, SMS, calen-

dario,contactos, etc). En la Figura 2.2, se puede observar la arquitectura de

capas del sistema operativo completa.

Figura 2.2: S.O. Android Arquitectura

Tal vez la capa más importante para el desarrollo del presente trabajo es

el framework de aplicaciones que está formado por las clases y servicios que

utilizan directamente las aplicaciones para realizar sus funciones. La mayor

parte de los componentes de esta capa son bibliotecas Java que acceden a los

recursos de las capas anteriores a través de la máquina virtual Dalvik. Por

19

2.2. ANDROID EN SMARTPHONES

Figura 2.3: Eclipse con SDK y ADT

ejemplo, Activity Manager, Noti�cation Manager y Location Manager, etc.

Estos componentes representan fundamentalmente el conjunto de herramien-

tas de desarrollo de cualquier aplicación. Toda aplicación que se desarrolle

para Android, ya sean las propias del dispositivo, las desarrolladas por Goo-

gle o terceras compañías, o incluso las que el propio usuario cree, utilizan

el mismo conjunto de APIs y el mismo "framework" representado por este

nivel.

Para el desarrollo de aplicaciones Android se provee al desarrollador un

SDK (Software Development Kit) en conjunto con un ADT, entre otras he-

rramientas que facilitan este proceso. El paquete SDK de Android incluye

un conjunto de herramientas de desarrollo que permite al programador crear

aplicaciones. Comprende un depurador de código, bibliotecas, un simulador

de teléfono, documentación, ejemplos de código y tutoriales. El paquete ADT

es un plugin para el IDE Eclipse (Figura 2.3) para conseguir un mayor po-

tencial en el desarrollo e integración de aplicaciones, con�riendo una mayor

versatilidad para una mejor construcción de aplicaciones Android. En otras

palabras, ADT amplía las capacidades ya existentes de Eclipse permitiendo

con�gurar rápidamente nuevos proyectos para Android, crear una interfaz de

usuario de aplicación, etc. A su vez, el desarrollador puede elegir para qué

versión de Android se quiere programar por lo que debe considerarse que

20

2.2. ANDROID EN SMARTPHONES

cada API varía en el tiempo agregando una nueva funcionalidad o reempla-

zando el código obsoleto en cada nueva versión. Igualmente, cada reemplazo

o cambio de funcionalidad está diseñado de tal modo que se garantice su

compatibilidad con versiones anteriores. De esta forma, cada nueva versión

de Android soporta las APIs de su nivel y las anteriores. El paquete SDK

también es actualizado con el desarrollo general de Android y con cada nueva

versión que es presentada por Google año tras año el software permite des-

cargar todos los elementos necesarios para desarrollar en el mismo. De esta

forma es posible siempre estar al día con las nuevas versiones, características

y correcciones de código que el sistema operativo posee.

Finalmente, las aplicaciones Android son muy diferentes a las de escritorio

dado que el ciclo de vida de estas están controladas por el sistema operativo

basándose en las necesidades del usuario y recursos disponibles, entre otros

factores. Si se tiene una aplicación que está consumiendo muchos recursos y

se ejecuta otra nueva aplicación, el sistema operativo probablemente le pida

a la primera que se quede en segundo plano, que libere todos los recursos que

pueda y, de ser necesario, la cerrará. El sistema operativo tiene más control

en estos dispositivos que en otros dado que los recursos en un smartphone

son menores a las computadoras de escritorio o notebooks y es necesaria

una administración cuidadosa. En la Figura 2.4 se presenta el ciclo de vida

de una aplicación con interfaz grá�ca Android. Otros elementos básicos del

desarrollo de aplicaciones móviles son:

Activity: Una actividad es la representación visual e interactiva en una

aplicación y son representadas por la clase Java Activity. A diferencia

de otras aplicaciones, una Activity en Android no tiene asignado un

método main() como punto de entrada principal, ya que su inicio es

responsabilidad de la capa de Framework para aplicaciones. En esta

capa se encuentra el servicio Activity Manager, quien se encarga de

crear, destruir y manejar todas las actividades de una aplicación. Una

actividad puede interpretarse como una máquina de estados que es-

tá pendiente de las acciones del usuario. Aunque el programador no

puede controlar la forma en que se iniciará, sí puede decidir qué sen-

21

2.2. ANDROID EN SMARTPHONES

Figura 2.4: Ciclo de vida Activity

tencias se ejecutarán en cada estado. Los estados por los cuales puede

transcurrir una Activity son los siguientes: Creación, Ejecución, Reanu-

dación, Pausa, Detención y Destrucción. Cada transición entre estados

está representada por uno de estos métodos: onCreate(), onStart(), on-

Restart(), onResume(), onPause(), onStop() y onDestroy(). Cuando el

usuario presiona sobre el icono de la aplicación en su dispositivo, el mé-

todo onCreate() es ejecutado inmediatamente para cargar la pantalla

de la actividad principal en memoria. Después de haber sido cargada la

actividad se ejecutan en secuencia el método onStart() y onResume(),

logrando de esta manera que la aplicación pase al estado de Ejecución.

En algunas ocasiones, una aplicación puede pausarse, por ejemplo cuan-

do se abren diálogos que toman el foco superponiéndose a la actividad.

El método llamado para la transición hacia la pausa es onPause().

También puede detenerse una actividad, una actividad está detenida

cuando no es visible en la pantalla, pero aún se encuentra en memoria

y en cualquier momento puede ser reanudada. Cuando una aplicación

es enviada a segundo plano se ejecuta el método onStop(). Al reanudar

la actividad, se pasa por el método onRestart() hasta llegar al estado

de ejecución y luego al de reanudación. Por último, cuando la actividad

ya no existe en memoria se encuentra en estado de destrucción. Antes

de pasar a destruir la aplicación se ejecutará el método onDestroy().

22

2.2. ANDROID EN SMARTPHONES

Figura 2.5: Empleo Intents

Intents: Son mensajes que se envían de un componente a otro o de una

aplicación a otra con la �nalidad de utilizar otras actividades, servicios

o Receivers. Podemos distinguir los intents explícitos de los implícitos.

Son explícitos cuando se entregan a un componente en especí�co y son

implícitos cuando sólo se entrega una referencia genérica sobre alguna

condición, presentando aquellas entidades que cumplan ese requisito

como candidatas para la tarea. En la Figura 2.5, se puede observar

como una Activity envía un Intent implícito el cual es tomado por

otras dos Activitys y pueden o no ejecutarse dependiendo del Intent

enviado.

Service: Un servicio es una entidad que ejecuta instrucciones en segun-

do plano sin que el usuario lo vea en la interfaz. Son muy utilizados

para realizar acciones de larga duración mientras las Activitys mues-

tran otro tipo de información. Un ejemplo claro del uso de servicios

es el de un reproductor de música. La reproducción se iniciará desde

una actividad pero la música se debe de seguir escuchando cuando el

usuario utilice otras aplicaciones. Existen dos tipos de servicios aquellos

que se inician explícitamente a través del método startService(), y el

que se liga con bindService() (Bound Service), este método devuelve un

objeto IBinder que de�ne la interfaz que los clientes pueden usar para

interactuar con el servicio y de esta forma permite que componentes

(como las actividades) se vinculen a un servicio, manden peticiones, re-

ciban respuestas, y realicen comunicaciones inter-procesos (IPC). Este

tipo de servicio solamente existe mientras sirve a un componente de

una aplicación y no se ejecuta inde�nidamente en un segundo plano. El

servicio invocado de forma explícita realiza una operación determinada

y se cierra al momento de �nalizar. Por otro lado, un bound service

23

2.2. ANDROID EN SMARTPHONES

depende de la vida del elemento al que fue ligado. A su vez, este últi-

mo puede compartir datos, realizar operaciones en conjunto y una gran

variedad de interacciones posibles.

Figura 2.6: Ciclo de Vida Service

Los servicios también tienen un ciclo de vida similar al de las activida-

des (Figura 2.6), pero con menor cantidad de estados (sólo comprende

los estados de Creación, Ejecución y Destrucción).

Content Provider: Un Content Provider es una interfaz que permite

intercambiar información persistente y estructurada entre dos aplica-

ciones. Cada aplicación tiene protegida su información de modo que

están aisladas de los contextos de otras aplicaciones. Una aplicación

24

2.2. ANDROID EN SMARTPHONES

Figura 2.7: Content Provider

que desee que todo o parte de la información que almacena esté dispo-

nible de una forma controlada para el resto de aplicaciones del sistema

deberá proporcionar un Content Provider a través del cuál se pueda

realizar el acceso a dicha información (Figura 2.7). Por defecto, la API

de Android trae consigo Content Providers prede�nidos para intercam-

biar información de audio, vídeo, imágenes e información personal. Pero

si en algún momento se desea intercambiar información con una estruc-

tura personalizada, se debe desarrollar la propia subclase heredada de

la clase ContentProvider.

Broadcast Receiver: Un BroadcastReceiver es un componente Android

que permite el registro de eventos del sistema operativo y también a

eventos producidos por otras aplicaciones. Todos los Receivers que son

registrados para un determinado evento son noti�cados por Android

cuando estos eventos ocurren. Con el componente BroadcastReceiver, es

posible capturar eventos como aviso de batería baja, un SMS recibido,

un SMS enviado, una llamada, un aviso de de la tajea SD, etc. Un

componente de tipo BroadcastReceiver debe ser registrado como un

receptor de eventos en la aplicación. Puede verse como un Listener que

25

2.2. ANDROID EN SMARTPHONES

Figura 2.8: Android Manifest

atiende a eventos del sistema o bien a eventos lanzados por aplicaciones.

Además, el evento puede incluir información adicional en un Intent. Por

lo tanto, es un componente que permite integrar aplicaciones entre sí .

AndroidManifest: es un archivo de con�guración donde se aplican las

con�guraciones básicas de una aplicación Android (Figura 2.8). Este

archivo contiene información esencial sobre el sistema Android com-

patible con la aplicación, necesaria para ejecutar cualquier aplicación.

En este archivo XML, se especi�can las Activitys utilizadas, Intents,

BroadcastReceiver, ContentProvider, bibliotecas, nombre de la aplica-

ción, hardware mínimo para la ejecución de la aplicación, permisos de la

aplicación, etc. Es un elemento esencial ya que se encarga de de�nir un

gran número de preferencias y condiciones para que un proyecto pue-

da funcionar correctamente en un smartphone o tablet con el sistema

operativo de Google.

2.2.1. Consumo de batería

Desde las primeras versiones de Android, el consumo de batería por parte

de los dispositivos móviles es un factor esencial a tener en cuenta a la hora de

26

2.2. ANDROID EN SMARTPHONES

desarrollar aplicaciones e incluso cuando se desarrolla el sistema operativo.

Por ejemplo, cuando el teléfono está con la pantalla apagada, algunas apli-

caciones solicitan activarse para realizar determinadas tareas, y lo usual es

que una vez que �nalice esta rutina el smartphone vuelva al modo de ahorro

de energía. El modo de ahorro de energía es una función útil y necesaria pa-

ra el funcionamiento óptimo del teléfono móvil. Sin embargo, algunos de los

procesos que más batería consumen son propios del sistema operativo como

aquellos que utilizan la pantalla de forma inadecuada, procesos que utilizan

los sensores como wi-� o 3G, actualizaciones de Google Play o la forma en

que se obtiene la localización del dispositivo. Por esto, Google viene desarro-

llando para las últimas versiones del sistema operativo mejoras sustanciales

para mejorar el consumo energético. Un ejemplo es el proyecto Volta , que se

centra en reducir el consumo energético de algunos de los componentes del

smartphone, como por ejemplo wi-�, bluetooth, GPS, etc. A su vez, también

tiene en cuenta una mejor plani�cación de las tareas para que el consumo

sea más e�ciente, entre otras características. Aunque en las últimas versiones

de Android estas características fueron implementadas, la cantidad de dis-

positivos es heterogénea y hace de esta una tarea compleja. Es decir, cada

fabricante tiene distintos componentes de hardware y el comportamiento de

estas mejoras no es fácil de aplicar haciendo que las mismas no sean sig-

ni�cativas en alguna de estas con�guraciones de hardware. Por otra parte,

las aplicaciones de usuario muchas veces no tienen en cuenta el consumo

energético como atributo no funcional, provocando un uso inadecuado de la

batería por constantes actualizaciones que afectan el rendimiento del equipo.

Como consecuencia se han desarrollado aplicaciones que tienen por objetivo

principal corregir el consumo de energía desmedido por parte de sus pares.

En el año 2015 se realizaron diversos estudios para determinar qué aplica-

ciones populares son la que más energía consumen. Facebook, Spotify, Waze

y Google Maps, entre otras, fueron algunas de las que lideraron los distintos

rankings realizados (Figura 2.9)2. Esto es el resultado de aplicaciones mal di-

2AVG Technologies, Games, Music and Shopping Apps Hit SmartphonesHardest , Amsterdam and San Francisco, 24-02-2015(http://now.avg.com/wp-content/uploads/2015/02/avg_android_app_performance_report_q4_2014.pdf)

27

2.2. ANDROID EN SMARTPHONES

Figura 2.9: AVG Report

28

2.3. TRABAJOS RELACIONADOS

señadas o inconvenientes como frecuencia de sincronización demasiado alta,

consumo de CPU por tiempos prolongados (wakelock) que le impiden al dis-

positivo entrar en modo ahorro de energía, etc. Algunos de estos problemas se

han solucionados en versiones posteriores de cada aplicación, aunque pueden

existir casos extremos en los que es imposible mejorar el consumo debido a

que el diseño principal ya es inadecuado y se debería volver a realizar tenien-

do en cuenta el recurso energético. Otro factor importante en el consumo de

energía es la publicidad. Muchas de las aplicaciones que son ejecutadas en el

sistema operativo Android son gratuitas y �nanciadas mediante publicidad,

la cual ocupa espacio y se renueva periódicamente en la pantalla, generando

un consumo adicional para la aplicación. Es decir que la publicidad, además

de consumir energía por el uso de pantalla, obliga a la aplicación a buscar

una nueva publicidad para lo cual es necesaria una conexión a datos. En mu-

chos casos el consumo energético por parte de la aplicación es mucho menor

que el consumo de la suma de las tareas que son necesarias para la descarga

de la publicidad (elección de publicidad, descarga y muestra de la misma)

por lo cual es necesario evaluar también el costo de agregar características

adicionales como publicidad a la hora de desarrollar una aplicación.

Por lo mencionado anteriormente, hace varios años que el consumo de

energía en dispositivos móviles es motivo de investigación a medida que nue-

vas tecnologías y capacidades van surgiendo. Esto posibilitó que hayan apa-

recido soluciones al problema y se lograra optimizar el funcionamiento de

dichos dispositivos. Sin embargo, reportes como el de AVG demuestran que

aún existen aplicaciones que hacen un uso excesivo de la batería y que estas

aplicaciones deben mejorar todavía más en cuanto a consumo de energía.

2.3. Trabajos Relacionados

En los últimos años se ha tratado de optimizar el consumo de batería

de las aplicaciones Android. Muchas investigaciones han surgido para tra-

tar este tema desde diferentes puntos de vista, realizando distintos tipos de

pruebas y obteniendo resultados importantes para la comunidad cientí�ca.

El propósito de esta sección es hacer una breve descripción de algunas de

29

2.3. TRABAJOS RELACIONADOS

estas investigaciones que sirvieron de guía para el presente trabajo y que en

menor o mayor medida se relacionan con el mismo.

2.3.1. Who Killed My Battery

Cuando navegamos por la web en nuestro smartphone anhelamos que la

experiencia sea igual a la que tendríamos con una computadora de escritorio.

Desafortunadamente eso es imposible, dado que estos dispositivos móviles

tienen muchos menos recursos para ser utilizados. El trabajo Nicoara [2012]

presentado en el año 2012 midió el consumo de energía en smartphones que

acceden a los sitios web más populares tales como Gmail, Amazon, Picasa,

Apple, Facebook, etc., para luego hacer recomendaciones sobre diseño de pá-

ginas con el �n de minimizar la energía necesaria para descargar dicha página

en el dispositivo móvil. Este documento se justi�ca indicando el inminente

crecimiento del trá�co en Internet por parte de los navegadores móviles y de

que muchos sitios proveen una versión móvil de estos. Sin embargo, los sitios

web están pobremente optimizados y la navegación a través de ellos consume

más energía de lo necesario. Por ejemplo, se especi�ca que el uso de forma-

tos GIF o PNG consume mucho mas batería que el formato JPEG. Como

conclusión del trabajo se puede inferir una nueva dimensión para evaluar el

diseño de paginas web en navegadores móviles y ayudar a los desarrolladores

a crear código más e�ciente en cuanto a energía. Por ejemplo, en Nicoara

[2012] se muestra como modi�cando scripts de la pagina de Wikipedia para

móviles se redujo un 30% el consumo de energía sin cambiar la experiencia

del usuario. De esta manera se muestra que existen formas de optimizar el

consumo de batería, pero no siempre son utilizadas.

2.3.2. Evaluating Android best practices for performan-

ce

Como se mencionó anteriormente, no es nuevo querer medir la performan-

ce del código Android. Aline Rodrigues Tonini [2013] se centra en las mejores

prácticas propuestas por Google a nivel de código, incluyendo el análisis del

30

2.3. TRABAJOS RELACIONADOS

impacto de éstas prácticas en aplicaciones reales. Para realizarlo, se tomaron

dos de esas prácticas: la sentencia for y la obtención/modi�cación de datos

mediante getters/setters. A ambas se las desarrolló de forma tradicional y

luego de forma optimizada para poder medir el tiempo de CPU que cada

una requería. De esta manera, si una aplicación consume menor tiempo de

procesamiento se in�ere que el consumo de batería de la aplicación es menor.

Las conclusiones de este trabajo dejaron en claro que las optimizaciones pro-

puestas mejoran el tiempo necesario para ser procesadas. Usar una aplicación

sin getters es 2.93 veces más rápido que una aplicación que sí los tiene, y el

uso de la sentencia for optimizada es un 25% más rápida que la tradicional.

2.3.3. Refactorizaciones para kernels computacionales

cientí�cos en dispositivos móviles

Alejandro Zunino [2013] obtiene un conjunto de buenas prácticas que mi-

nimizan el consumo de batería. A su vez, se investiga sobre el problema en el

contexto de kernels computacionales en aplicaciones cientí�cas. A partir de

una serie de micro-benchmarks se realizan mediciones de batería para distin-

tas propuestas de refactorización o mejoras en el código Android para luego

realizar el análisis en aplicaciones reales. Los micro-benchmarcks se centra-

ron en creación de objetos, obtención de datos, copia de arreglos, recorrido

de matrices, manejo de Strings, operaciones aritméticas, manejo de excep-

ciones, acceso a atributos y uso de tipo de datos primitivos. Los resultados

obtenidos indican, por ejemplo, que se obtuvo una mejora de un 20% para

la copia de arreglos utilizando bibliotecas, un 116% en el recorrido de ma-

trices por �la y no por columna, 78023% aproximadamente para el uso de

la clase StringBuilder por sobre el uso de la clase String en la concatenación

convencional. En cuanto a tipos de datos primitivos, int favorece el consumo

de energía entre un 186% y un 50% por sobre otros tipos de datos con mayor

precisión. Por otro lado, el uso de excepciones degrada el consumo un 9471%

sobre el no uso de las mismas. En cuanto al acceso de atributos, obtener una

variable de forma directa es 696% más e�ciente que realizando un método

get. Por último para la creación de objetos se obtuvo una mejora de 812%

31

2.3. TRABAJOS RELACIONADOS

reutilizando los mismos, aunque estotambién dependerá del tipo de objeto

reutilizado. De esta manera se pudo con�rmar que los micro-benchmarks con

peor performance son los que consumen mayor porcentaje de batería. Por lo

tanto prever un código con menor tiempo de ejecución a la hora de desarro-

llar una aplicación es enérgicamente e�ciente ya sea aplicando una o varias

de estas mejoras.

2.3.4. Measuring mobile phone energy consumption for

802.11 wireless networking

Rice and Hay [2010] hace hincapié en el consumo energético de los dis-

positivos móviles conectados a una red 802.11 wireless. En este trabajo se

investiga el costo energético de distintos smartphones cuando estos se conec-

tan a una red 802.11 y envían mensajes a través de esta. En esta investigación

se facilita la obtención del consumo de energía de las aplicaciones utilizan-

do una plataforma de medición que permite observar aspectos particulares

del desarrollo móvil con una granularidad �na. Por ejemplo, el consumo de

energía del dispositivo móvil mientras trata de conectarse a una red wi-�

para obtener su dirección IP, el envío de datos a través de la red o el uso

de bu�ers para el envío de dichos datos. Un resultado importante obtenido

en esta investigación se resume en que enviar un solo paquete con una gran

cantidad de datos no favorece al consumo de energía para algunos de los

smartphones seleccionados de las pruebas, como así también una considera-

ción secundaria como la elección del tamaño de los bu�ers de envío puede

tener un gran impacto en el consumo energético. Se obtuvo en los resultados

de los tests que los criterios para minimizar el consumo de energía varían

de acuerdo al dispositivo, sistema operativo y escenario particular. No todos

los smartphones seleccionados obtuvieron la misma conclusión. Por ejemplo,

en el caso del tamaño de los paquetes enviados, el smartphone Nexus se ve

bene�ciado a medida que el tamaño del paquete se incrementa, mientras que

para el HTC G1 y otros, el resultado encontrado es el inverso. En el caso

de la obtención de conexión a la red, la mayoría de los dispositivos obtuvo

una mejora con�gurando la dirección IP estática del dispositivo, aunque en

32

2.3. TRABAJOS RELACIONADOS

el caso del Nexus esta fue mínima. Como conclusión general se muestra que

aparentemente pequeñas decisiones pueden tener un impacto signi�cativo en

el consumo de energía. Además, se puso en evidencia la gran heterogeneidad

de los dispositivos y cómo una optimización tiende a variar de acuerdo a los

componentes que integran el smartphone.

2.3.5. An Automatic Detector of Energy Leaks for Smartp-

hone Applications (ADEL)

Este trabajo presenta una evaluación del impacto de las fugas de energía.

Las fugas de energía se producen cuando secciones de código de una apli-

cación no realizan tareas productivas Zhang et al. [2012], es decir, cualquier

consumo de energía que no cambia el estado del dispositivo o no produce un

resultado directo o indirecto (es decir que es un resultado que no es percibi-

do por el usuario), es desperdicio de batería, por lo tanto eliminando estas

secciones de código no alterarán el funcionamiento de la aplicación. En esta

investigación se propone una herramienta para detectar este inconveniente en

las aplicaciones que ejecutan en smartphones. ADEL es una extensión de la

plataforma Android que rastrea el �ujo de información de la red a través de

aplicaciones, es decir, detecta los problemas de fuga de energía en las comu-

nicaciones de red para aplicaciones. Lo que hace es agregar automáticamente

una etiqueta con un tag a cada objeto descargado y se realiza un seguimiento

de cada tag y de su propagación. De esta manera, la salida del sistema arroja

una asociación de los datos descargados que in�uyeron en el funcionamiento.

La herramienta provee a los desarrolladores el conocimiento de los tiempos

de llegada y el contenido de paquetes, permitiendo observar los defectos en

el diseño que producen una perdida de energía. ADEL es una herramienta

que detecta y aísla las fugas de energía resultantes de comunicaciones de red

mediante el trazado directo o indirecto del uso efectivo de los datos recibi-

dos. Para las pruebas se utilizaron 15 aplicaciones de las cuales se detectaron

4 causas principales que generan las fugas de energía: mala interpretación de

callbacks en APIs, mal diseño en el esquema de descarga, descargas repetidas

y fetching agresivo. Con el uso de la herramienta se logró identi�car fugas de

33

2.3. TRABAJOS RELACIONADOS

energía en 6 de las 15 aplicaciones y, la eliminación de éstas resultaron en una

reducción media del 56,5% en el consumo de energía debido a la red. Este

estudio revela 4 inconvenientes de fuga de energía que usualmente se pueden

encontrar, ayudando a los desarrolladores a tener una mayor conciencia sobre

éstos y a mejorar el diseño de las aplicaciones móviles para evitarlos.

2.3.6. Analysis of Di�erential Synchronisation's Energy

Consumption on Mobile Devices

En este trabajo se evalúa el consumo de batería del algoritmo de sincroni-

zación diferencial (di�sync) en dispositivos móviles, Simon et al. [2016]. Las

lecturas y escrituras en elementos compartidos son la clave de la funcionali-

dad en software colaborativo como SVN o Google Docs. Debido a las nuevas

velocidades de Internet, cada vez más dispositivos móviles pueden acceder

a este tipo de software. Sin embargo, las aplicaciones en estos dispositivos

deben tener en cuenta una característica especial: el consumo de energía. Es-

te trabajo surge del uso real sobre la edición de documentos PDF de forma

colaborativa, en donde el elemento compartido puede ser subrayado, se le

puede agregar notas, etc, entre un grupo de usuarios y utiliza el algoritmo

di�sync funcionando en tiempo real. Bajo este esquema se detectaron 3 áreas

en donde se pudo mejorar la e�ciencia de energía: ciclos vacíos en los cuales

ningún cambio necesita ser procesado, la energía de la cola de envío de datos

(intervalos entre ciclos) y la complejidad computacional. En el caso de los

ciclos vacíos, ocurren cuando el algoritmo di�sync se ejecuta en intervalos

regulares en los cuales no se obtiene ningún dato actualizado, generando un

desperdicio de energía. La energía de la cola hace referencia al tiempo en que

las distintas conexiones permanecen activas una vez �nalizada una conexión a

datos. Esto puede consumir cerca de un 60% de la energía de una conexión a

red haciendo que sea mas e�ciente realizar una transferencia inmediatamente

cuando termina la anterior o que el tamaño del intervalo sea lo su�cientemen-

te mayor para no generar desperdicio de energía constantemente. Por último

la complejidad computacional se relaciona directamente con el consumo de

energía del CPU y el uso de la misma. Con estas consideraciones, se llegó a

34

2.3. TRABAJOS RELACIONADOS

la conclusión de que hay que evitar los ciclos vacios, los intervalos de ciclos

deben ser ajustados dependiendo de la conexión y, �nalmente, el procesa-

miento de items pequeños reduce la complejidad computacional, por lo tanto

reduce el consumo de energía. En las pruebas realizadas para mejorar los in-

convenientes analizados se obtuvo una mejora general. Para los ciclos vacios,

se encontró que en un 96% se producía este inconveniente, por lo que se opto

por realizar una solución Push la cual utiliza un promedio de 0.398% de la

batería contra 8.151% en 7 minutos de la propuesta convencional y elimina

los ciclos vacios. El impacto de la complejidad computacional se puede re-

ducir con la correcta elección de la estructura de datos y para los problemas

de energía desperdiciada luego del envío de datos, se logró comprobar que

para un ciclo �jo, un intervalo de 6 segundos es el mas óptimo para todos

los tipos de redes (3G, GSM). De esta forma se logró detectar 3 tipos de

inconvenientes en los algoritmos de sincronización diferencial en tiempo real,

como así también una solución para cada uno de ellos y lograr una mejora

en el consumo de energía en una futura implementación del mismo.

2.3.7. Reducing Battery Consumption of Data Polling

and Pushing Techniques on Android using Gripe

Debido a la cantidad limitada de la batería, existe la necesidad de obtener

una manera que pueda ayudar a reducir el consumo de batería Boonkrong and

Dinh [2015]. Polling y Push son dos técnicas utilizadas por los dispositivos

móviles para obtener o enviar información desde Internet. Este paper plantea

el uso de la compresión conocida como Gripe aplicada a los datos antes

de ser enviados por el dispositivo móvil Android. Esta técnica utiliza una

variación del algoritmo LZ77 que funciona mediante la búsqueda de cadenas

duplicadas en los datos. La segunda aparición y las subsecuentes de una

cadena se sustituye entonces por un puntero a la primera ocurrencia. Por

otra parte, se aplica Codi�cación Hu�man con el �n de asignar códigos más

cortos. Debido a esto, Gripe ofrece un tamaño de archivo más pequeño como

consecuencia. En las pruebas realizadas, este formato de compresión logró

reducir en un 73% aproximadamente el tamaño de los datos para enviar

35

2.3. TRABAJOS RELACIONADOS

por algunas de las dos técnicas. En cuanto al envío de datos, en general

la propuesta de mensajes Push después de la compresión mejora el 31,5%

de la batería , mientras que en la propuesta Polling el 65.6%. Además, al

realizar el método de compresión el tiempo para agotar la batería es más

largo,es decir, la vida de la batería del dispositivo cuando se utiliza el método

Polling con la compresión Gzip se incremento cerca del 190% y en el caso de

mensajes Push un 46%. Estos resultados muestras que la compresión Gripe

es una alternativa posible y efectiva de mejorar el consumo de batería. Es

una técnica que acompaña a las propuestas de Push/Polling mejorando el

rendimiento energético de estas y, es una buena opción a tener en cuenta

en un futuro que se pueda optar por probar otros tipos de compresión para

comparar cual de estos mejora el rendimiento de las tácticas.

2.3.8. An Investigation into Energy-Saving Program-

ming Practices for Android Smartphone App De-

velopment

Li and Halfond [2014] considera el ahorro de batería del uso de las co-

di�caciones sugeridas en el sitio o�cial de desarrolladores de Android. Estas

se dividen en tres categorías: uso de la red, consumo de memoria y practi-

cas de programación a bajo nivel. La primer categoría hace referencia al uso

de HTTP request desdes los dispositivos móviles para la navegación por la

Internet. Estos request consumen un gran porcentaje de energía, por eso el

objetivo de este papear es mostrar una guía para el uso y diseño de estos.

La segunda categoría se estudia especí�camente si el consumo de memoria

esta ligado fuertemente con el gasto de batería, es decir, cuento mas memoria

consume una aplicación mayor será su consumo de energía. Sin embargo, el

uso de memoria insu�ciente puede causar un efecto no deseado y aumentar

el consumo de energía, por lo que es necesario saber cual es la cantidad de

memoria ideal. Por ultimo, la tercer categoría considera si los tips propues-

tos por el sitio o�cial de desarrolladores de Android, en cuanto a desarrollo,

para mejorar los tiempos de ejecución también favorecen el consumo de ener-

gía. Luego de realizar los test se logro llegar a las siguientes conclusiones:

36

2.3. TRABAJOS RELACIONADOS

En cuanto el uso de los Request, el uso de peticiones pequeñas puede ayu-

dar a mejorar el consumo de energía. Un tamaño de paquete que ronda los

100 bytes consume 0.6 mAh, mientras que paquetes de mas de 2000 bytes

tienden a 1 mAh. Si es necesario hacer varias solicitudes HTTP pequeñas,

los desarrolladores deben tratar de diseñar sus aplicaciones o protocolos para

que estas puedan ser agrupadas en una solicitud más grande para ahorrar

batería. Los resultados del experimento de memoria arrojaron que a pesar de

que es un componente importante que se debe manejar con cuidado y que

los desarrolladores deben evitar la asignación innecesaria memoria, no tiene

un gasto de energía tan importante como se pensaba. Mayor uso de memoria

aumenta sólo ligeramente la energía media del consumo de cada acceso. Para

�nalizar la tercer categoría, se analizó el acceso a campos, la invocación de

métodos y acceso a el tamaño de arreglos en ciclos. Para estas tres propues-

tas se obtuvo una mejora entre un 30% y 35% para acceso a datos, un 15%

para invocación , y �nalmente 10% respectivamente. Demostrando de esta

forma que los desarrolladores pueden mejorar el consumo de sus aplicaciones

teniendo presente estas características al desarrollar.

2.3.9. eDoctor: Automatically Diagnosing Abnormal Bat-

tery Drain Issues on Smartphones

En Ma et al. [2013] se presenta la herramienta eDoctor que detecta la des-

carga de la batería en forma anormal. Esta herramienta de�ne el concepto

de Abnormal Battery Drain como consumo de energía que no es causado por

el uso normal de una aplicación. Desde el punto de vista de los usuarios esto

se traduce en el uso normal del dispositivo pero, en un determinado punto

e inesperadamente, el dispositivo comienza a consumir mayor energía de lo

usual y como resultado en un par de horas la batería puede verse agotada por

completo. La herramienta utiliza el concepto de ejecución por fases para cap-

turar el comportamiento de una aplicación variable en el tiempo, que luego

se puede utilizar para identi�car una aplicación anormal. eDoctor también

registra eventos tales como la instalación, las actualizaciones de aplicaciones,

cambios de con�guración, etc. Aquí es critico diferenciar el uso normal de

37

2.4. CONCLUSIONES

anormal, por lo que la ejecución de una aplicación se divide en intervalos

de ejecución que luego se agrupan en fases. Cuando una aplicación empie-

za a consumir energía de una manera anormal , su comportamiento por lo

general se mani�esta como una nueva o mayor cantidad de fases que no apa-

recen durante la ejecución normal. La combinación de dicha información de

fase junto con los eventos relevante, tales como un cambio de con�guración,

pueden identi�car la aplicación culpable. Esta información es utilizada para

determinar si la aplicación ha tenido o no un comportamiento inesperado y

para sugerir la mejor solución posible. A su vez, en este trabajo, también

se hizo una medición de cuanto es el costo de tener una herramienta co-

mo esta ejecutando en el smartphone. Para realizar las pruebas se utilizaron

26 smartphones diferentes con 11 versiones diferentes de Android, en los cua-

les la herramienta detectó 47 de 50 problemas que fueron inyectados en los

dispositivos con menos de 1.5% de overhead. También se realizaron pruebas

en el mundo real con aplicaciones verdaderas en donde se encontraron proble-

mas como mal uso de un recurso (Acelerometro, GPS, sensor de orientación,

Wakelock) como así también problemas de con�guración (presición del GPS,

frecuencia de actualización). En estos casos se encontró una falencia para la

herramienta. Si una aplicación posee ABD desde el principio no será des-

cartada por eDoctor debido a que esta lo tomará como uso normal y no se

descartará hasta que ocurra una actualización de la aplicación o un cambio

de con�guración. Sin embargo, esta herramienta posee un buen porcentaje

para la detección de problemas en la mayoría de los casos.

2.4. Conclusiones

Todos y cada uno de estos trabajos intentan obtener una mejora en el

consumo de energía desde el lado del programador. La mayoría de estas

mejoras se aplican a nivel de código de la aplicación y de tener conciencia en

el diseño de la misma. Mas allá de las diferencias, el propósito del presente

trabajo es también concientizar a la comunidad de desarrolladores sobre estos

inconvenientes para lograr obtener resultados e�cientes en el desarrollo de

aplicaciones para dispositivos móviles.

38

2.4. CONCLUSIONES

En sus comienzos, sistemas operativos como Android posibilitaron el arri-

bo de un gran número de aplicaciones para los Smartphones. En el mundo de

los dispositivo móviles, Android se convirtió en uno de los sistemas operati-

vos más populares por las prestaciones que posee y por la gran portabilidad

que le permite funcionar adecuadamente en distintos dispositivos telefónicos.

A su vez, la facilidad que provee a los desarrolladores a la hora de diseñar e

implementar sus aplicaciones, lo han convertido en el más utilizado por estos.

Sin embargo, no todos estos desarrolladores logran una calidad adecuada en

sus aplicaciones porque no tienen en cuenta el consumo de energía como una

característica principal de este tipo de desarrollo, aunque puedan cumplir con

los requerimientos funcionales de las mismas. En este contexto, los usuarios se

ven afectados en el uso de sus dispositivos en el que la larga jornada diaria no

coincide con el tiempo de uso funcional de los Smartphones. Este panorama

ha llevado a un gran número de investigaciones por parte de la comunidad

cientí�ca para mejorar y corregir el modelo de e�ciencia de las aplicaciones

móviles. La mayoría de estos trabajos hacen referencia a la concientización

por parte de los desarrolladores sobre el diseño de aplicaciones móviles, co-

mo así también muestran las distintas alternativas que se poseen en este

campo. El presente trabajo realiza el mismo énfasis que las investigaciones

anteriormente mencionadas. Además, también se tmuestra a la comunidad de

desarrolladores los valores energéticos que poseen las distintas propuestas de

investigación que se pueden implementar en cuanto a ubicación y a conexión

de datos se re�ere, a forma de poder comprender mejor los problemas que

pueden surgir del uso de una u otra táctica de implementación.

39

Capítulo 3

Análisis y diseño de aplicaciones

3.1. Introducción

Este capítulo tiene como propósito general explicar el funcionamiento de

las tácticas evaluadas en este trabajo. También se analizan el desarrollo Java

para Android, las redes inalámbricas y las metodologías utilizadas durante

los experimentos.

Teniendo en cuenta que el foco del presente trabajo es estimar y com-

parar el consumo energético de diferentes tácticas de consumo de datos en

dispositivos móviles se realiza en primer lugar un análisis de las mismas. En

la Sección 2.3 se realizó una breve descripción de los trabajos que motivaron

y guiaron el presente documento, todos ellos tiene en común el análisis del

consumo de batería en dispositivos móviles con el �n de mejorar el rendi-

miento energético de las aplicaciones y servicios. En este sentido, la mayoría

de las aplicaciones móviles poseen una conexión activa para lograr el fun-

cionamiento. Por ejemplo, una aplicación de posicionamiento global recibe

la actualización del punto geográ�co en el que se encuentra un smartphone

por parte de un satélite o antena de telefonía, una aplicación de mensajería

instantánea intercambia mensajes con un servidor especí�co encargado de

administrar la comunicación entre dos dispositivos, una aplicación de correo

electrónico recibe los emails que fueron enviados al usuario, etc. Se entiende

que el consumo de energía en las aplicaciones basadas en el uso de datos se

40

3.1. INTRODUCCIÓN

realiza durante el tiempo en que se encuentra realizando una petición de da-

tos o recibiendo información de actualización. Por lo tanto, se considera que

el consumo por unidad de tiempo se calcula obteniendo la demanda de ener-

gía total en el tiempo de ejecución. A su vez, se debe tener en cuenta que este

consumo puede estar in�uenciado por diversos factores como el tamaño de

los paquetes recibidos en el dispositivo, en tipo de red inalámbrica utilizada,

etc. A continuación se presentan las características particulares de cada una

de las tácticas desarrolladas en el presente trabajo. Para esto se desarrollarán

en primer lugar las tácticas relacionadas con la sincronización de información

y luego aquellas relacionadas con geolocalización del dispositivo.

3.1.1. Polling

Una de las propuestas para sincronismo de datos es la táctica de Polling

sobre una arquitectura cliente/servidor Oluwatosin [2014] donde el cliente es

el dispositivo móvil en cuestión. Entonces, cuando una aplicación necesita

sincronizar sus datos el cliente establece una conexión con el servidor y en-

vía una solicitud para obtener la actualización deseada y el servidor entrega

al cliente los datos solicitados. Es decir, se crea una comunicación entre el

cliente y el servidor en la cual se envían los datos solicitados. Esta táctica

presenta una limitación importante ya que es el cliente quien decide cuándo

se realizan las consultas resultando quizás en consultas en falso cuando no

hay nueva información en el servidor. Además, las consultas en falso no son

el único inconveniente, ya que cualquier evento que se produce en el servi-

dor no se noti�cará al usuario hasta la próxima llamada que podría tardar

demasiado tiempo. Entonces, la elección del tiempo de espera para realizar

dicha consulta es una decisión importante de diseño de la aplicación. De es-

ta manera, si la decisión de los tiempos entre las diferentes solicitudes son

correctos, no se realizan consultas en falso y se logra un rendimiento óptimo

de la aplicación. Sin embargo, una elección de tiempo demasiado corto im-

plicaría consumo de energía signi�cativo, degradando la vida de batería del

dispositivo.

La Figura 3.1 muestra el esquema de Polling donde el cliente es un smartp-

41

3.1. INTRODUCCIÓN

Figura 3.1: Esquema de Polling

hone que envía y recibe información de un servidor. Esta información que

viaja en forma de mensajes posee una latencia que se resume en el tiempo

transcurrido desde que se realiza la petición hasta que se recibe el dato del

servidor de aplicaciones. El gasto de energía realizado por el dispositivo móvil

comienza cuando realiza la conexión mediante la solicitud y �naliza luego de

haber recibido la correspondiente respuesta para su posterior procesamiento.

Mientras la aplicación cliente se encuentra en standby esperando para rea-

lizar una nueva solicitud el consumo de energía por transferencia de datos

es nulo. Como resultado, el gasto de energía está dado por el tiempo que el

dispositivo utiliza recursos como CPU, memoria RAM, conexión WiFi, etc.

para realizar la conexión y el consumo energético durante la espera de la

respuesta donde la aplicación se encuentra activa.

3.1.2. Push

La técnica de Polling es e�ciente siempre que la solicitud obtenga un da-

to actualizado y que los datos actualizados sean capturados por el cliente

en todos los escenarios. Sin embargo, no puede asegurarse en muchos casos

ya que se debería conocer con certeza el ciclo de actualización de datos en

el servidor. Entonces, surge la táctica de mensajes Push. Esta táctica ase-

gura que, cada vez que llega un mensaje al cliente los datos recibidos han

sido modi�cados en el servidor. Su funcionamiento se basa en el concepto

de suscripción en donde la aplicación cliente establece una conexión con el

42

3.1. INTRODUCCIÓN

servidor suscribiéndose para recibir información cuando un evento ocurra (en

este caso actualización). De esta manera, cuando el servidor detecta que esta

condición se ha cumplido envía un mensaje a toda la lista de clientes intere-

sados en ese evento. En las aplicaciones que utilizan esta técnica el cliente

espera de forma pasiva el mensaje del servidor sin tener que abrir una nueva

conexión, sólo se deberá establecer nuevamente una conexión en caso de que

la aplicación sea reiniciada. De esta forma, esta alternativa ahorra el gasto

de energía de establecer la comunicación con el servidor para consultar por

los datos cada vez que los necesita, a diferencia de la táctica de Polling.

Figura 3.2: Esquema Push

Como se puede apreciar en la Figura 3.2, en este tipo de táctica el consu-

mo en el dispositivo móvil se realiza en dos momentos diferentes. El primero

ocurre cuando el smartphone realiza el proceso de suscripción al servidor, y

el segundo, cuando recibe un mensaje actualizado. Cuando ninguna de estas

actividades se realiza, el resultado del consumo de batería por actualización

de información es casi nulo.

Finalmente, este trabajo trata de determinar el consumo de batería de

las aplicaciones que necesitan consumir datos alojados en un servidor para

su funcionamiento. Sin embargo, esta no es la única forma de intercambio de

43

3.1. INTRODUCCIÓN

información entre dispositivos. Otra forma de intercambio de información son

los datos de geolocalización. Este tipo de datos permite obtener la ubicación

geográ�ca real del dispositivo mediante el intercambio de coordenadas geo-

grá�cas. El funcionamiento de los Smartphones con este tipo de tecnología

puede realizarse con alguna de las tácticas que se analizan en las secciones

siguientes.

3.1.3. GPS

Figura 3.3: Esquema GPS

Los dispositivos móviles tienen incorporados receptores de GPS, es decir,

receptores del Sistema de Posicionamiento Global. Este sistema se compone

de una red de cerca de 30 satélites que orbitan la Tierra a una altitud de

20.000 kilómetros aproximadamente. La forma en que opera este sistema es

gracias a que al menos 4 de estos satélites están visibles al dispositivo en

44

3.1. INTRODUCCIÓN

todo momento y cada uno de ellos transmite una señal sobre su ubicación

cada intervalos regulares de tiempo. Las señales son interceptadas por los

smartphones o cualquier dispositivo que posea el receptor GPS y este calcula

a qué distancia se encuentra el dispositivo de cada satélite según el tiem-

po que le tomó recibir el mensaje. Esto se repite con al menos 3 satélites

para lograr triangular las señales que determinan su ubicación. Cuanto más

satélites estén visibles para el dispositivo, mayor será la precisión de la po-

sición. Durante toda esta tarea el smartphone deberá esperar por la llegada

de una nueva señal enviada por el satélite para luego calcular la posición

exacta y mostrarla al usuario. A su vez, el dispositivo recibe información

continuamente a menos que se pierda la señal con los satélites. En este caso,

la cantidad de cálculos que el smartphone realiza más la llegada de nuevos

datos supone un consumo de energía considerable.En la Figura 3.3 se aprecia

el funcionamiento de este sistema.

45

3.1. INTRODUCCIÓN

3.1.4. Localización por red telefónica

El GPS no es la única forma de obtener la localización de un dispositivo

móvil. En el caso de los smartphones, dado que se trata de un sistema so�s-

ticado de radiocomunicaciones, existen torres con antenas o estaciones base

que se encargan de enviar y recibir señales de radio que pueden ser utilizadas

para la localización de los dispositivos, ya que la red de telefonía celular se

divide en múltiples celdas imaginarias. Es decir que en este caso se aprove-

cha la red de las compañías telefónicas utilizada para realizar llamadas para

obtener la posición del dispositivo móvil (Figura 3.4).

Figura 3.4: Esquema de geolocalización por antenas

Más detalladamente, el smartphone tiene transmisores de baja potencia

que le permiten comunicarse con la antena de la estación base más cercana.

Entonces, mientras una persona se desplaza el smartphone va cambiando de

una celda a otra en busca de señal y, utilizando estas antenas, un dispositivo

46

3.2. IMPLEMENTACIÓN DE TÁCTICAS

puede proporcionar información de su ubicación de tres formas: teniendo en

cuenta la distancia a las torres de telefonía, utilizando el tiempo que tarda

la señal en ir de torre a torre, o analizando la intensidad de la señal recibi-

da. Esta localización ocurre gracias a la multilateralización (triangulación de

antena utilizando combinación de una o mas de las tres formas de obtención

de ubicación mencionadas anteriormente) de las señales de radio entre varias

torres de radio de la red y el teléfono. Este método sin GPS es menos preciso

debido a que en muchas ocasiones la pérdida de señal o los obstáculos sobre

la misma hacen imposible su utilización. En este sentido, en sitios rurales o

remotos las torres de comunicación suelen estar más separadas y por esta

razón la señal puede ser irregular. Otros factores de interrupción de señal

son las montañas o edi�cios altos. En estos casos, el consumo de batería se

encuentra en los cálculos que realiza el dispositivo de las señales que envían

las torres de telefonía celular.

Todas y cada una de las tácticas mecionadas anteriormente utilizan el

intercambio de datos de diferentes formas. En la próxima Sección se presen-

tarán las aplicaciones que fueron utilizadas para realizar las mediciones de

consumo de batería y cómo fueron llevadas a cabo cada una de las propuestas

de intercambio de datos mediante el lenguaje Java.

3.2. Implementación de Tácticas

En las siguientes subsecciones se detallarán las implementaciones utiliza-

das en este trabajo de las tácticas previamente explicadas.

3.2.1. Servicios Web

Como se mencionó anteriormente, tanto la propuesta de Polling como

la de mensajes Push necesitan de un servidor para poder funcionar e in-

tercambiar mensajes, el mismo puede observarse en las Figuras 3.1 y 3.2.

Particularmente, en este trabajo se utiliza un servidor Apache Tomcat 6.0.39

que es un contenedor web con soporte de servlets y JSPs, las cuales son im-

47

3.2. IMPLEMENTACIÓN DE TÁCTICAS

portantes tecnologías web basadas en Java. Una de las características más

importante que posee este servidor es que fue desarrollado en Java y funciona

en cualquier sistema operativo que disponga de la máquina virtual correspon-

diente. Además, es una herramienta popular y comúnmente utilizada por la

comunidad de desarrolladores. Este servidor es utilizado para desplegar los

servicios web necesarios para lograr la comunicación y el envío de datos con

los Smartphones. Para la aplicación Push es necesario un servicio de sus-

cripción del dispositivo como así también un servicio que envíe los datos al

mismo cada un cierto tiempo y, por otro lado, la aplicación de Polling nece-

sita invocar un servicio en el servidor que le devuelva los datos solicitados.

De esta forma se realizará la transferencia de datos mientras se monitoriza

el consumo de batería de los dispositivos móviles.

En cuanto al tipo de servicios web utilizados se opta por realizar servicios

web REST Snehal Mumbaikar [2013]. Este tipo de servicios se asienta sobre el

protocolo HTTP como mecanismo de transporte de mensajes entre el cliente

y el servidor. A su vez, estos mensajes utilizan los tipos de petición de�nidos

por el protocolo para diferenciar qué operación debe realizar el servicio. Así,

el tipo de petición HTTP realizada (GET, POST, PUT o DELETE), junto

con la dirección URL especi�cada en la llamada, determinan la operación

a ejecutar por el servidor. Por otra parte, en cuanto al formato de datos

transmitidos, no se utiliza ninguno en particular. Además, una ventaja de

utilizar este tipo de servicios es que el tamaño de los paquetes que se envían

desde el servidor es más pequeño que el utilizado por otros protocolos. Por

ejemplo, SOAP está basado en XML, lo que facilita la lectura por parte de un

software de los mensajes, pero también resulta en mensajes más grandes y,

por lo tanto, considerablemente más lentos de transferir, haciendo al servicio

REST más apto para el entorno móvil donde los recursos son más limitados.

Los servicios mencionados son consumidos por las diversas aplicaciones

desarrolladas en Android. En la aplicación con comunicación basada en Po-

lling, se debe implementar un servicio GET que entrega un paquete al clien-

te, donde dicho paquete es una secuencia aleatoria con una longitud �ja de

500 caracteres que representan un texto de una aplicación de mensajería ins-

tantánea o un email enviado por una aplicación de correo electrónico. De esta

48

3.2. IMPLEMENTACIÓN DE TÁCTICAS

manera, cada vez que la aplicación cliente realice una solicitud, el servidor

creará uno de estos paquetes y se lo enviará en la respuestas.

En el caso de la aplicación de mensajes Push es necesario implementar

servicios más complejos debido a que se utiliza la tecnología GCM (Goo-

gle Cloud Messaging) de Google que será explicada en la Subsección 3.2.3.

Entonces, se debe desarrollar un servicio web para registrar al cliente como

dispositivo receptor de mensajes Push junto con un servicio para indicar que

se debe enviar un mensaje al dispositivo a través de la tecnología GCM. Este

último servicio, implica el desarrollo de un paquete idéntico al utilizado en

el servicio web de la táctica de Polling. Sin embargo, en este caso, en lu-

gar de enviar el paquete de datos al dispositivo, la información es enviada

a los servidores de Google y son estos los que se encargan de mandarlos al

Smartphone.

Una vez explicados los servicios web utilizados por las tácticas, en la

siguiente sección se explicarán las implementaciones de cada una de las apli-

caciones con las cuales se realizaran los experimentos de forma mas detallada.

3.2.2. Polling

Como ya se detalló anteriormente (Sección en la página 40), la táctica

de polling comienza su actividad en el cliente, por lo tanto, es este el que

controla los tiempos para realizar la conexión con el servidor y realizar la

petición de información. En la implementación del presente trabajo se busca

aislar la mayor cantidad de funcionalidad posible; es decir que, se desarrolló

una aplicación que sólo realiza la comunicación con el servidor sin introdu-

cir funcionalidad extra. De esta forma las mediciones de consumo de batería

por la comunicación son más precisas dado que se obtiene la información del

consumo de batería necesario para llevar a cabo esta comunicación sin ta-

reas adicionales que introducirían ruido en los experimentos. En de�nitiva, la

aplicación sólo contiene un botón que desencadena la conexión con el servi-

dor, realiza su correspondiente solicitud y recibe la respuesta de este. Luego,

la aplicación espera un tiempo �jo (2 segundos) para realizar la siguiente

petición.

49

3.2. IMPLEMENTACIÓN DE TÁCTICAS

En el diseño de la aplicación es importante tener en cuenta que desde la

versión 3 de Android no se permite realizar operaciones de larga duración

dentro del hilo principal de una actividad debido a que esta situación blo-

quearía al resto de los componentes. Como este sistema operativo posee un

plani�cador de CPU agresivo, cierra aquellas aplicaciones que realizan opera-

ciones de larga duración en su hilo principal, evitando su correcta �nalización.

Para solucionar esta limitación la aplicación llama a un servicio encargado

de realizar las tareas. A su vez, como podemos ver en las Figuras 3.6 y 3.5,

también se utilizan bibliotecas (org.apache.http) para establecer la conexión

con el servidor descripto anteriormente con la intención de minimizar el con-

sumo de batería Rodriguez et al. [2016]. En este caso se realiza la petición

de datos mediante el método GET previamente explicado. Adicionalmente,

como en cualquier aplicación Android, es importante de�nir los permisos ne-

cesarios para el funcionamiento de la misma, los cuales deben agregarse en

el archivo Manifest de la aplicación. Para este caso el permiso necesario es el

que permite la conexión a Internet (android.permission.INTERNET ).

50

3.2. IMPLEMENTACIÓN DE TÁCTICAS

Figura 3.5: Diagrama de Clases Poll

Figura 3.6: Conexión al servidor

3.2.3. Mensajes Push

En esta táctica se utiliza la tecnología GCM de Google para desarrollar

mensajes push. Esta tecnología introduce un intermediario en la comunica-

ción: un servidor de mensajería que se sitúa entre el servicio web que envía los

datos (3.2.1) y la aplicación cliente. Este servidor intermediario se encarga de

recibir las noti�caciones del servicio web y hacerlas llegar a las aplicaciones

51

3.2. IMPLEMENTACIÓN DE TÁCTICAS

Figura 3.7: Esquema GCM

móviles instaladas en los dispositivos clientes, cambiando el camino que rea-

lizan los paquetes, ya que no se realiza el intercambio de forma directa con

el servidor de aplicaciones. Esta tecnología funciona de la siguiente manera

(Figura 3.7):

1. La aplicación Android debe registrarse en los servidores GCM como

cliente capaz de recibir mensajes desde dicho servicio.

2. Se recibe un código de registro (Registration ID) que la aplicación clien-

te deberá conservar como identi�cador.

3. La aplicación cliente envía a la aplicación servidor el código de registro

GCM recibido (identi�cador único del cliente en el servidor). Utilizando

este código, la aplicación servidor puede indicar el dispositivo móvil

concreto al que desea enviar un mensaje.

4. El último paso es el envío de un mensaje desde el servidor hasta un

cliente determinado. Esto se hace a través del servidor GCM (paso 4.1)

y desde éste se dirige al cliente concreto que debe recibirlo (paso 4.2).

Lo primero que se debe realizar en el desarrollo es el registro de la apli-

cación con los servicios GCM de Google, que no aparece en la Figura 3.7 por

52

3.2. IMPLEMENTACIÓN DE TÁCTICAS

ser el paso previo de con�guración del servicio. Esta registración implica ob-

tener una API key y un identi�cador para la aplicación. Para esto se ingresa

a la consola de APIs de Google con una cuenta de email y se crea un nuevo

proyecto del que se obtiene un número que identi�ca a nuestra aplicación de

envío de mensajes, la cual debe ser activada desde la consola de servicios que

provee Google. Esta plataforma proporcionará diferentes formas de identi-

�cación remota ante sus servicios, una de ellas es llamada API key la cual

también se obtiene del menú de API access y será enviada con cada mensa-

je a los servidores de Google. Una vez �nalizada la etapa de con�guración

del servicio, lo siguiente es realizar la con�guración pero de la aplicación An-

droid. Como GCM es un servicio externo al desarrollo, es necesario descargar

la biblioteca para su implementación (Google Cloud Messaging for Android

Library).

El siguiente paso es realizar la implementación de la aplicación cliente

propiamente dicha. Esto se puede dividir en dos etapas: la primera, de registro

con los servidores de Google y al servidor de aplicaciones encargado de enviar

los mensajes al dispositivo y, la segunda, de implementación de los métodos

necesarios para recibir los mensajes. El primer paso es el más sencillo, y se

puede implementar con un botón en la aplicación cliente que envía al servidor

GCM de Google una petición de registro y a nuestro servidor de aplicaciones

que contiene los servicios web mencionados en la Sección 3.2.1. Al igual que

en la táctica de Polling, en la actividad principal de la aplicación cliente no

se pueden ejecutar tareas de larga duración por lo cual se realiza un thread

asíncrono para el registro en los servidores correspondientes. El botón envía

al servidor GCM el registro en conjunto con el id de la aplicación previamente

creada y, a su vez, se registra en el servidor de aplicaciones Tomcat (que es

el encargado de enviarle los mensajes cuando la información pertinente a la

aplicación se actualiza) a modo de registrarse como aplicación consumidora.

Este último registro es el consumo de un servicio en el servidor (Figura 3.9)

pero enviándole el id del dispositivo. El registro con el servidor de Google lo

provee la propia biblioteca de servicios GCM (Google Cloud Messaging for

Android Library), lo que facilita su codi�cación.

53

3.2. IMPLEMENTACIÓN DE TÁCTICAS

Figura 3.8: Diagrama de clases Push

Figura 3.9: Registro en servidor de aplicaciones

Para recibir mensajes en la aplicación cliente se deben implementar un

BroadcastReciver y un IntentService que es el encargado de procesar los men-

sajes. De esta forma se delegará toda la lógica de la aplicación al IntentServi-

54

3.2. IMPLEMENTACIÓN DE TÁCTICAS

ce. El BroadcasrReceiver será encargado únicamente de recibir los mensajes,

para lo cual recibe el identi�cador del registro y las noti�caciones emitidas

por el servidor Tomcat. Además, el BroadcastReciver también es implemen-

tado por las bibliotecas de Google y debe ser registrado en el Manifest de la

aplicación Android, como se muestra en las Figuras 3.10 y 3.8.

Figura 3.10: GCMBroadcastReceiver

En el caso del servicio de mensajería en el cliente debe ser implementado

por el desarrollador extendiendo la clase com.google.android.gcm.GCMBaseIntentService,

y debe sobrescribir los siguientes métodos:

onRegistered : Método invocado al recibir el identi�cador único asignado

por el servidor GCM. Este id es enviado al servidor de aplicaciones que

administra las noti�caciones.

onUnregistered : Método invocado después de que el dispositivo ha si-

do dado de baja en el GCM. Este método realizará tareas necesarias

indicadas por el desarrollador en caso de que la aplicación cliente in-

dique a los servidores que no desea recibir más noti�caciones de un

determinado evento.

onMessage: Se ejecuta al recibir un nuevo mensaje. Cada vez que el ser-

vidor GCM envíe un nuevo mensaje, esta porción de código se ejecutará

y se recibirá en forma de Intent el contenido de dicho mensaje.

onError : Método que gestionará los errores al realizar un alta o baja

del dispositivo.

Los métodos enumerados son invocados por el componente GCMBroadcas-

tReceiver registrado anteriormente. De todos ellos, el más destacable para el

55

3.2. IMPLEMENTACIÓN DE TÁCTICAS

caso es el onMessage ya que este es invocado varias veces y, por lo tanto,

la frecuencia con la que se lo invoque determina el consumo de energía. Por

último, se debe registrar el servicio en el Manifest de la aplicación Android. A

su vez, en el desarrollo de la aplicación es necesario declarar algunos permisos

adicionales: INTERNET, que le dará acceso a la aplicación; RECEIVE que

permite que la aplicación se registre, y por ultimo, C2M_MESSAGE permi-

te que la aplicación cliente sea capaz de recibir los mensajes enviados por los

servidores de Google (Figura 3.11).

Figura 3.11: Permisos GCM

3.2.4. Localización GPS

Android posee una biblioteca dedicada a los servicios de localización (an-

droid.location.LocationManager). Esta biblioteca provee una gran cantidad

de funcionalidad útil para obtener los proveedores de localización del disposi-

tivo. Las aplicaciones que son utilizadas para la geolocalización están basadas

en los mismos conceptos y es por eso que existen bibliotecas que evitan escri-

bir porciones de código para realizar localización (Figura 3.12). Generalmente

estas aplicaciones se componen de la subscripción de un listener a los eventos

de las redes inalámbricas.

56

3.2. IMPLEMENTACIÓN DE TÁCTICAS

Figura 3.12: Diagrama de clase Geolocalización

Para la aplicación de geolocalización por GPS se utiliza la suscripción

a LocationManager.GPS_PROVIDER que hace referencia al servicio de lo-

calización mediante satélites, como se explicó en la Sección 3.1. La biblio-

teca LocationManager posee acceso a todos los servicios de localización y

GPS_PROVIDER es la constante que hace referencia a la obtención de da-

tos desde los proveedores de localización satelital. Siempre que el sensor GPS

del dispositivo esté activado se pueden empezar a recibir los datos de localiza-

ción aunque existen algunos inconvenientes debido a que en Android no hay

ningún método �obtener posición actual�. Sin embargo, la manera de utilizar

estos servicios es a través de la obtención de la última posición conocida.

Este funcionamiento se debe a que el dispositivo puede perder señal de los

satélites imposibilitando la conexión directa con los mismos por un tiempo

prolongado. De esta forma, el dispositivo mantiene guardado el último punto

geográ�co en donde se encontró y del cual poseía señal. Es necesario un liste-

ner de localización que esté esperando cambios de posición del smartphone.

Entonces, cuando el dispositivo obtenga señal satelital Android le indicará al

listener que se ha recibido una nueva posición geográ�ca y podrá ser consul-

57

3.2. IMPLEMENTACIÓN DE TÁCTICAS

tada por la aplicación. De esta forma se puede inferir que la cantidad de veces

que el listener es invocado impacta directamente en el consumo de batería,

es decir que a mayor cantidad de puntos geográ�cos recibidos el consumo de

energía aumenta.

Figura 3.13: Subscripción location listener

En la Figura 3.13 se muestra el método onLocationChanged que es llama-

do cada vez que ocurre una lectura en el GPS. También se muestra cómo se

suscribe el Listener a las actualizaciones del LocationManager. En este caso,

el parámetro 2 que se corresponde con el tiempo que se desea entre actua-

lizaciones del sensor y el parámetro 3, que se corresponde con la distancia

recorrida entre las mismas, serán 0. De esta manera, cada vez que el sen-

sor obtiene información es transferida al listener inmediatamente para que la

aplicación pueda actualizar la información necesaria.

Por la naturaleza de este tipo de aplicaciones no se puede obtener una

medición del consumo de batería con hardware especí�co debido a que este

necesita estar conectado a la red eléctrica para su funcionamiento y, pa-

ra lograr cambios en el sensor de GPS o cualquier sensor de localización, es

necesario que el dispositivo este en movimiento. Para solucionar este inconve-

niente se utiliza la medición de consumo por software provista por el sistema

operativo. Android posee un servicio para obtener los niveles de batería por

software mediante una biblioteca (android.os.BatteryManager). Para la uti-

lización de este servicio también es necesario subscribirse con un listener a los

eventos de cambio de batería, es decir, cuando ocurre un cambio en el nivel de

esta se noti�ca a una aplicación las variaciones ocurridas. Se pueden observar

en la Figura 3.14 la declaración del Receiver batteryReceiver encargado de

58

3.2. IMPLEMENTACIÓN DE TÁCTICAS

obtener los niveles de carga en la batería y el método onReceive en el cual

se obtienen los valores necesarios para las evaluaciones mediante el manager

de batería BatteryManager. Por último, se muestra cómo con un IntentFilter

el batteryReceiver se registra a los eventos asociados con los cambios en los

niveles de la batería del dispositivo. De esta forma, cuando la aplicación co-

mienza su ejecución el receiver batteryReceiver obtiene la información hasta

que la misma �nalice. Con la información obtenida se genera un archivo in-

dicando el número de mediciones obtenidas junto con los niveles de batería

de la ejecución. De esta manera, se obtienen los datos de consumo energético

para su posterior análisis.

Figura 3.14: Receiver de batería

Por último, se deben registrar los permisos necesarios para el funciona-

miento de la aplicación. Para obtener datos del sensor es necesario el permiso

GPS ACCESS_FINE_LOCATION, mientras que para guardar el archivo

�nal con los datos que serán analizados se debe registrar el permiso WRI-

TE_EXTERNAL_STORAGE y para obtener la información de los cambios

de batería se registra el permiso BATTERY_STATS.

3.2.5. Localización por Triangulación de Antena

La aplicación de obtención de geolocalización por triangulación de an-

tena es similar a la aplicación de GPS en su desarrollo y funcionamiento.

Los puntos en común son el receiver para obtener los niveles de batería y el

desarrollo adicional para guardar en un archivo los datos obtenidos de la eje-

cución de la aplicación (Figura 3.15). Si bien los principios en los que se basa

59

3.3. METODOLOGÍA DE MEDICIÓN

Figura 3.15: Escritura de datos

Android para el posicionamiento global son los mismos para ambas aplica-

ciones, el listener que se debe desarrollar para la aplicación de triangulación

de antena requiere de distintos permisos. En primer lugar, la biblioteca Lo-

cationManager contiene el provider NETWORK_PROVIDER que indica la

localización por red de telefonía, es decir, utilizando la triangulación de an-

tena, como se explicó anteriormente y se puede apreciar en la �gura. Al igual

que la aplicación de GPS, la suscripción se realiza para obtener los datos

inmediatamente cuando ocurra una actualización utilizando el método on-

LocationChanged del listener. La siguiente modi�cación se realiza a nivel de

Manifest dado que se declara el permiso ACCESS_COARSE_LOCATION

que le permitirá a la aplicación obtener la localización de forma aproximada

del dispositivo usando las señales de las antenas telefónicas. Esto se realiza

debido a que la localización por torres telefónicas no es del todo precisa con

respecto al GPS, entonces con obtener una localización aproximada para este

tipo de servicio será su�ciente para las pruebas a realizar. Esta decisión se

debe a que el servicio de red telefónica no fue pensado en sus inicios para la

localización de dispositivos como si lo fue el GPS.

3.3. Metodología de medición

En esta sección se explican los pasos necesarios para la obtención de la

información sobre las 4 aplicaciones desarrolladas. En todas ellas, el objetivo

principal es obtener un número determinado de experimentos que aseguren

una convergencia en el consumo de batería. De esta forma, al obtener un

60

3.3. METODOLOGÍA DE MEDICIÓN

número determinado de pruebas se podrá realizar un análisis comparativo de

las aplicaciones y explicar los resultados cuantitativos de estas para poder

observar mejor su desempeño energético.

Esta subsección esta dividida en 2 grupos. El primero hace referencia

a las aplicaciones de mensajes de actualización (Subsección 3.2.2, Subsec-

ción 3.2.3) y el segundo hace referencia a las aplicaciones de posicionamiento

(Subsección 3.2.4).

3.3.1. Mensajería Push y Poll

En este tipo de aplicaciones las pruebas consisten en utilizar un dispo-

sitivo para medición llamado Monsoon Solution1, que debe estar conectado

al smartphone que ejecuta las aplicaciones (Figura 3.16). Este tipo de dis-

positivo de medición se encuentra diseñado para obtener mediciones precisas

de energía en dispositivos móviles, permitiendo además ver en tiempo real

el consumo de energía. La mayoría de estas herramientas están constitui-

das por un componente de hardware que se encarga de la obtención de los

datos en forma analógica o digital y un componente de software que recibe

las mediciones obtenidas para ser mostradas en una computadora. En este

caso particular los elementos son llamados Power Monitor hardware y Power

Monitor software. Estos pueden obtener el consumo de energía en mili am-

peres (mA) sobre una batería de litio, proporcionando a los desarrolladores

la posibilidad de optimizar la performance de sus aplicaciones. La obten-

ción de información se hace mediante una computadora portátil con software

especí�co conectada al Power Monitor hardware. De esta forma, cuando la

aplicación comience a ejecutar en el smartphone, el dispositivo Power Moni-

tor obtiene la información del consumo de batería y lo transmite al Power

Monitor software para su posterior análisis (Figura 3.17). A su vez, el dispo-

sitivo Monsoon Solution consta con una gran variedad de con�guraciones y

detalles importantes para el desarrollador.

Finalmente, los experimentos consisten en ejecutar las aplicaciones en un

smartphone conectado a WiFi, mientras el servidor de aplicaciones envía un

1https://www.msoon.com/

61

3.3. METODOLOGÍA DE MEDICIÓN

Figura 3.16: Conexión power monitor

Figura 3.17: Software de medición

62

3.3. METODOLOGÍA DE MEDICIÓN

numero determinado de mensajes (200). Para ello, el servidor se encuentra

en una red diferente a la red en donde el smartphone ejecuta la aplicación,

con distinto trá�co de red y ancho de banda, a modo de obtener mediciones

similares a las de un escenario real . A su vez, el smartphone es con�gurado

para que sólo se ejecuten los servicios y aplicaciones esenciales para el sistema

operativo. Cada una de las pruebas será realizada al menos 5 veces para cada

una de las aplicaciones antes de analizar los resultados. Para dichas pruebas

se cuenta con un Samsung Galaxy S3 con Procesador quad-core 1.4 GHz,

1GB RAM y una batería de Li-Ion 2100 mAh. Este tipo de dispositivo móvil

pertenece a una categoría de gama media de smartphones, la cual es muy

popular.

3.3.2. Geolocalización

Para las pruebas de localización geográ�ca, la metodología utilizada para

realizar los experimentos es diferente a la anteriormente mencionada debido

a la manera en la que se obtiene la información. Hay que recordar que para

este tipo de aplicaciones se debe medir el consumo de batería mientras se

recorre una distancia apropiada para el experimento, lo que implica no poder

utilizar el Power Monitor ya que debe ser conectado a la red eléctrica. A su

vez, es necesario estar en movimiento debido a que es parte de la prueba

observar cómo se comportan las dos aplicaciones en un entorno parecido al

del mundo real. Entonces, para estos experimentos se recorrerá una distancia

de 1,5 km a pie para obtener las mediciones del mismo camino recorrido

una y otra vez a forma de garantizar la misma cobertura de los satélites,

los mismos edi�cios que inter�eren la señal, los mismos puntos geográ�cos

obtenidos y el mismo tiempo en recorrer la distancia. De esta forma, con

ayuda de las bibliotecas que proporciona el sistema operativo Android, se

pueden obtener en las mediciones el porcentaje de batería que consume una

aplicación mientras está en ejecución. Esta manera de obtener los datos de

energía es la más simple de utilizar por cualquier desarrollador, aunque al

ser una medición por software es menos precisa y necesita lógica adicional

en la aplicación introduciendo más ruido. El smartphone está con�gurado de

63

3.3. METODOLOGÍA DE MEDICIÓN

forma tal que no pueda realizar ninguna actualización y no reciba ninguna

noti�cación por parte de otro tipo de aplicaciones instaladas en el mismo.

Así, se puede obtener las mediciones de consumo lo más precisas posible. Este

tipo de experimento requiere de mayor cantidad de pruebas para obtener una

convergencia aceptable. Para realizar el experimento se utiliza un Samsung

Galaxy S Advance con Procesador dual-core 1 GHz, 768 MB RAM, sistema

operativo Android 2.3.6 y una batería de Li-Ion 1500 mAh.

64

Capítulo 4

Experimentos

Luego del análisis de cada aplicación junto con sus características, este

capítulo explicará cómo se realizaron los experimentos y la metodología de

medición seguida. También se presentan consideraciones especiales a tener

en cuenta para cada una de las pruebas, los resultados obtenidos de forma

cuantitativa y su correspondiente análisis.

4.1. Consideraciones de los experimentos

El presente capítulo se centra en exponer los resultados de los experi-

mentos presentados anteriormente (Capítulo 3). Las mediciones realizadas

a las aplicaciones mencionadas se ejecutaron 7 veces para las tácticas de

Push/Polling, y 11 veces para las aplicaciones de geolocalización. La infor-

mación del consumo de batería fue obtenida de forma diferente para las apli-

caciones consumidoras de mensajes y geolocalización. Para las aplicaciones

que implementan las tácticas de Push y Polling, el Power Monitor obtuvo

información precisa del consumo de energía, tiempo transcurrido de la me-

dición, voltaje, etc. El consumo de cada prueba estuvo determinado por el

tiempo de ejecución de la aplicación multiplicado por el consumo obtenido

(Ecuación 4.1):

Consumo = (Tf − Ti) ∗ Power (4.1)

65

4.2. PROPUESTAS PUSH Y POLLING

Por otra parte, para las aplicaciones de geolocalización, se contó con una

biblioteca provista por el sistema operativo Android con la cual se obtuvo

el porcentaje de batería al comienzo de iniciar la ejecución y al �nalizar,

siendo esta diferencia el consumo de energía empleado para el funcionamiento

(Ecuación 4.2).

Consumo = PCTi− PCTf (4.2)

Luego de realizadas las pruebas, el consumo promedio de cada propuesta

fue de�nido por la suma de todas las mediciones dividido por la cantidad de

pruebas realizadas de cada táctica (Ecuación 4.3).

ConsumoPromedio =

∑Consumo (i)

Numero de ejecuciones(4.3)

En las siguientes Subsecciones primero se detallarán los resultados para

las aplicaciones de mensajes Push/Polling, y por último las aplicaciones de

geolocalización. Finalmente, se presenta un análisis en conjunto de todas las

aplicaciones evaluadas.

4.2. Propuestas Push y Polling

Los experimentos de estas dos propuestas consisten en ejecutar en el

smartphone las aplicaciones correspondientes con el hardware de medición

Monsoon Solution conectado e intercambiando mensajes con la aplicación de

la computadora. Estos mensajes, están compuestos por una carga de 500 ca-

racteres que son enviados desde el servidor de servicios web a la aplicación

que ejecuta el smartphone en un intervalo de tiempo de dos segundos. De

esta manera, se buscó equiparar la carga de los mensajes y el tiempo en

que se actualizan las aplicaciones, favoreciendo la comparación entre ambas

propuestas. Dicha igualdad proporcionará información de ambas tácticas en

contextos similares y permite detectar aquellos aspectos que aumentan el

consumo de energía a la hora de la implementación de cada una.

En las Figura 4.1 y la tabla 4.1 se puede observar el resultado del con-

sumo en mA de las propuestas de implementación realizando 7 ejecuciones

66

4.2. PROPUESTAS PUSH Y POLLING

de cada una de las aplicaciones. En ellas se observa que la táctica de Polling

consume mayor cantidad energía para el mismo número de mensajes envia-

dos. Es importante tener en cuenta que siempre que se realiza una solicitud

se obtiene un nuevo dato, es decir que nunca se produce una consulta en

falso, lo cual degradaría la performance. De esta manera lo que se obtuvo

es el caso ideal para la propuesta de Polling, el mínimo consumo de batería

para esta propuesta. Por lo tanto, en la vida real, el consumo energético se-

rá mayor a lo obtenido en estas ejecuciones debido a las consultas en falso,

logrando que la diferencia entre una y otra táctica sea considerablemente

mayor. Entonces, la diferencia real entre las propuestas radica en el tiempo y

la forma en que se comunican con el proveedor de los mensajes. En este caso,

el servidor de aplicaciones fue desarrollado para generar un nuevo dato cada

vez que es consultado. Cada dato que se consulta en el servidor implica un

gasto de energía en el dispositivo móvil. Si la consulta devuelve que no hubo

cambios, entonces se estará desperdiciando batería al obtener un dato que no

se ha actualizado. Para esta implementación, el mayor consumo de energía

está dado por la conexión constante con el servidor desde que se solicitan los

datos hasta que este entrega el response a la aplicación usuario.

Por otra parte, la propuesta de mensajes Push consume menor cantidad

de energía porque esta sólo establece la conexión con el servidor cuando se

registra en los servidores de aplicaciones y en el servidor GCM de Google.

En este caso particular y con �nes de análisis de las dos aplicaciones en en-

tornos similares, esta conexión se realiza sólo al principio de la ejecución de

la aplicación lo que luego implica que no sea necesario mantener la conexión

y no consumir energía extra para esta tarea. En el caso de una aplicación

real, la misma debe poseer la posibilidad de registrarse cada cierto tiempo

en los servidores a modo de garantizar que sigue subscripta a los eventos que

ocurren en él. Adicionalmente, hay que destacar que todas las pruebas se

realizaron dentro de la misma red, para las aplicaciones cliente, en el mismo

lapso de tiempo y que el servidor de aplicaciones se encontraba en una red

diferente. De esta manera, la carga de las redes y los diferentes anchos de

banda se asemejaron bastante a los casos en el mundo real y fue similar para

las pruebas de las diferentes tácticas, evitando así que factores externos in-

67

4.2. PROPUESTAS PUSH Y POLLING

�uyeran en los resultados. En sintesis, la propuesta de mensajes Push ahorra

aproximadamente un 15% de energía en comparación a la táctica de Polling

bajo un escenario con las características mencionadas anteriormente.

Prueba\Alternativa GCM PUSH (mA) POLLING (mA)

Prueba 1 349,1325 421,1641Prueba 2 342,5931 448,9562Prueba 3 351,5704 421,9021Prueba 4 341,5028 413,3174Prueba 5 350,8782 402,4656Prueba 6 349,9373 374,7194Prueba 7 353,1919 363,5219Media 348,40 406,57

Cuadro 4.1: Detalle Consumo de las Alternativas Push y Poll

Figura 4.1: Consumo Promedio Push/Poll

La ventaja de la táctica de GCM está dada por un menor tiempo en

la conexión con los servidores y en el registro en los mismos. Lo siguiente

que se analizó fue cuánto consume un registro en los servidores por parte

68

4.2. PROPUESTAS PUSH Y POLLING

de esta táctica. En la Tabla 4.2 se puede observar que en el promedio de

los 7 casos, el consumo de batería es cercano a los 4.25 mA, es decir, que

ese gasto de energía es necesario para poner en funcionamiento la aplicación.

Para obtener la información deseada, se trabajo con las mismas pruebas que

se realizaron pero solo de los primeros 7 segundos de ejecución. Este tiempo

se pudo apreciar en el momento de la obtención de las pruebas de forma

grá�ca con el software especi�co provisto por Power Monitor. En ese tiempo

reside el consumo de la aplicación para la conexión con los servidores.

Numero de Experimento Consumo Promedio Conexión (mA)

Prueba1 4.22Prueba2 4.46Prueba3 4.22Prueba4 4.16Prueba5 3.91Prueba6 4.35Prueba7 4.45Promedio 4.25

Cuadro 4.2: Detalle Consumo Promedio Registro GCM

Suponiendo el caso de que se mantenga estable el consumo de energía

y realizando el mismo experimento pero realizando la conexión con los ser-

vidores cada ves que se reciba un dato, se obtendría un consumo promedio

aproximado de 1194.15 mA. Este valor obtenido de forma analítica resulta

de restar al consumo promedio obtenido en la anterior prueba (348.40 mA),

el valor promedio de la conexión (4.25 mA) y dividirlo por la cantidad de

mensajes (200). De esta forma, se obtiene el valor del consumo promedio por

cada mensaje (1.72 mA) al cual se le suma consumo promedio de conexión

multiplicado por la misma cantidad de mensajes. El valor �nal, signi�caría un

aumento del 342% de consumo de energía con respecto al consumo original,

aproximadamente, degradando la mejora y haciendo a la táctica de Polling la

mejor opción. Es decir, la táctica de mensajes Push se comportaría como si

fuera la alternativa de Polling en donde la aplicación realiza la conexión con

el servidor para obtener la información, pero a diferencia de esta, la conexión

se realiza en dos etapas. Como ya se mencionó en la Sección 3.2.3, la aplica-

69

4.2. PROPUESTAS PUSH Y POLLING

ción se registra ante los servidores de Google para poder recibir mensajes y,

una vez que obtiene el ID correspondiente, debe registrarse con el servidor

de aplicaciones web para indicar la suscripción al evento. El esfuerzo que

realiza la aplicación usuario es mayor que en la táctica de Polling y eso se ve

evidenciado en los resultados.

De esta forma en un escenario en el que la cantidad de veces que se debe

realizar la conexión de una aplicación con la táctica GCM para recibir datos

fuera excesiva se debería considerar y comparar la performance de la táctica

Polling para el desarrollo de la aplicación. De esta forma, se muestra que la

cantidad de conexiones a datos por parte de un dispositivo móvil se debe

analizar para no agotar la batería del mismo. Realizar un request o mantener

una conexión a la espera de un dato es algo costoso en términos energéticos.

Consumo = CC + CM ∗ CR (4.4)

Cada propuesta posee diferencias con respecto a la otra y el contexto de

la aplicación es determinante en la elección de una por parte del desarro-

llador. Por ejemplo, una aplicación como WhatsApp debe ser implementada

con la táctica de mensajes Push por las ventajas que esta provee, e�cien-

cia energética y la latencia de los mensajes, entre otras. En este caso, se

busca minimizar el tiempo en que la aplicación tarda en recibir un mensa-

je dado que si es implementada por la táctica de Polling el mensaje no se

recibiría hasta la próxima consulta al servidor. Sin embargo, los momentos

en los que se necesita la información también pueden ser determinantes en

la elección. Supongamos que en un intervalo de una hora, una aplicación en

el dispositivo recibe 10 emails. Con la propuesta Push, cada email llegará al

dispositivo inmediatamente. En el caso de la táctica de Poll, con un intervalo

de 15 minutos, la aplicación también recibirá los 10 emails pero, como la

petición la realiza el cliente, el tiempo de latencia entre envío y recepción

es mayor. Dependerá la importancia de los emails y la latencia de recepción

para determinar también cuál de las dos tácticas resulta más conveniente. Si

los datos solo pueden ser leídos cada, por ejemplo, varios minutos, , tal vez

la propuesta de Polling sea mas conveniente.

70

4.3. GEOLOCALIZACIÓN

Finalmente, el consumo del envío de información con la propuesta Push

por parte del dispositivo se resume en la Ecuación 4.4, en donde CC es el

consumo de conexión y subscripción al servidor, CM la cantidad de mensajes

y CR el consumo de energía para la recepción. Este último dato lo obtenemos

de las pruebas que se realizaron, sabiendo que el consumo promedio es de

348,40 mA le restamos el consumo de conexión (4.25 mA) y lo dividimos por

la cantidad de mensajes que se enviaron en las pruebas (200). De esta forma,

para el escenario mencionado de los emails, el consumo promedio para la

táctica de Push es de 21,45 mA. Por otro lado, el consumo de la propuesta de

Poll se ve resumido en la Ecuación 4.5, donde CM es la cantidad de mensajes

y CER es el consumo que realiza la aplicación en enviar y recibir información.

Si dividimos el consumo promedio obtenido en las pruebas (406,57 mA) por

la cantidad de mensajes, obtenemos que el consumo de un solo mensaje

es de 2.03 mA. Para 10 emails el consumo promedio es de 20,3 mA. Si la

información que el usuario recibe no es importante se podría aumentar aún

más el tiempo de consulta al servidor y mejorar el consumo energético.

Consumo = CM ∗ CER (4.5)

4.3. Geolocalización

Debido a que este tipo de aplicaciones normalmente se utilizan en movi-

miento, representan un desafío para realizar mediciones precisas de consumo.

En consecuencia, a la hora de medir el trayecto recorrido se con�guró el te-

léfono de una manera tal que consumiera una cantidad de energía mínima e

indispensable con respecto a las aplicaciones y a toda la funcionalidad extra.

Sin embargo, existen ciertas limitaciones y problemas externos. Por ejemplo,

la cantidad de datos de posición obtenidos varía entre una evaluación y otra;

o la señal GPS o de celular se ve disminuida, provocando el cierre o funcio-

namiento incorrecto de la aplicación medida. Además, la llegada de mensajes

o llamadas por parte de algún tercero generando mediciones incorrecatas del

consumo, descartando las pruebas. De hecho, entre un 30% y un 40% del

71

4.3. GEOLOCALIZACIÓN

total de pruebas realizadas tuvieron que ser descartadas por alguno de estos

inconvenientes.

Figura 4.2: Consumo Promedio GPS/Triangulación de Antena

Experimento\Alternativa GPS (%) Antena(%)

Prueba 1 3 1Prueba 2 3 3Prueba 3 3 1Prueba 4 4 1Prueba 5 3 5Prueba 6 3 2Prueba 7 3 4Prueba 8 4 2Prueba 9 3 6Prueba 10 3 3Prueba 11 4 5

Cuadro 4.3: Detalle Consumo Geolocalización

Teniendo en cuenta estas limitaciones, se obtuvieron 11 experimentos vá-

lidos que arrojaron resultados re�ejados en las Figura 4.2 y la tabla 4.3.

72

4.3. GEOLOCALIZACIÓN

Podemos observar un consumo que ronda el 3% de la batería para ambas

propuestas, con un pequeño incremento en la táctica de posicionamiento por

GPS. Es decir, el consumo energético es mayor para los casos en que se uti-

liza los satélites que en los casos en que se utilizan las redes de telefonía. Sin

embargo, el consumo de energía en estas ultimas, varía considerablemente

entre una prueba y otra, haciéndola una táctica más inestable en cuanto al

consumo energético. Esto se debe a los inconvenientes propios de la perdida

de señal, desvío de las mismas por un objeto o problemas con las antenas

telefónicas.

Número de Experimento GPS Antena

Prueba 1 919 19Prueba 2 920 14Prueba 3 920 21Prueba 4 770 19Prueba 5 741 18Prueba 6 833 20Prueba 7 832 17Prueba 8 765 19Prueba 9 650 21Prueba 10 878 21Prueba 11 963 20Promedio 835 19

Desvió Estandar 92 2

Cuadro 4.4: Cantidad de Lecturas

De esta forma, un servicio que está diseñado para la geolocalización como

el GPS consume en promedio casi lo mismo que un servicio que está pensado

para la comunicación entre los usuarios. Sin embargo, en cuanto a la calidad

del servicio, existen grandes diferencias entre uno y otro. La cantidad de

lecturas que realizan ambas tácticas de la posición actual del smartphone

di�eren ampliamente y es ahí donde la ventaja del GPS es notoria. En el

detalle mostrado en la Tabla 4.4 se aprecia que la táctica de GPS posee una

gran cantidad de lecturas para los 1500 metros de distancia recorridos en un

tiempo promedio de 16 minutos, lo que implica una referencia a la posición

actualizada del smartphone casi en tiempo real. Por otra parte, la posición

73

4.4. CONCLUSIONES

obtenida por la red de telefonía es pobre y sufre de inconvenientes propios

tales como pérdida de señal o interferencia de la misma por los edi�cios.

En estos casos si se pudiera observar en un mapa la posición actual del

dispositivo se apreciaría que el punto va saltando de una posición a otra en

vez de desplazarse de manera casi continua.

De esta manera, cuando se desee obtener la posición actual del smartp-

hone es conveniente utilizar una propuesta como GPS, que aunque consume

mayor cantidad energía en promedio, posee una mejor calidad de servicio. En

los casos en que el proveedor de GPS no se encuentre disponible la propuesta

de posicionamiento por triangulación de antena dará un servicio de forma

limitada y menos precisa haciendo un mejor cuidado del consumo de ener-

gía. Estas conclusiones dependen mucho del tipo de aplicación y el uso de la

misma. Otra opción es utilizar un híbrido entre las dos tácticas. Supongamos

que una persona utiliza el posicionamiento global para ir de una ciudad a

otra que desconoce, al momento de iniciar el camino la opción de ubicación

por triangulación de antena mejora la e�ciencia debido a que consume menor

energía y no es necesaria tanta precisión porque la primera parte del camino

es conocido por el usuario. A medida que el dispositivo se va acercando al des-

tino la aplicación cambia la táctica de posicionamiento utilizada y comienza

a utilizar el posicionamiento por GPS, indicando con mejor exactitud que ca-

mino se debe tomar. De esta forma ambas tácticas se pueden complementar

de acuerdo a las necesidades del usuario y de la aplicación.

4.4. Conclusiones

Los resultados obtenidos en los experimento exponen las ventajas y falen-

cias de cada una de las propuestas presentadas. Se realizó una comparación

empírica entre ambos tipos de aplicaciones en donde se pudo observar que,

bajo escenarios similares, el comportamiento y el consumo de energía de cada

una de las tácticas di�ere con diversas variables a tener en cuenta. En líneas

generales, el impacto de cada una de las propuestas en el consumo de batería

es grande con respecto a otro tipo de aplicaciones, tornando la elección de

cada táctica una decisión importante para los desarrolladores. Mantener las

74

4.4. CONCLUSIONES

conexiones para el consumo de datos y administrar el tiempo o el momento

en que estas se realizan resultan fundamentales para la vida de la batería

del dispositivo. Si bien a veces la elección de una u otra propuesta depende

del contexto de la aplicación, el análisis realizado sobre el consumo de ener-

gía permitirá al desarrollador comprender mejor la aplicación que desarrolla.

También se pudo comprobar en cada experimento que las nuevas y avanza-

das propuestas de implementación mejoraron el uso e�ciente de energía. Sin

embargo, podemos decir que existen alternativas o casos especiales en los que

es necesario aplicar las tácticas que tienen un mayor consumo de batería.

75

Capítulo 5

Conclusiones

Las redes inalámbricas como el 3G, wi-� y el uso de sistemas de posicio-

namiento global han incrementado la funcionalidad de dispositivos móviles

como smartphones, otorgándoles así mayor importancia en la vida diaria de

los usuarios. Algunas de estas nuevas funciones necesitan de la actualización

constante de información, lo cual implica un gasto de energía por parte del

dispositivo móvil puesto que debe obtener esos datos de un servicio externo.

En el desarrollo de aplicaciones móviles es sumamente importante utilizar

los recursos de los dispositivos de forma cuidadosa, ya que los mismos son

limitados. Todas las aplicaciones que se ejecuten en un dispositivo móvil de-

ben tener presente la cantidad de memoria RAM, el procesador, batería, etc.,

dado que son recursos valiosos y no se debería hacer un uso excesivo de los

mismos. Por esto, los desarrolladores tienen la difícil tarea de decidir el di-

seño de la aplicación y las tácticas de conexión a utilizar para afrontar los

nuevos requerimientos no funcionales que se presentan. Por lo tanto, obtener

información desde un servidor no es una tarea que se pueda tomar a la lige-

ra y se debe analizar qué propuesta de implementación es adecuada para el

consumo de datos, sabiendo que esta decisión impactará directamente en la

aplicación y por consiguiente en el éxito o fracaso de la misma.

El objetivo principal del presente trabajo es mostrar cómo las aplica-

ciones que consumen datos y utilizan servicios de ubicación administran la

energía de un dispositivo móvil como un smartphone. Dichas aplicaciones,

76

son catalogadas por la comunidad de desarrolladores como aquellas que tie-

nen un consumo mayor de energía, acortando considerablemente el tiempo

de duración de la batería. Estas aplicaciones centran su funcionamiento en

el consumo de datos obtenidos desde un servidor o en la geolocalización rea-

lizada a través de sensores del dispositivo móvil.

Para las aplicaciones que consumen datos de un servidor particular, dos

de las tácticas mayormente utilizadas son la de mensajes Push y la táctica

de Poll. Estas realizan la conexión y la extracción de información de forma

distinta. Ambas fueron expuestas al mismo experimento para determinar

bajo las mismas condiciones cuál de las dos es mejor en términos de e�ciencia

energética. Este experimento se basó en obtener una determinada cantidad de

mensajes, con una longitud �ja, utilizando las propias características de cada

propuesta de implementación. Ambas tácticas fueron ejecutadas en el mismo

smartphone y utilizando wi-� como red inalámbrica y medio de conexión a

Internet. Con �nes de obtener resultados precisos se preparó el smartphone de

modo tal que sólo los servicios básicos se ejecutaran durante los experimentos

y las mediciones se realizaron con hardware especializado para esta tarea.

Además, para realizar pruebas reales se utilizaron servidores ubicados fuera

de la red en donde se ejecutó el dispositivo con la aplicación.

Los resultados que se obtuvieron arrojaron que la propuesta de mensajes

Push es un 15% más e�ciente en cuanto a consumo de batería que la pro-

puesta de obtención de datos de forma Polling. Esto se debe a que la primera

sólo realiza la conexión con el servidor de aplicaciones para indicarle que está

interesada en recibir información. Por el contrario, la táctica de Polling abre

una nueva conexión, manteníendola abierta cada vez que busca la informa-

ción, siendo ese momento donde se produce el mayor gasto de energía para

el dispositivo.. En condiciones ideales, la aplicación con una propuesta de

mensajes Push se debería suscribir una vez en un determinado servidor. Sin

embargo, esta situación ideal no siempre es posible debido a diversos facto-

res tales como desconexiones o fallas en la conexión a Internet, reinicio de

servidores, cambios de dirección IP, etc. Entonces, el número de conexiones

que realiza una aplicación con un servidor externo in�uye negativamente en

el consumo de batería. Los resultados arrojaron que para el mismo escenario

77

el consumo en la táctica de mensajes Push crece más de un 300% de forma

analítica, cuando su funcionamiento se asemeja al de la táctica de Polling,

haciendo a la táctica de obtención de datos mediante la propuesta Polling la

mejor opción. Comprender el contexto en el que se ejecutará la aplicación es

de suma importancia para la elección de la propuesta de implementación y,

de esta forma, se podrá mejorar el consumo de energía en aplicaciones con

consumo de datos.

Como segundo objetivo se analizaron las aplicaciones que utilizan servi-

cios de geolocalización y el consumo de energía asociado a ellas. Las pro-

puestas de desarrollo evaluadas en este caso fueron el uso del sistema GPS

y el posicionamiento utilizando las antenas de telefonía móvil. Ambas fueron

expuestas a un experimento que consistía en medir el consumo de batería

mientras el dispositivo se desplazaba recorriendo una distancia apropiada.

Con esto, se buscó obtener el posicionamiento en un entorno real, experi-

mentando cualquier tipo de suceso como desvío o pérdida de señal. Por lo

tanto, la obtención del consumo de batería se realizó mientras el smartphone

se mantuvo en funcionamiento con todos sus servicios. Además, es importan-

te tener en cuenta que las mediciones se debieron realizar por software dado

que, por las características del experimento, no se pudo conectar hardware

de medición especí�co al dispositivo.

Los resultados arrojaron que la táctica de obtención de ubicación por GPS

consume en promedio en 1500 metros de distancia el 3.27% de batería contra

el 3% que consume la propuesta de ubicación por antenas de telefonía para

el smartphone utilizado. Sin embargo, la diferencia más importante reside en

la calidad del servicio que provee el GPS: mientras este obtiene la ubicación

casi en tiempo real, la propuesta de utilización de las antenas de telefonía

posee inconvenientes propios de las ondas de radio y obtiene un servicio

de ubicación en forma degradada. Claramente se observa la diferencia entre

las dos propuestas y el hecho de que cada una de ellas fue diseñada para

distintos objetivos (una fue diseñada para la comunicación entre dispositivos

y la otra para ubicación). La aplicación con la propuesta GPS obtiene una

gran cantidad de puntos de localización (835 en promedio) y la propuesta

de localización por antena (19 en promedio). Los resultados arrojaron una

78

ventaja por parte de la utilización del GPS, con�rmando el uso de este por

la mayoría de las aplicaciones. Sin embargo, la ubicación por medio de las

antenas de telefonía proveen un servicio que se puede complementar o utilizar

dependiendo el contexto para ofrecer un consumo de batería medio entre las

dos propuestas sin degradar demasiado la calidad de los servicios.

A continuación del presente trabajo existen diversas posibilidades que

quedan abiertas y en las que es posible continuar o extender los resultados

alcanzados. Durante el desarrollo del trabajo, han surgido diversas temáti-

cas que se esperan analizar y desarrollar en un futuro. A continuación se

presentan los pasos que pueden desarrollarse.

Como primer paso, se analizará el mismo experimento en otros dispo-

sitivos móviles con versión más actualizada del sistema operativo Android.

Las últimas versiones como Android 5 o 6 contienen mejoras en el consumo

de batería por parte de las aplicaciones que estos ejecutan y en el uso de

los componentes del dispositivo móvil, según las especi�caciones detalladas

en su lanzamiento. De esta forma se podrá comparar cuánto ha mejorado el

sistema operativo el consumo de energía en sus últimas versiones y en disposi-

tivos con mejores componentes tecnológicos. De esa forma se espera veri�car

si realmente las últimas versiones de Androidmejoran el consumo de energía

de los distintos dispositivos. De esta forma, probando distintas mejoras, se

podrá obtener para un grupo de dispositivos móviles si los cambios en el sis-

tema operativo también mejoran el rendimiento sabiendo la heterogeneidad

de los mismos.

En segunda instancia, se analizarán los contextos de las aplicaciones que

consumen datos para tratar de determinar en qué momentos se debe realizar

una petición de actualización o cómo una aplicación puede pasar del uso de

una táctica a otra de forma inteligente. De esta manera, se podrá obtener un

consumo promedio entre dos propuestas, como por ejemplo las aplicaciones

de geolocalización. Esta no es una tarea fácil y se necesita análisis exhaustivo

para determinar qué aspectos hay que tener en cuenta sin degradar el consu-

mo de energía. Es decir que la aplicación de un mecanismo inteligente para

determinar qué alternativa utilizar según el contexto no empeore el consumo

energético. En este análisis se evaluará el impacto en aplicaciones reales de

79

las evaluaciones realizadas en el presente trabajo. De este modo el desarrolla-

dor contará con valores del impacto del esfuerzo que puede implicar aplicar

una u otra táctica.

80

Bibliografía

R. R. L. S. Adel Noureddine, Aurelien Bourdon. A preliminary study of the

impact of software engineering on greenit. First International Workshop

on Green and Sustainable Software, 2012.

A. V. R. Alejandro Zunino, Cristian Mateos. Refactorizaciones para kernels

computacionales cienti�cos en dispositivos moviles. 2013.

J. d. M. Aline Rodrigues Tonini, Marco Beckmann. Evaluating android best

practices for performance. Symposium of Microelectronics, 2013.

A. Barisone, F. Bellotti, R. Berta, and A. D. Gloria. Jsbricks: a suite of mi-

crobenchmarks for the evaluation of java as a scienti�c execution environ-

ment. Future Generation Computer Systems, 18(2):293 � 306, 2001. ISSN

0167-739X. doi: http://dx.doi.org/10.1016/S0167-739X(00)00097-2. URL

http://www.sciencedirect.com/science/article/pii/S0167739X00000972.

Java in {HPC}.

J. Bloch. E�ective Java programming language guide. Sun Microsystems,

Inc., Mountain View, CA, USA, 2001. ISBN 0-201-31005-8.

S. Boonkrong and P. C. Dinh. Reducing battery consumption of data polling

and pushing techniques on android using gzip. In 2015 7th International

Conference on Information Technology and Electrical Engineering (ICI-

TEE), pages 565�570, Oct 2015. doi: 10.1109/ICITEED.2015.7409011.

D. Li and W. G. J. Halfond. An investigation into energy-saving program-

ming practices for android smartphone app development. 2014.

81

BIBLIOGRAFÍA

X. Ma, P. Huang, X. Jin, P. Wang, S. Park, D. Shen, Y. Zhou, L. K. Saul,

and G. M. Voelker. edoctor: Automatically diagnosing abnormal battery

drain issues on smartphones. In Proceedings of the 10th USENIX Confe-

rence on Networked Systems Design and Implementation, NSDI '13, pa-

ges 57�70, Berkeley, CA, USA, April 2013. USENIX Association. URL

http://dl.acm.org/citation.cfm?id=2482626.2482634.

G. A. Nicoara, Narendran Thiagarajan. Who killed my battery: Analyzing

mobile browser energy consumption. Session: Mobile Web Performance,

2012.

H. S. Oluwatosin. Client-server model. IOSR Journal of Computer Enginee-

ring, 2014.

A. Rice and S. Hay. Measuring mobile phone energy con-

sumption for 802.11 wireless networking. Pervasive and

Mobile Computing, 6(6):593 � 606, 2010. ISSN 1574-

1192. doi: http://dx.doi.org/10.1016/j.pmcj.2010.07.005. URL

http://www.sciencedirect.com/science/article/pii/S1574119210000593.

Special Issue PerCom 2010.

A. Rodriguez, C. Mateos, and A. Zunino. Improving scienti�c applica-

tion execution on android mobile devices via code refactorings. Soft-

ware: Practice and Experience, pages n/a�n/a, 2016. ISSN 1097-024X.

doi: 10.1002/spe.2419. URL http://dx.doi.org/10.1002/spe.2419.

spe.2419.

J. Simon, P. Schmidt, and V. Pammer-Schindler. Analysis of di�eren-

tial synchronisation's energy consumption on mobile devices. CoRR,

abs/1601.01539, 2016. URL http://arxiv.org/abs/1601.01539.

P. P. Snehal Mumbaikar. Web services based on soap and rest principles.

2013.

L. Zhang, M. S. Gordon, R. P. Dick, Z. M. Mao, P. Dinda, and

L. Yang. Adel: An automatic detector of energy leaks for smartpho-

82

BIBLIOGRAFÍA

ne applications. In Proceedings of the Eighth IEEE/ACM/IFIP Inter-

national Conference on Hardware/Software Codesign and System Synt-

hesis, CODES+ISSS '12, pages 363�372, New York, NY, USA, 2012.

ACM. ISBN 978-1-4503-1426-8. doi: 10.1145/2380445.2380503. URL

http://doi.acm.org/10.1145/2380445.2380503.

83