Aexi(7)—初步成果

Aexi(7)—初步成果

         今天终于完成了基本的图文混排.下面我们来一下效果图

在里面输入了一个放假的通知试试效果.9月3号才放假显得有点遥远啊,不过还是比较开心的.但是Aexi能初见成效我会更加开心.

         下面的计划就是再将Aexi进行一些优化,修复大量的bug,并将其移植到Android平台上封装成一个库.

那么目前存在的主要的bug有哪些呢?

第一点也就是刚开始编写的那个类—Caret.这个类虽然是第一个编写的类,但是确实最为复杂的一个类.它肩负着标记插入位置，删除位置，响应方向键，响应鼠标拖拽等等一系列职责。但是Caret在设计之初却有着诸多不合理的地方，而最重要的一点就是在Caret中有着三种不同的坐标体系。第一种是Caret的绝对坐标,用x,y来标记,第二种是Caret标记的物理结构中的位置,用一个int值来表示.这个值也是文档中插入和删除文字时候的标记.

第三种是文档的显示结构,用pageIndex,rowIndex,columIndex.来标记.

这三种坐标体系的互相转换是相当麻烦并且极易出错.并且第三种表示方法还具备相当的不安全性.一旦文档的物理结构变化,有可能会直接导致Caret的老的page,row,columnIndex坐标失效.由于这种变化在通知Caret的时候,Caret需要根据旧的坐标进行转换,所以很有可能出现空指针错误.所以需要寻求一种更加聪明的方法来重新标记Caret的位置.这个后面我们会再开一篇博客专门去研究.

第二点:  就是我们需要对文档的内存结构进行优化.前几天由于机缘巧合,我们辅导员让我做了一个doc文件的文本分析的小项目.这个小项目我用到了appache组织开源的poi库.在使用这个库的过程中,我了解到doc文件的内存组织结构.其中doc文件的结构为Range、Section（对应Aexi中的page，不过更加灵活），paragraph,row，characterRun。其中，这个characterRun就是整个的核心。CharacterRun就表示了一段连续格式的文字。这样的设计就比Aexi中把每一个字符都存储为一个对象不知道要高到哪里去了.为什么这么说呢?其实这样做的好处就在于对内存的极大存储.举个例子说:一篇格式不是很复杂的文档,除了标题外可能就是正文了.假设标题5个字,正文部分1000字.在Aexi中对应了1005个对象,每个对象存储了一个char字段占一个字节,还有字体信息(采用享元模式,整篇文档算为20个字节),frame信息(位置,大小等,每个字符对象都持有一个frame对象,4个int值,8个字节),这样算来Aexi中就占用了8*1005+ 20 = 8060个字节.而word中的结构只用了1005 + 20 = 1025个字节.整整节省了约8倍内存,非常惊人.

当然使用word这种的内存格式就对我们目前的排版算法和各种鼠标键盘的操作产生了非常高的要求.以我目前的功力实现起来还是有点力不从心.

第三点就是页面的格式和风格还没有考虑进去,页眉页脚,行距,段落间距等还没有考虑进去.

第四点就是目前的事件处理机制是否真的合理.目前的事件处理的机制是我仿照Android的事件处理机制设计的层层传递再层层传回来的方案.这样在出现的事件比较单一的时候看起来非常的方便.但是当逻辑变得复杂的时候,我们的事件分发,只是分发了click事件,现在的事件已经不止这些了.比如我们需要在拖拽选择的时候需要监听drag事件.而在拖拽结束的时候,需要监听release事件以便于给相应的字符设置Slection.

在这样的需求变得复杂的时候.原来的逐级转发最后将事件传递给具体的图元的方式显得有些力不从心,是否可以对目前的方式进行扩充或者直接推翻重来就显得非常重要了.

第五点：很多地方为了方便而进行的不安全的强转,欠了的债迟早要还的.

第六点:一直听说开发时可以使用单元测试进行驱动开发,但是一直没有实践过,在后期的修改中可以考虑加入单元测试来研究一下单元测试是如何有效的降低耦合性的.

第七也就是最后一点就是需要为把Aexi移植到Android平台上做一些准备.比如说将一些平台相关的代码隔离开.如字体,绘制图形的api的接口等.当然,这里就比较简单了,每次遇到移植的问题,最简单粗暴的方法就是中间加一层.

         以上就是目前分析出来的有待优化的地方了.但是以后Aexi可能要停一段时间了,因为万恶的阶段考试和期末考试,为了绩点,现在只能暂时忍痛割爱了.

         期末考试过后,会继续更新Aexi 的.