Comments 58
Вы гений, почему бы Вам не работать в Google?
Этот вопрос мне часто задавали. Скажем так, есть во мне некий скепсис по отношению к большим корпорациям. И даже Google, при всей их ориентации на разработчиков, не способен сделать для моего комфорта больше, чем сделаю я сам.
А насчет «гения» — ну это вы погорячились. Как говорил дедушка Ленин — «учиться, учиться и еще раз учиться». А затем — работать.
А насчет «гения» — ну это вы погорячились. Как говорил дедушка Ленин — «учиться, учиться и еще раз учиться». А затем — работать.
UFO just landed and posted this here
В NDK появилась возможность работать с битмапами из нативного кода только начиная с API level 9. Т.е. если ваша целевая платформа — Android 2.3 и выше, тогда проблем нет. Если же вы ориентируетесь на Android 2.2 или более ранние версии — официально поддерживаемого пути нет (хотя, конечно же, можно сделать платформно-специфичную обвязку). Но не ожидайте слишком многого — все, что есть в native для работы с битмапами — это API для прямого доступа к памяти. Все операции вращения/стягивания/копирования и т.д. нужно реализовывать самому или воспользоваться существующими библиотеками (например, OpenCV, хотя она и не совсем для этого предназначена).
UFO just landed and posted this here
Аппаратная поддержка есть, но API для нее закрытое. Вы, тем не менее, можете эти API (закрытые) использовать, но будьте готовы, что с выходом новой версии Android все поломается и придется писать доп. код для поддержки новой версии. И так для каждой новой версии. На самом деле это не такая уж большая проблема, особенно если учитывать, что Android в open source (т.е. можно посмотреть исходники и выяснить что изменилось), но бывают и с этим проблемы. Помните honeycomb? Устройства уже на рынке, и три версии вышло (3.0, 3.1, 3.2) а исходников — нету. В таких ситуациях останется только брать dex декомпилятор и с помощью какой-то там матери разбираться. Тоже не смертельно, но не так уж легко и приятно.
UFO just landed and posted this here
Ну весь API анроидовский — он пока в Джаве, и как правильно заметил ниже crystax — в идеологии Гугль — NDK это не замена Java API — а дополнительная возможность для написания критического по скорости кода и способа повторно использовать существующий код. Они постепенно добавляют возможности и новый API (например, с помощью NativeActivity уже можно создать приложение вообще без использования Java), но native API по любому всегда будет у'же родного. Хотя бы потому, что значительная часть API реализована уже в джаве, и вызов ее из ndk значит привлечение медленного jni.
UFO just landed and posted this here
Дурацкий вопрос: а почему собственно не openGL? Если результат, все равно потом идет на экран, то для упомянутых вами действий GL отлично подходит, плюс автоматом есть аппаратное ускорение.
UFO just landed and posted this here
Аа, ну так бы сразу и сказали, что использовать подходящие инструменты вам религия не позволяет…
ЗЫ: весь UI в iOS рисуется через OpenGL в конечном счете ;)
ЗЫ: весь UI в iOS рисуется через OpenGL в конечном счете ;)
UFO just landed and posted this here
Жирно. Вообще-то, говоря про «религию» речь шла исключительно про инструменты, и не надо затевать дурацкий холивор «Android vs iPhone». А ирония состоит в том, что более плавное отображение UI в iOS достигается в большой степени как раз за счет отрисовки с помощью аппаратно-ускоренного OpenGL, который вы считаете «медленным прибамбасом» :)
UFO just landed and posted this here
То, что вы описали — это тоже один из факторов.
За сим откланяюсь — посмотрев на ваши комментарии к вашей же статье я понял, что спорить с воинствующем невеждой — дело неблагодарное.
За сим откланяюсь — посмотрев на ваши комментарии к вашей же статье я понял, что спорить с воинствующем невеждой — дело неблагодарное.
UFO just landed and posted this here
Скажите, пожалуйста, вы зачем все это пишете? Хотите рассказать, как в Андроиде все плохо? Спасибо, и без вас таких героев достаточно. Прекращайте срач, ей-богу.
UFO just landed and posted this here
В данном топике вы не столько говорите о том, что на солнце есть пятна, сколько перескакиваете с одной темы на другую, сопровождая это довольно бессмысленными и провокационными замечаниями.
По существу же вопроса — что закрыто в Android? Многопоточность?!!! Конечно же нет! Там вполне стандартные Posix threads, а в Java — Java threads. Закрыто же низкоуровневое API к аппаратному ускорению графики (но OpenGL поддерживается, и этого часто более чем достаточно). Но закрыто оно не по причине злобных намерений Google, а просто из-за того, что оно — нестабильное. Google, если вы не в курсе, берет на себя обязательство обеспечить 20-летний срок жизни программы, а потому очень аккуратно подходит к вопросу стабильности API. А ресурсы даже у Google для этого весьма ограниченные.
И вообще, прекращайте генерировать белый шум. Пойдите лучше на source.android.com, скачайте исходники и поизучайте. Ей-богу, это будет куда более полезной тратой времени, чем написание коментариев «ни о чем».
По существу же вопроса — что закрыто в Android? Многопоточность?!!! Конечно же нет! Там вполне стандартные Posix threads, а в Java — Java threads. Закрыто же низкоуровневое API к аппаратному ускорению графики (но OpenGL поддерживается, и этого часто более чем достаточно). Но закрыто оно не по причине злобных намерений Google, а просто из-за того, что оно — нестабильное. Google, если вы не в курсе, берет на себя обязательство обеспечить 20-летний срок жизни программы, а потому очень аккуратно подходит к вопросу стабильности API. А ресурсы даже у Google для этого весьма ограниченные.
И вообще, прекращайте генерировать белый шум. Пойдите лучше на source.android.com, скачайте исходники и поизучайте. Ей-богу, это будет куда более полезной тратой времени, чем написание коментариев «ни о чем».
UFO just landed and posted this here
*facepalm*
Не вижу никакой связи между алгоритмом планировщика и закрытостью/открытостью низкоуровневого API аппаратного ускорения графики. Вся разница между Android-ом и iOS (в разрезе обсуждения производительности графики) состоит исключительно в том, как реализован планировщик. Не понимаю, почему вы все время пытаетесь приплести сюда закрытость/открытость API (тем более что на уровне ядра, где работает планировщик, такого понятия и не существует вовсе). В огороде бузина, а в Киеве дядька.
Впрочем, объяснять детали устройства планировщика я не буду, да и, пожалуй, вовсе ничего больше объяснять не буду. Ваши коментарии пестрят фактическими ошибками вперемешку с перескакиванием с одной темы на другую (кто ясно мыслит, тот ясно излагает). Повторюсь. Если вам это действительно интересно, читайте документацию, изучайте исходники и т.д. В противном случае — увольте, свое время на вас тратить не буду.
Впрочем, объяснять детали устройства планировщика я не буду, да и, пожалуй, вовсе ничего больше объяснять не буду. Ваши коментарии пестрят фактическими ошибками вперемешку с перескакиванием с одной темы на другую (кто ясно мыслит, тот ясно излагает). Повторюсь. Если вам это действительно интересно, читайте документацию, изучайте исходники и т.д. В противном случае — увольте, свое время на вас тратить не буду.
Упс, согласившись про «один из факторов» — я конечно загнул, просто не прочитав внимательно сообщение этого кадра. Вообще-то изначальная фраза «Просто в случае нативного программирования никто не встрянет без спроса, и не будет дёргания, а есть OpenGL или нет его — дело вкуса.» — это бред от начала до конца. И еще, я не верю, что человек утверждающий «более 10 лет опыта в С++» может настолько не разбираться в работе ОС и многозадачности. Тут или толстый троллинг, или автор врет насчет своего опыта. А может и то и другое…
UFO just landed and posted this here
«Запретить прерывания»? Лол, вы бредите. Пойдите почитайте что-нибудь, скажем, про современные операционные системы, защищенный режим, виртуальную память. Про многозадачность и многопоточность наконец. А то по потокам бессвязного бреда в комментариях вперемешку с заявлениями «процессоры, openGL и html — это все говно, я могу сделать лучше» — вырисовывается четкая картина подростка с манией величия и склонностью к троллизму. Тоже мне, болгенОс v2.0…
Пользуясь случаем хочу вам сказать большое спасибо. Ваши сборки NDK мне в свое время сильно экономили время.
Спасибо за безвозмездный вклад в общее дело. Как у Вас находится столько времени на разработку «для удовольствия»?
UFO just landed and posted this here
А вы игры писали под android? Там java кода 2%, если он вообще есть. И поверте не просто так…
Странное у вас определение идеологии 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.
Тут, конечно, все дело в том, что для Google NDK — это вынужденный шаг. Они не хотели давать разработчикам доступ к native, но реальность жестока — розовые мечтания разбились о жестокие ограничения реального мира и Java оказалось просто непригодной для многих задач на Android (прежде всего вычислительных). Поэтому Google начал сдавать позиции — сначала открыл NDK (когда уже по факту многие разработчики стали встраивать native части в свои приложения), затем — добавил поддержку C++ exceptions и RTTI (опять-таки, после того как уже очень многие этим пользовались), на очереди — следующие улучшения. Я четко осознаю, что для Google native — не приоритетное направление, отсюда это постоянное запаздывание. Но вот какая штука — для меня и для многих других разработчиков, в отличие от Google, это направление приоритетное. Спасение утопающих — дело рук самих утопающих.
Кроме того, вы так говорите о добавленных возможностях, как будто они кому-то мешают. На самом деле это не так. Если вы в своем приложении не используете wide characters — прекрасно, эта часть кода и не будет присутствовать в конечном бинарнике. Если вы явно выключите исключения и/или RTTI — это тоже будет выкинуто. Но, в отличие от Google NDK, если вам это все понадобится, вы сможете включить эти возможности без проблем. Иными словами, я предлагаю дополнительные возможности, а уж пользоваться ими или нет — решать разработчикам. По моему скромному мнению, этот подход много лучше того, что используется в Google.
UFO just landed and posted this here
Вы совершенно верно процитировали: «you should only use native code if it is essential to your application». Так вот, несмотря на общую правильность этой фразы, Google не прикладывает особых усилий для облегчения жизни разработчиков, для которых «native code is essential». Почему так происходит — вопрос отдельный, но конечный результат неудовлетворителен. А, как известно из народных пословиц, свято место пусто не бывает.
Повторюсь еще раз — я даю разработчикам возможности, которых не хватает в первую очередь мне самому, а там уж само собой так получается, что эти фичи востребованы не только мной. Это типичное проявление рынка, между прочим — есть спрос, появляется предложение.
Спорить о идеологической правильности не хочу. В отличие от многих, не считаю себя вправе указывать другим людям что им нужно, а что — нет. Мой подход исключительно инженерный: «Вот вам инструмент, а что с ним делать, решайте сами».
Позволю себе только заметить — идеологическая правильность и прочий bullshit хороши, только если они удовлетворяют потребности пользователей. Если же нет — они не выживают.
Повторюсь еще раз — я даю разработчикам возможности, которых не хватает в первую очередь мне самому, а там уж само собой так получается, что эти фичи востребованы не только мной. Это типичное проявление рынка, между прочим — есть спрос, появляется предложение.
Спорить о идеологической правильности не хочу. В отличие от многих, не считаю себя вправе указывать другим людям что им нужно, а что — нет. Мой подход исключительно инженерный: «Вот вам инструмент, а что с ним делать, решайте сами».
Позволю себе только заметить — идеологическая правильность и прочий bullshit хороши, только если они удовлетворяют потребности пользователей. Если же нет — они не выживают.
Мне кажется, тут дело скорее не в «производительности джава vs проиводительность native», а в переносимости. Некоторые вещи, действительно в VM слишком накладно, но думаю в трех случаях из четырех, к NDK прибегают по другим причинам. Слишком много кода уже написано на C/C++ и слишком высока цена, что бы писать потенциально переносимый кода, пускай и на более удобном (для некоторых), но специфичном для платформы языке. Игры с небольшими костылями в виде Marmelade — я вообще пишу без строчки кода на родных платформенных языков вроде Java/ObjectiveC.
Совершенно верно, часто важна даже не «производительность», а «портируемость». Скажу откровенно, во всех Android проектах, где мне довелось поучаствовать с 2009-го года, всего один раз встал вопрос о производительности. В остальных же случаях нативная часть была нужна главным образом из-за портируемости. К примеру, в проекте rhomobile, в котором я участвовал несколько лет, было единое ядро на C и C++, и совсем немного платформно-специфичной обвязки для конкретных платформ (iOS, Android, Win Mobile, Symbian). Собственно, в значительной мере моими силами это единое ядро и было создано.
Google же игнорирует этот аспект, упирая только на производительность. А с точки зрения бизнеса куда важнее повторная используемость уже написанного и отлаженного кода, чем «идеологическая правильность».
Google же игнорирует этот аспект, упирая только на производительность. А с точки зрения бизнеса куда важнее повторная используемость уже написанного и отлаженного кода, чем «идеологическая правильность».
Плюсанул и пост, и карму. Таких разработчиков и таких статей побольше бы на хабре.
Супер! Спасибо огромное! Не знал, что есть такая штука, хотя постоянно работаю с NDK.
Спасибо :) Использовал crystax ndk r4 вместе с cocos2d-x, после принятия ваших изменений стало достаточно официального ndk.
Кто живет на дне океана?
Сейчас занимаюсь подобной темой, но больше всего с Objective-C поддержкой и clang. Буду рад влиться в проект.
Sign up to leave a comment.
Улучшенный Android NDK (Native Development Kit)