Comments 29
Чувак, большое тебе спасибо за продвижение Go в сторону Андройда :)
Им потом памятник обязательно поставят.
А вот развитие Go в русском сообществе, а особенно популяризация в мобильной составляющей, это сейчас достаточно важно.
Неделя Go на Хабре прям.

Проведенный анализ не выявил проблем кода. Алгоритм работал безупречно, памяти потреблял в строго отведенных количествах, не отвлекался на посторонние процессы, все асинхронно, аппаратных ресурсов предостаточно. Вывод напрашивался только один — виртуальная машина android dalvik имеет производительность, отличную от JVM, и в рамках dalvik данный код обречен на тормоза.
Вот так просто — причина в dalvik? Или причина в каких-то участках кода, которые тормозят под dalvik? Вы профилирование кода когда проводили, не нашли этих участков?

Мне просто видится странным полностью переписывать реализацию на другом языке, при этом не попытавшись оптимизировать уже существующий вариант. Или, по крайней мере, разобраться, что именно тормозит.
Переход на другой язык не было простым решением. В анализ сложившейся ситуации было вложено немало времени. Да, был небольшой маневр для оптимизации, но кардиналных улучшений не предвещал. Против идеи продолжить оптимизировать java-код также был тот факт, что Google Keyboard использует для своих предсказаний именно нативный код, правда не на golang. Возможно, есть решение этого вопроса и в dalvik, но это уже будет совсем другой алгоритм, и с неопределенными сроками завершения.
Ничего себе. Даже будучи оптимистически настроенным касательно Go на Android/iOS, уж никак не ожидал подобной истории так быстро (особенно учитывая совсем свежий статус gomobile).

Разрабатывается обычный golang package, никаких дополнительных рекомендаций. Экспортные методы будут доступны из android.

А в «обычный golang package» всё же нужно импортить что-то из gomobile и вызывать какие-то функции или это может быть уже существующий пакадж, который писался ещё до того, как gomobile был в мыслях?
Ничего дополнительного с кодом golang делать не надо. Ему вобще не интересно, где и кто его запускает. Всю работу сборки библиотеки для android проделает gomobile.
Вроде ходили слухи что скоро можно будет на Go полностью разрабатывать приложения для Android (т.е. обходиться одним Go, без Java). Есть какие-то подвижки в этом направлении?
Да-да, нужно только исправить линкер, а то его писало 2.5 хипстера в обеденные перерывы, сделать нормальную поддержку x86 архитектуры (а то мои appium-тесты и android-x86 «чота не работают» (ц)), и добавить вменяемый механизм вызова java-методов, не требующий вставки кода на C (https://github.com/golang/mobile/blob/master/audio/al/al_android.go — ШТА ЭТО?).
Мне даже страшно представить то время, когда golang покроет весь функционал android, а заодно и ios. Это какая-то утопия. Но судя по происходящему, это весьма вероятная реальность недалекого будущего.
В java коде была явно какая-то проблема (а скорее всего — в его интеграции на андроид). Не может время работы уменьшиться с 7 секунд на java до 10мс на Go.
Есть ли возможность попробовать снять трейс методов на java коде? (кнопочка start method tracing в Android Studio на вкладке Android). Уж больно интересно, что там может тормозить.
Боюсь, такой возможности нет. Но при разработке следующего приложения обязательно обращусь за помощью.
Согласен, вы можете сомневаться в качестве проведенного анализа проблемы. Но даже в этом случае мы стоим перед фактом, что библиотека на golang заработала, а на java — нет. И у меня даже нет сомнений, на чем реализовывать требовательный функционал в следующий раз.
То что вы завели Go на андроиде это похвально, но не разобравшись с ситуацией, мы получим ещё один миф, что java тормозит.
Ни в коем случае не хотел бы поучаствовать в создании такого мифа. Люди, слышите, java не тормозит! Статья не об этом, если кому-то показалось.
Вообще показалось. Из статьи выходит, что проще переписать на Go, чем пытаться оптимизировать java.
Да нет такого мифа есть куча измерений. Посмотрите на измерение сортировки на Dalvik. Главное упущение в статье, что Android уже не использует Dalvik (ADT). Во-вторых Dalvik тоже сильно отличается 1.5 от 2.3 (появился первый JIT). У меня есть достаточно примеров, которые тормозят, в свое время когда пытался оптимизировать, приходилось делать совершенно идиотские оптимизации как реиспользование объектов, лишь бы не выделять память заново. В конце концов, эти оптимизации устарели, а еще, хуже всего, вели к логическим ошибкам. Лучше уже было на С важные куски написать. В общем, фризы — бич Dalvik интерпретатора.

И не java тормозит, а Dalvik совсем никакой по сравнению с JVM.
На самом деле, в новом android runtime ART получились такие-же рузультаты, как на dalvik. Не стал включать это в статью, наверное, зря. Вынос требовательного функционала в нативный код остается пока актуальным вариантом.
Добрый день, подскажите пожалуйста где можно найти туториал для ознакомления с golang для людей без С++ прошлого. Спасибо.
Знания с++ при разработке на golang потребуются только в специальных случаях. Так что начинать изучать можно с любого доступного места. Например, отсюда. На Хабре также полно материала.
Надеюсь, это не будет считаться рекламой play.google.com/store/apps/details?id=com.rpkue.android.qwas

Да, реддит видел, спасибо, перевод уже в процессе.
А каков размер библиотеки получился? По моим наблюдениям бинарники у Go довольно не маленькие. А так идея заманчивая.
Да, библиотека получается большая. В моем случае — 3,5 Мб. Но она не отъедает dalvik heap, а в сжатом виде имеет вполне приличный размер: в моем случае — 1 Мб. Поэтому размер библиотеки не должен стать ограничением этого метода.
Only those users with full accounts are able to leave comments. Log in, please.