Жизненный цикл мобильного приложения

Три состояния и выгрузка

Состояний три. Открыто - приложение на экране и работает. Свёрнуто - человек ушёл в другое, но процесс жив и данные в памяти на месте. Выгружено - система забрала память для чего-то другого, процесс убит, память очищена.

Третье состояние и есть источник большинства жалоб, потому что наступает оно постоянно и без предупреждения: телефон с двумя гигабайтами памяти выгружает фон быстро, а прошивки некоторых производителей - их доработанные версии системы - делают это ещё агрессивнее ради батареи. Для человека это выглядит как «я же просто ответил на звонок» - он не знает и не должен знать, что приложение убили.

// Значит, проверка формулируется так: свернуть, дождаться выгрузки (её можно вызвать принудительно из настроек разработчика), вернуться - и увидеть тот же экран с теми же данными, а не белый лист и пустую корзину. Всё, что человек ввёл и не отправил, приложение обязано сохранить не в памяти, а в хранилище на устройстве. Тестировать только живое приложение - значит не проверить самый частый реальный сценарий.

свёрнуто / выгружено

процесс жив, данные в памяти / процесс убит, память очищена

восстановление состояния

возврат на тот же экран с теми же данными после выгрузки

Старты и поворот экрана

Старты различают по тому, что уже готово. Холодный - процесса нет вовсе, всё поднимается с нуля: самый долгий и самый хрупкий. Тёплый - процесс жив, но экраны пересоздаются. Горячий - приложение просто возвращается из фона, почти мгновенно. Меряют и проверяют их отдельно, потому что человек оценивает приложение именно по холодному старту: он первый.

Отдельная особенность Android: поворот экрана, смена языка или темы пересоздают экран заново. Всё, что лежало в памяти экрана и не было сохранено явно, при этом теряется - отсюда вечная классика с опустевшей формой после поворота телефона.

// Поэтому поворот прогоняют на каждой форме с заполненными полями, а не «на всякий случай один раз». И проверяют не сам поворот в одиночку: смена системной темы на тёмную и смена языка системы делают ровно то же самое.

холодный старт

запуск с нуля: самый долгий путь и первое впечатление о продукте

пересоздание экрана

поворот, смена языка или темы: несохранённое в памяти теряется

Ссылки и уведомления по состояниям

Ссылка, ведущая внутрь приложения на конкретный экран, - отдельный объект тестирования, и проверять её надо во всех трёх состояниях. В открытом приложении она почти всегда работает: всё уже поднято. В выгруженном тот же путь требует запустить процесс, восстановить сессию (то есть понять, что человек уже входил и заново логинить его не надо), разобрать адрес и открыть нужный экран - и если что-то из этого не совпало, человек видит главную вместо товара или белый экран.

Дополнительные ветки, которые обычно не проверяют: ссылка у неавторизованного (после входа должен открыться исходный экран, а не главная), ссылка на удалённый товар (внятное сообщение, а не пустой экран), ссылка на функцию, которой нет в его версии приложения.

// Уведомления проверяют по тем же трём состояниям, и поведение у них разное. В свёрнутом - системная плашка. В открытом - системную плашку показывать обычно не принято, и приложение рисует своё сообщение внутри; если этого не сделали, уведомление молча пропадёт. В выгруженном - нажатие должно поднять приложение и открыть тот экран, о котором уведомление, вместе с его содержимым.

ссылка внутрь приложения

адрес, открывающий конкретный экран; самый хрупкий путь - в выгруженное

уведомление по состояниям

в фоне, в открытом и в выгруженном ведёт себя по-разному

Как отвечать: «Как тестировать жизненный цикл приложения?»

Отталкиваюсь от того, что переходы между состояниями - это точки, где теряются данные, и проверяю именно их, а не одно лишь живое приложение. Главный сценарий - выгрузка системой: сворачиваю приложение, принудительно вызываю выгрузку процесса, возвращаюсь - и жду, что увижу тот же экран с теми же данными, а не белый лист и пустую корзину. Это самая частая реальная ситуация, потому что система забирает память постоянно, а на некоторых прошивках ещё и агрессивнее ради батареи. Дальше холодный старт: он самый долгий и по нему человек судит о приложении. Отдельно проверяю вход по ссылке - я считал пути входа, их двенадцать: четыре источника на три состояния, - и самый хрупкий это ссылка в выгруженное приложение, где надо одновременно подняться, восстановить сессию и открыть нужный экран. На Android обязательно гоняю поворот на каждой заполненной форме, потому что поворот пересоздаёт экран и несохранённое исчезает; туда же смена темы и языка. Уведомления проверяю во всех трёх состояниях, потому что ведут они себя по-разному, и в открытом приложении легко теряются.

Почему это сильный ответ: акцент на переходах как точках потери, главный сценарий назван и описан по шагам, входы посчитаны, и добавлены поворот и уведомления с объяснением, почему они ломаются.

На чём валят

• −Тестировать только живое приложение: возврат после выгрузки даёт белый экран или пустую корзину.
• −Проверить ссылку в открытом приложении и не проверить её в выгруженном - там она чаще всего и ломается.
• −Не прогнать поворот на каждой заполненной форме: пересоздание экрана стирает несохранённое.
• −Проверить уведомление только в фоне - в открытом приложении оно молча не показалось.
• −Забыть про вход по ссылке у неавторизованного: после входа открывается главная, а не исходный экран.