关键词：
现在开发IM应用动不动就要求多端——即Android端、iOS端、PC端、Web端等，Android端和iOS端作为两种不同的移动端技术，单独开发和维护还能理解，PC端和Web端如果要单独开发那就有点头大了，必竟开发传统的PC桌面应用成本太高（QT这类技术跟Web技术相比，上手难度大的多，而且太小众）。所以，很大情况下大家都是PC富客户端和Web端二选一，对于比较磨叽的老板、产品经理或客户来说，这是个很费口舌的事情（你懂的。。。）。
在即时通讯网的官方技术群里不只一次看到大家在讨论Electron技术，作为新一代基于Web的桌面技术，已经被越来越的产品采用，成熟度和认可度都不错，Electron技术可以降低开发PC端的成本和难度，或许PC富客户端和Web端再也不需要二选一了。
桌面应用程序，又称为 GUI 程序（Graphical User Interface），但是和 GUI 程序也有一些区别。桌面应用程序 将 GUI 程序从GUI 具体为“桌面”，使冷冰冰的像块木头一样的电脑概念更具有 人性化，更生动和富有活力。
我们电脑上使用的各种客户端程序都属于桌面应用程序，近年来WEB和移动端的兴起让桌面程序渐渐暗淡，但是在某些日常功能或者行业应用中桌面应用程序仍然是必不可少的。
传统的桌面应用开发方式，一般是下面两种。
1）原生开发：
直接将语言编译成可执行文件，直接调用系统API，完成UI绘制等。这类开发技术，有着较高的运行效率，但一般来说，开发速度较慢，技术要求较高，例如：
a. 使用C++ / MFC开发Windows应用；
b. 使用Objective-C开发MAC应用。
2）托管平台：
一开始就有本地开发和UI开发。一次编译后，得到中间文件，通过平台或虚机完成二次加载编译或解释运行。运行效率低于原生编译，但平台优化后，其效率也是比较可观的。就开发速度方面，比原生编译技术要快一些。例如：
a. 使用C# / .NET Framework(只能开发Windows应用)；
b. Java / Swing。
不过，上面两种对前端开发人员太不友好了，基本是前端人员不会涉及的领域，但是在这个"大前端"的时代，前端开发者正在想方设法涉足各个领域，使用WEB技术开发客户端的方式横空出世——这就是本文正在介绍的“Electron”技术。
Electron是由Github开发，用HTML，CSS和JavaScript来构建跨平台桌面应用程序的一个开源库。 Electron通过将Chromium和Node.js合并到同一个运行时环境中，并将其打包为Mac，Windows和Linux系统下的应用来实现这一目的。通过Node它提供了通常浏览器所不能提供的能力。
Electron于2013年作为构建Github上可编程的文本编辑器Atom的框架而被开发出来（PS：据说这个Atom看起来很漂亮，但很难用...）。这两个项目在2014春季开源。
其实，Electron在早期一直是由原作者 Cheng Zhao 一个人维护和开发的（他现在是 Github 北京 Atom 编辑器开发 team 的一名工程师）。在这之前，Zhao主要进行node-webkit（现在叫nw.js）的开发工作。从概念上，Electron与nw.js很相似，但是他们有很重要的区别：一个主要的不同点是Electron 通过 Googles Chromium Content Module 来使用 Chromium 的功能，nw.js 则直接使用了 Chromium本身。
可能主要是因为，猿类里的亚种——“前端开发”，又有了新的出路了吧，已经在岗的前端也有了新一年的 KPI/OKR，刚起步的创业公司可以只拉一个前端就能开发跨平台的多个桌面客户端... ...（开个玩笑）。
1）可以用 Web 前端技术开发跨平台的桌面客户端：
这是 Electron 最迷人的地方，究其根本是因为它是建立在 Chromium 和 NodeJS 之上的，一个负责界面，一个负责背后的逻辑，典型的"你负责貌美如花，我负责赚钱养家"，为什么 Electron 能够开发跨平台的桌面应用也就可以理解了。
而对于前端开发来说，“不要和老夫说什么 C++，Java，老夫行走江湖就一把 JS，遇到需求就是干”。前端开发可以用自己熟悉的方式去写应用界面，逻辑部分也还是 JS，如果你精通 Node 后端，那后端也可以插一脚，“鸟枪换大炮”，你开发客户端的能力有一种“忽如一夜春风来”的感觉。
但是，不同系统间还是会有很大的不同，“同一套代码，编译出跨平台的多个客户端”，话是这么说，但你得因为系统的不同做一些额外的处理，以使得打包出的不同系统下的应用都可以正常工作，这可能是一些“if - else”的成本，但相比于那80%都能完全复用的代码，这些成本已经很小了。
综上所述：一个 Web 前端开发者可以花很少的成本去上手 Electron，而相比于以前开发多平台客户端的成本，利用 Electron 开发多平台客户端的成本是极低的。即时通讯聊天软件app开发可以加蔚可云的v：weikeyun24咨询
2）可以从 NodeJS 的生态获得极大的助力：
因为 Electron 是基于 NodeJS 的，意味着，NodeJS 这个大生态下的模块，Electron 也都可以用，这减少了很多造轮子的时间，你要写一些逻辑将首先思考有没有成熟的模块可以引入，而不是自己吭哧吭哧闭门造车，自己造时间精力会大量得被消耗，上路还可能翻车。
Electron 从 NodeJS 获益有2个方面，一个方面是如现代的 web 项目一般，开发构建流程可以引入很多成熟的包去打造出适合自己项目的开发工作流，另一个方面就是其应用本身也可以依赖需要的包去完成自己的功能。
3）“这个东西做Web版就可以，干吗还要开发PC客户端版？”
既然 Electron 是用 Web 技术写客户端，那么看上去 Electron 要做的事，可以搬到网站上。
为什么还要搬到PC客户端，这里有3个角度的回答：
a. 用户角度： 客户端是一款独立的软件，其综合体验一般都是比网站高的，尤其是涉及到「工具」范畴的应用，此外，特定的用户群体也会有类似的使用习惯；
b. 发行方角度： 客户端是另一种产品形式，是一种产品的分发方式和入口，客户端可以实现很多本地应用独有的需求去触达用户，也能提供更加可靠的服务；
c. 开发角度： 终于...不用考虑浏览器兼容了，Chromium 也足够开发使用一些先进的 CSS 或 JS 特性，我们现在还没计划引入 webpack 和 babel，因为现在好像够用，克制才是爱，除了写起来爽，对于开发来说，终于跳出了浏览器的沙盒，你可以自己去控制 Electron 中的“浏览器”，莫名的开心。
这些综合起来回答这个小节的问题就是，用 Electron 开发客户端，用户体验好，开发麻烦小，功能更强大，老板脱发少。
4）那在 Electron 和 NW.js 之间，为啥选择前者？
我没怎么用过 NW.js，但当时在没有时间深入体验的实际情况下，我选择生态好的。
Electron 相关的社区生态很好，之后的开发过程也证明了这一点，遇到的问题基本都能通过 Stackoverflow 找到，如果没有找到，新开一个问题或者去 Github 提 Issue 都可以得到较快的解决，除非是一些已知的问题或一些看文档可以解决的问题，这类问题可能会被忽略过去。
所以，生态更好一些，我选择了 Electron。
5）总结一下，使用Electron开发的理由：
a. 使用具有强大生态的Web技术进行开发，开发成本低，可扩展性强，更炫酷的UI；
b. 跨平台，一套代码可打包为Windows、Linux、Mac三套软件，且编译快速；
c. 可直接在现有Web应用上进行扩展，提供浏览器不具备的能力；
d. 你是一个前端👨💻～
当然，我们也要认清它的缺点：性能比原生桌面应用要低，最终打包后的应用比原生应用大很多。
Electron的开发体验
兼容性：虽然你还在用WEB技术进行开发，但是你不用再考虑兼容性问题了，你只需要关心你当前使用Electron的版本对应Chrome的版本，一般情况下它已经足够新来让你使用最新的API和语法了，你还可以手动升级Chrome版本。同样的，你也不用考虑不同浏览器带的样式和代码兼容问题。
NodeJS环境：这可能是很多前端开发者曾经梦想过的功能，在WEB界面中使用Node.js提供的强大API，这意味着你在WEB页面直接可以操作文件，调用系统API，甚至操作数据库。当然，除了完整的 Node API，你还可以使用额外的几十万个npm模块。
跨域：你可以直接使用Node提供的request模块进行网络请求，这意味着你无需再被跨域所困扰。
强大的扩展性：借助node-ffi，为应用程序提供强大的扩展性（更详细的介绍可以自行百度相关资料了解一下）。
浅析现代web端im即时通讯开发技术
传统的Web端即时通讯技术从短轮询到长连询，再到Comet技术，在如此原始的HTML标准之下，为了实现所谓的“即时”通信，技术上可谓绞尽脑汁，极尽所能。自从HTML5标准发布之后，WebSocket这类技术横空出世&... 查看详情
浅析im即时通讯开发出现上网卡顿？网络掉线？
特别推荐即时通讯开发者来阅读，因为针对移动弱网的问题，确实可以找到很多有价值的答案。作为即时通讯（IM、消息推送等应用场景）相关技术的开发者人员来说，似乎了解跨专业的通信技术（这是大... 查看详情
浅析即时通讯开发实时信息推送服务器ddpush
IM(InstantMessaging)即时通讯系统，从1996年ICQ的出现，到国际巨头割据的今天，已经深刻地影响了互联网，甚至人类社会的变化。从移动互联网时代开始，即时通讯系统更是加剧演变进化，除了iOS和Android提供... 查看详情
浅析im即时通讯开发加白名单
IM在Android上的保活问题经常在即时通讯网的论坛和技术群里被讨论，自从Android8.0后系统大大降低了后台运行应用的保活容忍度，保活从黑科技横行的时代进入了技术蛮荒阶段，真要实现保活，技术难度越来越大。... 查看详情
浅析百万消息量小规模im即时通讯系统技术
现如今的互联网产品中，即时通讯技术已经不仅限于传统IM聊天工具本身，它早已通过有形或无形的方式嵌入到了各种形式的互联网应用当中。IM技术（或者说即时通讯技术）对于很多开发者来说，确实是必不... 查看详情
浅析百万消息量小规模im即时通讯系统技术
现如今的互联网产品中，即时通讯技术已经不仅限于传统IM聊天工具本身，它早已通过有形或无形的方式嵌入到了各种形式的互联网应用当中。IM技术（或者说即时通讯技术）对于很多开发者来说，确实是必不... 查看详情
浅析大型im即时通讯系统开发难度
本文从一个简单的系统例子开始，从单机架构、主从副本、同城灾备、同城双活，再到异地双活、异地多活，由浅入深、循序渐进地讲解了大型分布式系统异地多活容灾架构的技术原理和基本的实现思路，非常适... 查看详情
浅析即时通讯开发前置httpsso单点登陆接口的原理
一个安全的信息系统，合法身份检查是必须环节。尤其IM这种以“人”为中心的社交体系，身份认证更是必不可少。一些PC时代小型IM系统中，身份认证可能直接做到长连接中（也就是整个IM系统都是以长连接为中... 查看详情
浅析即时通讯移动端开发dns域名劫持等杂症
对于互联网，域名是访问的第一跳，而这一跳很多时候会“失足”（尤其是移动端网络），导致访问错误内容、失败连接等，让用户在互联网上畅游的爽快瞬间消失。 而对于这关键的第一跳，包括鹅... 查看详情
浅析即时通讯开发框架netty4.x线程模型
将具体代码实现前，先来谈谈Netty的线程模型。正如许多博客所提到的，Netty采用了Reactor模式，但是许多博客也只是提到了而已，同时大家也不会忘记附上几张DougLee大神的图，但是并不会深入的解释。为了更... 查看详情
浅析即时通讯开发框架netty4.x线程模型
将具体代码实现前，先来谈谈Netty的线程模型。正如许多博客所提到的，Netty采用了Reactor模式，但是许多博客也只是提到了而已，同时大家也不会忘记附上几张DougLee大神的图，但是并不会深入的解释。为了更... 查看详情
浅析怎么开发分布式im即时通讯系统
本文不会给出一套通用的IM方案，也不会评判某种架构的好坏，而是讨论设计IM系统的常见难题跟业界的解决方案。因为也没有所谓的通用IM架构方案，不同的解决方案都各有其优缺点，只有最满足业务的系统才是... 查看详情
浅析im即时通讯开发移动端dns域名劫持问题
对于互联网，域名是访问的第一跳，而这一跳很多时候会“失足”（尤其是移动端网络），导致访问错误内容、失败连接等，让用户在互联网上畅游的爽快瞬间消失。而对于这关键的第一跳，包括鹅厂... 查看详情
浅析即时通讯移动端im开发中登录请求的优化
到底是“登陆”还是“登录”？这是很多处女坐开发者纠结的问题，不过它不是本文本讨伦的内容。本文将针对移动端IM的登陆功能给出相应的优化建议。源起在移动IM模块中，最核心最复杂的模块莫过于登录模块。... 查看详情
浅析im即时通讯开发之扫码登录二维码
二维码技术使用起来很简单，本系列的前三篇文章也专门针对IM扫码登录这个功能做了详细的分享，但本着学习技术不留死角的习惯，我认为有必要单独学习一下到底什么是二维码（说不定哪天被个刚入行的程序... 查看详情
浅析im即时通讯开发中tcp协议层keepalive保活机制
对于IM这种应用而言，应用层的网络保活的最直接办法就是心跳机制，比如主流的IM里有微信、QQ、钉钉、易信等等，可能代码实现细节有所差异，但理论上无一例外都是这样实现。（PS：没错，当初微... 查看详情
im即时通讯开发：为什么要用https？浅析短连接的安全性
对于IM开发者来说，IM里最常用的通信技术就是Socket长连接和HTTP短连接（通常一个主流im会是这两种通信手段的结合）。从通信安全的角度来说，Socket长连接的安全性，就是基于SSL/TLS加密的TCP协议来实现的... 查看详情
activemq即时通讯服务浅析
一、 概述与介绍ActiveMQ是Apache出品，最流行的、功能强大的即时通讯和集成模式的开源服务器。ActiveMQ是一个完全支持JMS1.1和J2EE1.4规范的JMSProvider实现。提供客户端支持跨语言和协议，带有易于在充分支持JMS1.1和1.4使用J2... 查看详情