Оговорюсь сразу: некоторых деталей я глубоко не знаю поэтому что-то в моих посылках может быть неверно.

Принципиальная разница в архитектуре Android и iPhone состоит в том что
Android это фактически однозадачная система. Во всяком случае в плане UI.
Т.е. android девайс это один единственный процесс в котором крутится Dalvik (Java VM).
Приложение Android есть java .class[es] который грузится в эту самую VM и соответственно приложение попадает
в общий memory heap. Со всеми вытекающими. Выполнить GC в такой системе — сделать stop-the-world.
Существуют способы incremental GC но имхо для GUI особенно такого типа они не подходят.

iPhone OS это в общем-то полномасштабная multitasking OS. Приложение есть процесс со своей собственной таблицей страниц памяти и пр. handlers.

Т.е. фактически имеем противостояние Cooperative Multitasking и Preemptive multitasking.

Очевидно что iOS лучше масштабируется под бОльшие разрешения экрана (больше экран — бОльшие приложения — больше памяти им нужно)
Но Android OS более оптимальна для low-level devices. Хотя бы теоретически. Когда Google говорит про то что Android он не для tablets я так
понимаю имеется ввиду именно это.

Т.е. в Android имеем одно большое дерево объектов в памяти. В iOS — каждый процесс имеет свое дерево (меньшей высоты).
Соответсвенно memory management в iOS дешевле в принципе. И локален для каждого прцесса. В iOS гораздо меньше наблюдаетсе UI freeze эффектов.

Но в Android можно лучше сделать Activity stack — back button там в принципе лучше работает. Что естественно ибо Android OS это один большой Activity stack.

Windows Phone я так понимаю это в общем-то тот же Android (архитектурно) в котором вместо Dalvik работает .NET VM.
Я так понимаю что Windows Phone OS на tablets мы не увидим. Гораздо больше шансов увидеть W7 на tablets.
Хотя я бы лично развивал Windows Mobile — как OS она достаточно mature. Графику переработать только.

Еще про late binding как отдельный аспект. Понятно что OS и приложения должны как-то взаимодействовать —
т.е. нужен некий API механизм. В принципе Windows Mobile + COM как протокол предсталяется достаточно production level на настоящий момент.
Честно говоря я был несколько удивлен решением Windows Phone (как еще один Android). Мотивации оных разработчиков тайна мраком покрытая есмъ.
Для "недо-PC" наверное такой вариант (OS есть VM, приложения есть classes в общем memory heap) в принципе подходит.
Но как бы уже телефоны по вычислительной мощности являются девайсами на которых Windows XP (и вся ветка NT) начинала вполне себе комфортную работу.

Скорее всего нас ждет будущее в которм будет Chrome OS, W7 и iOS. Android и WP если будет то на low-end совсем.

Вот такое мое видение проблем и перспектив.

Здравствуйте, c-smile, Вы писали:

CS>Т.е. фактически имеем противостояние Cooperative Multitasking и Preemptive multitasking.

А потоки в пределах процесса там есть (у обоих)?
Зависание одного приложения вешает всю систему?

Здравствуйте, c-smile, Вы писали:

CS>Оговорюсь сразу: некоторых деталей я глубоко не знаю поэтому что-то в моих посылках может быть неверно.

Так и есть.

CS>Принципиальная разница в архитектуре Android и iPhone состоит в том что
CS>Android это фактически однозадачная система. Во всяком случае в плане UI.
CS>Т.е. android девайс это один единственный процесс в котором крутится Dalvik (Java VM).
CS>Приложение Android есть java .class[es] который грузится в эту самую VM и соответственно приложение попадает
CS>в общий memory heap. Со всеми вытекающими. Выполнить GC в такой системе — сделать stop-the-world.
CS>Существуют способы incremental GC но имхо для GUI особенно такого типа они не подходят.

Неверно. В Android linux ядро, а в нем обычная preemptive multitasking. Что же касается Dalvik VM, то она не одна на всю ось, а одна на каждый process. Ядро вообще не знает, что за процесс оно schedul-ит (с Dalvik VM внутри или обычный native) — для него они все одинаковы. Т.е. stop-the-world, если вдруг понадобится, выполняется в рамках только одного приложения, никак не затрагивая остальные.

Здравствуйте, c-smile, Вы писали:

CS>Android это фактически однозадачная система. Во всяком случае в плане UI.
CS>Т.е. android девайс это один единственный процесс в котором крутится Dalvik (Java VM).

Нет, это не так: http://developer.android.com/guide/topics/fundamentals.html :

Each process has its own virtual machine (VM), so an application's code runs in isolation from other applications

Здравствуйте, c-smile, Вы писали:

