聊一聊在移動互聯網時代做一個桌面應用

前言

掐指一算距上一次開發桌面應用已經過去十幾年，在某國際領先的遠洋貨櫃集裝箱運輸公司開發設計的人力資源管理系統，供全球200多個辦公室和上萬名員工使用，據說至今仍在使用，生命力之旺盛讓我倍感驕傲。那時候PC是使用率最高的設備，Windows XP是在PC上接近壟斷的操作系統，IE6佔據着我們主要的上網入口，Microsoft還視開源爲對手，.NET Framework還不能跑在Linux平臺上，iOS還沒有出現，安卓只是一個初生兒，剛剛被如日中天的Google收購，萬年的Java SWING和AWT一如既往的醜陋和運行緩慢。

當接到收銀系統這個項目時，內心還是很興奮的，因爲在8年前也曾經爲某直銷巨頭開發店鋪收銀系統，在這套系統上爲某直銷巨頭全國幾百家店鋪運營着幾百億的生意。一直印象非常深刻的是Joyce在2011年8月的某一天中午，請我們在宴（摔）薈（杯）喫(爲)飯（號）後4個平均年齡30+的男人就搬進了一個小黑屋，中間有人進出但這4個人一直沒有變，爲了國際化還邀請港臺人士參與開發設計，歷時4個月終於熬出第一個版本並在距離廣州50公里的一個店鋪試運行,試運行半年後全國上線。

技術選型

靈魂拷問

在項目尚未正式啓動之初，在我的大腦中一遍又一遍浮現出過去設計店鋪收銀系統的場景，在靈魂深處總有一個問題響起 “你還會這麼做嗎? ”

1. 設計一個Web版本的系統
答案是否。在WEB風起雲湧的年代，各大廠商用WEB技術由於較高的開發和部署效率代替了衆多用VB,DELPHI,MFC, WinForm, WPF,以及Java Swing/Awt等實現的桌面端應用。Web系統有着較高的開發部署效率，但全部的操作依賴網絡能力，缺乏本地的處理能力，對本地設備的操作不友好，同時需考慮瀏覽器的兼容性問題。然而在移動互聯網時代以用戶體驗爲導向又要兼顧開發部署的效率，一直在原生和純H5應用之間走融合的路線。

2. 支持IE的系統
。受制於當時的運行環境，Google Chrome和Mozilla Firefox未能成爲主流，IE作爲Windows標配被廣大的企業用戶所採用。只支持IE帶來巨大的痛苦，IE7/IE8的兼容性問題以及ActiveX運行權限均給部署帶來了極大的不便，完全不支持當時正在上升Chrome和Mozilla也帶來更多的質疑和挑戰。在8年後的今天，這個選擇明顯更容易做出來決定，Google Chrome一騎絕塵佔據絕對的優勢，成爲事實的標準。

3. 採用JSF作爲組件框架
答案是否定的。相信很多同學不知道JSF是什麼或者忘記JSF, 的確這個技術早已淡出了人們的視野

JavaServer Faces (JSF) is a Java specification for building component-based user interfaces for web applications[1] and was formalized as a standard through the Java Community Process being part of the Java Platform, Enterprise Edition. It is also a MVC web framework that simplifies construction of user interfaces (UI) for server-based applications by using reusable UI components in a page.[2]

時間拔回到2011年，JSF憑藉着組件驅動UI設計模型和AJAX 無縫的集成，並且VB/WinForm一樣的開發效率。試想一下，所見即所得的開發模式，通過豐富的組件用拖拉拽即可完成一個界面開發，怎麼能不被打動呢? 況且選擇了當時最現代的PrimeFace的組件庫，開發起來不要太爽。
軟件開發沒有銀彈，一切美好的想像都容易被打臉，在項目後期JSF已經成爲技術債務之一，主要體現在以下幾個方面:

• 性能不佳，頁面渲染效率低下，且有內存泄露問題
• 前後端耦合嚴重，頁面組件依賴後端維護狀態，修改成本極大
• 版本兼容較差，從JSF 2.1 到 2.2存在嚴重不兼容

4. 引入EJB
答案是否。這個問題其實跟桌面應用不是直接相關，閒聊一二。也許有人要問，Rod Johnson 在2002年就發現了著作<>並讓Spring Framework迅速成爲事實的J2EE開發框架，爲什麼還要使用EJB的這麼笨重的技術呢? 當時至少有以下幾點吸引我們：

