- Студия Android занимает слишком много памяти
- ОТВЕТЫ
- Ответ 1
- Ответ 2
- Android Studio (до 1,5 ГБ)
- Gradle (до 1,5 ГБ)
- Эмулятор
- Ответ 3
- Ответ 4
- Ответ 5
- Ответ 6
- Ответ 7
- Ответ 8
- Ответ 9
- Ответ 10
- Ответ 11
- Ответ 12
- Большие требования к памяти в Android – что делать?
- Для начала немного теории
- Анализ памяти кучи
- Утечки памяти
- Высвобождайте память в ответ на события
- Большая куча
- Проверка, сколько памяти сможет использовать ваше приложение
- Используйте оптимизированные структуры данных
- Предотвращайте перемешивание памяти
Студия Android занимает слишком много памяти
Я установил Android Studio 1.0 RC 2. У меня установлено 4 ГБ ОЗУ, но после запуска Android Studio и запуска Android-эмулятора более 90% физической памяти использовались только этими двумя. Есть ли способ уменьшить использование этой памяти? Из-за этой проблемы с памятью я не могу одновременно открывать другие приложения.
ОТВЕТЫ
Ответ 1
В настоящее время я использую Android Studio на компьютере под управлением Windows 8.1 с 6 гигабайтами оперативной памяти.
Я обнаружил, что отключение VCS в Android Studio и использование внешней программы для управления VCS очень помогли. Вы можете отключить VCS, зайдя в Файл → Настройки → Плагины и отключив следующее:
- Интеграция CVS
- Интеграция с Git
- GitHub
- Google Cloud Testing
- Google Cloud Tools Core
- Облачные инструменты Google для Android Studio
- hg4idea
- Интеграция Subversion
- Mercurial Integration
- TestNG-J,
Ответ 2
В моем случае существовали два основных источника памяти: IDE и Gradle:
Android Studio (до 1,5 ГБ)
JVM IDE настроен на максимальный размер кучи. Вы можете увидеть это в нижнем правом углу основного интерфейса:
Это можно уменьшить, отредактировав связанные с памятью настройки в файле .vmoptions . Например, я изменил максимальный размер кучи на 512 МБ:
К сожалению, я обнаружил, что снижение этого значения увеличивает частоту замораживания Android Studio, возможно, для его сбора мусора.
Gradle (до 1,5 ГБ)
Gradle также может использовать много оперативной памяти после разработки на некоторое время. Windows просто показывает его как Java(TM) Platform SE Binary :
Вы можете исправить это, изменив параметры Gradle JVM. Вы можете сделать это для каждого пользователя, отредактировав gradle.properties :
- Откройте файл gradle.properties , создав его, если он не существует:
- Windows: %USERPROFILE%\.gradle\gradle.properties
- Linux/Mac:
Обновите свойство org.gradle.jvmargs , создав его, если необходимо. Я поставил свое на это:
Я не заметил никакой разницы в производительности сборки для моего небольшого проекта с максимальным размером кучи, установленным на 256 МБ ( -Xmx256m ).
Обратите внимание, что вам может потребоваться перезапустить Android Studio, чтобы старый Gradle процесс был убит; в противном случае вы можете запустить оба одновременно.
Эмулятор
Что касается эмулятора, занимающего много вашей оперативной памяти, ваш скриншот показывает, что он занимает около 800 МБ. Вы можете выбрать, сколько ОЗУ выделять эмулятору:
- Отредактируйте AVD
- Нажмите «Показать дополнительные настройки»
- Уменьшить значение ОЗУ
Ответ 3
Вы можете ускорить работу Eclipse или Android Studio, вы просто выполните следующие действия:
- Использовать/открывать один проект за раз
- очищайте свой проект после запуска приложения в эмуляторе каждый раз
- использовать мобильное/внешнее устройство вместо эмулятора
- Не закрывайте эмулятор после использования один раз, используйте один и тот же эмулятор для запуска приложения каждый раз
- Отключить VCS с помощью File- > Settings- > Plugins и отключить следующие функции:
1.CVS-интеграция
Интеграция 2.Git
3.GitHub
4. Google Cloud Tools для Android Studio
5. Интеграция с преобразованием
Я также использую Android Studio с установленной 4 ГБ основной памятью, но после этих инструкций действительно повышается производительность Android Studio.
Ответ 4
Android Studio недавно опубликовала официальное руководство для компьютеров с небольшим объемом памяти: Руководство
Если вы используете Android Studio на компьютере, характеристики которого меньше рекомендуемых (см. системные требования), вы можете настроить среду IDE для повышения производительности на своем компьютере следующим образом:
Уменьшите максимальный размер кучи, доступный для Android Studio. Уменьшите максимальный размер кучи для Android Studio до 512 МБ.
Обновите Gradle и плагин Android для Gradle: обновите до последних версий Gradle и плагин Android для Gradle, чтобы убедиться, что вы используете последние улучшения производительности.
Включение режима энергосбережения. Включение режима энергосбережения отключает ряд memory- и фоновых операций, требующих значительного расхода энергии, включая выделение ошибок и проверки на лету, автозаполнение кода и автоматическую инкрементную компиляцию фона. Чтобы включить режим энергосбережения, выберите «Файл»> «Режим энергосбережения».
Отключение ненужных проверок ворса. Чтобы изменить проверку ворса Android Studio, выполните следующие действия: Нажмите «Файл»> «Настройки» (на Mac, Android Studio> «Настройки»), чтобы открыть диалоговое окно «Настройки». На левой панели разверните раздел «Редактор» и нажмите «Инспекции». Установите флажки, чтобы выбрать или отменить выбор проверок ворса в соответствии с вашим проектом. Нажмите Применить или ОК, чтобы сохранить изменения.
Отладка на физическом устройстве: для отладки в эмуляторе используется больше памяти, чем для отладки на физическом устройстве, поэтому вы можете улучшить общую производительность Android Studio, отладив на физическом устройстве.
Включить в качестве зависимостей только необходимые службы Google Play. Включение служб Google Play в качестве зависимостей в ваш проект увеличивает объем необходимой памяти. Включайте только необходимые зависимости для улучшения использования памяти и производительности. Дополнительную информацию см. в разделе «Добавление сервисов Google Play в ваш проект».
Уменьшите максимальный размер кучи, доступный для компиляции файла DEX. Установите для javaMaxHeapSize для компиляции файла DEX значение 200 м. Дополнительную информацию смотрите в разделе Улучшение времени сборки за счет настройки ресурсов DEX.
Не включайте параллельную компиляцию: Android Studio может компилировать независимые модули параллельно, но если у вас недостаточно системы памяти, вам не следует включать эту функцию. Чтобы проверить этот параметр, выполните следующие действия: Нажмите Файл> Настройки (на Mac, Android Studio> Настройки), чтобы открыть диалоговое окно «Настройки». На левой панели разверните Построение, Выполнение, Развертывание и затем нажмите Компилятор. Убедитесь, что опция «Компилировать независимые модули параллельно» не отмечена. Если вы внесли изменение, нажмите «Применить» или «ОК», чтобы изменения вступили в силу.
Включение автономного режима для Gradle. Если у вас ограниченный полосовой переключатель, включите автономный режим, чтобы не допустить попытки Gradle загрузить отсутствующие зависимости во время сборки. Когда автономный режим включен, Gradle выдаст ошибку сборки, если у вас отсутствуют какие-либо зависимости, вместо того, чтобы пытаться загрузить их. Чтобы включить автономный режим, выполните следующие действия:
Нажмите Файл> Настройки (на Mac, Android Studio> Настройки), чтобы откройте диалоговое окно настроек.
На левой панели разверните Построение, Выполнение, Развертывание и затем нажмите Gradle.
В разделе «Глобальные настройки Gradle» установите флажок «Автономная работа».
Нажмите Apply или OK, чтобы изменения вступили в силу.
Ответ 5
Я использовал все рекомендации Сэма выше, но я обнаружил, что параметры командной строки VM больше не поддерживаются, как описано. (Я получил ошибку при использовании)
В качестве альтернативы я смог значительно уменьшить gradle, добавив следующую строку в файл gradle.properties
По А.С. ver 1.3, файл находится на том же уровне папки, что и «gradle.build».
Вышеупомянутая конфигурация представляет собой «стек памяти» 512 мегабайт и «кучу памяти» 1024 мегабайта.
Я тестировал это на небольшом проекте, используя настройки, в которых оба размера памяти были установлены на 256 мегабайт. Он ограничивал размеры JVM, как ожидалось. Во всех моих тестах я перезапустил A.S. для принудительной перезагрузки JVM.
Надеемся, что это спасет других, занимающихся этой проблемой, от получения ответов «Получите себя лучше».: -)
Ответ 6
Чтобы уменьшить отставание, я бы рекомендовал следующие шаги
my pc specs: 2 gb ram, процессор: intel core2 duo
сначала убейте весь фоновый процесс, если у вас есть сервер или база данных, вы можете сначала остановить их с помощью следующих команд
sudo service apache2 stop
sudo service mysql stop
Затем включите режим энергосбережения в студии android по файлу > режим энергосбережения
Он может отключить фоновый процесс, а затем студия выглядит хорошо
Ответ 7
Чтобы запустить Android-приложение на низкоуровневой машине.
- Закройте ненужные веб-вкладки в браузере
- Для пользователей антивируса исключить автоматически создаваемую папку
- Android-студия имеет 1.2 Гб по умолчанию может уменьшиться до 512 МБ
Справкa > Редактирование пользовательских параметров VM
Макеты будут ускоряться
- Для Gradle один из основных компонентов в студии Android Mkae уверен как сейчас, 3.0betastrong > является последним
Ниже приведены советы, которые могут повлиять на качество кода, поэтому используйте с осторожностью:
Студия содержит Режим безопасности при включении, она закрывает фоновые операции, которые повторяются, дополняют код и т.д.
Вы можете запустить ручную проверку lint при необходимости ./gradlew lint
Большинство из них используют Android-эмуляторы, в среднем потребляют 2 ГБ оперативной памяти, поэтому, если возможно, использование реального устройства Android, это уменьшит нагрузку на ваш компьютер. В качестве альтернативы вы можете уменьшить ОЗУ эмулятора, и это автоматически уменьшит потребление виртуальной памяти на вашем компьютере. вы можете найти это в конфигурации виртуального устройства и настройке заранее.
Gradle автономный режим — это функция для пользователей с ограниченной пропускной способностью отключить загрузку зависимостей сборки. Это уменьшит фоновые операции, которые помогут повысить производительность студии Android.
Студия Android предлагает оптимизацию скомпилировать несколько модулей параллельно. На низких операционных системах эта функция, скорее всего, будет иметь негативное влияние на производительность. Вы можете отключить его в диалоговом окне настроек .
Ответ 8
У меня есть Android Studio 2.1.1. Используйте эмулятор genymotion для использования в браузере. Быстрее, если вы используете Android Marshmallow. И My Ram Is 4gb.And Установите плагин для genymotion в Android Studio. Вы увидите хороший результат, вместо того, чтобы тратить время на запуск андроид-эйуматора, это займет 5 минут. От 10 до 20 секунд и быстрее, поэтому я рекомендовал вам использовать genymotion.
Ответ 9
Я люблю это видео YouTube от Google, где есть несколько советов и трюков. Видео также содержит преимущества и недостатки предлагаемых изменений.
Ответ 10
Попробуйте переключить JVM в затмение openj9. Это будет использовать гораздо меньше памяти. Я поменял его, и он использует 600 МБ постоянно.
Ответ 11
нота! не ограничивайте оперативную память до 512 м, потому что в Android Studio 3.3 делают проблемы
Ответ 12
Откройте нижеприведенный путь к вашей системе и удалите все свои avd (Виртуальные устройства: эмулятор)
C:\Users <Имя пользователя>.android\АВД
Примечание: — Удаление Эмулятора только из Android Studio не удалит все пробелы, захваченные их AVD. Так что удалите все avd из указанного выше пути, а затем создайте новый эмулятор, если вам нужно.
Источник
Большие требования к памяти в Android – что делать?
Здравствуйте, уважаемые читатели.
Сегодня предлагаем вашему вниманию небольшой материал о грамотном использовании памяти в Android.
Приятного чтения!
Эта статья посвящена базовым приемам управления использованием памяти в приложениях – например, в браузерах, фоторедакторах и программах для просмотра PDF – в которых предъявляются большие запросы к памяти.
Для начала немного теории
Большинство приложений для Android работают поверх среды исполнения (ART), заменившей ныне устаревающую виртуальную машину Dalvik. ART и Dalvik похожи на виртуальную машину Java (JVM), с которой их роднят схожие принципы проектирования. Они используют для хранения данных приложений два отдельных пространства: стек и кучу.
Стек-память в Java используется для хранения локальных переменных (примитивных типов и ссылок на объекты). Каждый поток Java имеет собственный отдельный стек. Стек-память относительно невелика по сравнению с памятью кучи. Размер стека Java в Dalvik обычно составляет 32 KB для кода Java и 1 MB для нативного кода (C++/JNI). В ART появился унифицированный стек для Java и C++, размер которого составляет около 1 MB.
Когда приложение выбирает всю стек-память до предела, выдается ошибка StackOverflowError . Наиболее вероятные причины, по которым может быть достигнут предел стека – либо бесконечная рекурсия, либо чрезмерно глубокий вызов метода. Ссылки на стек-память всегда делаются в очередности LIFO (последним пришел – первым обслужен). Всякий раз при вызове метода в стек проталкивается новый фрейм с локальными переменными этого метода. Когда метод завершит работу, его фрейм выталкивается из стека, и любое возможное результирующее значение отправляется обратно в стек. Итак, первая проблема (бесконечная рекурсия) – это баг, который легко исправить, но вторая требует некоторого рефакторинга, заключающегося в разворачивании рекурсивных вызовов метода и преобразования их в цикл.
Память кучи в Java используется виртуальной машиной для выделения объектов. Когда бы ни создавался объект, это происходит в куче. Виртуальные машины, например, JVM или ART, выполняют регулярную сборку мусора, убирают все объекты, на которые больше не осталось ссылок, и таким образом высвобождают память для выделения новых объектов.
Для обеспечения удобства использования Android жестко ограничивает размеры кучи для каждого работающего приложения. Предельный размер кучи варьируется от устройства к устройству и зависит от того, сколько RAM на этом устройстве. Если ваше приложение достигает предельного размера кучи и пытается выделить еще памяти, то выдается ошибка OutOfMemoryError , и приложение завершается. Давайте рассмотрим некоторые примеры, помогающие избежать такой ситуации.Анализ памяти кучи
Самый важный инструмент, позволяющий разобраться с проблемами памяти в ваших приложениях и понять, как используется память – это профилировщик памяти, доступный в Android Studio.
Этот инструмент визуализирует, сколько памяти потребляет ваше приложение с течением времени. Можно делать мгновенные снимки кучи Java в работающем приложении, записывать операции выделения памяти и следить за кучей или этой хронологией выделений памяти в мощном UI.
Типичный сеанс работы с профилировщиком памяти должен выглядеть так:
- Отсматриваем наиболее частые выделения памяти и проходы сборщика мусора для выявления возможных проблем с производительностью.
- Отсматриваем, как использовалась память с течением времени, в особенности такие операции, на которые, как известно, требуется выделять много памяти. Убедитесь, что после завершения этих операций использование памяти снижается. Например, ниже показано, как воздействует на память активность PdfActivity из PSPDFKit после загрузки документа.
- Делаем дамп кучи в разные моменты времени исполнения вашего приложения и проверяем, как используется память. Ищем большие объекты, которые хранятся в памяти и не подпадают под сборку мусора. Дампы кучи также помогают выявить утечки памяти – например, можно поискать в дампе кучи ваши активности и посмотреть, были ли собраны их старые экземпляры.
Утечки памяти
Современные сборщики мусора – это сложные произведения технологического искусства, результат многолетних исследований и разработок, в которых участвовали сотни людей, от академиков до разработчиков-профессионалов. Однако до сих пор приходится быть начеку, чтобы не допускать утечек в памяти.
Образцовое решение для выявления утечек в памяти – библиотека LeakCanary. Она автоматически выдает уведомления, когда в вашей тестовой сборке (development build), выдавая вам стектрейс утечки в UI этой программы. Можно (и следует) интегрировать ее уже сегодня, тем более, что это не сложно!
Особенно легко спровоцировать утечки памяти, работая со сложными жизненными циклами активностей или фрагментов Android. Такое часто случается в тех точках, где разработчики удерживают сильные ссылки на контексты UI или другие UI-специфичные объекты в фоновой задаче или в статических переменных. Один из способов спровоцировать такие задержки – активно покрутить устройство, когда тестируете ваше приложение.
Высвобождайте память в ответ на события
Android может затребовать у приложения выделенную память или просто принудительно завершить его, когда память необходимо высвободить для выполнения более критичных задач. Прежде, чем это произойдет, система позволит вам отдать всю память, которая вам не нужна. В вашей активности понадобится реализовать интерфейс ComponentCallbacks2 . В таком случае, всякий раз, когда ваша система будет испытывать дефицит памяти, поступит вызов к вашему методу onTrimMemory() , и вы сможете высвободить память или отключить те возможности, которые не будут работать в таких условиях дефицита памяти.
Так, подобные обратные вызовы обрабатываются в приложении PSPDFKit. Приложение PSPDFKit проектировалось с расчетом активного использования памяти для кэширования, чтобы работа с приложением шла как можно более гладко. Исходно неизвестно, сколько памяти доступно на устройстве, поэтому PSPDFKit адаптируется к ситуации и ограничивает использование памяти, когда получает уведомления о том, что памяти недостаточно. Поэтому приложения, интегрированные с PSPDFKit, работают даже на низкотехнологичных устройствах, но со сниженной производительностью из-за того, что кэширование отключено.
Большая куча
Одно из лобовых решений, позволяющих справиться с высокими требованиями к памяти – запросить большую кучу Dalvik для вашего приложения. Для этого можно добавить android:largeHeap=»true» к тегу в файле AndroidManifest.xml .
Если для свойства largeHeap задано значение true , Android будет создавать все процессы для вашего приложения с большой кучей. Эта настройка предназначена только для тех приложений, которые по природе своей без нее работать не смогут, то есть, они используют объемные ресурсы, которые должны одновременно умещаться в памяти.
Настоятельно не рекомендуется использовать большую кучу, если тем самым вы хотите только поднять потолок возможного использования памяти. Использование памяти всегда нужно оптимизировать, поскольку даже большой кучи вашему приложению может не хватить при работе на слабом устройстве с небольшой памятью.
Проверка, сколько памяти сможет использовать ваше приложение
Никогда не помешает проверить, насколько велика куча вашего приложения и динамически адаптировать ваш код и доступные возможности под эти пределы памяти. Можно прямо во время исполнения проверить максимальный размер кучи при помощи методов getMemoryClass() или getLargeMemoryClass() (когда включена большая куча).
Android поддерживает даже такие устройства, на которых всего 512 MB RAM. Убедитесь, что не обошли вниманием и низкотехнологичные устройства! При помощи метода isLowRamDevice() можно проверить, не запущено ли ваше приложение на таком устройстве, где мало доступной памяти. Точное поведение этого метода зависит от устройства, но обычно он возвращает true на тех устройствах, где меньше 1 GB RAM. Нужно убедиться, что ваше приложение корректно работает и на этих устройствах, и на них отключать все возможности, использующие большой объем памяти.
Подробнее о том, как Android работает на устройствах с малым объемом памяти, можно почитать здесь; здесь же даются дополнительные советы по оптимизации.
Используйте оптимизированные структуры данных
Во многих случаях приложения используют слишком много памяти по той простой причине, что для них используются не самые подходящие структуры данных.
Коллекции Java не могут хранить эффективные примитивные типы и требуют упаковки их ключей и значений. Например, HashMap с целочисленными ключами следует заменять оптимизированным SparseArray . В конечном итоге, вместо коллекций всегда можно использовать сырые массивы, и это отличная идея, если ваша коллекция не поддается изменению размера.
К другим структурам данных, неэффективным с точки зрения использования памяти, относятся различные сериализации. Да, действительно, форматы XML или JSON удобны в использовании, можно сократить использование памяти, если работать с более эффективным двоичным форматом, например, буферами протоколов.
Все эти примеры с упоминанием структур данных, оптимизированных для экономии памяти – просто подсказки. Как и в случае с рефакторингом, нужно сначала найти источник проблем, а затем переходить к таким оптимизациям производительности.
Предотвращайте перемешивание памяти
Виртуальные машины Java/Android выделяют объекты очень быстро. Сборка мусора также идет весьма быстро. Однако при выделении большого количества объектов за короткий промежуток времени можно столкнуться с проблемой под названием «перемешивание памяти» (memory churn). В таком случае виртуальная машина не будет успевать выделять объекты в таком темпе, а сборщик мусора – их утилизировать, и приложение начнет притормаживать, а в экстремальных случаях даже израсходует всю память.
Основная проблема на территории Android в данном случае такова, что мы не контролируем, когда будет происходить сборка мусора. Потенциально это может приводить к проблемам: например, сборщик мусора работает именно в то время, пока на экране разворачивается анимация, и мы превышаем порог в 16 мс, обеспечивающий гладкое отображение кадров. Поэтому важно предотвращать чрезмерно активное выделение памяти в коде.
Пример ситуации, приводящей к перемешиванию памяти – выделение больших объектов, например, Paint внутри метода onDraw() представления. В таком случае быстро создается много объектов, и может начаться сборка мусора, которая может негативно повлиять на работу этого представления. Как указывалось выше, всегда нужно отслеживать использование памяти, чтобы избегать таких ситуаций.
Источник