开源代码要慎用,容易中毒:记划词模块重构感受
本文原创,转载请以链接形式注明地址:http://kymjs.com/code/2016/08/13/01
先说感受再看看我是怎么中毒以及怎么解毒的。
何为中毒,并不是说性能多么差,也不是代码多么烂,而是你容易受到别人代码的影响,不知不觉间就顺着他的思路走了。
当然,有一种避免的办法就是,拿来主义。我只拿你的代码用,完全不看你怎么写的,也不做功能定制和扩展,那当然也就百毒不侵。
事情的经过是这样的(我要开始讲故事了)。
很久很久以前,天地混沌,盘古开天辟地以后有了太阳和月亮,天空和大地,Android 操作系统也随之崛起。但是,还缺少一样东西,那就是自定义控件。有一天,我奉众神之王宙斯之命创建一个通用划词模块,让每条产线都接入这个控件。 何为通用划词模块,就是要通用,要有划词,还是个模块。
??? 扯不下去了,你们自己看图识意吧。
中毒开始
就是这样两个效果,点按选中文字高亮,并弹出悬浮窗。
这种控件,偷个懒吧,去 GitHub 上找找,这一找,就成了我中毒的,开始。为了不坑大家,我就不说我找的那个项目地址了。
看了代码,那个项目是这样来做的:在 TextView 长按下的时候,通过getOffsetForPosition()
来获取到当前点击坐标最近的一个字符在全部文本的第几个位置,以及layout.getPrimaryHorizontal()
来根据一个位置获取到这个位置的字符在 View 内部的坐标。然后在这个文本相应的位置显示一个悬浮窗,这个悬浮窗是一个自定义 View,里面有一个 PopupWindow ,在 PopupWindow 里面自定义了一个布局显示自己的内容。
结合我们自己的逻辑,原本网上的开源项目只有一个悬浮窗,而我们自己的业务需要显示三个悬浮窗,分别是:数据加载中的样子、正常显示翻译内容的样子,找不到翻译内容的样子。
既然已经有了一个雏形了,那就在这个项目上做扩展吧。(从有这个想法开始,就跌入了一个大大的深坑)
慢性中毒
扩展的方法就是仿照原有的写法,再自定义两个悬浮窗,然后根据显示逻辑来切换什么时候应该显示哪个悬浮窗。好不容易做好了三种状态要显示的悬浮窗都做好了,又发现长按的时候操作菜单和游标也需要显示在正确的位置上。
那再改改,根据长按的坐标,找到对应的文本在 TextView 第几个字,找到这个字在第几行,找到这行文字的顶部坐标再减去行间距,再把悬浮操作菜单。原项目为了方便直接获取到 TextView 的边界值,直接在 TextView 的外层套了一个 Scrollview,方便实时获取到 TextView 的坐标。
结果又发现如果 TextView 在一个 Scrollview 里面的时候,如果 Scrollview 发生滚动,悬浮窗应该自动 dismiss;
那再改改,滚动状态获取不到啊,那不如让 TextView 在初始化的时候递归遍历父控件,如果是可以滚动的控件就给这个控件添加一个滚动状态监听器,发生滚动直接 dismiss 悬浮窗。
至此,一个划词模块的开发是完成了,功能表现也良好。
中毒太深
我靠,这通用划词模块根本不通用啊,谁特么也不知道业务线接入时候的环境是怎样的。
- 你控件使用的是自定义控件,可业务线有可能自己想使用划词功能的控件也是个自定义的 TextView,那没办法让一个 Java 类同时继承两个类啊。
- 业务线有可能一个界面同时有多个 TextView 都要接划词功能,我们之前完全没有考虑这种情况啊。照这种状态可能每个界面同时显示多个悬浮窗出来。
- 每个 TextView 在使用的时候,外面都套了一个 ScrollView,这要是接入这控件的界面有多个 TextView,界面估计要卡到爆。
解毒,重构的开始
没办法,意识到自己中毒太深了以后,只想说一句,活该你他妈偷懒想用别人代码。
首先理清项目的结构。整个项目分三大块:接入控件(TextView),游标和高亮,悬浮窗。
第一步,为了控件能够通用,把接入控件抽出来做成一个接口,只暴露出该 View 有的方法,然后所有要接入划词功能的 View 都实现这个接口就好了,其中 getTouchX() 和 Y 是返回用户手指按下的坐标,需要在实现接口协议时重写 onTouch() 事件记录下坐标:
public interface IViewProtocol {
Context getContext();
CharSequence getText();
CharSequence getSelectedText(); // 获取当前选中的文本
int getTop();
int getBottom();
int getLeft();
int getRight();
float getTouchX();
float getTouchY();
int[] getLocationInWindow();
}
第二步:创建一个 Controller 负责控制悬浮窗的显示,并将原项目中的悬浮窗修改为自定义 PopupWindow(原项目是一个 View,包含一个 PopupWindow,又包含一个自定义布局)。 PopupWindow 最大的好处就是,它的显示逻辑和隐藏逻辑都可以交给系统去控制,就不需要我们手动再控制显示隐藏了。
定义一个接口,封装悬浮窗应该包含的方法:
public interface IFloatWindow {
PopupWindow getFloatWindow();
boolean isShowing();
void showAsDropDown(IViewProtocol anchor, int xoff, int yoff, int gravity);
void showAtLocation(IViewProtocol anchor, int x, int y, int gravity);
void update(int x, int y, int width, int height, boolean force);
void dismiss();
int getHeight();
int getWidth();
}
悬浮窗有两类,一类是非交互的,类似加载界面、游标。另一类是可交互的,例如上文截图。
不可交互的很简单,直接显示就好了,抽出公共基类 AbsFloatWindow,实现 PopupWindow 创建、初始化、显示位置等方法就够了。
可交互的需要考虑内部控件的事件,他们的内容区域是不同的,但是外部显示框框是一样的。
所以需要再多写一个基类 AbsContentView<T> extends AbsFloatWindow
其中泛型 T 表示这个悬浮窗要显示的内容实体类。例如服务器返回一段翻译好的数据给客户端,客户端要将翻译后的内容显示出来;但如果网络请求失败,应该显示另一种内容;服务器无法翻译的时候,又显示另一种内容的文本。
并且需要注意的是,有交互的控件还得要暴露出控件给业务线,让他们自己根据自己的业务修改控件的图片、文字、点击事件。
第三步:抽出 SelectionInfo,封装高亮显示的文本信息,包括文本的起始坐标,结束坐标,文本长度,高亮的背景颜色,在整个 TextView 文本的位置等。
public class SelectionInfo {
public static final int DEFAULT_CLOLOR = 0xffb7d9f8;
private Object mSpan; //用于显示背景颜色
private int mStart;
private int mEnd;
private Spannable mSpannable;
}
最后
从改为使用 PopupWindow 开始,我们已经解决了界面中多 TextView 弹出多个悬浮窗的问题。
使用接口协议也完美的解决了业务线自定义控件的兼容性问题,不过为了他们使用方便,我们还是可以定义一个默认的 TextView 让他们选择,同时也是他们修改自己的自定义控件的一个模板。
把之前所有基于控件内部的坐标全部转换成根据View.getLocationInWindow()
获取屏幕绝对坐标,也解决了嵌套一层 ScrollView 的问题。
问题解决,又可以浪了。
最后的最后
记划词模块重构感受
——开源代码要慎用,容易中毒