electron

Sugar-Electron 基于Electron的轻量级开发框架 前言 关于应用稳定性 关于开发效率低 特性 设计原则 安装 脚手架 核心功能 基础进程类——BaseWindow 举个例子 服务进程类——Service 举个例子 进程通信——ipc 请求响应 举个例子 发布订阅 举个例子 主进程与渲染进程间通信（进程名"main"，为主进程预留） 举个例子 进程管理——windowCenter 举个例子 进程间状态共享——store 举个例子 配置——config 举个例子 插件——plugins 插件封装 插件安装 插件使用 自动初始化核心模块 举个例子 注意事项 API start BaseWindow Service windowCenter ipc store 前言 今天给大家带来一款基于Electron桌面开发平台的自研应用框架Sugar-Electron，期望能改善Electron应用稳定性和帮助开发团队降低开发和维护成本。 笔者使用Electron做桌面应用，已经有3年的时间，期间也遇到很多大大小小的坑。但总结起来，最大的问题还是应用稳定性和开发效率问题。我们期望通过这个框架，能让应用程序在这两个方面有所优化。 项目源码地址： https://github.com/SugarTurboS/Sugar-Electron 如有任何疑问，可以扫码加入微信群聊讨论

electron-vue这个插件没用过，因为里面的electron版本和vue版本固定了感觉不灵活所以没去尝试，使用 Vuecli3.0 和electron5.0.8版本用到了串口，无语的是打包每次都成功了，一运行就报错。报错的意思大概就未引用seriaport模块，一顿无语。。。我不是在配置文件加了么。。。。 只好去他们的官网查看，终于让我找到了问题所在 蛋痛的是，这文件加在哪儿？？？？ 心里是崩溃的，最后没办法怀着试试的心态加到根目录 打包后成功了。。。。 嗯。。。研究这个已经三个星期了，各种坑，对于我这个英语菜的我都不好意思的人，还是很开心的。。。。看来是时候好好学习下英语了， 来源： oschina 链接： https://my.oschina.net/u/4335726/blog/4286134

导航： （一）Electron跑起来 （二）从零搭建Vue全家桶+webpack项目框架 （三）Electron+Vue+Webpack，联合调试整个项目 （四）Electron配置润色 （五）预加载及自动更新 （六）构建、发布整个项目（包括client和web） 摘要： 到目前为止，我们的项目已经具备了PC客户端该有的一些基础功能和调试环境，但是总感觉缺了灵魂，那就是结合实际项目、实际业务的细节处理，缺着吧。。。这篇文章就介绍一下预加载和自动更新，文字功底有限，如有介绍的不清楚的地方，欢迎留言指正，或者跳过文字，直接去看代码，项目完整代码： https://github.com/luohao8023/electron-vue-template ，随博客更新。 一、预加载 1、什么是预加载？什么场景能用到？　 preload String (可选) -在页面运行其他脚本之前预先加载指定的脚本 无论页面是否集成Node, 此脚本都可以访问所有Node API 脚本路径为文件的绝对路径。 当 node integration 关闭时, 预加载的脚本将从全局范围重新引入node的全局引用标志。 摘自electron官网的一段介绍， https://www.electronjs.org/docs/api/browser-window 。

原生开发应用开发 Microsoft阵营的 Winform WinForm是·Net开发平台中对Windows Form的一种称谓。 如果你想深入的美化UI，需要耗费很大的力气，对于目前主流的CSS样式表来讲，美化Winform的界面以及自定义控件是需要耗费更多的时间的。 WPF 基于XML+C#+CSS的呈现方式让它在UI上有了更加灵活的设计宽度 WPF和WinForms是两种完全不一样的UI技术，WPF也并不能完全取代WinForms。 WPF不能运行在其他操作系统，并且在XAML中编写样式表，通用性还是不如HTML强，从学习应用的范围来讲，还是HTML更好一些。 UWP 微软为了针对移动端市场开放的开发框架，如果你的APP只需要运行在Windows下，我认为WPF或者UWP是最好的选择，毕竟在调用系统原生API上微软的亲儿子们有着巨大的优势。 windows上各种各样的技术开发的IDE和其他程序 性能上：Java最差 -> Electron -> WindowsForms -> 原生 -> WPF 占内存：Java最多 -> Electron -> WPF -> WindowsForms -> 原生 Java阵营 Swing 零几年学Java的老头子们几乎都是从Swing开始学起的，Swing谜一般的默认UI审美观让我直接放弃了继续学习下去的动力。 JavaFx

