alternativas para el desarrollo de aplicaciones móviles
TRANSCRIPT
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