Допустим, вы создаете программную клавиатуру на Android и хотите получать информацию о тексте вокруг курсора, чтобы вы могли делать предложения автокоррекции. Документы для InputConnection сообщают вам:
Помните, что ваш IME может быть не единственным источником изменений в тексте, и постарайтесь быть как можно более консервативными в отправляемых вами данных. и как можно более либеральным в получаемых данных.
Хорошо, не забудьте сделать много звонков на InputConnection#getTextBeforeCursor, за исключением того, что в документации указано:
учтите, что это вызовет передачу IP C туда и обратно, что займет некоторое время. Предположим, что этот метод требует много времени. Также имейте в виду, что редактор может выбрать возврат меньше символов, чем запрошено, даже если они доступны по соображениям производительности.
Кроме того,
Этот метод может не работать, если входное соединение стало недействительным (например, сбой процесса) или клиент слишком долго отвечает с текстом (ему дается пара секунд для возврата). В любом случае возвращается 0
Чтобы убедиться, что клавиатура не дергается и не блокируется потенциально на СЕКУНД, прежде чем реагировать на новые события, мы полагаем, что нужно быть умными в том, как запрашивать текст вокруг курсора.
5 лет go кто-то из команды Android framework создал то, что я считаю довольно хакерским решением для системной клавиатуры:
Временное решение для сохранения скорости отклика при медленном InputConnection.
- Добавить механизм для обнаружения медленного или нереагирующего InputConnection (I C)
- При обнаружении I C медленности пропустить определенные вызовы I C, которые известны как дорогие (например, getTextAfterCursor).
- Аналогичным образом отключает обучение / отмену обучения на медленном I C.
- I C флаг медленности сбрасывается при запуске ввода в новом TextView или по прошествии фиксированного количества времени.
Примечание. Это в основном временные обходные пути. Постоянным решением является рефакторинг RichInputConnection, чтобы он был менее чувствителен к медлительности IC в целом.
Системная клавиатура поддерживает внутренний кеш текста перед курсором, который стирается при изменении положения курсора, за исключением когда ожидается изменение курсора («ожидается» как в logi c of isBelatedExpectedUpdate).
У меня есть несколько вопросов об этом решении:
- Возможно ли, что позиция курсора изменится случайно на позицию, которую мы ожидали, но в результате другого механизма, чем наша клавиатура. В конце концов, IME - не единственный субъект, который может изменять текст. (Думаю, да, поскольку метод
isBelatedExpectedUpdate в соответствии с его документацией является heuristi c, и «[получение правильного результата] почти невозможно достичь, даже очень и очень стараясь». И коммит говорит: «Это красиво настолько сильным, насколько это возможно. " - Почему I C так медленно реагирует на текст перед курсором?
- Можно ли запросить текст курсора вне основного потока? Можно ли убедиться, что он отражает фактическое состояние поля ввода?
- Как можно реорганизовать код, который зависит от
InputConnection, чтобы он был менее чувствителен к его медленности?