Где программа хранит свои данные после запуска в оперативной памяти
Обновлено: 07.07.2024
При использовании приложений под Android иногда появляются вопросы: «А где приложение хранит созданные файлы?», «Можно ли до них достучаться?» и «Удалятся ли файлы при удалении приложения?» Давайте попробуем посмотреть, где же приложение может хранить свои данные и какие последствия это имеет для пользователя.
Внутреннее хранилище данных
Смысл следует непосредственно из названия. Внутреннее хранилище (internal storage) располагается всегда в памяти смартфона вне зависимости от того, есть ли возможность установки карты памяти (и тем более того, вставлена ли она). Эта область памяти является защищенной. Находится в системном разделе /data. По умолчанию все файлы, которые там располагаются, доступны только тому приложению, которое их создало. Разумеется, можно сделать файлы доступными для других приложений, но это надо делать специально. Если приложение не открывает файлы для доступа извне, достучаться к ним можно будет только получив root.
Назначение хранилища понятно: внутренние защищенные данные, к которым не должно быть нерегламентированного доступа. Проблемы (с точки зрения пользователя) могут быть в следующих случаях:
- Неоправданно большой объем данных. Хочется вынести данные на карту памяти, чтобы сэкономить внутреннее пространство для других нужд, а приложение не дает.
- По мнению пользователя, регламент доступа к данным должен быть другим, не таким, как предлагает приложение.
Пример: приложение «Лекции по истории России». В приложении хороший контент (и по содержанию, и по качеству звука). Но сохраняется он во внутреннюю память. На бюджетных устройствах, где этой памяти мало, становится затруднительным закачать заранее много лекций, а потом, отключившись от интернета, слушать их. Второй проблемой становится собственно регламент доступа к данным. Даже если ограничиться тематикой истории, у меня есть аудиофайлы, полученные из трех источников: данное приложение, подкасты и аудиоверсии роликов с youtube. Хочется взять и объединить навек в их земной юдоли под владычеством всесильным Властелина Мордора их все в единый плейлист, и слушать его одним аудиоплеером. Но на смартфоне без root это сделать невозможно.
Внешнее хранилище «личных» данных
С точки зрения разработчика, кроме внутреннего хранилища данных, для персональных целей приложения есть еще внешнее хранилище. Оно необязательно размещается на карте памяти. Это может быть и внутренняя память смартфона, но весь раздел с такими данными размещается в общем доступе. В корне раздела есть папка Android/data, а в ней — подпапки с именами пакетов приложений.
Плюсы такого подхода очевидны: данные доступны извне для целей пользователя. А если это карта памяти, то и емкость может быть ограничена только вашими финансами (в продаже уже можно найти карты памяти на 400 гигабайт). Минусы тоже понятны: в любой момент любое приложение (конечно, имеющее разрешение на доступ к «внешним» данным) может взять и стереть чужие файлы. Также файлы будут удалены системой при удалении приложения (или при очистке его данных).
Пример приложения: подкаст-менеджер BeyondPod (более-менее свежей версии, раньше файлы хранились по-другому). Пользователь имеет доступ к скачанным подкастам и может легко удалять их (например, в целях экономии места) или слушать их во внешнем плеере.
Общее внешнее хранилище
Располагается в корне «внешнего» раздела на одном уровне с папкой «Android». Предназначается для хранения данных, разделяемых между разными приложениями. Обычно в документации Google в качестве примера приводят картинки (фото с камеры — папка DCIM). Основная проблема данных файлов: они никогда не удаляются автоматически. Даже если приложение вы удалили.
Пример: мессенджер Telegram. После того, как вы удалили приложение, загруженные файлы никуда не исчезают. Они продолжают спокойно лежать на накопителе данных, занимая драгоценное место.
Как можно удалить файлы, не удаляя приложения
Здесь важно ввести еще одну классификацию файлов приложений. Она справедлива для внутреннего хранилища и для внешнего хранилища личных данных. Все данные делятся на два типа: собственно данные и кэш.
Данные (папка data) — некие файлы, которые, по логике Google, нужны для постоянной работы с ними. Если полностью их удалить, то приложение поведет себя точно так же, как если бы его переустановили (удалили и заново установили). Частичное удаление файлов может не привести ни к каким неприятным последствиям. Но важно понимать, какие конкретно данные вы удаляете (например, очевидно, что скачанные файлы подкастов можно удалять совершенно свободно — это не повлияет на работоспособность подкаст-менеджера).
Кэш — временные данные, которые сформированы в ходе работы приложения и нужны для ускорения этой работы. Например, данные, которые часто нужны в интернете, загружаются и в дальнейшем вместо загрузки открываются локально (разумеется, кэш может обновляться, чтобы не показывать устаревшие данные). Удалять кэш любого приложения можно совершенно спокойно, это штатная операция.
Очистка памяти и кэша вызывается из настроек приложения. Кнопка «Очистить кэш» очищает только кэш, а кнопка «Очистить данные» — и кэш, и данные приложения.
Удаление файлов приложения из общего внешнего хранилища выполняется только вручную. Более того, даже оценка того, от какого приложения эти файлы остались, тоже выполняется вручную.
Управление памятью – одна из главных задач ОС. Она критична как для программирования, так и для системного администрирования. Я постараюсь объяснить, как ОС работает с памятью. Концепции будут общего характера, а примеры я возьму из Linux и Windows на 32-bit x86. Сначала я опишу, как программы располагаются в памяти.
Каждый процесс в многозадачной ОС работает в своей «песочнице» в памяти. Это виртуальное адресное пространство, которое в 32-битном режиме представляет собою 4Гб блок адресов. Эти виртуальные адреса ставятся в соответствие (mapping) физической памяти таблицами страниц, которые поддерживает ядро ОС. У каждого процесса есть свой набор таблиц. Но если мы начинаем использовать виртуальную адресацию, приходится использовать её для всех программ, работающих на компьютере – включая и само ядро. Поэтому часть пространства виртуальных адресов необходимо резервировать под ядро.
Это не значит, что ядро использует так много физической памяти – просто у него в распоряжении находится часть адресного пространства, которое можно поставить в соответствие необходимому количеству физической памяти. Пространство памяти для ядра отмечено в таблицах страниц как эксклюзивно используемое привилегированным кодом, поэтому если какая-то программа пытается получить в него доступ, случается page fault. В Linux пространство памяти для ядра присутствует постоянно, и ставит в соответствие одну и ту же часть физической памяти у всех процессов. Код ядра и данные всегда имеют адреса, и готовы обрабатывать прерывания и системные вызовы в любой момент. Для пользовательских программ, напротив, соответствие виртуальных адресов реальной памяти меняется, когда происходит переключение процессов:
Голубым отмечены виртуальные адреса, соответствующие физической памяти. Белым – пространство, которому не назначены адреса. В нашем примере Firefox использует гораздо больше места в виртуальной памяти из-за своей легендарной прожорливости. Полоски в адресном пространстве соответствуют сегментам памяти таким, как куча, стек и проч. Эти сегменты – всего лишь интервалы адресов памяти, и не имеют ничего общего с сегментами от Intel. Вот стандартная схема сегментов у процесса под Linux:
Когда программирование было белым и пушистым, начальные виртуальные адреса сегментов были одинаковыми для всех процессов. Это позволяло легко удалённо эксплуатировать уязвимости в безопасности. Зловредной программе часто необходимо обращаться к памяти по абсолютным адресам – адресу стека, адресу библиотечной функции, и т.п. Удаленные атаки приходилось делать вслепую, рассчитывая на то, что все адресные пространства остаются на постоянных адресах. В связи с этим получила популярность система выбора случайных адресов. Linux делает случайными стек, сегмент отображения в память и кучу, добавляя смещения к их начальным адресам. К сожалению, в 32-битном адресном пространстве особо не развернёшься, и для назначения случайных адресов остаётся мало места, что делает эту систему не слишком эффективной.
Самый верхний сегмент в адресном пространстве процесса – это стек, в большинстве языков хранящий локальные переменные и аргументы функций. Вызов метода или функции добавляет новый кадр стека (stack frame) к существующему стеку. После возврата из функции кадр уничтожается. Эта простая схема приводит к тому, что для отслеживания содержимого стека не требуется никакой сложной структуры – достаточно всего лишь указателя на начало стека. Добавление и удаление данных становится простым и однозначным процессом. Постоянное повторное использование районов памяти для стека приводит к кэшированию этих частей в CPU, что добавляет скорости. Каждый поток выполнения (thread) в процессе получает свой собственный стек.
Можно прийти к такой ситуации, в которой память, отведённая под стек, заканчивается. Это приводит к ошибке page fault, которая в Linux обрабатывается функцией expand_stack(), которая, в свою очередь, вызывает acct_stack_growth(), чтобы проверить, можно ли ещё нарастить стек. Если его размер не превышает RLIMIT_STACK (обычно это 8 Мб), то стек увеличивается и программа продолжает исполнение, как ни в чём не бывало. Но если максимальный размер стека достигнут, мы получаем переполнение стека (stack overflow) и программе приходит ошибка Segmentation Fault (ошибка сегментации). При этом стек умеет только увеличиваться – подобно государственному бюджету, он не уменьшается обратно.
Динамический рост стека – единственная ситуация, в которой может осуществляться доступ к свободной памяти, которая показана белым на схеме. Все другие попытки доступа к этой памяти вызывают ошибку page fault, приводящую к Segmentation Fault. А некоторые занятые области памяти служат только для чтения, поэтому попытки записи в эти области также приводят к Segmentation Fault.
После стека идёт сегмент отображения в память. Тут ядро размещает содержимое файлов напрямую в памяти. Любое приложение может запросить сделать это через системный вызов mmap() в Linux или CreateFileMapping() / MapViewOfFile() в Windows. Это удобный и быстрый способ организации операций ввода и вывода в файлы, поэтому он используется для подгрузки динамических библиотек. Также возможно создать анонимное место в памяти, не связанное с файлами, которое будет использоваться для данных программы. Если вы сделаете в Linux запрос на большой объём памяти через malloc(), библиотека C создаст такую анонимное отображение вместо использования памяти из кучи. Под «большим» подразумевается объём больший, чем MMAP_THRESHOLD (128 kB по умолчанию, он настраивается через mallopt().)
Если в куче оказывается недостаточно места для выполнения запроса, эту проблему может обработать сама программа без вмешательства ядра. В ином случае куча увеличивается системным вызовом brk(). Управление кучей – дело сложное, оно требует хитроумных алгоритмов, которые стремятся работать быстро и эффективно, чтобы угодить хаотичному методу размещению данных, которым пользуется программа. Время на обработку запроса к куче может варьироваться в широких пределах. В системах реального времени есть специальные инструменты для работы с ней. Кучи тоже бывают фрагментированными:
И вот мы добрались до самой нижней части схемы – BSS, данные и текст программы. BSS и данные хранят статичные (глобальные) переменные в С. Разница в том, что BSS хранит содержимое непроинициализированных статичных переменных, чьи значения не были заданы программистом. Кроме этого, область BSS анонимна, она не соответствует никакому файлу. Если вы пишете static int cntActiveUsers , то содержимое cntActiveUsers живёт в BSS.
Сегмент данных, наоборот, содержит те переменные, которые были проинициализированы в коде. Эта часть памяти соответствует бинарному образу программы, содержащему начальные статические значения, заданные в коде. Если вы пишете static int cntWorkerBees = 10 , то содержимое cntWorkerBees живёт в сегменте данных, и начинает свою жизнь как 10. Но, хотя сегмент данных соответствует файлу программы, это приватное отображение в память (private memory mapping) – а это значит, что обновления памяти не отражаются в соответствующем файле. Иначе изменения значения переменных отражались бы в файле, хранящемся на диске.
Пример данных на диаграмме будет немного сложнее, поскольку он использует указатель. В этом случае содержимое указателя, 4-байтный адрес памяти, живёт в сегменте данных. А строка, на которую он показывает, живёт в сегменте текста, который предназначен только для чтения. Там хранится весь код и разные другие детали, включая строковые литералы. Также он хранит ваш бинарник в памяти. Попытки записи в этот сегмент оканчиваются ошибкой Segmentation Fault. Это предотвращает ошибки, связанные с указателями (хотя не так эффективно, как если бы вы вообще не использовали язык С). На диаграмме показаны эти сегменты и примеры переменных:
Изучить области памяти Linux-процесса можно, прочитав файл /proc/pid_of_process/maps. Учтите, что один сегмент может содержать много областей. К примеру, у каждого файла, сдублированного в память, есть своя область в сегменте mmap, а у динамических библиотек – дополнительные области, напоминающие BSS и данные. Кстати, иногда, когда люди говорят «сегмент данных», они имеют в виду данные + bss + кучу.
Бинарные образы можно изучать при помощи команд nm и objdump – вы увидите символы, их адреса, сегменты, и т.п. Схема виртуальных адресов, описанная в этой статье – это т.н. «гибкая» схема, которая по умолчанию используется уже несколько лет. Она подразумевает, что переменной RLIMIT_STACK присвоено какое-то значение. В противном случае Linux использует «классическую» схему:
Внешняя память - это память, предназначенная для длительного хранения программ и данных. Целостность содержимого ВЗУ не зависит от того, включен или выключен компьютер.
Внутренняя память -
Оперативная память (ОП) предназначена для временного хранения выполняемых программ и данных, обрабатываемых этими программами. Это энергозависимая память. Физически реализуется в модулях ОЗУ (оперативных запоминающих устройствах) различного типа. При выключении электропитания вся информация в оперативной памяти исчезает.
Объём хранящейся информации в ОЗУ составляет от 32 до 512 Мбайт и более. Занесение информации в память и её извлечение, производится по адресам. Каждый байт ОП имеет свой индивидуальный адрес (порядковый номер) . Адрес – число, которое идентифицирует ячейки памяти (регистры) . ОП состоит из большого количества ячеек, в каждой из которых хранится определенный объем информации. ОП непосредственно связана с процессором. Возможности ПК во многом зависят от объёма ОП.
Кеш память - очень быстрая память малого объема служит для увеличения производительности компьютера, согласования работы устройств различной скорости.
Специальная - постоянная, Fiash, видеопамять и тд.
Постоянное запоминающее устройство (ПЗУ) – энергонезависимая память для хранения программ управления работой и тестирования устройств ПК. Важнейшая микросхема ПЗУ – модуль BIOS (Basic Input/Output System – базовая система ввода/вывода) , в котором хранятся программы автоматического тестирования устройств после включения компьютера и загрузки ОС в оперативную память. Это Неразрушимая память, которая не изменяется при выключении питания
Перепрограммируемая постоянная память (Flash Memory) – энергонезависимая память, допускающая многократную перезапись своего содержимого
CMOS RAM (Complementary Metal-Oxide Semiconductor) - память с невысоким быстродействием и минимальным энергопотреблением от батарейки. Используется для хранения информации о конфигурации и составе оборудования компьютера, о режимах его работы. Содержимое изменяется программой, находящейся в BIOS (Basic Input Output System).
Видеопамять – запоминающее устройство, расположенное на плате управления дисплеем и предназначенное для хранения текстовой и графической информации, отображаемой на экране. Содержимое этой памяти сразу доступно двум устройствам – процессору и дисплею, что позволяет изменять изображение на экране одновременно с обновлением видеоданных в памяти.
Так что данные хранятся во внешней памяти.
Часто возникает необходимость узнать, где та или иная программа (приложение) хранят свои настройки в реестре Windows. Бывает, что поиск по реестру не дает никаких результатов, или же программа хранит свои настройки не в одной какой-либо ветке реестра, а в нескольких и нужно их все найти, чтобы посмотреть/поменять настройки или сделать их резервную копию. В данной статье мы рассмотрим как это можно сделать.
Как узнать, где программа хранит свои настройки в реестре
После скачивания и распаковки архива можно обнаружить два exe файла: Procmon.exe и Procmon64.exe
После первого запуска, программа предложит нам принять условия лицензионного соглашения, поэтому не забываем нажать кнопочку "Agree"
Для примера посмотрим к каким разделам реестра обращается стандартный графический редактор Paint, который присутствует в ОС Windows. Для этого сначала запускаем Process Monitor, а после этого интересующее нас приложение, в данном примере графический редактор Paint. Далее, в диспетчере смотрим как именно называется исполняемый файл, в случае с Пейнтом, он называется mspaint.exe .
Чтобы отфильтровать все ненужные записи от любых других приложений, мы включим фильтр, в котором укажем, что хотим видеть только активность, которая вызвана процессом mspaint.exe , для этого мы выбираем пункт меню "Filter" и в нем опцию с одноименным названием "Filter. ".
После чего выбираем из раскрывающегося меню пункт "Process Name", вписываем имя нужного нам процесса mspaint.exe и жмем на кнопку "Add", чтобы наш фильтр добавился:
Теперь осталось применить фильтр, чтобы все посторонние записи не отображались. Для этого жмем на кнопку "Apply" и потом на "OK", для закрытия окна настроек.
В результате перед нами будет вся информация о том, к каким конкретно разделам и ключам реестра обращается mspaint.exe в процессе своей работы:
Теперь можно закрыть редактор Paint и посмотреть куда он записывает все свои настройки, после завершения работы. Они будут также отображаться в окне Process Monitor, достаточно просто воспользоваться скроллом. Таким не хитрым способом, можно мониторить любой процесс и точно знать как и где он хранит информацию.
Читайте также: