electron 收集整理

开发环境配置
本地示例文件
\meiqi\electron\meiqi_tools\
安装开发环境,配置后之后,可以F5直接运行,支持断点调试.
浏览器封装
接口暴露
考虑类似小程序的接入方式. 但是目前没想到需要封装的独立实现.(本地实现,基本可以考虑通过扩展)
扩展暂时没有发现,实在有需要,甚至可以考虑直接打包成jar然后通过electron调用jar实现.
网页/客户端通讯
ipcMain
ipcRenderer
可以直接在网页端,用nodejs的语法.
require类动作,为自动注入实现,需要开启 nodeIntegration: true
客户端/服务端通讯
是否考虑单页应用,然后浏览器完成全部工作? 把更新工作,全部交给web端
状态标志
用户登录,需要考虑状态保持的问题.或者每次登录都需要重新输入密码? 实现记住密码.
调试
web调试
可以通过直接触发(shift+ctrl+i)谷歌自带的调试,进行web-view部分的调试
客户端调试(菜单部分不可以隐藏)
主进程调试,通过vsc直接调试
菜单部分不可以隐藏,不然web-view部分的调试快捷键会无效(shift+ctrl+i).
考虑再另外注册调试动作.
热更新考虑,现在每次修改,都需要点击F5,可能无法再继续优化,web端可以考虑补充快捷键进行刷新
UI
暂时不考虑美化,直接打包,实现最基本的功能.
了解是否可以实现一套ui 实现 PC 和 手机端,减少工作量
考虑单页路由,实现快速和较好的用户体验,主要后面需要考虑上websocket, 需要考虑做成一个完整的app,需要通讯的保持
公司的页面一天到晚自己乱搞,改版,比较浪费时间,不方便写成单页应用, 或者自定义实现,相对来说,不是很显示.
或者考虑一套简单通用的单页应用,快速上手,然后让美工学习
打包
体积:普通情况下,打包大小接近150M+,需要经过压缩和精简处理(待测试了解)
打包教程:
经测试,不需要搞什么asar(暂时没有发现实际作用,后续需要vue类需要考虑)
直接压缩包:62M+
通过hm nis 打包大小:45M+
可以控制icon,开始菜单,卸载,二次安装还能选择是否覆盖等操作,其它相关
这样相对容易分发,但是更新需要再研究下,以及版本的相关控制.
代码干扰考虑
\resources\app\ 中直接包含了客户端的源码,防止别人修改后,发布,有一定危害(暂时没有靠谱的解决方案….甚至官方不提供支持…).
特殊功能考虑
打算封装一次,通过修改路径,让程序打开对应的网站实现相关功能. 不过只有打包的应用,安装时,才会出现图标,路径以及标题,说明这些.
cookie的读取和控制,还在折腾中.后续打算配置客户端,普通数据采集的验证码输入,直接让用户安装客户端或者直接提供谷歌扩展实现.相对来说.客户端会简单点.只需要做一步登录即可.
采集工具考虑.
获取指定的域名的cookie列表,如果不设置参数改为{},可以获取所有cookie内容.
断点阶段,会无法输出,应该是有远程调用,只有恢复浏览器活动时,才会触发then
require(‘electron’).session.defaultSession.cookies.get({ url: ‘xxx’ })
.then((cookies) => {
console.log(cookies);
}).catch((error) => {
console.log(error);
});
简单采集工具思路,主要针对普通采集,登录后,补充一个检测,登录成功,自动上传cookie内容到指定服务器,服务器通过该cookie进行数据采集
通过对url以及页面内容进行检测,检测到符合目标,就直接提示采集标志成功.如果发现失效,则直接跳转到登录页面.
只能针对小众东西,对有强自动化,各种验证的,再来~
自动更新
只有客户端需要更新,内容直接通过服务器访问,基本不需要更新,客户端更新,需要了解自带的版本检查流程相关.
目前内部使用的土方法
打包一次->压缩….
这个不适合更新
自动更新
需要注意特殊配置, 像数据库是否会被覆盖.
更新时,如果出现对数据库的修改,需要实现升级处理.
填坑
Jquery 找不到问题
npm 所有socket默认端口都是1080,即使关闭代理,也莫名奇妙会跑代理,一直报1080端口错误.shadowsock 默认端口是1080…如果出现,不是缓存问题…要注意.
c++混合开发
bug
自带notification 各种使用限制,环境的兼容问题.暂时通过node-notifier代替
修复node-notifier循环注册事件bug
需要考虑该种调用,是否关闭即无效.
本地存储
官方推荐
web 端有localStore类存储,不是很妥当,关键数据,还是考虑保存到本地数据库中.
实际环境可能出现的问题
断网, 断电, 程序损害时的迁移.
考虑让用户自行手动录入订单

爽爆的elasticsearch xpack sql

 

最近的一个场景:商品表到20w+ 属性表直接破了800w+(有个需要搜索其它的需求….导致80w的中间表不用,必需得跑全表,同时有个属性多字段匹配的功能.比如颜色,材质会出现复数字段.导致属性表较大,几乎有的没的属性都得上), 数据库单独移动到ssd,速度大概提升2-3倍, 下阶段还能通过将属性表按分类分表或者简单点直接用merge表引擎. 进行简单优化..

感觉都不如这个牛逼啊……

比较懒,写了个工具将sql自动转成elasticsql 只需要这段代码~

elasticsearch辅助工具

顺便做个广告:

https://www.xmaibu.com/

搜索部分就是使用elasticsearch 同时支持图片搜索,属性搜索…