Napjainkban egyre több okosórára tervezett applikáció lát napvilágot. A trend még az Apple éves Keynote előadásaiban is tetten érhető, hiszen a főszerepet az iPhone helyett egyre inkább az Apple Watch tölti be. Az Apple mellett más cégek is igyekeztek belépni az okos kiegészítők piacára, és napjainkra két fő operációs rendszer vált elterjedtté ezeken az eszközökön: az Apple által fémjelzett watchOS és az Android fejlesztette wearOS. Mivel a terület az ipar 4.0 vonatkozásában is ígéretes lehetőségeket kínál, 2019-ben mi is megkezdtük a Kitchen Budapestnél az okos eszközökkel kapcsolatos ötletek kidolgozását.

A Canary volt az első ilyen projektünk, amelyet egy hallássérült emberek számára tervezett „riasztóóraként” lehet definiálni. A fejlesztéshez a Huawei Watch 2 okosórát választottuk, amely támogatja az eSIM-et, a wearOS-t, továbbá a legjobb opciónak mutatkozott ár-érték arány szempontjából, és az akkumulátora is megbízhatónak bizonyult. Az eszköz egyetlen célja az volt, hogy ez az alkalmazás fusson rajta.

Az ipari környezetben végzett munka gyakran hordoz veszélyeket magában. Vészhelyzet esetén (pl. tűzeset) megszólal a riasztóberendezés, amely valamilyen hallható utasítással jelez a dolgozóknak. Annak érdekében, hogy a munkahely a hallássérült emberek számára is biztonságos legyen, az általunk kidolgozott ötlet alapján a riasztórendszer egy SMS-t küld az órának, amely rezegni kezd a dolgozó csuklóján, és ezáltal egy taktilis riasztás váltja ki a hallható jelzést. Ezen a ponton a felhasználónak meg kell nyomnia egy gombot a felhasználói felületen, ami visszajelzést küld az admin felületnek arról, hogy észrevette a riasztást. Az admin felület egy egyszerű honlap, amelyet azért hoztunk létre, hogy figyeljük az akkumulátorszintet, a pulzusszámot, valamint azt, hogy viseli-e a dolgozó a készüléket és észrevette-e a riasztást.

Admin platform

Az applikáció és az admin felület közötti folytonos kommunikáció biztosításához a Google többféle megoldást is kínál, többek között a Firebase-t, amely a wearOS-be integrálva a saját szerverével valós idejű üzenetváltást biztosít. A Firebase akkumulátor-hatékony megoldás, mert használatával feleslegessé válik az admin felülettel való külön kapcsolat implementálása.

Esetünkben a GDPR-szabályzat miatt tilos volt harmadik szolgáltatót használni, így a kommunikációt websocket alkalmazásával oldottuk meg, ami azonban hozzájárult az akkumulátor gyors merüléséhez. Mint korábban említettük, az óráink egyetlen célja az volt, hogy az alkalmazás fusson rajta, így a mobiltelefon-hálózatot 2G-re korlátoztuk, mivel az akkumulátortörténeti adatokat megfigyelve úgy tűnt, hogy a hálózat nagyon sok energiát fogyaszt. A kapcsolatra nem volt hatással, ugyanakkor ily módon sikerült némileg kímélnünk az akkumulátort.

Ezen a ponton a Canary egy kétirányú kommunikációs csatornán csatlakozott az admin felülethez, így következő lépésként logikusnak tűnt, hogy ezt a csatornát használjuk arra, hogy átküldjük a riasztásokat az órára. Azonban a gyárakban történő teszteléskor kiderült, hogy alig volt megfelelő mobilhálózat. A riasztások órára küldéséhez az SMS megbízhatóbb megoldásnak bizonyult (itt ismét érdemes megjegyezni, hogy a Firebase integráció is szolgálhatta volna ezt a célt). Az SMS alacsony akkumulátor töltöttség és gyenge mobilhálózat esetén is megérkezik az órára. További előnyként említhető, hogy a beérkező SMS-re történő vibráló reagálást könnyű volt kivitelezni a BroadcastReceivers használatával.

Az Android 6.0-tól kezdve a Google bevezette a mélyalvó állapotot, ami az akkumulátorspórolás érdekében meg-megszakította az órán levő websocket kapcsolatot. Ez számunkra nem volt elfogadható, hiszen biztosítanunk kellett, hogy az óra online maradjon az admin felületen (azaz legyen egy nyitott websocket kapcsolata). Ennek érdekében bevezettünk egy frontend service-t, amely biztosította az applikáció zavartalan működését akkor is, ha a felhasználó nem lépett vele kapcsolatba. (Az alvó üzemmód az akkumulátor spórolás érdekében állította meg az applikációt – a különböző funkciókkal ellátott átlagos okosóra ugyanis intenzív használat mellett maximum egy napot bír ki.)

A fent említett visszajelzés mellett a websocket-et arra is használtuk, hogy értesítsük az admin felületet az akkumulátorszintről, a dolgozók pulzusáról, valamint arról, hogy viselik-e az órát vagy sem. Mivel egy átlagos műszak akár 9 óra hosszú is lehet, nagy kihívást jelentett, hogy minden funkció bekerüljön az applikációba, de azok mégse merítsék le teljesen az akkumulátort 5 óra alatt. Úgy gondolom, hogy az ötleteléseinknek köszönhetően minden lehetséges módon sikerült energiát spórolnunk.

Az admin felületre küldendő üzenetek ütemezéséhez Handlert használtunk. A frontend service miatt az ütemezés csak akkor történt meg, amikor az applikáció futott. Az AlarmManager és a JobScheduler rendszer erőforrásokat használ a feladatok ütemezéséhez. A Handler csak applikációs erőforrásokat használ, így az hatékonyabbnak bizonyult.

