Ближе к концу 2015 года мы столкнулись с дилеммой. Не успели мы выпустили приложение для iPad flowkey, как начали поступать запросы на версию для Android. Разве вы не знаете, что Android занимает большую часть рынка? Вы ведь знаете, что iPad для бездумных хипстеров, верно? "Разве ты не любишь нас больше ??" "Удовольствие ??"
Сообщение было ясным, но проблема была серьезной: с большой долей рынка Android возникает множество проблем, с которыми разработка iOS просто не сталкивается: разные разрешения экрана, сильно различающиеся характеристики производительности даже на новых высокопроизводительных устройствах, даже принципиально разные архитектуры процессоров на устройствах одного поколения. Как небольшая команда разработчиков (нас было четверо на момент написания), перспектива создания Android-приложения на незнакомом стеке, чтобы попытаться охватить все эти основы в любое разумное время, все время разработки, отладки и улучшение версий браузера и iPad могло показаться невозможным.
Однако у нас были благословения удачи в виде раннего решения нашего технического директора о переходе на гибрид (через Meteor) и хорошей подготовки благодаря огромным усилиям, которые мы вложили в оптимизацию производительности для версии для iPad, чтобы она работала ровно. на доисторическом (в компьютерные годы) iPad 2.
Основная особенность Flowkey - это то, что мы просто называем «игрок». Вы можете посмотреть и послушать песню или отрывок, которые вы пытаетесь выучить, замедлить ее, сделать петли и, что немаловажно, выучить в «режиме ожидания».
Режим ожидания дает вам как ученику возможность научиться находить ноты в песне в удобном для вас темпе. Видео и ноты воспроизводятся до ноты или аккорда, затем делают паузу и ждут, пока вы сыграете нужные ноты на своем настоящем пианино или клавиатуре, прежде чем снова перейти к следующей ноте или аккорду.
В браузере определение высоты звука работает через JavaScript Web Audio API, включая getUserMedia () для доступа к микрофону устройства. Но именно здесь гибридная мечта начинает разваливаться: браузер iPad, Safari и его программные аналоги UIWebView и WKWebView действительно имеют реализацию. API веб-аудио, но не getUserMedia (). Это ограничение делает невозможным доступ к микрофону из контекста браузера и делает одну из наших основных функций недоступной для гибридного использования.
Сначала мы попытались обойти это, используя собственный код для внедрения звуковых буферов микрофона в WebView для обработки в нашем существующем коде JavaScript. Это сработало, но едва - было значительное отставание, и это оказало заметное влияние на производительность даже на последней модели iPad Air. Не желая довольствоваться второсортным опытом, мы приняли решение, которое напрямую повлияет и на будущее нашего приложения для Android: мы решили переписать наши процедуры определения высоты тона в Swift.
Swift - одно удовольствие. Используя Swift, приятно писать краткий, красивый и производительный код, который хорошо читается, легко рассуждает и легко отлаживает. Спустя два года после того, как я начал работать со Swift, я все еще испытываю к нему те же чувства, что и Дэн Ким о Котлине здесь.
Версия Swift нашего определения высоты тона работала. Он был чрезвычайно производительным и обеспечивал лучший опыт, чем когда-либо мог иметь API веб-аудио, со значительно меньшей задержкой и более высокой точностью. И было много ликования.
Через несколько месяцев у нас возникла дилемма: у нас было гибридное приложение, которое уже неплохо работало на Android, но одна из наших основных функций отсутствовала (на самом деле две - это история в другой раз) по причинам производительности. У нас была версия обнаружения питча на JavaScript и версия на Swift, но ни одна из них не подходила для нашего все более актуального проекта Android.
Итак, нам пришлось сделать выбор: использовать JavaScript и ограничить загрузку приложений Android только новейшими устройствами и по-прежнему испытывать снижение производительности при использовании определения высоты тона? Перепишите определение высоты тона еще раз на C или C ++? Отказаться от этой функции на Android?
Единственный из тех возможных путей, которые мы всерьез рассматривали, в конце концов, это снова переписать определение высоты тона на более переносимом языке, таком как C. в команде имел какой-либо значительный опыт работы с любым из этих языков, вероятно, был бы пронизан ошибками и несоответствиями. Как команда из четырех человек, мы также не хотели поддерживать три версии одного и того же кода.
Проблеск света появился в виде записи в блоге Ромена Гойе о запуске кода Swift на Android. Основываясь на его наблюдениях, оказалось возможным - особенно после того, как Swift стал открытым исходным кодом в тогда неизвестный момент времени - запускать код Swift через JNI с Java на устройствах Android. После некоторых размышлений (учитывая, что время было не на нашей стороне), мы решили рискнуть и пойти по пути запуска нашего кода Swift на Android.
В следующей части рассказывается Как мы помещаем приложение в Android Play Store с помощью Swift.
