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 的.