概述
此文并非系統(tǒng)的說(shuō)明如何用QT重構(gòu)整個(gè)客戶端，而只是粗算工期，給出一個(gè)時(shí)間概念
當(dāng)前項(xiàng)目的優(yōu)勢(shì)
- 我們目前的人員配置都更熟悉VS開(kāi)發(fā)。
- 目前使用的UI開(kāi)發(fā)技術(shù)名為Sciter這相當(dāng)于是基于html5+css的UI開(kāi)發(fā)框架，自由度很大
痛點(diǎn)總結(jié)
1. 切換選擇模型節(jié)點(diǎn)效率低
此處雖經(jīng)歷多次優(yōu)化，但目前仍然不理想
因?yàn)楦镜臄?shù)據(jù)模型和業(yè)務(wù)邏輯很難改變了，主要問(wèn)題在于引擎需要每次都經(jīng)過(guò)分析生產(chǎn)一個(gè)json來(lái)描述屬性組成，而客戶端則需要分析這個(gè)json生成新的ui。而生成json，分析json，生成ui這三步都不是很輕的操作，綜合就會(huì)效率低了。
改進(jìn)策略：嘗試參考AI模型訓(xùn)練算法， 我們可以考慮也訓(xùn)練算法。 比如我們點(diǎn)擊同類型節(jié)點(diǎn)很可能生成的json實(shí)際上是相同的，只是參數(shù)不一樣。而對(duì)于相同的json需要生成的ui也是一樣的，也只是參數(shù)不一樣。 但根據(jù)節(jié)點(diǎn)類型不同，確實(shí)有存在多種不同的json。 那我們是不是研究利用節(jié)點(diǎn)的各種特征形成一個(gè)特征碼，來(lái)對(duì)應(yīng)某一個(gè)json，某個(gè)ui頁(yè)面，下次再遇到同樣特征的的節(jié)點(diǎn)看看怎么簡(jiǎn)化生成json和生成ui的操作，特征碼和json，ui都是通過(guò)用戶不斷的點(diǎn)擊各種節(jié)點(diǎn)訓(xùn)練出一套東西，到時(shí)候我們打包的時(shí)候帶上它，就能大幅提升性能。
2. 各個(gè)屬性面板無(wú)法適當(dāng)保持UI狀態(tài)
目前我們的屬性面板刷新后各種UI狀態(tài)會(huì)丟失，比如滾動(dòng)位置，折疊狀態(tài)，輸入框焦點(diǎn)等等，這在實(shí)際操作中會(huì)帶來(lái)不便。比如滾動(dòng)到某個(gè)位置編輯一個(gè)屬性，之后想編輯另外節(jié)點(diǎn)的該屬性，此時(shí)切換節(jié)點(diǎn)，面板會(huì)重置，導(dǎo)致還得重新找到這個(gè)要編輯的屬性。
此處目前還沒(méi)考慮好具體的解決方案
3. 引擎目前采用的回調(diào)模式有些混亂
對(duì)于客戶端來(lái)說(shuō)，用的最多的除了接口，還有就是回調(diào)，但目前只能指定一個(gè)回調(diào)函數(shù)，并不支持多注冊(cè)，另外回調(diào)五花八門。 這種現(xiàn)象可以說(shuō)是由于歷史原因造成的，這使得當(dāng)客戶端和插件同時(shí)需要回調(diào)時(shí)，就很麻煩了，現(xiàn)在只好轉(zhuǎn)發(fā)。
改進(jìn)策略： 可以提供回調(diào)接口類，同時(shí)支持多注冊(cè)，以及反注冊(cè)這都是常規(guī)的套路了。另，回調(diào)接口要分類。
4. 目前UI遇到難定位的問(wèn)題不太好調(diào)試
因?yàn)楝F(xiàn)在UI使用的html+CSS+腳本的方式，這使得調(diào)試起來(lái)并不是很方便。
改進(jìn)策略： 如使用QT不存在這個(gè)問(wèn)題
5. ANE模塊如果方塊數(shù)量很多的話效率低
這個(gè)模塊由于現(xiàn)在使用的全場(chǎng)景繪制，如果說(shuō)方塊數(shù)很多的話，將會(huì)效率低下
改進(jìn)策略：想一個(gè)策略使用局部繪制
6. UI缺乏綜合設(shè)計(jì)
UI圖標(biāo)，字體，間距。。。等各種UI元素并沒(méi)有一個(gè)統(tǒng)一的設(shè)計(jì)
改進(jìn)策略：出原型，出設(shè)計(jì)，既然是2次開(kāi)發(fā)，一定要有這兩個(gè)東西，否則又是修修補(bǔ)補(bǔ)
7. 數(shù)據(jù)定義管理
現(xiàn)在有一個(gè)常見(jiàn)的現(xiàn)象，同個(gè)數(shù)據(jù)結(jié)構(gòu)在引擎和客戶端都有類似的定義，甚至有些枚舉值也是如此，從而導(dǎo)致了一定程度的混亂
改進(jìn)策略：該哪邊定義的數(shù)據(jù)結(jié)構(gòu)enum就由哪邊來(lái)定義，注意引擎應(yīng)該從來(lái)不需要知道客戶端定義的數(shù)據(jù)結(jié)構(gòu)。 但客戶端經(jīng)常需要知道引擎定義的數(shù)據(jù)結(jié)構(gòu)
8. UI工程目錄結(jié)構(gòu)不夠清晰
現(xiàn)在客戶端各個(gè)模塊代碼文件目錄結(jié)構(gòu)不夠清晰
改進(jìn)策略：詳細(xì)區(qū)分各個(gè)模塊
9. 歷史遺留
我們這個(gè)工程原生參考東西有點(diǎn)多，包括技術(shù)選型也是如此，有些東西都是過(guò)時(shí)的了，比如XTreme, 有一些UI風(fēng)格也還是老的。
改進(jìn)策略：該扔掉的東西就扔掉
10. 渲染窗口鍵鼠事件
現(xiàn)在渲染窗口的鍵鼠事件都是由UI轉(zhuǎn)發(fā)的，這會(huì)使得代碼看起來(lái)有點(diǎn)奇怪，出問(wèn)題了也不知道責(zé)任在哪邊。
改進(jìn)策略：引擎不在依賴客戶端轉(zhuǎn)發(fā)消息，引擎自己去響應(yīng)，客戶端除了提供hwnd，不對(duì)該hwnd做任何消息映射。
相反的引擎可能會(huì)提供一個(gè)渲染窗口的專用回調(diào)，來(lái)提供一些事件給客戶端用，比如showContext這樣的。 總之要的結(jié)構(gòu)就是，這個(gè)hwnd完全由引擎管理消息處理。
11. 插件和客戶端過(guò)于耦合
現(xiàn)在客戶端要負(fù)責(zé)通知插件各種事件，比如文件打開(kāi)，甚至細(xì)分為文件打開(kāi)之前，文件打開(kāi)之后，新建文件 等等有好多，插件的目的本來(lái)是為了讓客戶端看起來(lái)更輕快一些，但這樣一搞，客戶端就被纏住了。
改進(jìn)策略：客戶端除非極特殊確實(shí)需要通知插件的，不在通知插件類似這樣的事件，統(tǒng)一由引擎進(jìn)行分發(fā)。比如文件打開(kāi)，關(guān)閉這些引擎是知道的。
12. 插件管理有些混亂
現(xiàn)在我們客戶端加載插件是通過(guò)遍歷目錄，查看dll構(gòu)造來(lái)決定是否加載插件的，這感覺(jué)像是固定加載并不像是插拔的感覺(jué)。
改進(jìn)策略：應(yīng)該把我們客戶端打造成帶“插槽”的主機(jī)，而插件就像是可以插入這些插槽的外設(shè)，應(yīng)可以隨意插拔。 但實(shí)際上我們可能會(huì)設(shè)計(jì)成插件配置表，來(lái)加載指定的插件，可能不同的oem對(duì)應(yīng)不同的配置表?？傊灰鸭虞d哪些插件的邏輯寫(xiě)在c++代碼中。
最終目標(biāo)為：所有的插件提供安裝卸載能力，客戶端有一個(gè)插件管理器頁(yè)面可用于卸載已經(jīng)安裝的插件，但這個(gè)設(shè)計(jì)要求我們不要出現(xiàn)客戶端必須依賴的插件。 比如你卸載了物理插件，客戶端只是失去了物理編輯能力，但不會(huì)因此而無(wú)法運(yùn)行，崩潰等等， 如果說(shuō)是客戶端必須實(shí)現(xiàn)的主要能力，就不要做成可安裝卸載的模式，即便做成插件類型的工程，也不走可拆卸插件的套路和接口實(shí)現(xiàn)。
13. 太多固定加載的窗體
現(xiàn)在我們程序啟動(dòng)相當(dāng)“累”，除了必須的初始化3d環(huán)境，還需要固定加載很多頁(yè)面，這會(huì)導(dǎo)致啟動(dòng)變慢，甚至啟動(dòng)后有卡頓幾秒，還有就是很多頁(yè)面在多種需求下要求不能關(guān)閉，關(guān)閉只是隱藏， 關(guān)于這一點(diǎn)，我ui這邊也有一個(gè)頁(yè)面要求固定不能關(guān)閉，那就是場(chǎng)景樹(shù)
改進(jìn)意見(jiàn)：不要出現(xiàn)任何必須存在不能關(guān)閉的彈出窗口，dock pane，插件(尤其是它)。除非，除非實(shí)實(shí)在在沒(méi)辦法了。
14. 客戶端文字編碼不嚴(yán)格
現(xiàn)在客戶端的char編碼不夠嚴(yán)謹(jǐn)，經(jīng)過(guò)李帥改造可能已經(jīng)好很多。
改進(jìn)意見(jiàn)：當(dāng)char作為要顯示的文字時(shí)，一律使用utf8編碼。QT從5.0開(kāi)始， QString也會(huì)固定認(rèn)為char*是utf編碼
15. 目前我們的項(xiàng)目都只配置了Release編譯選項(xiàng)
這可能導(dǎo)致發(fā)布版本的時(shí)候忘記開(kāi)啟編譯優(yōu)化，在一定程度上降低性能、但其實(shí)也有點(diǎn)好處，就是我們平時(shí)運(yùn)行的版就是用戶最終用的版，也確實(shí)遇到過(guò)Debug不出問(wèn)題，relase出問(wèn)題的情形。
改進(jìn)已將：最好還是debug release兩個(gè)編譯選項(xiàng)都配置，開(kāi)發(fā)期還是在debug下跑，發(fā)布在用release。
使用QT優(yōu)勢(shì)
通常VS和QT對(duì)比打架的時(shí)候，QT陣營(yíng)的利器就是跨平臺(tái)，但對(duì)于我們來(lái)說(shuō)這個(gè)跨平臺(tái)似乎只是錦上添花，目前重點(diǎn)還是windows。但用QT開(kāi)發(fā)UI，除了跨平臺(tái)還有一個(gè)好處，我認(rèn)為也是最大的好處，那就是QT開(kāi)發(fā)UI仍然算是與時(shí)俱進(jìn)，尤其是開(kāi)發(fā)我們這種大型工具類軟件。
和腳本+HTML+CSS比起來(lái)，QT開(kāi)發(fā)ui更容易調(diào)試，也更健壯，效率更高（效率其實(shí)主要還是看代碼質(zhì)量和策略），也有強(qiáng)大文檔支持。
我們?cè)瓉?lái)Dock Pane的開(kāi)發(fā)是借助皮膚庫(kù)XTreme, 而QT這方面是原生支持的，這個(gè)還是很有用的一個(gè)特性。
使用QT難點(diǎn)
目前我們的伙伴們，對(duì)QT的熟練程度不如VS高，有一定的學(xué)習(xí)成本。
但說(shuō)白了客戶端主要還是寫(xiě)功能邏輯，而功能邏輯VS和QT并無(wú)區(qū)別，無(wú)非是對(duì)QT的一些設(shè)計(jì)器什么的沒(méi)VS那么熟練。
QT開(kāi)發(fā)UI并沒(méi)有HTML+CSS那么方便，雖然QT也有自己被稱為QSS的東西，但和CSS比起來(lái)簡(jiǎn)直不堪大用，方便度也差很多，所以說(shuō)呢，以前分分鐘寫(xiě)出來(lái)的效果，用QT就得重載，寫(xiě)代碼。舉個(gè)簡(jiǎn)單的例子來(lái)說(shuō)，假設(shè)我們要制作一個(gè)三態(tài)按鈕，用CSS那就幾個(gè)樣式規(guī)定的事情，可以說(shuō)一分鐘就搞定了。但用QT你就得寫(xiě)代碼，保守估計(jì)也得20分鐘完成。這就是說(shuō)用QT并不能使我們開(kāi)發(fā)ui的工作變的更簡(jiǎn)單，相反的，會(huì)變的比原來(lái)復(fù)雜。
通常的控件，比如舉例說(shuō)的按鈕并沒(méi)什么問(wèn)題，只是用QT會(huì)變的復(fù)雜一點(diǎn)而已
但至少有2個(gè)控件開(kāi)發(fā)難度很大，當(dāng)然這個(gè)在老工程里也是開(kāi)發(fā)難度最大的2個(gè)控件
也就是動(dòng)畫(huà)控件和ANE控件，這倆控件用QT的話就只能完全使用自繪模式了，用html+css除了自繪還能利用很多東西，不細(xì)說(shuō)了。 完全自繪復(fù)雜度會(huì)大幅提升，包括鼠標(biāo)點(diǎn)擊，鍵盤什么的，都得自己判斷和響應(yīng)。 當(dāng)然帶來(lái)的好處是，性能提升，如果能做到局部繪制，性能會(huì)大幅提升。
使用QT工期評(píng)估
概述：現(xiàn)在我們只能粗略估計(jì)，依照老工程從代碼量，頁(yè)面數(shù)量，可以預(yù)見(jiàn)的難點(diǎn)控件評(píng)估
1. c++客戶端代碼量
185個(gè)源碼文件，行數(shù):184477
重構(gòu)估期: 5個(gè)月
2. 腳本文件
124個(gè)腳本和html文件, 行數(shù):32366
重構(gòu)估期：3個(gè)月
3. 頁(yè)面數(shù)量(可能有遺漏，因?yàn)椴寮械奈也恢?
個(gè)數(shù)61 (這其中假如有tab切換到不同頁(yè)面，實(shí)際上算成一個(gè)頁(yè)面了，比如設(shè)置頁(yè)面，渲染輸出頁(yè)面等等)
重構(gòu)估期：3個(gè)月
4. 難點(diǎn)耗時(shí)控件
動(dòng)畫(huà)控件：1-2個(gè)月（包括曲線圖，時(shí)間線）
ANE控件：1-2個(gè)月 (這個(gè)主要想實(shí)現(xiàn)局部繪制，難度不小)
虛擬場(chǎng)景樹(shù)：1個(gè)月 這個(gè)可以說(shuō)是咱們軟件的一個(gè)軸心, 因?yàn)槲覀円С殖髷?shù)據(jù)，所以難點(diǎn)在于效率。
5. 15個(gè)插件重構(gòu)
估期: 1-3個(gè)月 (這個(gè)主要看到時(shí)候是否能夠同步進(jìn)行, 相關(guān)開(kāi)發(fā)人員是否都能分配進(jìn)來(lái))
6. 預(yù)留給策劃和UI設(shè)計(jì)的時(shí)間
估期：3個(gè)月
綜上
1年-1.5年
