CC BY
21
ANDROID. PERFORMANCE PATTERNS Uyen V.1, Thao L.2, Hieu L.3, Khoe N.4, Lam N.5, Huong L.6 (Russian Federation)
1Uyen Vu - Student, DEPARTMENT OF IT IN THE FUEL AND ENERGY INDUSTRY, FACULTY OF LASER AND LIGHT ENGINEERING;
2Thao Le - Student, DEPARTMENT OF GEOINFORMATION SYSTEMS, FACULTY OF INFOCOMMUNICATION TECHNOLOGIES; 3Hieu Le - Student; 4Khoe Nguyen - Student, DEPARTMENT OF SECURE INFORMATION TECHNOLOGIES, FACULTY OF INFORMATION SECURITY AND COMPUTER TECHNOLOGIES; 5Lam Nguyen - Student; 6Huong Luu - Student, DEPARTMENT OF COMPUTER SYSTEM DESIGN AND SECURITY, FACULTY OF INFORMATION SECURITY AND COMPUTER TECHNOLOGIES, SAINT-PETERSBURG NATIONAL RESEARCH UNIVERSITY OF INFORMATION TECHNOLOGIES, MECHANICS AND OPTICS, SAINT PETERSBURG
Abstract: during the term "test mobile technology" hide different kinds of tests, including testing of applications specifically designed for mobile devices, mobile testing and testing mobile Web applications. Under the testing of mobile applications Test refers to activities undertaken in relation to applications using the worked test methods and tools to ensure compliance with the stated function, behavior, performance, and quality of service features: mobility, ease of use, interoperability, connectivity, security and privacy. Keywords: service, system, data, resource, framework.
ANDROID. ПРЕДСТАВЛЕНИЕ ПАТТЕРНЫ Уиен В. Т. Ф.1, Тхао Л. Д.2, Хиеу Л. В.3, Кхое Н. Х.4, Лам Н. Ч.5, Хыонг Л. Ч. Т. Т.6 (Российская Федерация)
1Уиен Ву Тхи Фыонг - студент, кафедра информационных технологий топливно-энергетического комплекса, факультет лазерной и световой инженерии; 2Тхао Ле Дык - студент, кафедра геоинформационных систем, факультет инфокоммуникационных технологий;
3Хиеу Ле Ван - студент; 4Кхое Нгуен Хыу - студент, кафедра безопасных информационных технологий, факультет информационной безопасности и компьютерных технологий; 5Лам Нгуен Чонг - студент; 6Хыонг Лыу Чан Тхи Тхьен - студент, кафедра проектирования и безопасности компьютерных систем, факультет информационной безопасности и компьютерных технологий, Санкт-Петербургский национальный исследовательский университет информационных технологий, механики и оптики, г. Санкт-Петербург
Аннотация: за термином «тестирование мобильных технологий» скрываются различные виды испытаний, в том числе тестирование приложений, специально предназначенных для мобильных устройств, тестирование мобильных устройств и тестирование мобильных веб-приложений. Под тестированием мобильных приложений понимаются тестовые мероприятия, проводимые по отношению к приложениям с использованием проработанных тестовых методов и инструментов,
European science № 2(24) ■ 32
гарантирующих соответствие заявленным функциям, поведению, производительности, качеству обслуживания и характерным особенностям: мобильности, удобству использования, интероперабельности, связности, безопасности и конфиденциальности.
Ключевые слова: сервис, система, данные, ресурс, фреймворк.
Services are an integral component for almost every mobile application, but the functionality they provide comes with a drain on battery and system resources. And if you're not paying attention, they can get a little greedy with that, too. Using services in the most efficient way possible means killing them off the right way and sometimes not even using them. Remember, services are how an application indicates to the operating system that it needs to perform a longer running operation outside of normal activity UI flow. Basically, you can do work and don't have to wait for input events to do it. Which is all great, but there's a few things you need to be aware of.
Firstly, that from a system-level, services aren't free. Creating, scheduling, running, and even destroying services costs time and memory. Secondly, services run on the UI thread of your application, which is trying to update the screen every 16 milliseconds or so. This means if you're doing a bunch of work in a service, you can easily miss that 16 millisecond window and end up dropping a frame. Now, let me be very clear about this. In 90% of the cases, the best way to avoid these issues is to not use a service. In fact, there's a lot of situations where services are being used when they don't need to be. For example, using a service to listen and respond to events is way overkill. APIs like BroadcastReceiver can still respond fine to events even when your app is running in the background. This goes double for spinning up a service just to poll a server for data. Again, bad idea. You should be leveraging Google Cloud Messaging instead to allow the server to push updates to you which you can still receive in your app directly without needing a service running. And if you know that your work is going to be happening in the background, then it doesn't make sense to bother the framework to be scheduling services for you. Instead, try using an actual threading setup, like IntentServices, or Async Task Loaders, all of which will get you the same result but with less scheduling overhead on the system, and actually get your things off the UI thread. Which is a bonus, as well [1].
Basically, there's lots of options provided by the framework to do various types of asynchronous work without needing to resort to the overhead that services demand. So if you can, try to leverage one of those solutions first. But if you've exhausted all of those options and you still find that a service is the only way to solve the problem, then you need to adhere to the one primary rule of services, do not let services live longer than they are needed. You've got to remember there's two distinct types of services with two distinct ways to terminate them. See, started services stay alive until they are explicitly stopped with a stopSelf or stopService call, or your app ends. Until then, the service just sits around waiting to process things and eating up resources. Now, a bound service, on the other hand, stays around and consumes system resources until all of its clients unbind from it by calling unbindService or your app ends. Now, mixing these two services is useful but it's a common source of errors. For example, calling to create your service and then calling bindService on it for IPC communication. The problem here is that even when the client calls unbindService, it won't terminate yet because it's waiting around for a stopService to be called. The gist is this, you must get your pairing of start, stop, bind, and unbind right before this service will actually terminate, and basically, that's the trick with services. Avoid them if you can. And if you are using them, make sure that you're not letting them ramble off into the weeds for longer than they should be. And if you have a suspicion that your services might be doing that, Systrace is a great visual tool to help you see where your system time is going and what apps are responsible for it. And that's what Android Performance Patterns are all about making sure you're doing the right things at the right times so that you don't
33 ■ European science № 2(24)
waste resources or perf cycles. Which is why you should check out the rest of the Android
Performance Patterns content [2].
Список литературы /References
1. Android Performance Patterns: Rescue tips. [Электронный ресурс]. Режим лоступа: https://android.jlelse.eu/android-performance-patterns-rescue-tips-8cle4c7cbli0#.meklsa7ns/ (дата обращения: 03.04.2016).
2. Google's Android Performance Patterns. [Электронный ресурс]. Режим доступа: https://www.infoq.com/news/2015/01/google-android-performance/ (дата обращения: 08.01.2015).
Список литературы на английском языке /References in English
1. Android Performance Patterns: Rescue tips. [Electronic resource]. URL: https://android.jlelse.eu/android-performance-patterns-rescue-tips-8c1e4c7cb1f0#.meklsa7ns/ (date of access: 03.04.2016).
2. Google's Android Performance Patterns. [Electronic resource]. URL: https://www.infoq.com/news/2015/01/google-android-performance/ (date of access: 08.01.2015).
European science № 2(24) ■ 34
