Встраивание Python в мобильные приложения – нюансы...

transcript

Встраивание Python в мобильныеприложения

нюансы interoperation, новые приемы разработки

Никита Лесников

Дисклеймер

I Доклад носит общий характер, без нюансовотдельных платформ

I Все описанные решения не “коробочные”, чтобывелосипед поехал, надо существеннопоработать напильником

I В простых случаях, где нетмногоплатформенности или серверной части,многие описанные решения будут оверкилльны

I Не смущает вышесказанное? Тогда поехали...

Зоопарк ЯП

I Языки программирования не являются “вещью всебе”

I Часто область применения определяет больше,нежели синтаксис или дисциплина типизации

I В отдельных областях de facto сложилисьрешения, от которых отойти нельзя при всехкажущихся недостатках

Зоопарк ЯП

Web - классический пример

I Сколько языков необходимо, чтобы создатьтипичное веб-приложение?

I Попробуем посчитать:

1. HTML - разметка страниц2. CSS - стилизация страниц3. JavaScript - клиентское скриптование4. Что угодно еще - серверная часть

I Четыре языка для описания одной сущности!I Организационный кошмарI Повторное использование кода невозможно

I Попробуем посчитать:

1. HTML - разметка страниц2. CSS - стилизация страниц3. JavaScript - клиентское скриптование4. Что угодно еще - серверная часть

I Попробуем посчитать:1. HTML - разметка страниц

2. CSS - стилизация страниц3. JavaScript - клиентское скриптование4. Что угодно еще - серверная часть

I Попробуем посчитать:1. HTML - разметка страниц2. CSS - стилизация страниц

3. JavaScript - клиентское скриптование4. Что угодно еще - серверная часть

I Попробуем посчитать:1. HTML - разметка страниц2. CSS - стилизация страниц3. JavaScript - клиентское скриптование

4. Что угодно еще - серверная частьI Четыре языка для описания одной сущности!I Организационный кошмарI Повторное использование кода невозможно

I Попробуем посчитать:1. HTML - разметка страниц2. CSS - стилизация страниц3. JavaScript - клиентское скриптование4. Что угодно еще - серверная часть

I Четыре языка для описания одной сущности!

I Организационный кошмарI Повторное использование кода невозможно

I Четыре языка для описания одной сущности!I Организационный кошмар

I Повторное использование кода невозможно

Web - попытки решить проблему

I node.js - возможность разработки сервернойлогики на JavaScript (позволяет code reuseмежду клиентской и серверной частями)

I шаблонизаторы - отделяют HTML-код страницыот ее логического представления, делаявозможным смену представления без правкибизнес-логики

I Объективные качества упомянутых подходовлежат за рамками этого доклада

Мобильная разработка чем-то похожа...I Авторы кроссплатформенных приложений длямобильных платформ сталкиваются с (почти тойже) проблемой

I Разве что код надо переписывать один и тот жена разных языках, а не компоновать единыйпроект из разнородных кусочков

I Java, Objective-C и C++ достаточно различны,чтобы сделать автоматическое портированиедостаточно нетривиальным

I Даже поддержка native code многого негарантирует - Objective-C++ не совместим науровне лексера с C++03, на Androidnon-POSIX-compliant-libc

I Если у проекта есть серверная часть,добавляются “языковые проблемы веба”

...однако и чем-то различна

I У всех платформ современных смартфонов, заисключением Windows Phone 7, есть-таки общаячерта

I Как ни странно, это ANSI CI Objective-C является его прямымнадмножеством, у Android с C изначально всехорошо

I Разве что как язык C не слишкомвоодушевляющ - подсчет битов являетсяпоследним делом, которым хочется заниматьсяв большом кроссплатформенном проекте с и такограниченными ресурсами

I Особенно, когда “высвободившаяся”производительность изначально не нужна

I Как ни странно, это ANSI C

I Objective-C является его прямымнадмножеством, у Android с C изначально всехорошо

Казалось бы, причем тут Python?

I Python - интерпретируемый высокоуровневыйязык с динамической типизацией

I ООП, интроспекция, метапрограммирование -все в наличии

I Куча крутых библиотек, в том числе в базовойпоставке (что отражено в девизе - batteriesincluded)

I Простой API для C, что автоматически означаетпростой API для чего угодно