CS>Очевидно что iOS лучше масштабируется под бОльшие разрешения экрана (больше экран — бОльшие приложения — больше памяти им нужно)
CS>Но Android OS более оптимальна для low-level devices. Хотя бы теоретически. Когда Google говорит про то что Android он не для tablets я так
CS>понимаю имеется ввиду именно это.

Вы имели ввиду версию 2, так как 3 выпускается как раз для планшетов. И если например по смотреть на Android 3, то он гораздо лучше подходит для планшетов, нежели iOS.

CS>В принципе Windows Mobile + COM как протокол предсталяется достаточно production level на настоящий момент.
CS>Честно говоря я был несколько удивлен решением Windows Phone (как еще один Android). Мотивации оных разработчиков тайна мраком покрытая есмъ.
CS>Для "недо-PC" наверное такой вариант (OS есть VM, приложения есть classes в общем memory heap) в принципе подходит.
CS>Но как бы уже телефоны по вычислительной мощности являются девайсами на которых Windows XP (и вся ветка NT) начинала вполне себе комфортную работу.

основная проблема, что и Com, и NT на текущий момент завязаны на конкретную архитектуру железа.
и шаг влево-вправо на уровне железа очень дорого обходится для архитектуры без VM, а в мобильных девайсах сейчас как раз критично постоянное изменение железа под выжимания максимальной эффективности на единицу заряда батарейки

Здравствуйте, DarkGray, Вы писали:

DG>основная проблема, что и Com, и NT на текущий момент завязаны на конкретную архитектуру железа.
DG>и шаг влево-вправо на уровне железа очень дорого обходится для архитектуры без VM, а в мобильных девайсах сейчас как раз критично постоянное изменение железа под выжимания максимальной эффективности на единицу заряда батарейки
Это не показатель. Chromium как основа ChromeOS готов выжрать всё до единой капли, тока код и страницы подавай. И хоть VM хоть не VM — всё упирается в работу которая делается или не делается. Собственно отсюда дешевых производительных устройств и не бывает. Учитывая современные потребности — а именно например скайп (в смысле онлайн видео и звук) — не каждый нетбук это тянет... — ну и за что боремся?

Здравствуйте, ArtDenis, Вы писали:

AD>Здравствуйте, c-smile, Вы писали:

CS>>Android это фактически однозадачная система. Во всяком случае в плане UI.
CS>>Т.е. android девайс это один единственный процесс в котором крутится Dalvik (Java VM).

AD>Нет, это не так: http://developer.android.com/guide/topics/fundamentals.html :
AD>

AD>Each process has its own virtual machine (VM), so an application's code runs in isolation from other applications

Спасибо Денис. Да это несколько меняет дело.

CS>Принципиальная разница в архитектуре Android и iPhone состоит в том что

iOS — закрытая проприетарная (забудем уж про freeBSD) ОС, находящаяся под полным контролем Apple, и приспособленная к работе лишь на очень фиксированном спектре оборудования.

Android — банальнейший Linux, открытый. Допиливай — не хочу.

Это принципиальная разница. Остальное не так принципиально и существенно.

Здравствуйте, c-smile, Вы писали:

CS>Спасибо Денис. Да это несколько меняет дело.

А "несколько" — это насколько? Просто когда я встречаю таки ляпы, обычно сообщение уже дальше не читаю

Здравствуйте, ArtDenis, Вы писали:

AD>Здравствуйте, c-smile, Вы писали:

CS>>Спасибо Денис. Да это несколько меняет дело.

AD>А "несколько" — это насколько? Просто когда я встречаю таки ляпы, обычно сообщение уже дальше не читаю

Меняет в том смысле что я вообще перестаю понимать зачем там Java.
Известно что в managed средах потребность в физической памяти превышает
номинал — ту реальную память которая нужна для исполнения алгоритма. Причем чем больше процессов тем больше отношение потерь.
Известно что managed code медленнее чем non-managed. Плюс Java как язык несильно способствует созданию оптимальных решений. C# в этом смысле более продвинут. Хотя бы есть структуры. Я как-то писал WYSIWYG редактор на Java и могу сравнивать с аналогичным в C++ — небо и земля.

Т.е. если бы Android был моно-задачной OS я бы понял. Но "мультипроцесность" и Java — не понимаю в чем фишка.
(Но голову пеплом посыпаю все равно — надо было ознокомиться с архитектурой ея upfront)

Не понимаю зачем оно, короче. Та же Samsung Bada и/или iOS в качестве контр-примеров.
Кстати в Objective-C 2.0 есть GC но только на desktop. Apple не стал тащить GC в iOS. У них опыта больше?

Здравствуйте, SkyDance, Вы писали:

CS>>Принципиальная разница в архитектуре Android и iPhone состоит в том что

