- Регистрация
- 03.05.2016
- Сообщения
- 682
- Благодарностей
- 421
- Баллы
- 63
Всем привет, пару дней как начал разбираться с ZD. Встал вопрос, как работать с эмуляторами по типу работы профилей в ZP.
Прочитал статью Уменьшение размера машины ZennoDroid для хранения. замечательная статья, но размер машин все равно большой, даже без работы.
Проблема:
Создание отдельных машин кушает много места и чем дольше работает, тем больше занимает места, счет идет на Гб.
- Даже при использовании общего системного диска образ занимает 1-2Гб с одним установленным яндекс браузером.
- Даже если архивировать .vmdk это 500-800 Мб, + время на распаковку\архивацию.
А это машины еще не начинали работать.
Нашел группу методов:
- app.GetCookie(pack);
- app.GetCookiePath(pack);
- app.BackupAppData(pack, path);
- app.RestoreAppData(pack, path);
GetCookie - получает куки приложения, но что с ними делать, если нет метода загрузки кук на другую машину.
GetCookiePath - получает путь где лежат куки в бэкап, но посмотреть файл с куками не получается (надо разбираться)
BackupAppData и RestoreAppData получаем все данные приложения со всеми куками и можем их загрузить на другую машину. Вес бэка маленький, вроде как не плохая альтернатива работы профилей ZP.
Логика работы через бэкапы:
- Создаем машину
- Устанавливаем нужное для работы приложение, авторизуемся если надо
- Работаем
- Делаем бэкап приложения
- Удаляем машину
Для дальнейшей работы:
- Создаем новую машину
- Подгружаем бэкап
- Работаем
- Сохраняем в новый бэкап
- Удаляем машину
Но тут встает другая проблема. Все машины имеют разные идентификаторы, и если мы будем бэкапить одну и туже прилку по разным машинам, для антифрод системы это должно быть очень подозрительно.
Получается это тоже не лучший вариант решения проблемы.
Хочется услышать, как работают опытный пользователи ZennoDoroid если есть необходимость работать с большим количеством уникальных машин в которых хранится история работы(аккаунты\куки) работы.
Прочитал статью Уменьшение размера машины ZennoDroid для хранения. замечательная статья, но размер машин все равно большой, даже без работы.
Проблема:
Создание отдельных машин кушает много места и чем дольше работает, тем больше занимает места, счет идет на Гб.
- Даже при использовании общего системного диска образ занимает 1-2Гб с одним установленным яндекс браузером.
- Даже если архивировать .vmdk это 500-800 Мб, + время на распаковку\архивацию.
А это машины еще не начинали работать.
Нашел группу методов:
- app.GetCookie(pack);
- app.GetCookiePath(pack);
- app.BackupAppData(pack, path);
- app.RestoreAppData(pack, path);
GetCookie - получает куки приложения, но что с ними делать, если нет метода загрузки кук на другую машину.
GetCookiePath - получает путь где лежат куки в бэкап, но посмотреть файл с куками не получается (надо разбираться)
BackupAppData и RestoreAppData получаем все данные приложения со всеми куками и можем их загрузить на другую машину. Вес бэка маленький, вроде как не плохая альтернатива работы профилей ZP.
Логика работы через бэкапы:
- Создаем машину
- Устанавливаем нужное для работы приложение, авторизуемся если надо
- Работаем
- Делаем бэкап приложения
- Удаляем машину
Для дальнейшей работы:
- Создаем новую машину
- Подгружаем бэкап
- Работаем
- Сохраняем в новый бэкап
- Удаляем машину
Но тут встает другая проблема. Все машины имеют разные идентификаторы, и если мы будем бэкапить одну и туже прилку по разным машинам, для антифрод системы это должно быть очень подозрительно.
Получается это тоже не лучший вариант решения проблемы.
Хочется услышать, как работают опытный пользователи ZennoDoroid если есть необходимость работать с большим количеством уникальных машин в которых хранится история работы(аккаунты\куки) работы.