• 按業務組件開發部署，這一點跟現在服務化無太多的本質的區別
• 應用服務器 (Weblogic) 提供業務組件的負載均衡能力
• EJB調用採用RPC效率高於HTTP協議
• 提供穩定的事務支持能力，包括二階段事務

5. 使用ActiveX驅動硬件設備
答案是不一定。脫離運行環境討論設計都是耍流氓，一個應用定位運行在Windows上的Web應用要想驅動本地設備，ActiveX是首選。ActiveX最大的問題就是對環境的依賴太過於嚴重，如本地權限控制，需要安裝註冊等，額外增加了實施的成本。

6. 依賴Windows域策略管理系統環境
答案是不一定。Windows域管理對於Windows PC管理仍然是最高效的存在，沒有了Windows域策略，對於終端的掌控就基本沒有，包括安全管理，瀏覽器設置，註冊ActiveX等。

7.支持票據打印的
票據打印是任何收銀系統都無法缺少的功能，打印的速度，穩定性和內容的靈活性是票據打印系統主要面對三大問題。用什麼打印驅動，支持哪些打印指令，支持哪些尺寸的打印紙，如何設計打印模板?

8. 實現所有支付集成以及備用方案
答案是肯定的。人財物是一個店鋪運行的三個核心要素。當時微信支付寶尚未流行，刷卡和現金是主要的付款方式，爲實現刷卡與系統的集成，需要跟銀行建立專線通訊，前端與後端進行打通，大大的提升了數據準確性和及時性。雖然付出較大的成本，收益在於簡化後端的處理步驟，讓每一筆款都能清晰記錄。

9. 內網系統
答案是否定的。隨着整個國家網絡基礎設施的穩定，互聯網的帶寬和延時都得到了顯著的改善，一個在內網性能良好的系統放到互聯網上不會出現明顯的卡頓。公網上運行帶來部署的靈活性和低成本，但也帶來安全性的威脅。

10. 支持離線
答案是肯定的。一個在公網運行的系統肯定要考慮網絡中斷的風險，雖然發生的機率不高。提供離線的功能，確保店鋪在斷網的情況下仍然能維持最低要求運作。

技術選擇

拷問完上面的問題後，心中大致有一個答案，主要考慮以下十點:

• 互聯網化的桌面應用，現代化的用戶界面與體驗
• 支持離線即本地操作的能力
• 支持前後端分離架構，最大程度利用現有的資產
• 支持跨平臺
• 支持原生和H5，在體驗和效率中取得平衡
• 支持驅動本地硬件。
• 支持自動更新
• 易發佈以及安裝
• 對運行環境依賴低
• 開發成本低

最後我們選擇Electron作爲我們桌面應用的框架, 使用WEB技術開發，本地支持良好，無需購買昂貴的M$工具

爲什麼選擇Web技術開發桌面應用

開發成本低且技術可重用

• 快速開發週期：熟悉HTML5，CSS3，JS和一些Node.js的開發週期都可以直接進入構建桌面應用程序的過程。
• 跨平臺兼容性：基於Chromium和Node.js（兩者都是跨平臺的），應用程序可以在支持這兩個平臺的任何地方運行。
• 精美的交互式GUI設計：HTML5，CSS3和JS的結合已證明了多年來可以實現的功能。
• 直觀且經濟高效的Web程序重用：首先由創建該Web應用程序的同一開發人員將其轉換爲桌面應用程序相對容易（即節省成本）。

傳統的桌面應用開發軟件WinForm和Windows Presentation Framework正逐年下降

爲什麼選擇Electron

Electron 技術特點

數於千計的應用構建在Electron之上，包括衆多知名軟件如Slack, Visual Studio Code， WhatsApp和PostMan等。

同樣使用Web技術開發桌面的NW.JS已被Electron全面超越，無論是功能，還是社區活躍程度均無法跟Electron相比。

NW.JS VS Electron 功能比較

NW.JS VS Electron 下載量

NW.JS VS Electron 社區活躍度

參考文檔

• JavaServerFace
• PrimeFace
• Electron JS
• NW.JS
• Performance-wise-is-a-wpf-application-better-than-an-electron-one-coded-wisely
• What are the pros and cons of Electron and WPF plus C# for building Windows desktop applications?

後記