electron 和 我们的项目

前端桌面的应用开发框架，个人感觉比nw好用

  • api不多。NB的是能结合前端UI开发，瞬间让丰富的wenUI在桌面端转起来，因为chorme内核基本不用去考虑兼容问题，而且而且还跨平台。所以是现在桌面端开发的非常靠谱的技术栈。
  • 缺点是生成的安装包偏大，不过在现在硬件富余的PC机上，可以忽略不计吧。

我们的项目：
目前的八爪鱼团队,致力打造领先的数据采集器。通过我们的采集工具方便用户比较容易采集到数据。

  • 结合我们的项目，内存资源管理问题（我们项目要比较考虑这个，根据业务需要，会有比较多的browserWindow，而且显隐比较频繁）这就需要我们对窗口管理精准。能统一销毁，精准显示（这是我们这次迭代的重要）
  • IPC通信。这个应该会是electron项目的一个痛点。官方提供的方案很基本的观察者模式，但是业务复杂了，最后也需要能统一管理模块（目前还没有想的很好方法，做一遍梳理，方便下次迭代优化），现在总结的就是：
    • 能不用就不要用ipc通信
    • 能一次ipc搞定就不要分两次
    • 及时销毁销毁监听
  • 安全模块。这个是一个比较重要的模块。既然是客户端，则代码就放在电脑磁盘上，敏感业务逻辑还是比较容易暴露的，还包括一些敏感的信息。我们采用的 .node等（属于公司机密，就不多说了），来保证代码的安全性。但是这有个大bug隐患(.node文件，会比较容易被回收。会导致模块不能运行）
  • 工程化问题，这个比web项目复杂多，也是百步之行最后一步，我们踩坑不少。
  • 其他开发的和web开发差不多了，但是仅仅是理论上差不多

遇坑无数：

  1. 兼容性问题，虽然win和mac是同一套webui和chrome内核，但是mac下1px问题依然存在,mac下srcollbar不占宽高
  2. electron自身 api在不同系统下表现不同，
  3. 特殊依赖包问题。我们又个需求在win下支撑本机账户登录mssql数据库，这个功能在mac下不能实现（显然mac用户怎么会有用账户直接直接登录mssql），这个模块只能为win定制。怎么考虑项目代码统一管理情况下，在依赖都不同的情况下怎么开发问题。打包发布问题。
  4. 刚才说到.node文件编译。在mac、win下是两套代码编译。然后又发布在同一个模块里面。
  5. 息屏后 elctron 防止关键.node文件被回收
  6. 打包后的文件在不同系统下签名和安全策略问题
  7. mac打包后代码公证
  8. 数据库支持管理，我们支持mysql,mssql,orcal,sqllite四种数据库
  9. 多语言管理，多语言平时的开发调试
  10. 安全代码策略问，
  11. 自动升级问题
  12. 工程化发布问题
  13. bpmn流程管理（我们需要这个步骤的执行控制）
    …

还有一些问题和web项目开发比较雷同

  1. 项目工程化，代码规范，
  2. 测试用例覆盖管理
  3. code review 流程化
  4. 版本管理问题
    …

在接下来就是编码能力

  1. 面向对象
  2. 合理的模块化
  3. es ts 新特性增加代码可读性
  4. js各种避坑指南
  5. react mbox最佳实现

最后解决问题的能力

  1. 实际开发会遇到各种问题，我们就遇到一个问题中途一个sqllite版本升级了问题，失去了本地加密的能力，赶紧打补丁包。这个时候无形中给开发增加了一个恶心的开发任务：

    • 怎么判断有没有被安装高版本，从而判断有没有必要copy数据库
    • 怎么考虑兼容装两个sqllite模块
    • 从高版本读出来后，写入可以加密的低版本
    • 什么时候备份出新版本数据库。
    • 什么时候写入低版本
    • 保证文件不被锁定后不能做删除和重命名操作

  2. mac代码公证，要求说有引用的二进制引用都必须签名，

    • 怎么打包
    • 怎么在 electron-builder build 前做好签名而且不从新被编译
    • 怎么签名
    • 怎么公证

  3. 怎么一个二进制.node安全模块同时兼容mac和win

  4. 性能的优化优化再优化