聊一聊在移动互联网时代做一个桌面应用

前言

掐指一算距上一次开发桌面应用已经过去十几年,在某国际领先的远洋货柜集装箱运输公司开发设计的人力资源管理系统,供全球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 社区活跃度

在这里插入图片描述

参考文档

后记

发布了87 篇原创文章 · 获赞 42 · 访问量 10万+

猜你喜欢

转载自blog.csdn.net/vipshop_fin_dev/article/details/103205417