对于编辑器的一些思考：Android实践篇

理论脱离不开实践。所以我连续用了几个晚上实现了一个Android的编辑器。效果如下：

虽然说是编辑器，但是编辑相关的API或者protocol我还没做完。所以这东西，目前可以作为代码预览器或者查看器。

前几天，亚马逊说Kindle要退市。这也让我想起我以前在京东做的，就是电子书。当然，当时没做多好。不过，当时京东电子书业务的代码，是收购了一家现成的电子书的app的代码。也就是说，当时京东是有两套电子书相关的代码的。旧版的，是基于一个类浏览器的项目，后来基本停止运行了，人员分布到其他项目了。

之所以提京东的这个事。那是因为京东当年收购的这一家电子书的app，实际上也传出来过亚马逊也想收购的消息。但是实话说，亚马逊收不收购，kindle的电子书阅读效果也就那样了。

写电子书排版的东西，实际上跟我写这个编辑器有一定的联系。不过，现在Android的API很丰富了，如果当年有比较新的API，那么项目做起来会方便一些。当然，难度依然有。如果我把现在的编辑器的字体换一换，加上line wrap，加上空格的justification，那么就是一个很简易的电子书阅读器，或者是简易的Word，甚至做成markdown编辑器也不难。

目前，Android版的编辑器最小的API依赖是23，也就是Android 6.0。在京东的时候，21的API也刚出来，也就是Android 5.0，甚至没有测试机，用的京东内部的一个员工提供的手机测试的。

回到编辑器的话题上来。line wrap先不谈。就说编辑器怎么做的问题。没有难题，就是画图。基于Android的View，扩展出来一个自定义的View，然后在onDraw中绘制。

Android的onDraw里面，会在Canvas中绘制。那么大概过程如下：

第5个，就是难度在的地方，按道理，我是可以把TeX的短行算法直接放进去，但是代码编辑器一般是不会这么干的。这个地方的难度在于，一行数据改变之后，其他行数据可能也要更新，如何不卡，如何不崩，就是难点。

编辑器的绘制就是这样。接下来是交互。

第一个交互就是让这个编辑器像系统的TextView一样可以编辑，可以接受输入。这部分，Android的文档写的很晦涩，但也不是不能搞：

这四个函数，覆盖掉基本就能处理输入了。不过怎么处理软键盘的行为，这个测试量就不小了。

第二个交互就是支持触摸手势或者相关的事件。这个介绍的文章就很多了。我这里就不描述了。

第三个交互，就是图上面的光标怎么做。一种方法，就是在View里面设置一个Timer，给定一个300毫秒或者500毫秒的值来控制光标的显示还是不显示，通过onDraw来实现。另一种方法，就是把编辑器的组件拆分成几个View，所有组件都是放在一个ViewGroup里。也就是说光标是一个View。

其他的就不是很麻烦了，跟绘制的关系就不大，属于设计编辑器的后端。比如是不是要用piece table，command或者快捷键怎么处理。这些只要熟悉Java就可以写。

iOS上面，做这种类似的View流程其实很相似，只不过iOS上有CoreText，有CTFrame和CTLine之类的现成组件来做相关的工作。在设计上，经过我比较之后，我发现这俩平台的API互有胜负。