Buddy-mobiilisovelluksen optimointi : muistinhallinnan ja käyttöliittymän optimointi Android-sovelluksessa

Abstract

Buddy on Centria-ammattikorkeakoulun Capstone project -kursseilla luotu ohjelmisto. Ohjelmisto koostuu palvelimesta, mobiilisovelluksesta ja tietokannassa. Kun ensimmäinen ohjelmisto valmistui vuonna 2024, siitä löytyi merkittäviä muistinhallintaan, käyttöliittymään ja sovellusarkkitehtuuriin liittyviä ongelmia. Opinnäytetyössä keskityttiin korjaamaan muistinhallintaan ja käyttöliittymään liittyviä ongelmia. Työ keskittyi mobiilisovellukseen. Tavoitteena oli luoda uuteen sovellukseen responsiivisempi käyttöliittymä ja parantaa muistinhallintaa. Työ aloitettiin kartoittamalla teoriapohjaa parhaiden optimointikäytäntöjen varmistamiseksi. Tähän teoriapohjaan kuului keskeisiä käsitteitä ja käytäntöjä Android-sovelluksen optimoinnissa. Toiminnallinen osuus jaettiin lähtötilanteen kartoittamiseen, optimointivaiheeseen sekä tulosten tarkasteluun. Tuloksien tarkastelua varten suoritettiin kolme testiä. Työ tehtiin Android Studio -ohjelmointiympäristössä Java-ohjelmointikielellä.

Potentiaalisia muistiongelmia löytyi lähtötilanteessa säikeiden hallinnasta, sovellusarkkitehtuurista, aktiviteettien hallinnasta, resurssien vapautuksesta ja suurien tietuelistojen käsittelystä. Vanha sovellus käytti vain vahvoja viittauksia ohjelmakoodissa, mikä esti joissain tilanteissa viitattujen objektien vapautuksen. Käyttöliittymän ongelmia olivat muun muassa tarpeettoman syvät asetteluhierarkiat, aktiviteettiarkkitehtuuri ja tarpeeton rasterikuvien käyttö ikoneissa. Uusi sovellus luotiin käyttämään viittä aktiviteettia, joista jokainen sisälsi 3–4 fragmenttia. Säikeiden hallinta keskitettiin ja säikeille luotiin säiepooli. Aktiviteettiarkkitehtuuri rakennettiin niin, että taustalle jäävät aktiviteetit vapautetaan. Palveluita keskitettiin sovelluksen elinkaaresta vastaavalle instanssille. Palvelimelta tulleet vastaukset käsiteltiin paikallisesti ja abstrakteissa pohja-aktiviteettiluokissa vähennettiin niistä perittävän koodin määrää. Sovelluksen käyttöliittymää kevennettiin hyödyntämällä vektorigrafiikkaa, tasoittamalla asettelujen hierarkkista rakennetta ja käyttämällä tietuelistojen visualisointiin RecyclerView-komponenttia. Tuloksissa havaittiin sovelluksen muistin käytön tasaantuneen. Tyypillisesti muistin käyttö oli alle 200 megatavua uudessa sovelluksessa sen koko elinkaaren aikana ja käyttämättömät objektit vapautuivat. Vanhassa sovelluksessa muistin käyttö nousi koko sovelluksen elinkaaren ajan. Uudessa sovelluksessa tietuelistojen käsittely oli tehokkaampaa ja subjektiivisten havaintojen perusteella sovellus tuntui responsiivisemmalta. Näitä havaintoja tuki teoriapohja.

Buddy is a software created during Capstone project courses at Centria University of Applied Sciences. The software consists of a server, a mobile application and a database. When the first software was completed in 2024, significant problems were found related to memory management, user interface and application architecture. The thesis focused on fixing problems related to memory management and user interface in the mobile application. The objective was to create a more responsive user interface and better memory management for the new application. The work began by mapping the theory base to ensure best optimization practices. This theory base included key concepts and practices in optimizing an Android application. The functional part was divided into analyzing the initial situation, the optimization phase and reviewing the results. Three tests were performed to examine the results. The work was carried out in the Android Studio programming environment in the Java programming language.

Potential memory issues were initially found in thread management, application architecture, activity management, resource release, and handling large datasets. The old application used only strong references in the program code, which sometimes prevented the release of referred objects. Problems with the user interface included, among others, unnecessary deep layout hierarchies, activity architecture, and unnecessary use of raster images in icons. The new application was created to use five activities, each containing 3 to 4 fragments. Thread management was centralized, and a thread pool was created for the threads. The activity architecture was built so that activities left in the background are released. Services were centralized to the instance responsible for the application’s lifecycle. Responses from the server were processed locally and the amount of inherited code from abstract base activities was reduced. User interface was optimized by using vector graphics, flattening hierarchical structures of layouts and using RecyclerView component to visualize datasets. The result showed that the application’s memory usage was stabilized. Typically, memory usage was less than 200 megabytes in the new application throughout the application’s lifecycle, and unused objects were released. In the old application, memory usage increased throughout the application’s lifecycle. Datasets processing improved, and the application felt more responsive based on subjective observations. These observations were supported by the theoretical basis.