Колись давно, я потис пост «Чи потрібні Андроїд кілери? Остаточне вирішення питання »досить поверхневий. Але фундаментальні поняття не можна описати просто двома словами. І ось, через роки, на новому рівні Андроїд програміста повертаюся до питання.
Платформа Android є досить унікальною в тому сенсі, що дозволяє декільком додаткам працювати одночасно. Розробники прийшли з іншої платформи можуть знайти спосіб, завдяки якому це працює, несподіваним. Розуміння мультизадачности в Android має важливе значення для розробки додатків, які будуть добре працювати і інтегруватися з іншою частиною Android платформи. У даній статті розглядаються основи многозадачного дизайну Android, його впливу на те, як працюють програми, і як ви можете найкращим чином скористатися унікальними особливостями Андроїд.
Старший розробник Android Діана Хакборн (Dianne Hackborn)
проектні вимоги
1. Не потрібно, щоб користувачі закривали додатки, коли закінчили працювати з ними. Це характерно для комп'ютерів, але не дуже добре працює в мобільному середовищі, де є потреба в частому короткочасному повторному використанні багатьох додатків протягом усього дня.
4. Доступні інтерфейси API повинні бути достатніми для написання вбудованих додатків Google, як частина філософії «всі програми створені рівними». Це означає, що фонове відтворення музики, синхронізація даних, GPS навігація і завантаження додатків повинні бути реалізовані за допомогою тих же API, які доступні для сторонніх розробників.
Перші дві вимоги конфліктують між собою.
Ми не хочемо, щоб користувачі турбувалися про закриття своїх додатків, потрібно зробити вигляд, що всі програми завжди працюють. У той же час, мобільні пристрої мають жорсткі обмеження на використання пам'яті, так що система буде деградувати або навіть давати збої, оскільки цей принцип буде вимагати більше оперативної пам'яті, ніж є в наявності. На відміну від цього настільний комп'ютер з файлом підкачки просто почне повільніше працювати. Ці конкуруючі обмеження були ключовим мотивом в розробці Android.
Коли додаток зупиняється?
Поширена непорозуміння багатозадачності Android лежить на відміну між процесом (process) і додатком (application). У Андроїд вони не є тісно пов'язаними сутностями.
Додатки можуть бути показані користувачеві, але не мати реально працюючого в даний час процесу. Кілька додатків можуть спільно використовувати процеси, або один додаток може використовувати кілька процесів в залежності від його потреб; процес (и) додатки можуть залишатися в Android, навіть якщо це додаток вже не активно і нічого не робить.
Той факт, що ви можете побачити, що додаток «працює» (running) не означає, що додаток реально працює чи робить що-небудь. Просто система Андроїд вирішила не вбивати процес, а залишити його на випадок, якщо воно знадобиться в майбутньому.
Крім того, ви можете вийти із програми на деякий час щоб повернутися до нього в те місце, де ви зупинилися, і протягом цього часу, можливо, Android може позбутися будь-якого процесу, щоб звільнити ресурси для інших потреб.
Ключ до розуміння того, як Android обробляє додатки в тому, що процеси не зупиняються начисто. Коли користувач залишає додаток, його процес зберігається в фоновому режимі, що дозволяє йому продовжувати працювати (наприклад, завантаження веб-сторінок), якщо це необхідно, і відразу ж переходить на передній план, якщо користувач повертається до нього. Поки вистачає пам'яті Андроїд НЕ буде вбивати процеси, тобто вони будуть «running» весь цей час.
Звичайно, оскільки існує обмежений обсяг пам'яті, Android повинен вирішити коли позбутися від процесів які не потрібні. Детальніше тут «Основи створення додатків». Рішення завершувати процес чи ні засновано тому, наскільки важливий процес для поточної роботи користувача і скільки часу пройшло з тих пір, як цей процес останній раз був необхідний користувачеві.
Після того, як Android визначив, що йому необхідно видалити процес, він робить це жорстоко, просто насильно вбиваючи його. При цьому ядро системи звільняє всі зайняті ресурси, незалежно від того наскільки добре написано додаток. Це спрощує операції з пам'яттю і прискорює реакцію на багато серйозно ситуації.
Якщо користувач пізніше повертається до додатка, яке було вбито, Android'у потрібен спосіб, щоб повторно запустити його в тому ж стані, як це було в останній раз, щоб відповідати принципу «всі програми працюють весь час» (all applications are running all of the time). Це робиться шляхом відстеження частин призначеного для користувача додатки (активностей), і знову запускаючи їх з інформацією про останній стані. Це останній стан генерується кожен раз, коли користувач залишає цю частину програми (але не тоді, коли воно було вбито).
Явна робота в фоновому режимі
Отже, у нас є спосіб для додатків неявно працювати у фоновому режимі, поки процес не буде убитий системою Android в рамках свого регулярного управління пам'яттю. Це добре для таких речей, як завантаження веб-сторінок у фоновому режимі, але як щодо більш складних вимог? Відтворення музики у фоновому режимі, синхронізація даних, відстеження місця розташування, будильники і т.д.
Є два основних засоби: Broadcast Receivers і Services.
BroadcastReceiver
Широкомовні повідомлення (BroadcastReceiver) дозволяють додатком працювати, протягом короткого проміжку часу, в фоновому режимі в результаті певної події. Він може бути використаний багатьма способами при створенні об'єктів більш високого рівня: наприклад, AlarmManager дозволяє додатку мати трансляцію відправку в певний час, і LocationManager може послати широковещательное повідомлення, коли він виявляє цікаві зміни в місці розташування. Оскільки інформація про пристрій є частиною manifest, Android може знайти і запустити додаток, навіть якщо воно не працює; Звичайно, якщо у нього вже є свій процес доступний у фоновому режимі, широковещательное повідомлення може дуже ефективно послано безпосередньо до нього.
При обробці Broadcast, додаток отримує фіксований проміжок часу (в даний час 10 секунд), щоб зробити свою роботу. Якщо воно не завершується в зазначений момент, то додаток вважається поганим, і процес негайно переводиться в фонове стан, щоб бути вбитим, якщо знадобиться пам'ять.
Широкомовні повідомлення (BroadcastReceiver) відмінно підходять для невеликих шматочків роботи у відповідь на зовнішнє подія, наприклад, розмістивши повідомлення користувачу після відправки нового звіту про місцезнаходження GPS. Вони дуже легкі, так як процес додатки повинен тільки бути присутнім якщо активні BroadcastReceiver. Оскільки вони є активними в обмежений період часу, досить сильні гарантії можуть бути дані в тому, що їх процес не буде убитий під час виконання. Однак BroadcastReceiver не підходять для завдань невизначеною тривалості, наприклад роботи з мережею.
Служби дозволяють додатком виконувати тривалі за часом фонові операції. Насправді є багато інших функцій, які Служби надають, але в даному контексті їх основною метою є дозволити програмі продовжувати працювати в той час як воно знаходиться в фоновому режимі (тобто не на передньому плані), до тих пір поки робота не буде виконана. Сам додаток контролює, коли його служба працює явно і коли відбувається зупинка служби.
Управління Службами відрізняється від широкомовних повідомлень, так як необмежену кількість Служб можуть запросити запуск на невизначений проміжок часу. І може не бути достатньо оперативної пам'яті, щоб тримати все служби працюють.
Якщо оперативної пам'яті занадто мало, процеси мають служби будуть негайно вбиті, так як вони є фоновими процесами. Проте, в разі необхідності, Android буде пам'ятати, що ці служби хочуть залишитися працювати, і перезапустити їх в більш пізній час, коли стане доступно більше пам'яті (RAM). Наприклад, якщо користувач переходить на веб-сторінку, яка вимагає великої кількості оперативної пам'яті, Android може вбити такі фонові служби, такі як синхронізація, поки не будуть обслужені потреби браузера в пам'яті.
Служби можуть вести додаткові переговори запитуючи «передній план», при цьому служба переходить в стан «будь ласка Не вбивай мене», але вимагає включення повідомлення користувачу про те, що вона активно працює. Це корисно для таких служб, як фонове відтворення музики або навігація, при цьому користувач усвідомлює, що вони активні. Коли ви слухаєте музику, ви завжди можете побачити музичний символ в рядку стану. Android не буде намагатися вбити ці служби, але як компроміс, гарантує, що користувач знає про них і в змозі зупинити їх в явному вигляді при бажанні.
вбудовані компоненти
Вбудовані широкомовні приймачі та служби дозволяють розробникам створювати широкий спектр ефективних фонових операцій.
В Android 1.0 вони були використані для реалізації майже всіх фонових завдань:
- відтворення музики, якщо користувач залишає додаток-плеєр
- повторювані будильники за розкладом
- календар з відображенням повідомлення у відповідний час
- фонове завантаження файлів
- повідомлення про нову електронну пошту
- синхронізація контактів.
У міру того як платформа розвивалася, ті ж самі основні компоненти були використані для здійснення багатьох нових можливостей для розробників:
- методи введення з використанням IME
- віджети
- живі шпалери та ін.
Післямова
У подальших інтерв'ю з розробниками платформи Діана Хакборн (Dianne Hackborn) на питання «що команда Android хотіла б зробити по-іншому на самому початку розвитку платформи?» Відзначила, що потрібно було б спочатку забезпечити більший контроль платформи над додатками, сильніше обмежити з точки зору доступу до деяких системних функцій.
Story by Dianne Hackborn «The Claiming of Peaches»
Читати ще
- Чи потрібні Андроїд кілери? Остаточне вирішення питання
- Припинено підтримка Eclipse Android Developer Tools
- Розуміння упаковки APK в Android Studio 2.2
- Android Studio. Failed to create the SD card
