首先作為一個開源框架/AssetStore 插件的作者深知，維護插件、框架的使用文檔是一件很麻煩的事情。 大部分主流的文檔方案，基本都是用 markdown 編寫。 不管是用 markdown 編寫 還是用 word 還是其他的方式寫文檔，都涉及一個文件管理的問題。 這些文件要么部署在網站上，要么部署在 github 上，要么會隨著代碼包含在插件里。 文件維護起來會很麻煩，而每次修改文檔，也需要找到對應的文件。 對于文檔維護，有了第一個痛點，就是文檔管理的痛點。 第二個痛點，就是閱讀的痛點，每次自己買完插件或者下載好別人的框架，都需要跳轉到網頁去看文檔，或者如果插件中已經包含了文檔，那么我需要下載一個對應的軟件把文檔打開，有時是 pdf、有是能打開 .md 格式的軟件，有時需要是 Word，總之多多少少需要在多個軟件之間來回切換，IDE、Unity、文檔閱讀器（瀏覽器、World、Typora 等等），總之對于只用一個屏幕的童鞋來說，非常不方便。 這就是第二個痛點，閱讀的痛點。 然后就是第三個痛點，語言的痛點，很多插件的文檔都是英文的，所以很多好用的插件，在國內的使用率差了一大截，原因就是沒有對中文支持。  所以關于文檔這塊，有三個痛點，總結如下： * 文檔管理的痛點：需要維護文件、需要部署。 * 閱讀的痛點：需要對應軟件打開、需要多個軟件之間切換。 * 語言的痛點：中文不支持。 而 QF Pro 給出的方案，就是 DocKit。 首先關于第一個痛點，文檔管理的痛點，DocKit 是這樣做的。 首先在項目中任意位置，即可創建文檔文件，操作如下：  創建好了之后，目錄如下：  首先文檔文件的 Inspector ，有一個 EN 的選項框，按下之后，變成如下：  這里全部都變成了英文，也就是說 QFramework Pro，都會支持中英文。 （畢竟，QF Pro 上架 AssetStore，需要去賺老外的錢。。。） OK，我們切換回來，如下：  我們點擊打開窗口，或者我們也可以直接雙擊文檔文件，之后可以看到如下圖所示的窗口。  現在卵都沒有。 我們先創建第一個節點，文本節點，鼠標右鍵選擇 Create Node，如下：  然后選擇 DocKit/TextNode 文本節點，如下：  這樣就創建好了一個文檔節點，如下：  以上就是文本節點的創建流程。 下面我們給他支持英文文檔，如下:  只要只要勾選右上方的 EN 選框就能支持中英文切換。 接著，我們來進行簡單的導出功能，如下：  點擊生成 Markdown 文件， 之后會在目錄看到如下:  我們用支持 Markdown 格式的軟件打開，如下所示：  OK，以上就是 DocKit 的基本使用流程。 流程如下： * 創建文檔文件 * 創建文本節點 * 編寫文檔 * 導出為 Markdown 那么這樣的流程，如何解決了三個痛點呢？ * 對于文檔管理來說，只需要將文檔文件和插件一起放在目錄里即可，這樣即方便修改維護，也適合直接發布，也省去了用戶需要額外打開網頁或者下載閱讀軟件的麻煩。最重要的是，支持離線閱讀，不用有網絡環境。 * 對于文檔閱讀來說，文檔的表現形式是圖的形式，圖的形式天生比文字文檔更直觀更容易閱讀，而且用戶無需安裝其他軟件，僅僅是在 Unity 內部即可閱讀文檔，既然 Unity 支持了這么方便好用的編輯器，當然文檔的方式也要用 Unity 的方式解決了，這很酷，不是么。 * 對于語言問題來說，QF Pro 肯定是要支持中文文檔的，畢竟是現在國內發展起來的框架，其次，也要支持英文，畢竟也要上 AssetStore 去賺美刀，也是一個國際化的必經之路，QF 的 DocKit 支持了一鍵切換中英文，任何位置都支持切換的選項框。 所以以上的三個痛點都算解決了。 在這個基礎之上，還支持了 Markdown 導出的功能。 為什么要支持 Markdown 導出呢？ 因為我們并不是 24 小時都待在電腦旁的，有的時候，我們閱讀文檔是在手機或者 ipad 上看的，這個時候如果 DocKit 寫的文檔只在 Unity 內觀看的話，就有點太雞肋了，所以就支持了 markdown 格式的導出。 markdown 格式幾乎支持轉成任何文檔格式：word、pdf、textbundle、html 等等，所以只要支持個 markdown 格式也就解決了這個問題。 其實自己研究過一套 pdf 導出方案，無奈，為了實現這個功能依賴了十幾兆的其他庫，不值當，所以就舍棄掉這個功能了。 這就是 DocKit 的一個基本介紹了。 DocKit 除了支持文檔節點，還是支持圖像節點，如下所示。  圖像創建流程與文本節點一樣，不再贅述。 從外部導入圖片的方式如下，點擊 ... 按鈕，會打開桌面文件夾，如下所示：  這里筆者選擇一張圖片，然后打開，結果如下：  這樣圖像節點就導入進來了。 導入存放的目錄，默認在同名目錄的 Editor 目錄下，如下：  如果重復導入同名文件，則會自動用 ID 改名，如下：  如果重復資源或者圖片修改了比較多，會產生很多無用資源，這里只需按下文檔文件的清空不用的圖片資源按鈕即可，如下：  不過目前，這兩個封面 和 封面1 這兩個圖片都有被引用，因為在第一次設置貼圖資源的時候，如果 中文圖片 和 英文圖片都沒有進行設置過，那么會把設置的圖片同時設置給 中文圖片 和 英文圖片。 因為很多時候中英文圖片引用的是同一張。 然后剛才的操作中，又導入了一張圖片，此時只會講當前語言的圖片替換，也就是說現在 中文圖片是封面1 英文圖片是封面2。 所以還需要再導入一次圖片，然后點擊清空不用的圖片資源，結果如下：  OK，這是圖片節點的導入功能。 為什么要從桌面開始導入呢？ 因為很多截圖軟件（比如 Mac 自帶的截圖軟件）都是截圖之后會自動保存到桌面，為了配合這個特性，所以圖片節點的導入就默認打開桌面文件夾了，這樣會形成一個流程上的閉環，如果習慣了寫文檔的效率會非常高。 不過，其實更高的方式是截圖完直接從剪切板中獲取圖片，然后直接粘貼到文檔中，但是這個功能，要實現需要依賴 Mono2.0 的 System.Windows.Form.dll 和 System.Drawing.dll 這兩個文件，所以同樣棄用了，QF Pro 要盡可能少的依賴，不然很容易和其他插件其沖突，后期維護起來會很麻煩。 OK，圖像節點創建好了，當然也支持導出為 Markdown 功能了，我們導出一次 Markdown，結果如下：  完美。 好了，介紹好了 文本節點和圖像節點，其實還要支持很多其他節點，比如表格節點、一些動作節點支持簡單的編程，還有代碼展示節點，大標題小標題節點、GIF 動畫節點等等，而剩下就是擴展節點的工作量了，這部分慢慢做就可以，可以將重心轉到下一個模塊的開發了。 除了實現以上功能外，還對 GraphView 做了很多調教工作，比如雙擊文檔區可以支持全屏/窗口切換，如下： 窗口：  全屏：  還有其他的小功能，DocKit 的整體進度如下：  * DocKit - 使用可視化編程編寫項目文檔（正在進行） * 節點 * 文本（已完成） * 圖像（正在進行） * GIF 動畫（接下來） * 表格節點 * 動作列表節點（可以執行） * 導出 * Makrdown（已完成） * PDF（已完成，由于會依賴幾十兆的 dll，所以功能取消） * 導入 * 圖片節點 快速從項目外部導入圖片（已完成） * 圖片導入時重名自動增加計數 ID 為后綴（已完成） * 多語言 * 中英文切換已完成） * 生成的 Makrdown 文件，支持中英文版本作為后綴（已完成） * 圖像節點支持中英文同時引用同一張圖片功能（已完成） * 中英文切換（已完成） * 手勢 * 雙擊全屏/窗口切換(已完成) * 快速創建接節點(Ctrl/CMD + 鼠標左鍵）（已完成） * 雙擊圖像文件自動打開窗口（已完成） 所有的 UI 庫，不管是 NGUI 和 UGUI、還是 UIElement 等，最先實現的基礎控件基本都是 文本控件 和 圖片控件，因為任何其他的空間都可以用文本控件和圖片控件組合而成。 所以，DocKit 支持了 文本節點 和 圖片節點，就能滿足大部分的需求了，因為不管是代碼還是表格都能用圖片的形式來展示。 之所以先做 DocKit，是因為，要做好一個插件和方案，文檔是非常重要的部分，文檔做好了，可以節省大量的時間、精力和團隊間的溝通成本。 而不管是獨立游戲、還是公司的項目、或者是開發插件和框架、本質上都是軟件工程，軟件工程中文檔是非常重要的。 而 QFramework Pro 版本會有大量的文檔編寫需求。 但是這里筆者有一個小的觀點，產品的設計，盡可能讓用戶開箱即用，就是最好做到不用看說明書就能上手使用，比如蘋果手機等。 所以筆者會選擇直接給個選項框，來切換中英文，如下：  而不是寫個文檔，告訴用戶，中英文如何切換 blablabla。 產品設計和關卡設計是有點通的，關卡設計中使用金幣來引導玩家來做出設計師想讓玩家做的操作是一個很常見的套路。 就是一個東西最好是一看就能明白，這個就是一個小小的理念吧，一是使用體驗會好一點，二是能減少大量的文檔編寫工作量（逃。。。。） OK，關于 DocKit 就說道這里，DocKit 只是 QF Pro 眾多功能規劃中的一個小功能，后續還會有很多。 還有一件事情，由于 AssetStore 審核需要 3 個工作日，所以 QF Pro 將會分為兩個版本發布。 一個版本是 AssetStore 版，即穩定版，由于審核需要 3 個工作日，當 QF Pro 的用戶遇到緊急問題時無法盡快修復。 所以，再開一個快速迭代版本，這個版本就放在自己平臺發布了。 AssetStore 版和 快速迭代版，不支持互相轉換，建議只買一個版本，AssetStore 版更穩定，快速迭代版功能更快體驗到問題也能及時修復，但是相對會不穩定一些，很有可能有 API 的變更。 當然如果你想多多支持 QF Pro 讓他更好，也可以兩份都購買作為支持和鼓勵。 目前此文所述的功能，已在快速迭代版中支持，而 AssetStore 只要當前版本審核通過了，會立即提交快速迭代版當時的相對穩定的版本。 快速迭代版，會優先編寫中文文檔，每當可以發布 AssetStore 版本時，會進行文檔的翻譯工作。 QF Pro 目前暫不兼容 QFramework 的開源版本（ToolKits 版），但是會隨著 QF Pro 的迭代，慢慢將 API 兼容到 QFramework 的開源版本，所以目前不要直接升級 QF 開源版到 Pro 版本，建議在新工程中體驗 QF Pro 的功能。 任何 QFramework Pro 的更新信息，會優先發布在此系列的專欄、視頻中，所以對 QF Pro 感興趣的童鞋多多關注筆者，以方便獲取更新。 OK 就說道這里。 ## 各種地址 * DocKit 所參考的可視化編輯方案 * XNode（參考一部分功能） 地址：https://github.com/Siccity/xNode * https://github.com/Siccity/xNode * BlueGraph（參考一部分功能和樣式，顏值最高，但是 bug 也最多） * https://github.com/McManning/BlueGraph * NodeGraphProcessor（主要是這個，DocKit 再次基礎上魔改，最新版適配了 2019.3） * 地址：https://github.com/alelievr/NodeGraphProcessor * 感謝煙雨大佬的關于 NodeGraphProcessor 的一篇文章，其中的架構圖讓我很快弄清楚了 NodeGraphProcessor 的結構 * 地址：https://zhuanlan.zhihu.com/p/362259030 * QFramework Pro AssetStore 主頁：[http://u3d.as/SJ9](http://u3d.as/SJ9) * 快速迭代版（眾籌地址）：https://www.gamepixedu.com/course/72 * QFramework QQ 群：623597263 * 此文首發于 http://doc.qframework.cn 或 https://qframework.cn * 轉載請注明地址：https://liangxiegame.com 在這個地址可以看到我全部的作品鏈接