I Весь рантайм также написан на С ипредставляет из себя самодостаточную системудля разработки, отладки и выполнения кода

I Этот самый “весь рантайм” можно сделатьчастью вашего приложения

Как это можно использовать?

I Писать на Python большую частьслабокритичного к платформенным нюансам ипроизводительности кода

I Как следствие, нативная и/илиплатформозависимая часть сократится

I Общее количество кода станет сильно меньше,что всегда хорошо

I При адекватном подходе производительностьбудет более чем приемлимой

Почему именно Python?I Больше вопрос вкуса

I Хорошая альтернатива - Lua, легчевстраивается, но и стандартная библитекапоменьше (“из коробки” ее фактически нет)

I Python очень консистентен и предсказуем -“неожиданностей” не бывает почти никогда придолжном понимании основных концепций

I “Должное понимание” - не некое абстрактноепонятие, как, например, мифическое “хорошеезнание C++”, оно вполне достижимо за оченьограниченный срок

I По опыту wargaming.net, программисты безпрежнего знания Python, но с сильнымбэкграундом в других областях, осваиваются засчитанные дни

Почему именно Python?I Больше вопрос вкусаI Хорошая альтернатива - Lua, легчевстраивается, но и стандартная библитекапоменьше (“из коробки” ее фактически нет)

О чем я расскажу

I Цель - не перечислить написать referencemanual по embedding API, а показать одно извозможных решений целого спектра проблем

I Не знаете Python? Это не страшно, его знаниетут некритично - повествование больше науровне идей

I Мне тоже по ходу можно (и нужно) задаватьвопросы, если что-то непонятно

Собственно по теме доклада :)I Берем source distribution c исходниками Python

I Собираем статическую библиотеку, отключиввсе ненужное

I “Все ненужное” - это почти все. И чем болеепочти, тем безболезненнее проходит сборка -core python собирается при помощи autotools икомпилятора C, без внешних зависимостейвообще

I Проблемы могут быть, но все решается быстрымпоиском по core development документации,stackoverflow и подобным ресурсам

I Большинство проблем лечатся ключами кconfigure

I Даже core сборка содержит много крутыхвещей (коллекции, регэкспы, хеши, даты,сериализацию, адекватный Unicode)

I Это всегда допустимый fallback

Собственно по теме доклада :)I Берем source distribution c исходниками PythonI Собираем статическую библиотеку, отключиввсе ненужное

libPython.a есть? идем дальше

I Настраиваем линковку с этим блобом

I Делаем вот так:#include <Python .h>

