EditText选择模式的一些问题

过年这段时间正好比较有空，而且有一个客服相关的需求，借这个机会把一年前写的支持输入表情和@mention的EditText又重构了一遍，具体见SpEditTool,重构过程中对EditText选择模式又有了一些新的认识，在这里记录下

选择模式的光标

场景描述

在实现响应软键盘光标移动事件之前已经实现了让光标不进入@mention字符串的逻辑（离start位置近就重置回start位置，离end位置近就重置回end位置），但是在光标只移动一格的情况下会回退到之前的光标位置，光标永远无法跨过一个@mention字符串。所以对于软键盘的光标移动时经过@mention需要特殊处理

当selectionStart=selectionEnd时

这种情况比较好处理，无非是判断光标是否进入了@mention内部，左移的时候就把selectionStart和selectionEnd都设置到@mention的start位置，右移的时候设置到end位置

当selectionStart!=selectionEnd时

这种情况是使用软键盘选中一段文字时出现

在处理这个场景时，我最开始犯了一个错误

            int selectionStart = Selection.getSelectionStart(text);
            int selectionEnd = Selection.getSelectionEnd(text);
复制代码

我认为selectionStart代表签名的光标位置，selectionEnd代表后面的光标位置，selectionStart一定小于等于selectionEnd。 因为光标左右移动并没有参数表示是移动哪个光标，所以最初实现的时候想当然的忽略了这个点，觉得左右移动只有两种情况：

光标	移动方向	结果
前面的光标	左移	选中前面的@mention
后面的光标	右移	选中后面的@mention

然而实际的情况是四种：

光标	移动方向	结果
前面的光标	左移	选中左边的@mention
前面的光标	右移	取消选中左边的@mention
后面的光标	右移	选中右边的@mention
后面的光标	左移	取消选中右边的@mention

当然这样写出来的逻辑是有问题的，在编码的过程中发现其实selectionStart和selectionEnd的意思和自己最开始想的并不一样

• selectionStart表示在选择过程中不变的光标位置
• selectionEnd表示在选择过程中移动的位置

所以知道了selectionStart/selectionEnd和左右移动方向就可以覆盖以上的四种情况了，但是场景分类跟之前会有些区别

selectionEnd光标移动方向	selectionEnd>selectionStart	结果
左移	true	选中左边的@mention
左移	false	取消选中右边的@mention
右移	true	选中右边的@mention
右移	false	取消选中左边的@mention

对于Selection.setSelection(Spannable text, int start, int stop),start!=stop的情况下，start表示选择过程中不变的光标，stop表示变化的光标

最终实现代码

        //处理光标左移事件
        if (keyEvent.getKeyCode() == KeyEvent.KEYCODE_DPAD_LEFT
                && keyEvent.getAction() == KeyEvent.ACTION_DOWN) {

            int selectionStart = Selection.getSelectionStart(text);
            int selectionEnd = Selection.getSelectionEnd(text);
            IntegratedSpan[] integratedSpans = text.getSpans(selectionEnd, selectionEnd, IntegratedSpan.class);
            if (integratedSpans != null && integratedSpans.length > 0) {
                for (IntegratedSpan span : integratedSpans) {
                    int spanStart = text.getSpanStart(span);
                    int spanEnd = text.getSpanEnd(span);
                    //selectionEnd表示移动的光标
                    if (spanEnd == selectionEnd) {
                        Selection.setSelection(text, selectionStart, spanStart);
                        return true;
                    }
                }
            }
        }
        //处理光标右移事件
        if (keyEvent.getKeyCode() == KeyEvent.KEYCODE_DPAD_RIGHT
                && keyEvent.getAction() == KeyEvent.ACTION_DOWN) {
            int selectionStart = Selection.getSelectionStart(text);
            int selectionEnd = Selection.getSelectionEnd(text);
            IntegratedSpan[] integratedSpans = text.getSpans(selectionEnd, selectionEnd, IntegratedSpan.class);
            if (integratedSpans != null && integratedSpans.length > 0) {
                for (IntegratedSpan span : integratedSpans) {
                    int spanStart = text.getSpanStart(span);
                    int spanEnd = text.getSpanEnd(span);
                    if (spanStart == selectionEnd) {
                        Selection.setSelection(text, selectionStart, spanEnd);
                        return true;
                    }
                }
            }
        }
复制代码

两个地方的setSelection可能有些反直觉，不过仔细想一想确实是取消选中和选中用的是同样的参数

选择模式下replace的问题

有个朋友在使用这个库的时候提了个Issues #7 ，就扔了一张图

不得不说这张图还是挺有误导性的，我最初一直以为后面输入的部分的样式是来自于第一个@mention，而且后面一长串都带了样式，让我认为是持续输入了多个字符都带了样式，这个现象挺让我费解的，因为我的demo中所有setSpan(Object what, int start, int end, int flags)的flags全都是SPAN_EXCLUSIVE_EXCLUSIVE，按道理不会出现后面输入的字符也带样式的情况，自己尝试复现也没有成功

今天一个偶然的操作让我可以弄出图上的效果，说下自己的操作路径

• 插入两个@mention
• 选中第二个
• 然后调出输入法选中26键中文输入模式
• 打一长串字母然后按回车

以上操作可以复现出Issues #7 中的问题，但是原因却不是第一个@mention的样式影响到了后面的字符串，而是有两个@mention，第二个@mention在选中状态下被replace，样式没有消失

因为库中自定义了一个SpannableStringBuilder,所以解决方案也比较简单

    @Override
    public SpannableStringBuilder replace(int start, int end, CharSequence tb, int tbstart,
            int tbend) {
         ...
        //先删除再插入，解决选择模式下span样式不正常消失的问题
        if (start != end && tbstart != tbend) {
            super.replace(start, end, "", 0, 0);
            super.insert(start, tb, tbstart, tbend);
        } else {
            super.replace(start, end, tb, tbstart, tbend);
        }
        ...
        return this;
    }
复制代码

当然有可能Issues #7的问题并不是我这样操作出现的，后续有碰到同样问题的童鞋欢迎反馈

ImageSpan的replace

发现自己的东西有问题，当然得去试一试微信有没有问题，毕竟行业标杆嘛。 令人失望的是微信的@mention并没有上面的问题，不过微信的单个表情在选中时打字会没有效果

反过头看自己的表情输入，经过上面的特别处理之后，选中单个表情输入文字文字倒是照常输进去了，但是表情竟然没删掉

调试了一下发现选中表情时调用replace(int start, int end, CharSequence tb, int tbstart, int tbend)，end只比start大1，但是demo中ImageSpan对应的字符串长度应该都是4，问题就出在这里了，对一个表情，选中情况下得replace4次才能被删掉

原因看了下代码没分析出来，不过解决方案倒是简单，之前@mention已经实现了让光标不能进入内部的逻辑，将对应的Span用IntegratedSpan标记下就行了

public class IsoheightImageSpan extends ImageSpan implements IntegratedSpan {
    ...
}
复制代码

一波推广

一个高效可扩展，在EditText/TextView中输入和显示gif和@mention等图文混排内容的库

重构过程中参考了iYaoy的思路，在此特别感谢

转载于:https://juejin.im/post/5c6bca96f265da2dd1685d6a