SD>iOS — закрытая проприетарная (забудем уж про freeBSD) ОС, находящаяся под полным контролем Apple, и приспособленная к работе лишь на очень фиксированном спектре оборудования.

SD>Android — банальнейший Linux, открытый. Допиливай — не хочу.
SD>Это принципиальная разница. Остальное не так принципиально и существенно.

Меня как разработчика приложений и мою жену как пользователя абсолютно не интересует открытость и закрытость ОС.
Нас обоих интересует набор функций. Разный но тем не менее.

Меня например в данный момент интересуют абстракции типа HFONT, HDC и HBITMAP в Android NDK которых там нет как класса.

С точки зрения программизма Windows Embedded/Mobile реально более солидно выглядит.

Здравствуйте, c-smile, Вы писали:

CS>Не понимаю зачем оно, короче. Та же Samsung Bada и/или iOS в качестве контр-примеров.
для работы на принципиально разной аппаратной платформе. Bada и iOS к железу привязаны намертво.

Здравствуйте, Хвост, Вы писали:

Х>Здравствуйте, c-smile, Вы писали:

CS>>Не понимаю зачем оно, короче. Та же Samsung Bada и/или iOS в качестве контр-примеров.
Х>для работы на принципиально разной аппаратной платформе. Bada и iOS к железу привязаны намертво.

А Windows Embedded/Mobile и/или MeeGo?

Здравствуйте, c-smile, Вы писали:

CS>А Windows Embedded/Mobile и/или MeeGo?
а они тоже привязаны. Я тут не имею ввиду привязку самой OS, а скорее прикладного уровня, в том месте где появляется нейтив. Андроид уже тоже привязан к ARM намертво, т.к. NDK заточено фактически только под ARM'ы. Вот до появления NDK приложения под андроид могли работать (с оговорками на версию апи) где угодно. Под "андроид" я подразумеваю опять же не голую OS, а операционку + приложения сторонних разработчиков.

Здравствуйте, Хвост, Вы писали:

CS>>Не понимаю зачем оно, короче. Та же Samsung Bada и/или iOS в качестве контр-примеров.
Х>для работы на принципиально разной аппаратной платформе. Bada и iOS к железу привязаны намертво.
Я не особо в теме, но странно слышать, что Bada привязана к железу. Это же только оболочка над ОС.

Здравствуйте, c-smile, Вы писали:

CS>Не понимаю зачем оно, короче. Та же Samsung Bada и/или iOS в качестве контр-примеров.
CS>Кстати в Objective-C 2.0 есть GC но только на desktop. Apple не стал тащить GC в iOS. У них опыта больше?
Не, просто через полтора года Джобс сообщит нам, что Apple изобрела GC в мобильных устройствах

А мне интересно, на практике этот GC используют? Учитывая консервативность Си-шного сообщества, можно ожидать, что GC — это персона нон грата. Опять же, GC не сразу появился в Objective-C и не работает в Mac OS ниже 10.5. К тому же сам Objective-C, будучи нативным языком, возможно не так хорошо приспособлен к сборщику, как Java — отсюда и решение пока не внедрять. Рано или поздно появится.

Здравствуйте, c-smile, Вы писали:

CS>Оговорюсь сразу: некоторых деталей я глубоко не знаю поэтому что-то в моих посылках может быть неверно.

По-моему, правельнее будет сказать "что-то может быть верно".

CS>Еще про late binding как отдельный аспект. Понятно что OS и приложения должны как-то взаимодействовать -
CS>т.е. нужен некий API механизм. В принципе Windows Mobile + COM как протокол предсталяется достаточно production level на настоящий момент.

Делали такое до Windows Phone. Не вышел каменный цветок.

Здравствуйте, c-smile, Вы писали:

CS>Известно что managed code медленнее чем non-managed.

Чем-то напомнило былые годы...
"Всем известно, что самый быстрый код можно получить только программируя на асме" — так говорили в 80-х годах прошлого века. Ну, и где оно сейчас? Эх, 640 килобайт памяти на всё... 256 оттенков цвета...

Здравствуйте, Mr.Delphist, Вы писали:

MD>Чем-то напомнило былые годы...
MD>"Всем известно, что самый быстрый код можно получить только программируя на асме" — так говорили в 80-х годах прошлого века. Ну, и где оно сейчас?
Оно и сейчас есть. К примеру в BigNum реализации пришлось таки пару функций написать с ASM вставками (ADD + multiple ADC, SHLD и т.п.), т.к. на ЯВУ просто нет таких абстракций, а эмуляция компилировалась в изрядно более медленный код. Я б и рад от них избавиться, но нет даже интринсиков которые можно былоб использовать.