OptimizedDLL.StartUp.Main();
static void Main()
[MTAThread]
///
/// The main entry point for the application.
///
static class Program
Ваш пустой exe-файл может выглядеть следующим образом:
Те из вас, кто читал Стивена Пратшнера (Steven Pratschner), знают, что Compact Framework размещает управляемые exe и dll в первом гигабайте разделяемой памяти за пределами слота, в котором выполняется ваше приложение, что, безусловно, замечательно. А вот что вы могли и не знать, так это то, что операционная система автоматически блокирует в нижней части слота ровно столько памяти, сколько занимает ваш exe-файл. Таким образом, несмотря на то, что CLR контролирует выполнение приложения и в любовном порыве располагает его в разделяемой памяти, Windows CE отбирает драгоценную порцию памяти, потому как полностью уверена, что именно там и работает наше приложение. А ведь наше приложение управляемое и его там нет! Те из вас, у кого есть огромные управляемые exe-файлы, вы теряете огромный кусок памяти в своем слоте, который можно было бы использовать с гораздо большей пользой! Так что первый урок заключается в том, чтобы сделать то, что сделал Брайан создать пустой exe-файл в виде заглушки, которая запускает приложение из отдельной управляемой сборки.
Это достаточно здорово и значительно увеличивает наши возможности. Потенциально становится возможным разработать множество игр и приложений, которые ранее не видывали на Windows телефонах.Внимание, вопрос. Как это возможно? Это магия?
Справа находится OptimizedExe.exe, запущенное в слоте 11. Это совершенно пустой exe-файл. Функция Main вызывает метод статического класса в управляемой DLL и всё. В результате мы получаем exe-файл размером 5 килобайт. В управляемой сборке под названием OptimizedDLL.dll у нас находится всё тот же 2.25 мегабайтный битмап и форма. Если приглядеться к изображению справа, можно с удивлением обнаружить, что в слоте 11 нет никаких синих участков! А если смотреть ещё пристальнее, то 2.25 мегабайтную сборку невозможно обнаружить где-либо ещё.
Слева вы видите Compact Framework приложение StandardExe.exe, запущенное в слоте 14. Это простое управляемое приложение содержит в себе битмап размером 2.25Мб в качестве ресурса и форму, на которой этот битмап находится. Если приглядеться, то видно, что 2.25 синих мегабайт находится в нижней части слота 14. Это пространство, занятое нашим exe-файлом.
Чтобы помочь нагляднее разобраться с этим невероятным открытием, я продемонстрирую две иллюстрации, на которых изображена карта использования памяти управляемым приложением, работающим в двух различных вариантах. Приложение, запущенное на эмуляторах, которые вы видите ниже, отображает использование 32 слотов разделяемой виртуальной памяти.Красным отмечена свободная память, синим использованная, зеленым зарезервированная. Слот 1 полон системных библиотек и вы не можете не заметить, что у каждого последующего слота есть небольшая синяя область. Это пространство используется системой и управляемыми библиотеками, что означает невозможность получить свои честные 32 мегабайта.
Недавно я встретил своего хорошего друга Глена Джонса (Glen Jones), который хотел поделиться со мной некоторыми интересными находками. Имейте в виду, дело не только в том, что я считаю Глена и его коллег одними из лучших Compact Framework разарботчиков в мире. Его комманда спроектировала и разработала одно из самых больших и сложных приложений, работающих на Windows Mobile, используя Compact Framework. Как и любые другие компании, которые разрабатывают огромные Windows Mobile приложения, проблемы с нехваткой памяти не обошли и их. Брайан Пайк (Brian Pike), Один из архитекторов "команды мечты" недавно обнаружил, что если держать в памяти пустой exe-файл, а формы, код, ресурсы и данные хранить в отдельных управляемых сборках, то это уменьшает количество расходуемой виртуальной памяти в занимаемом им слоте, одновременно с этим получая возможность использовать память вне слота в рамках 1Гб разделяемой памяти.
Возвращаясь в сегодняшний день, вы увидите, что Windows CE 5.0 и Windows Mobile 6.x имеют некоторое сходство со своими прадедушками из 80-х и 90-х. 32-битная встраиваемая операционная система, которой мы доверяем управлять нашими Windows телефонами, состоит из пачки слотов, но в отличии от DOS с её 640Кб, ваше приложение получает 32Мб виртуальной памяти. Однако, совершенно как в DOS у вас нет доступа ко всему адресному пространству, потому что другие вещи, такие как системные библиотеки это пространство уже используют.
Некоторые из нас даже работали в OS/2, которая выделяла 740Кб для наших DOS-сессий, обеспечивая им вытесняющую многозадачность. Да, я мог запускать несколько DOS-игр одновременно в разных окнах без каких либо проблем. Удивительно, у меня была целая пачка защищённых от сбоев слотов, каждый из которых имел свои 740Кб памяти.
Кто-нибудь ещё помнит старые добрые времена DOS, когда мы проводили время, пытаясь выжать более 640Кб для драйверов, программ, резидентов и даже Windows? Такие вещи как QEMM, HIMEM, EMM386.EXE пробуждают у меня теплые воспоминания.
Оригинал статьи находится в блоге .
Перевод: эффективный способ работы с памятью в Compact Framework
Перевод: эффективный способ работы с памятью в Compact Framework / Хабрахабр
Комментариев нет:
Отправить комментарий