Не совсем так. Файлы мапятся в виртуальное адресное пространство приложения. Изначально, эти адреса не имеют физических страниц, но при первом обращении к замапленному файлу будут выделены физические страницы и в них прочитаны данные из файла. Так вот, когда ядро почует нехватку памяти оно пойдёт и поотрывает физические страницы у давно не используемых маппингов. Как только приложение сново захочет полезть за ресурсам (т.е. обратиться по адресам маппинга) — не проблема, ядро уж где-нить нароет новых страниц (возможно по пути грохнув какой-нить другой процесс).
Т.е. грубо говоря наличие ресурсов в памяти это кэш. Если просто читать файлы с SD карты то они также попадут в кэш только немного другими путями. Так что зачем платить больше :)
В твоём случае ты сначала всосёшь в память ресурсы из APK, а затем продублируешь данные на SD карту тем самым в два раза больше отъев страниц (которые разумеется могут быть оторваны в случае out of memory).
Хотя если уже есть и работает то можешь оставить как есть. У меня просто долго компилируется проект и я каратаю время развёрнутыми ответами :)
apk он маппит через mmap() так что по необходимости memory cache будет сброшен. Я конечно могу ошибаться, но логично если ресурсы так и остаются в пределах замапленного региона, в сжатом виде, а распаковываются на ходу в AssetInputStream. Так что я не вижу причины париться если не превышен лимит на размер apk (не помню сколько там).
Я всё равно не понимаю, почему не затолкать всё в res или assets, поставить preferExternal и расслабиться? В конце концов не везде есть SD (Nexus S).
Лицензию любую BSD-подобную (MIT, ZLIB, etc..). Для десктопов в принципе подойдёт LGPL, но для мобильных платформ она особо не применима.
>он также как и раньше безальтернативно регистрируется в системе как провайдер и когда нажимаешь номер чтобы позвонить, то еще надо выбирать — скайп или просто по телефону?
Да, но можно поставить галочку чтобы всегда использовал что-то одно.
Бывает. Быстренко глянул код — в принципе ОК, что после таймаута отправляет запрос, но я бы предпочёл чтобы запрос отправлялся только для известных сервисов. Хотя, кому надо могут альтернативное расширение сделать.
У меня сложилось впечатление, что Microsoft уже пофиг на Windows как игровую платформу. В смысле не совсем пофиг, просто уже не ставят на неё ставки и особо не беспокоятся — xbox всё равно денег больше приносит, а там они сами себе хозяева.
А полноценный Windows и так станет нишевым продуктом, как и в общем и Mac OS X — десктопы же.
Я признаться не вникал в этот их dri2 (всё-таки это требует времени больше пятнадцати минут) по этому не берусь судить о мотивах перенесения управления буфферами в ядро. Думаю у них были на то вменяемые причины, не от делать же нечего запихали.
Кстати у меня 2.6.38 тоже не ахти работает с Sandy Bridge, 2.6.39 получше (пропали артифакты) но после нескольких suspend/resume система начинает на короткое время подвисать когда кто-нибудь к opengl обращается.
Ага, и сидело бы управление буфферами в X-сервере — не многим лучше если он упадёт.
Стараниями Intel у mesa есть нормальный компилятор шейдеров и в купе с gallium инфраструктура для написания драйверов без написания велосипедов. Хотя конечно ещё допиливать и допиливать.
Т.е. грубо говоря наличие ресурсов в памяти это кэш. Если просто читать файлы с SD карты то они также попадут в кэш только немного другими путями. Так что зачем платить больше :)
В твоём случае ты сначала всосёшь в память ресурсы из APK, а затем продублируешь данные на SD карту тем самым в два раза больше отъев страниц (которые разумеется могут быть оторваны в случае out of memory).
Хотя если уже есть и работает то можешь оставить как есть. У меня просто долго компилируется проект и я каратаю время развёрнутыми ответами :)
Лицензию любую BSD-подобную (MIT, ZLIB, etc..). Для десктопов в принципе подойдёт LGPL, но для мобильных платформ она особо не применима.
Да, но можно поставить галочку чтобы всегда использовал что-то одно.
// Линукс-пользователь
А полноценный Windows и так станет нишевым продуктом, как и в общем и Mac OS X — десктопы же.
Кстати у меня 2.6.38 тоже не ахти работает с Sandy Bridge, 2.6.39 получше (пропали артифакты) но после нескольких suspend/resume система начинает на короткое время подвисать когда кто-нибудь к opengl обращается.
Стараниями Intel у mesa есть нормальный компилятор шейдеров и в купе с gallium инфраструктура для написания драйверов без написания велосипедов. Хотя конечно ещё допиливать и допиливать.