Почему мы выбрали Flutter для разработки rich text-редактора?

Чтобы добиться стабильности, высокой производительности и поведения, привычного для пользователей Google Docs или Word, необходимо учитывать множество факторов:

• работу с текстом на уровне Unicode: составные символы, эмодзи, удаление по графемам;
• поддержку IME (Input Method Editor — инструмент для ввода символов, отсутствующих на клавиатуре, например, иероглифов или специальных знаков) и многоязычного ввода, особенно для китайского и японского языков;
• различия в поведении клавиатуры, фокуса и буфера обмена между Android и iOS;
• архитектуру, способную обрабатывать вложенные структуры и большие объёмы текста без просадок;
• и, наконец, постоянные затраты на поддержку, обновления и кроссплатформенную совместимость.

Поэтому, прежде чем принимать решение о разработке кастомного редактора, надо крепко подумать и тщательно оценить существующие решения на рынке.

Но наш проект оказался не из простых. Перед нами стояла задача - разработать мобильное приложение на заказ, которое должно было объединить в себе:

• свободное перемещение между собой текстовых и медиаблоков,
• гибкое форматирование текста,
• кроссплатформенную работу,
• корректное отображение мультимедиа на различных устройствах.

Реализовать такой комплекс задач в единстве ни одна из готовых библиотек не способна. Многие из них работают через WebView и JavaScript, что снижает производительность. При тестировании другие оказались нестабильными, не выдерживали нагрузку или не позволяли настроить интерфейс под наши требования. Поэтому мы начали рассматривать альтернативные подходы и технологии, в том числе Flutter как основу для кроссплатформенной разработки мобильного приложения. О том, почему мы выбираем Flutter в качестве основы для серьёзных проектов, подробно рассказали в этой статье.

Итак, для создания полноценного редактора, требовалась платформа, сочетающая высокую производительность, возможность полной кастомизации и кроссплатформенную поддержку без дублирования логики.

Мы рассматривали разные технологии, но именно Flutter-разработка дала нам необходимое:

1. Контроль над рендерингом и вводом

• EditableText, TextPainter и RenderEditable во Flutter предоставляют низкоуровневый доступ к рендерингу текста и управлению курсором.
• Поддержка TextInputClient позволяет напрямую взаимодействовать с системной клавиатурой, обрабатывать TextEditingValue, в том числе selection и composing — необходимые для работы IME и предиктивного ввода.

2. Полную кастомизацию UI

Flutter не привязан к нативным компонентам — UI можно строить с нуля. Это критично, когда речь идет о вложенных блоках, мультимедийном контенте и rich text с произвольной структурой. Мы получили полный контроль над внешним видом и поведением всех элементов редактора.

3. Производительность на уровне нативной

Один из стресс-тестов — работа с файлами объёмом 180 МБ (для сравнения, “Война и Мир” “весит” 3-4 МБ) производительность оставалась в допустимых пределах. (Да, мы проводили тест с таким объемным текстом и контролировали тайминг выполнения через Stopwatch.)

4. Кроссплатформенность

Один и тот же код обработки текста, структуры документа, рендеринга и взаимодействия с моделью работал на Android и iOS без платформенной адаптации. Это резко сократило время на поддержку и позволило сосредоточиться на продукте, а не на инфраструктуре.

5. Расширяемость и поддержка сообщества

Готовые решения (Fleather, Quill) были полезны на старте как архитектурные ориентиры. Flutter имеет активное сообщество, открытую документацию и доступ к исходникам — что критично при необходимости глубокой кастомизации.

Итоги разработки:

• максимальный объем обрабатываемого текста: до 180 МБ без критических просадок производительности;
• целевое значение производительности: стабильные 60 fps при текстах объёмом до 3 МБ (средние сценарии);
• время отклика на пользовательские действия — менее 1 мс при текстах до 100 КБ; 3–5 мс при работе с текстами от 3 МБ и выше;
• задержка рендеринга на кадр (реальное измерение) — чаще всего менее 100 микросекунд;
• передача больших объёмов текста: возможна, но требует оптимизации — загрузка 180 МБ занимает ~10 секунд при хорошей сети.

Разработка кастомного rich text-редактора — это проект, который нельзя реализовать шаблонно. Он требует глубокого погружения в архитектуру, умения работать с низкоуровневыми механизмами Flutter и понимания, как обеспечить производительность при сложной структуре данных.

Для нас это был не просто кейс, а инженерный вызов. И его решение стало еще одним подтверждением, что команда ItFox умеет решать задачи за пределами стандартных SDK и готовых библиотек.

Мы подходим к каждому проекту индивидуально, особенно если речь идет о сложной разработке мобильных приложений для бизнеса с нетипичными сценариями использования. Беремся за проекты, где важны точность, гибкость и масштабируемость — и доводим такие решения до результата.

Если Вы ищете команду для реализации сложного мобильного приложения — от MVP до полнофункциональной платформы, — мы готовы помочь.