目前大多数网络摄像头都是通过 RTSP 协议传输视频流的，但是 HTML 并不标准支持 RTSP 流。除了 Firefox 浏览器可以直接播放 RTSP 流之外，几乎没有其他浏览器可以直接播放 RTSP 流。Electron 应用是基于 Chromium 内核的，因此也不能直接播放 RTSP 流。 在借助一定工具的情况下，可以实现在 Web 页面上播放 RTSP 流。本文介绍的方法可以应用于传统 Web 应用和 Electron 应用中，唯一的区别是将 Electron 应用的主进程当作传统 Web 应用的服务器。 目前已有 RTSP 播放方案的对比 既然是做直播，就需要延迟较低。当摄像头掉线时，也应当有一定的事件提示。处于这两点，对目前已有的已经实现、无需购买许可证的 RTSP 播放方案进行对比（处于原理阶段的暂时不分析）。 基于 flv.js 的 RTSP 播放方案 flv.js 是 Bilibili 开源的一款 HTML5 浏览器。依赖于 Media Source Extension 进行视频播放，视频通过 HTTP-FLV 或 WebSocket-FLV 协议传输，视频格式需要为 FLV 格式。 服务器端（主进程） 服务器端采用 express + express-ws 框架进行编写，当有 HTTP 请求发送到指定的地址时，启动 ffmpeg 串流程序，直接将 RTSP

环境 测试环境：electron + vue + axios 需求 想要做并行请求（比如爬虫）需要尽量快的请求页面。 假如一次发出请求到返回所需时间为100ms： 方案1（串行）：请求一次接口等待返回处理结果后继续下一次请求。这样会受制于请求的速度，假如请求100次那么需要总时间为100ms * 100 = 10000ms 方案2（并行）：利用Promise，同时发起多个请求，但不等待每个请求结束。而是Promise.all等待其全部结束再进行处理。 假如请求100次那么需要总时间为100ms * 1= 100ms 可以看出速度有极大的提升，理论上（实际需要看机器配置和网络带宽情况）无论多少请求都只需要100ms。 并行实现 我们的需求就是方案2的并行实现。所以如下实现： async t () { const time1 = new Date (). getTime () / 1000 const task = [] for ( let i = 0 ; i < 100 ; i ++ ){ task . push ( this . t1 ()) // 发起请求 } await Promise . all ( task ) // 等待所有请求结束 // await this.$http.all(task) // 与Promise一样 const time2 = new Date ().

| A consistent experience is a better experience.——Mark Eberman | 一致的体验是更好的体验。——Mark Eberman 《摘自设计师的16句名言》 背景 1.UI一致性项目 积木（Tangram）Sketch插件源于美团外卖UI的一致性项目，该项目自2019年5月份被提出，是UI设计团队与研发团队共建的项目，目的是改善用户端体验的一致性，提升多技术方案间组件的通用性和复用率，整体降低视觉改版的研发成本。 一直以来，外卖业务都处于高速发展阶段，人员规模在不断扩大，项目复杂度在持续增加。目前平台承载了美团餐饮、商超、闪购、跑腿、药品等多个业务品类，用户入口也覆盖了美团App外卖频道、外卖App、大众点评等多个独立应用。因为客户端一直比较侧重业务开发，为了满足业务快速上线的需求，UI组件并没有统一的实现，而是分散到各个业务场景中，在开发过程中因UI缺乏同一的标准而导致以下问题不断凸显： UI/UE层面 ① UI缺乏标准化的设计规范，在不同App及不同语言平台上设计风格不统一，用户体验不一致。 ② 设计资源与代码均缺乏统一的管理手段，无法实现积累沉淀，无法适应新业务的开发需求。 RD层面 ① 组件代码实现碎片化，存在多次开发的情况，质量难以得到保证。 ② 各端代码API不统一，维护拓展成本较高，变更主题、适配Dark