void execute_python_code ( ){

Py_ In i t ia l i ze ( ) ;PyRun_SimpleString ( "python_code_here" ) ;Py_Finalize ( ) ;

I Все, мы исполнили код на Python

I Настраиваем линковку с этим блобомI Делаем вот так:#include <Python .h>

Как-то слишком просто?

I Ну, это самый “высокоуровневый” вариант

I Годится, например, для Python-консоли временивыполнения

I Есть более тонкие инструментыI Но суть та же:

1. Если в другом потоке, лочим мутекс стейта2. Манипулируем состоянием, вызываем методы3. Концептуально, все вызовы “в один конец” - из C

в Python

I Ну, это самый “высокоуровневый” вариантI Годится, например, для Python-консоли временивыполнения

в Python

I Есть более тонкие инструменты

I Но суть та же:

в Python

1. Если в другом потоке, лочим мутекс стейта

2. Манипулируем состоянием, вызываем методы3. Концептуально, все вызовы “в один конец” - из C

в Python

1. Если в другом потоке, лочим мутекс стейта2. Манипулируем состоянием, вызываем методы

3. Концептуально, все вызовы “в один конец” - из Cв Python

в Python

А в обратную сторону как?

I Core python может не осилить реализациюмногих компонент приложения, ибо там особыеинтерфейсы, имеющиеся в нативном коде, но“прозрачно” недоступные

I Плохо, писать много “скучного” кода на Python -наша цель

I Да и спускать критичные по скорости ботлнекив C/C++ тоже хотелось бы для спокойствия

I Это решается написанием модулей расширения

Некоторые деталиI Придумываем для каждой сущности аналог врантайме Python

I Пишем унылые функции-передергивалки,которые возьмут на себя bookkeepingреференс-каунтинга, маршаллинга объектовPython в С и обратно

I Заполняем сишную структуру, которая задастинтерпретатору интерфейс модуля

I Вызовем функцию-инициализатор модуля послестарта интерпретатора

I Все, можно вызывать нативные функции изкода на Python.

I В детали не буду вдаваться из-за регламента,но поверьте, там все дуболомно просто, развечто очень много бойлерплейта

Сторонние модулиI То же самое касается чужих модулей,распространяемых в исходниках

I Во “взрослых” применениях они обычнособираются в shared library (.dll, .so, .dylib),однако никто не мешает слинковаться с нимистатически и вызвать функцию-инициализаторвручную

I Не стоит стесняться так делатьI Идеальная на мой взгляд ситуация - когда кодсразу вызывает питоновский аналог main, илишь самые низкоуровневые вызовы приходятобратно на нативный уровень

I Нативный уровень уменьшается по максимуму,и портировать его намного проще (код наPython ведь переписывать не нужно)

I Не стоит стесняться так делать

I Идеальная на мой взгляд ситуация - когда кодсразу вызывает питоновский аналог main, илишь самые низкоуровневые вызовы приходятобратно на нативный уровень

GameDev - чуть ли не идеальный случай

I Интерфейсов мало - OpenGL, OpenAL, тач,несколько дополнительных ивентов

I Хранилище ресурсов, сеть, UI - можно частошарить, ведь они все равно “свои”

I Тяжелые вещи вроде AI и поиска путейспускаются в нативные модули

SWIG - пишем обвязку проще

I SWIG - генератор связующего кода по слегкаразмеченному “файлу интерфейса” для кода наC/C++.

I Фактически способен по .h файлусгенерировать для сишных функций полныйаналог, с адекватным сопоставлением типов(вроде превращения int* в список чисел)

I С memory policy тоже все хорошо - сишныеобъекты наследуют поведение reference countedобъектов Python.

I Умеет “зеркалировать” и иерархии классов C++I Радикально снимает вопрос написания кодавзаимодействия Python-C

I Умеет “зеркалировать” и иерархии классов C++

I Радикально снимает вопрос написания кодавзаимодействия Python-C

SWIG - пример

example.i%module native_code%{int * heavy_func(char* p) ;%}example.pyimport native_codes = sum(native_code . heavy_func( " test " ) )

boost::python

I Темплейтная библиотека для C++,добивающаяся аналогичных целей

I По целям аналогична SWIG, но достигает ихдругим способом

I Может быть удобнее, когда зависимость отboost не пугает, а усложнение процесса сборкиеще одной утилитой (SWIG) нежелательно

I Интерфейсы задаются макросамипрепроцессора в коде

I В отличие от SWIG позволяет пользоватьсяфункциями embedding API напрямую, что можетбыть важно (SWIG, впрочем, не запрещает тоже,однако править сгенерированный кодметодологически неправильно)

boost::python

Производительность

I Зная способы размещения кода как в нативной,так и в скриптовой части приложения, надоуметь прикидывать, какую подсистему кудаотнести

I Следует представлять себе запросы скриптов кпамяти и процессорному времени

I Там все очень плохо

"Все плохо"-1, память

I В зависимости от разрядности интерпретатораи наличия отладочных опций при сборке размеробъекта Python может сильно плавать, но всеравно не может быть меньше двух указателей

I В Python все - объектI int размером 30 байт - это нормальноI Инстансы классов (насколько это понятиеприменимо к Python) - часто от 300 байт

I В Python все - объект

I int размером 30 байт - это нормальноI Инстансы классов (насколько это понятиеприменимо к Python) - часто от 300 байт

I В Python все - объектI int размером 30 байт - это нормально

I Инстансы классов (насколько это понятиеприменимо к Python) - часто от 300 байт

I В Python все - объектI int размером 30 байт - это нормальноI Инстансы классов (насколько это понятиеприменимо к Python) - часто от 300 байт

"Все плохо"-2, скорость

I Динамическая типизация - проверка типов накаждой операции

I Reference counting - постоянные cache missesиз-за нелокального обращения к памяти

I Каждый вызов метода - обращение к диктунеймспейса с запросом соответствующегоключа (поиск в хеше)

I Тяжелая структура фреймов стека и замыканий- долгие прологи и эпилоги на входах/выходах вметоды и по раскрутке исключений

I В клинических случаях доводилось видетьускорение в 50 раз после переписывания на C

"Все плохо"-3, latency

I Stop-the-world garbage collector - на большиххипах задержка GC сверху не ограничена

I GIL (глобальный мутекс на доступ к состояниюинтерпретатора для всех потоков) - ростзадержек при выполнении тяжелой логикидругими потоками

"Все плохо"-3, latency

I Stop-the-world garbage collector - на большиххипах задержка GC сверху не ограничена

I GIL (глобальный мутекс на доступ к состояниюинтерпретатора для всех потоков) - ростзадержек при выполнении тяжелой логикидругими потоками

Так ли все плохо?

I Правило 80/20 - в 20 процентах кода проводится80 процентов времени, и эти 20 процентовможно писать на C/C++

I Для остальных 80 процентов даже клиническоезамедление в 50 раз (редко наблюдаемое напрактике) часто допустимо - например, 0.01 среакции на событие для пользователянеотличимы от 0.0002 с

I Памяти на современных смартфонах довольномного, и если пользоваться правильнымиинструментами (например, sqlite вместо“велосипедных” хранилищ и форматов), торазница в потреблении памяти составляетединицы мегабайт и более чем приемлима

I Вопрос действительно больших хипов насмартфонах пока не стоит

I В действительно плохих случаях наличиеreference counting позволяет отключать GC вкритичные моменты - останутся только меморилики от циклических ссылок

I При должной культуре программированияможно избавиться и от них, используя слабыессылки, и при этом работать без GC

I Это не так нереально, как может показаться напервый взгляд - именно таким образомреализована серверная часть World of Tanks

I Причем число мест, где понадобились слабыессылки, можно пересчитать по пальцам

I Вопрос же задержки решается довольнокардинально - для Python очень многоасинхронных библиотек, где проблемасинхронизации потоков не стоит вообще

I Подробнее - чуть позже

I Вопрос же задержки решается довольнокардинально - для Python очень многоасинхронных библиотек, где проблемасинхронизации потоков не стоит вообще

I Подробнее - чуть позже

Похоже, что все-таки терпимо

I Однако о названных особенностях забывать нестоит

I И ни в коем случае не заниматьсяпреждевременной оптимизацией!

I В случае динамических языков хитросплетениефакторов весьма сложно, и без грамотногопрофайлинга можно сделать только хуже

I Благо, для грамотного профайлинга есть всенеобходимое

Зачем так жить?

I Пока что из плюсов только code reuse междуплатформами

I И может быть сервером (это если он есть)I Но при этом надо заниматься интеграцией, ибояться плохой производительности

I И может быть сервером (это если он есть)

I Но при этом надо заниматься интеграцией, ибояться плохой производительности

I И может быть сервером (это если он есть)I Но при этом надо заниматься интеграцией, ибояться плохой производительности

I Библиотека у Python приятная, ровно как и онсам как язык, но этим трудно удивить людей,знакомых с managed платформами

I Попробую дать дополнительные доводы впользу подхода, которые, на мой взгляд,оправдывают его не очень эффективнуюреализацию

I Библиотека у Python приятная, ровно как и онсам как язык, но этим трудно удивить людей,знакомых с managed платформами

I Попробую дать дополнительные доводы впользу подхода, которые, на мой взгляд,оправдывают его не очень эффективнуюреализацию

Интерпретируемость

I Байткод Python для него такие же данные, как ивсе остальное

I Его можно хранить в ресурсах, присылать посети, компоновать из него классы

I Можно слегка подправить у пользователя ссервера расположение элементов UI, логикутаймаутов, или нечто подобное, на что обычножалко тратить целый апдейт

I Естественно, нельзя забывать про возможныеуязвимости и адекватный сендбоксинг

Интроспекция

I Иерархию классов, определения методов,любые значения можно менять в рантайме

I Очень полезно при отладке и первичнойнастройке

I Сильно сокращает compile/run/eval циклI Минимальная реализация - консоль черезRunSimpleString

I Возможность манкипатчинга кода на лету безрестарта порою очень кстати

I Может заменить львиную долю одноразовыхлогов и “админок”

I Сильно сокращает compile/run/eval цикл

I Минимальная реализация - консоль черезRunSimpleString

Отладка и профайлинг

I Можно потребовать оттрейсить нескольковызовов определенного метода

I Можно запросить подробную информацию овремени выполнения всех кодовых путей

I Все это - на хосте (в нашем случае - насмартфоне)

I Причем в произвольный момент, и без рестартаприложения

Pickle - универсальная сериализация

I Все объекты Python могут быть сериализованы вединый формат - pickle

I Формат можно расширить на типы модулейрасширения

I Код сериализации писать не надо - все есть врантайме

I Циклические ссылки не являются проблемой

Гибкое состояние

I Интерпретатор позволяет управлять своимсостоянием в широких пределах

I Через системные классы - стеком, сборщикоммусора, исключениями

I Через специальные методы - поведениемобъектов

I Remote procedure call, работающий полностьюпрозрачно - реальность, реализуемая за оченьконечное время

I Ровно как и green threads, реализованныебиблиотекой

Greenlet

I Выполнение любой специальным образомзапущенной функции может быть прекращено ивозобновлено в любой момент

I Как следствие, становятся возможнынетривиальные структуры управления

I Например, внешне синхронный интерфейс касинхронным API

Greenlet

Gevent

I Хрестоматийный пример - библиотекаасинхронного сетевого взаимодействия Gevent

I Под капотом - event-based API (epoll, kqueue,iocp)

I Внешне же код выглядит, как синхронныйсетевой код в отдельном потоке из учебника

I Каждый поток является “зеленым” (реализованчерез сохранение состояния интерпретатора),его overhead очень мал

Gevent

I Фактически код линейный, синхронный, простой

I Без callbackов и FSMI (хотя под капотом оно именно так и работает)I Это невероятно удобно, особенно в логике, гденадо много ждать - UI, сеть

Gevent

I Фактически код линейный, синхронный, простойI Без callbackов и FSM

I (хотя под капотом оно именно так и работает)I Это невероятно удобно, особенно в логике, гденадо много ждать - UI, сеть

Gevent

I Фактически код линейный, синхронный, простойI Без callbackов и FSMI (хотя под капотом оно именно так и работает)

I Это невероятно удобно, особенно в логике, гденадо много ждать - UI, сеть

Gevent

I Фактически код линейный, синхронный, простойI Без callbackов и FSMI (хотя под капотом оно именно так и работает)I Это невероятно удобно, особенно в логике, гденадо много ждать - UI, сеть

Зеленые потоки - больше примеров

I Таймеры - sleep() просто пробуждает гринлет,вместо того, чтобы объект, нуждающийся втаймауте, сам работал с коллбэками

I Анимации - изменение накапливаемогозначения в цикле со sleep выглядит кудаинтуитивнее логики на коллбэках

I Игровой AI - сложное поведение очень просто“размазать” по тикам игрового мира, и при этомне изуродовать код

I В литературе по теории языковпрограммирования проблема уродования кодаколлбэками называется inversion of control

I Greenlet ее по большей части решаетI На мой взгляд, одна из особенностей Python,которая дает ему (наряду с Lua, Erlang и новымC#), существенные новые выразительныесредства по сравнению с болееортодоксальными языками

I Greenlet ее по большей части решает

I На мой взгляд, одна из особенностей Python,которая дает ему (наряду с Lua, Erlang и новымC#), существенные новые выразительныесредства по сравнению с болееортодоксальными языками

I Greenlet ее по большей части решаетI На мой взгляд, одна из особенностей Python,которая дает ему (наряду с Lua, Erlang и новымC#), существенные новые выразительныесредства по сравнению с болееортодоксальными языками

Stackless Python

I Стоит посмотреть этот форк CPython, если идеизеленых потоков вам близки

I Вкратце - Greenlet на стероидахI Есть шедулер, хвостовая рекурсия,возможность переезда зеленых потоков междумашинами (почти Erlang/OTP)

I Success story - MMORPG Eve Online

Stackless Python

I Вкратце - Greenlet на стероидах

I Есть шедулер, хвостовая рекурсия,возможность переезда зеленых потоков междумашинами (почти Erlang/OTP)

Stackless Python

Спасибо за внимание

Вопросы?

Встраивание Python в мобильные приложения – нюансы...

Documents