Qt — дело хорошее, но только это никоим образом не замена NDK. Кроме того, у меня есть все основания полагать, что Qt, собранный на базе CrystaX NDK, и работать будет лучше.
Да, есть, начинаем этим заниматься с завтрашнего дня. Собственно, вот тикет, по которому можно будет отслеживать статус. Тикет старый, заведен больше года назад, но в первую очередь нужно было обеспечить надежную работу базового уровня (libcrystax как замена libc), без этого не было смысла браться за работу, которая ожидает честного POSIX поведения от системы. Теперь же, когда большая часть работы по обеспечению POSIX-соответствия проделана, можно браться и за более заметные для пользователей задачи.
Когда-то давно я делал подобное, только заточенное на манипуляции с физическими величинами (масса, время, расстояние, сила тока и т.д.). Поддерживались различные системы измерений (СИ, СГС и т.д.) и автоматическое конвертирование между ними. На раннюю версию (но уже вполне функциональную) можно посмотреть здесь.
Уже давно для своих проектов использую rake — весьма неплохая альтернатива make, лишенная перечисленных выше недостатков. К тому же, если возможностей Rake DSL не хватает, всегда можно локально перейти на обычный ruby — и все это бесшовно. Жаль только, что за пределами мира RoR rake малоизвестен. Фактически rake — это такой "'make' done right". Не больше, но и не меньше.
Каждый раз, когда вижу подобные прогнозы, хочется спросить: «Это вам кто-то сказал или вы сами догадались?»
Серьезно, говорится с таким апломбом и такой уверенностью! Но на чем она, уверенность эта, основана? Простая линейная интерполяция. Историю нельзя линейно интерполировать! Впрочем, экспоненциально, параболоидно и т.д. тоже нельзя.
Не вижу никакой связи между алгоритмом планировщика и закрытостью/открытостью низкоуровневого API аппаратного ускорения графики. Вся разница между Android-ом и iOS (в разрезе обсуждения производительности графики) состоит исключительно в том, как реализован планировщик. Не понимаю, почему вы все время пытаетесь приплести сюда закрытость/открытость API (тем более что на уровне ядра, где работает планировщик, такого понятия и не существует вовсе). В огороде бузина, а в Киеве дядька.
Впрочем, объяснять детали устройства планировщика я не буду, да и, пожалуй, вовсе ничего больше объяснять не буду. Ваши коментарии пестрят фактическими ошибками вперемешку с перескакиванием с одной темы на другую (кто ясно мыслит, тот ясно излагает). Повторюсь. Если вам это действительно интересно, читайте документацию, изучайте исходники и т.д. В противном случае — увольте, свое время на вас тратить не буду.
В данном топике вы не столько говорите о том, что на солнце есть пятна, сколько перескакиваете с одной темы на другую, сопровождая это довольно бессмысленными и провокационными замечаниями.
По существу же вопроса — что закрыто в Android? Многопоточность?!!! Конечно же нет! Там вполне стандартные Posix threads, а в Java — Java threads. Закрыто же низкоуровневое API к аппаратному ускорению графики (но OpenGL поддерживается, и этого часто более чем достаточно). Но закрыто оно не по причине злобных намерений Google, а просто из-за того, что оно — нестабильное. Google, если вы не в курсе, берет на себя обязательство обеспечить 20-летний срок жизни программы, а потому очень аккуратно подходит к вопросу стабильности API. А ресурсы даже у Google для этого весьма ограниченные.
И вообще, прекращайте генерировать белый шум. Пойдите лучше на source.android.com, скачайте исходники и поизучайте. Ей-богу, это будет куда более полезной тратой времени, чем написание коментариев «ни о чем».
Скажите, пожалуйста, вы зачем все это пишете? Хотите рассказать, как в Андроиде все плохо? Спасибо, и без вас таких героев достаточно. Прекращайте срач, ей-богу.
Аппаратная поддержка есть, но API для нее закрытое. Вы, тем не менее, можете эти API (закрытые) использовать, но будьте готовы, что с выходом новой версии Android все поломается и придется писать доп. код для поддержки новой версии. И так для каждой новой версии. На самом деле это не такая уж большая проблема, особенно если учитывать, что Android в open source (т.е. можно посмотреть исходники и выяснить что изменилось), но бывают и с этим проблемы. Помните honeycomb? Устройства уже на рынке, и три версии вышло (3.0, 3.1, 3.2) а исходников — нету. В таких ситуациях останется только брать dex декомпилятор и с помощью какой-то там матери разбираться. Тоже не смертельно, но не так уж легко и приятно.
В NDK появилась возможность работать с битмапами из нативного кода только начиная с API level 9. Т.е. если ваша целевая платформа — Android 2.3 и выше, тогда проблем нет. Если же вы ориентируетесь на Android 2.2 или более ранние версии — официально поддерживаемого пути нет (хотя, конечно же, можно сделать платформно-специфичную обвязку). Но не ожидайте слишком многого — все, что есть в native для работы с битмапами — это API для прямого доступа к памяти. Все операции вращения/стягивания/копирования и т.д. нужно реализовывать самому или воспользоваться существующими библиотеками (например, OpenCV, хотя она и не совсем для этого предназначена).
Совершенно верно, часто важна даже не «производительность», а «портируемость». Скажу откровенно, во всех Android проектах, где мне довелось поучаствовать с 2009-го года, всего один раз встал вопрос о производительности. В остальных же случаях нативная часть была нужна главным образом из-за портируемости. К примеру, в проекте rhomobile, в котором я участвовал несколько лет, было единое ядро на C и C++, и совсем немного платформно-специфичной обвязки для конкретных платформ (iOS, Android, Win Mobile, Symbian). Собственно, в значительной мере моими силами это единое ядро и было создано.
Google же игнорирует этот аспект, упирая только на производительность. А с точки зрения бизнеса куда важнее повторная используемость уже написанного и отлаженного кода, чем «идеологическая правильность».
Вы совершенно верно процитировали: «you should only use native code if it is essential to your application». Так вот, несмотря на общую правильность этой фразы, Google не прикладывает особых усилий для облегчения жизни разработчиков, для которых «native code is essential». Почему так происходит — вопрос отдельный, но конечный результат неудовлетворителен. А, как известно из народных пословиц, свято место пусто не бывает.
Повторюсь еще раз — я даю разработчикам возможности, которых не хватает в первую очередь мне самому, а там уж само собой так получается, что эти фичи востребованы не только мной. Это типичное проявление рынка, между прочим — есть спрос, появляется предложение.
Спорить о идеологической правильности не хочу. В отличие от многих, не считаю себя вправе указывать другим людям что им нужно, а что — нет. Мой подход исключительно инженерный: «Вот вам инструмент, а что с ним делать, решайте сами».
Позволю себе только заметить — идеологическая правильность и прочий bullshit хороши, только если они удовлетворяют потребности пользователей. Если же нет — они не выживают.
Странное у вас определение идеологии NDK. Напомню, NDK — это Native Development Kit. Так же, как SDK — это Software Development Kit. Вы же не удивляетесь, что Google добавляет в SDK с каждой версией новые возможности? Почему же должно быть как-то по другому в отношении NDK?
Тут, конечно, все дело в том, что для Google NDK — это вынужденный шаг. Они не хотели давать разработчикам доступ к native, но реальность жестока — розовые мечтания разбились о жестокие ограничения реального мира и Java оказалось просто непригодной для многих задач на Android (прежде всего вычислительных). Поэтому Google начал сдавать позиции — сначала открыл NDK (когда уже по факту многие разработчики стали встраивать native части в свои приложения), затем — добавил поддержку C++ exceptions и RTTI (опять-таки, после того как уже очень многие этим пользовались), на очереди — следующие улучшения. Я четко осознаю, что для Google native — не приоритетное направление, отсюда это постоянное запаздывание. Но вот какая штука — для меня и для многих других разработчиков, в отличие от Google, это направление приоритетное. Спасение утопающих — дело рук самих утопающих.
Кроме того, вы так говорите о добавленных возможностях, как будто они кому-то мешают. На самом деле это не так. Если вы в своем приложении не используете wide characters — прекрасно, эта часть кода и не будет присутствовать в конечном бинарнике. Если вы явно выключите исключения и/или RTTI — это тоже будет выкинуто. Но, в отличие от Google NDK, если вам это все понадобится, вы сможете включить эти возможности без проблем. Иными словами, я предлагаю дополнительные возможности, а уж пользоваться ими или нет — решать разработчикам. По моему скромному мнению, этот подход много лучше того, что используется в Google.
На самом деле времени уходит не так уж много. Да и feedback от благодарных пользователей — это очень мощная движущая сила, благодаря которой уже не раз, когда выбор стоял между пассивным отдыхом и работой над NDK, выбор делался в пользу последнего.
Этот вопрос мне часто задавали. Скажем так, есть во мне некий скепсис по отношению к большим корпорациям. И даже Google, при всей их ориентации на разработчиков, не способен сделать для моего комфорта больше, чем сделаю я сам.
А насчет «гения» — ну это вы погорячились. Как говорил дедушка Ленин — «учиться, учиться и еще раз учиться». А затем — работать.
Серьезно, говорится с таким апломбом и такой уверенностью! Но на чем она, уверенность эта, основана? Простая линейная интерполяция. Историю нельзя линейно интерполировать! Впрочем, экспоненциально, параболоидно и т.д. тоже нельзя.
Впрочем, объяснять детали устройства планировщика я не буду, да и, пожалуй, вовсе ничего больше объяснять не буду. Ваши коментарии пестрят фактическими ошибками вперемешку с перескакиванием с одной темы на другую (кто ясно мыслит, тот ясно излагает). Повторюсь. Если вам это действительно интересно, читайте документацию, изучайте исходники и т.д. В противном случае — увольте, свое время на вас тратить не буду.
По существу же вопроса — что закрыто в Android? Многопоточность?!!! Конечно же нет! Там вполне стандартные Posix threads, а в Java — Java threads. Закрыто же низкоуровневое API к аппаратному ускорению графики (но OpenGL поддерживается, и этого часто более чем достаточно). Но закрыто оно не по причине злобных намерений Google, а просто из-за того, что оно — нестабильное. Google, если вы не в курсе, берет на себя обязательство обеспечить 20-летний срок жизни программы, а потому очень аккуратно подходит к вопросу стабильности API. А ресурсы даже у Google для этого весьма ограниченные.
И вообще, прекращайте генерировать белый шум. Пойдите лучше на source.android.com, скачайте исходники и поизучайте. Ей-богу, это будет куда более полезной тратой времени, чем написание коментариев «ни о чем».
Google же игнорирует этот аспект, упирая только на производительность. А с точки зрения бизнеса куда важнее повторная используемость уже написанного и отлаженного кода, чем «идеологическая правильность».
Повторюсь еще раз — я даю разработчикам возможности, которых не хватает в первую очередь мне самому, а там уж само собой так получается, что эти фичи востребованы не только мной. Это типичное проявление рынка, между прочим — есть спрос, появляется предложение.
Спорить о идеологической правильности не хочу. В отличие от многих, не считаю себя вправе указывать другим людям что им нужно, а что — нет. Мой подход исключительно инженерный: «Вот вам инструмент, а что с ним делать, решайте сами».
Позволю себе только заметить — идеологическая правильность и прочий bullshit хороши, только если они удовлетворяют потребности пользователей. Если же нет — они не выживают.
Тут, конечно, все дело в том, что для Google NDK — это вынужденный шаг. Они не хотели давать разработчикам доступ к native, но реальность жестока — розовые мечтания разбились о жестокие ограничения реального мира и Java оказалось просто непригодной для многих задач на Android (прежде всего вычислительных). Поэтому Google начал сдавать позиции — сначала открыл NDK (когда уже по факту многие разработчики стали встраивать native части в свои приложения), затем — добавил поддержку C++ exceptions и RTTI (опять-таки, после того как уже очень многие этим пользовались), на очереди — следующие улучшения. Я четко осознаю, что для Google native — не приоритетное направление, отсюда это постоянное запаздывание. Но вот какая штука — для меня и для многих других разработчиков, в отличие от Google, это направление приоритетное. Спасение утопающих — дело рук самих утопающих.
Кроме того, вы так говорите о добавленных возможностях, как будто они кому-то мешают. На самом деле это не так. Если вы в своем приложении не используете wide characters — прекрасно, эта часть кода и не будет присутствовать в конечном бинарнике. Если вы явно выключите исключения и/или RTTI — это тоже будет выкинуто. Но, в отличие от Google NDK, если вам это все понадобится, вы сможете включить эти возможности без проблем. Иными словами, я предлагаю дополнительные возможности, а уж пользоваться ими или нет — решать разработчикам. По моему скромному мнению, этот подход много лучше того, что используется в Google.
P.S. Если не ошибаюсь, мы ведь некоторое время работали над одним проектом? Для AndroidWorks.
А насчет «гения» — ну это вы погорячились. Как говорил дедушка Ленин — «учиться, учиться и еще раз учиться». А затем — работать.