2013-11-22 Завести фреймворки андроида на нормальной системе?
Блин, ведроид — это реально винда какая-то. Монолит монолитом, ни одного нормального linux’ового куска. Гугл — уроды, пилять. Как подумаю, так расстраивает — не описать.
И вот думается мне — а нельзя ли (принципиально) завести его фреймворк на нормальной системе, выпилив при этом остальные внутренности? А именно — убрать нафиг binder, зиготу, SurfaceFlinger, всякие system_server’ы и прочую отстойные байду. Оставить — реально — ТОЛЬКО далвик и модифицированные фреймворки. Вместо SurfaceFlinger’а — то есть композитора, который, я так понимаю, сам по себе вещь довольно тупая — впилить обычный вывод в окно X11.
Вместо binder’а, красивого костыля, на котором там полсистемы работает — впилить нормальную связь через unix сокеты. Тут только пара вопросов:
- Насколько крупными сообщениями обмениваются приложения через binder? Обычно, вроде, совсем мелкими и сериализованными (Parcelable), так что имхо ничего страшного при переходе на сокеты быть не должно. С другой стороны, вроде я где-то читал, что в binder’е есть возможность zero-copy отправки крупных буферов в адресное пространство другого процесса, и вроде это используется для графики — как раз для связи с SurfaceFlinger’ом. Соответственно, вопрос — используется ли это реально где-то ещё? Если да, можно попытаться нагородить что-то на разделяемой памяти (posix или sysv). Если нет — то вообще забить на эту фичу и всё тут.
- Есть ли там какие-то хитрожопые фичи для аутентификации? Судя по сообщению авторши в LKML (ага-ага, binder баба какая-то изобрела) — вроде там ничего сильно хитрого нет; тогда обычных файловых пермишнов будет вполне достаточно.
Совместимости с приложениями с нативными кусками в таком подходе, естественно, добиться сложнее — потому что, во-первых, далеко не все приложения вообще есть под x86’ой андроид, а во-вторых, даже для тех, что есть, придётся обеспечивать совместимость ABI с кучей кастрированных библиотек, в частности, с этим тупым огрызком под названием «bionic libc». Хотя чисто теоретически и это, по-моему, возможно — можно модифицировать /lib/ld-linux.so.2 и научить его именно для таких *.so’шек подгружать нужные обёртки. Но вот как раз если заниматься такой фигнёй — работы уже всё-таки сильно больше.
Чисто теоретически, наверное, даже Dalvik можно попытаться ликвидировать и заменить его нормальной JVM, причём оно от этого ведь ещё и ускорится — там оптимизации умные. Но:
- Какая-то попытка этого уже есть, называется IcedRobot, и насколько я понимаю, там всё несколько сдохло.
- При таком подходе придётся все запускаемые приложения dex2jar’ить — преобразовывать обратно в java’шный формат (ну даже допустим ладно, это не так страшно).
- На JVM, видимо, придётся отказаться от такой идеи (совсем уж розовая мечта) — научить dalvik разделямой памяти. То есть научить его память, выделенную под загруженный apk / dex / jar, разделять между всеми процессами, использующими этот apk / dex / jar. Типа получились бы такие so’шки на java, или что-то типа assembly в дотнете. Имхо это было бы мегакруто, потому что это решение потребления памяти Java’ой — ну, в смысле, при параллельном выполнении большого числа Java’шных программ. Тогда и никакие тупые изобретения типа «зиготы» (она как раз для разделения памяти придумана) не нужны.
UPD: Ага, блин, оказывается, далвик тоже зависит от нестандартной ядерной фичи — драйвера разделямой памяти ashmem. Круто, чо… Велосипедисты :). Хотя, конечно, как реализовать автоматическое удаление сегмента разделяемой памяти после завершения всех процессов, его использовавших — сходу не скажу…
[ Хронологический вид ]Комментарии
Войдите, чтобы комментировать.