Ütemezési feladatok az Androidon:

  •  JobScheduler: olyankor érdemes használni, amikor nem fontos az időzítés, vagy a végrehajtáshoz - például a hálózattípus vagy a töltőcsatlakozás vonatkozásában - feltételeket szeretnénk szabni (pl. egy áramforráshoz csatlakoztatott készüléken nagyobb letöltést szeretnénk beütemezni).
  • AlarmManager: adott feladatok adott időpontban (például minden reggel 8 órakor) való lefuttatásához használható.
  • Handler: időzítési műveletek (például tick, timeout) esetén optimális használni, mint ahogy mi is tettük a Canary esetében.

A 10 másodperc alatt ismétlődő feladatok ütemezéséhez csak a Handler garantál közel pontos megvalósítást. Az energiamegtakarítás érdekében megnöveltük a Handler ismétlési idejét. Először minden 3. másodpercben küldtünk pulzus üzenetet és minden 30. másodpercben akkumulátor üzenetet, de ez nem szolgált érdemibb adatokkal a felhasználó vagy az óra állapotáról. Így optimalizáltuk az üzenetütemezést és végül az akkumulátorszintről csak 10 percenként, míg a pulzusszámról 7 másodpercenként küldtünk adatot. Az on/off szenzorokat is kiaknáztuk, és gondoskodtunk arról, hogy a pulzusmérő kikapcsoljon, ha a felhasználó leveszi az órát.

Igyekeztünk a felhasználói felületet a felhasználói élmény figyelembevétele mellett a lehető legegyszerűbbé tenni, mivel az összetett, animációval rendelkező felületek intenzíven merítik az akkumulátort. Animáció nélküli egyszerű felhasználói felületeket terveztünk, amelyek csupán a szükséges információkat tartalmazzák. A Huawei Watch 2 óra minimálisra való „lecsupaszítása” egyúttal sok energiát is megtakarított. Minden olyan tevékenységet kikapcsoltunk, amely rendszer erőforrásokat használ, pl. számlap, Bluetooth, wifi, always-on képernyőmód, gesztusok, Android szolgáltatások, azaz tulajdonképpen minden, amire nem volt szükségünk, de merítheti az akkumulátort. Ezt követően egy napon keresztül teszteltük az órát, ellenőrizve, hogy semmilyen alapvető funkciót nem kapcsoltunk ki. Ezzel a megoldással, valamint a hálózat 2G-re csökkentésével jelentősen javítottuk az óra élettartamát. A Google javaslatai szerint az okosórák akkumulátorral kapcsolatos problémáit az óra alvó módba küldésével, az értesítések kikapcsolásával és a képernyő fényerő csökkentésével is orvosolhatjuk.

Canary

Amikor a felhasználó riasztást kap, az óra képernyője bekapcsol, és addig vibrál, amíg a felhasználó észreveszi azt és visszajelzést küld az admin felületre. Annak érdekében, hogy biztosítsuk az óra bekapcsolódását, a megfelelő felület megjelenését és elkerüljük az alvó mód aktiválódását, wakelock-ot használtunk. A wakelock nélkül az óra ugyan elkezdene rezegni, de a képernyő továbbra is fekete maradna, és a felhasználónak külön meg kéne nyitnia az applikációt a menüben, majd megnyomnia a megfelelő gombot. A visszajelzés elküldését követően a wakelock feloldódik, így az óra ismét az energiát megtakarító alvó módba kerül. Fontos, hogy csak szükség esetén használjuk a wakelock-okat, és oldjuk fel őket, amint a munka befejeződött. 

Az applikációnkat Battery Historiannal teszteltük. A Google szerint „ez a program az applikációk és rendszerviselkedések rendszerméretű vizualizációját biztosítja, és feltünteti azok összefüggéseit az adott idő alatti akkumulátorfogyasztással.” Alkalmazásával megbizonyosodhattunk arról, hogy nem használunk akkumulátorfogyasztást eredményező felesleges wakelockokat. Segített ellenőrizni a mobilhálózat akkumulátorra gyakorolt hatását is. Ezen felül arra is igen eredményesen használtuk, hogy megfigyeljük, ejtünk-e hibákat, és hogy miként javul a Canary működése minden egyes iterációt követően.

Nagy kihívást jelentett, miként tudjuk az összes funkciót beépíteni az applikációba. A projekt kezdetén a legnagyobb probléma a rezgés megoldása volt. Mivel az applikáció hajlamos kikapcsolni, első androidos projektem során komoly feladatot jelentett a lehetséges összes eshetőség feltérképezése, majd annak tesztelése, hogy megjelenik-e a megfelelő felhasználói felület és rezegni kezd-e az óra az SMS érkezésekor. Az óra eltérően reagált például akkor, ha egy másik applikáció is meg volt nyitva, vagy ha az SMS érkezésekor épp a menüt böngésztem.

A tesztelés keretében több mint 2000 üzenetet küldtünk, így néhány hónap múlva már szinte otthon is állandóan a projektünkben használt jellegzetes rezgést hallottam. Miután rájöttünk, hogy az akkumulátor 5 óra alatt lemerül, egy igen intenzív, minden részletre kiterjedő internetes kutatómunka és ötletelés következett, amelynek eredményeképpen végül sikerült egy 9-10 órás élettartamot elérnünk. A tapasztalatok fényében eszközölt javításoknak és a segítőkész kollégák közreműködésének köszönhetően megvalósult projekt sikeresen debütált a T-Systems tavalyi Symposium-án.