Производительность редактора блоков Thunkable X
Разработка мобильных приложений на Thunkable X имеет немало подводных камней, но настоящая засада находится там, где совсем не ожидаешь её встретить и на всём ходу сажаешь свой проект на мель.
На странице ограничений платформы Thunkable X дана информация о том, что можно создавать приложения размером до 50 Мб и с неограниченным количеством экранов. Так это можно создавать огромные приложения, состоящие из десятков, если не сотен тысяч блоков! Теоретически это возможно, но на практике вся работа может резко замедлиться уже при использовании 300 блоков на одном экране. Что значит замедлиться? Это значит, что после выполнения любой операции в редакторе блоков он будет зависать на 20-30 секунд и дольше. 300 блоков на экран - это много или мало? Этого будет достаточно, если вашему приложению не требуется функциональность, выходящая за рамки имеющейся функциональности компонентов. Но, если требуется реализовать собственные алгоритмы, то лимит в 300 блоков может быть превышен уже через пару дней, а нужную функциональность её пилить и пилить.
Основная проблема состоит в том, что на данный момент не существует решения, благодаря которому можно хотя бы на порядок увеличить производительность редактора блоков. Если каким-то чудом вам и удастся cкопировать на экран 800-1000 блоков, то работа с ним на этом и закончится, несмотря на мощный компьютер и огромную пропускную способность вашего интернет соединения по той причине, что любое малейшее изменение в редакторе блоков приводит к неимоверно огромному трафику между пользовательским компьютером и сервером Thunkable X, а также затрат на автокомпиляцию. Передвинули блок в редакторе? Тонна мегабайт отправляется на сервер и компилируется для отображения в Thunkable Live. Если в среде разработки подряд сделано 5 изменений в большом проекте, то картина может выглядеть так: через 20 секунд после этого на экране тестируемого устройства отобразятся данные после первого изменения, ещё через 20 секунд, после второго, а потом приложение может и зависнуть, потому что канал обмена данными просто забивается наглухо.
Выход? Создавать простые экраны и размещать на них небольшое количество блоков, уменьшить количество "тяжелых" блоков, вынести их на отдельный вспомогательный экран, создавать многоблочный алгоритм на пустом вспомогательном экране с последующим его копирование на рабочий экран, оптимизировать алгоритм в целях уменьшения количества блоков.
К "тяжелым" блоком относятся блоки инициализации глобальных переменных (initialize) и блоки, расположенные на вкладке Any Component.