第一次开发Electron应用后台。由于工作内容多为一些日常活动，虽然活动主要以已经准备好的模板为主，但其实并没有太多开发的必要。一般是调整好按钮的位置，颜色，字体大小就可以马上放行，但是操作感觉事件里面的一切都要开发好才可以放行，会影响他们的操作效率(╮(╯▽╰)╭），并开始下发开发说明：希望能够模块化拖拽生成一个activity（°(°ˊД?°)°可以大致理解为MAKA等生成H5的工具），好吧，没有交互，没有设计，给你这么大的空间，好好玩，好好加鸡腿。╮(╯▽╰)╭一脸茫然，说自己以前做过，要回去好好想想。..经过一段时间对Electron大法的深入思考（挣扎半天，差点吐血），(╯▔＼▔)╯认为用Electron可以把难度降到最低（本来想做成后台应用，但是我的直觉告诉我，多简单怎么来的），可以使用web技术开发（效率），可以使用海量的nodejs模块（支持要好很多），可以摆脱兼容性问题（只兼容一个浏览器），就是一个，听着都开心）。以上就是选择Electron开发的原因。如何更新既然要做客户端，更新就是个大问题。如果更新整个应用，在基本开发完成后，打包压缩到72M（不做任何优化，依赖包很多，压缩后node_modules也有20M），应该算很大了.如果是第一次分发，没有问题，但是每次整个应用都要手动更新操作，操作起来一定很不爽，必须开发自动更新的方案。看了Github上的文档，有专门的章节介绍自动更新入口。Electron团队也很贴心，给出了一系列的解决方案，但是我觉得我不需要这么高深的技术（我只需要简单一点），好吧(╯▔＼▔)╯，我决定做自己一套。首先，使用electron-packager打包Electron应用（因为公司都是windows，所以只能针对windows打包，但是打包过程也比较耗时，大部分时间都花在了复制node_modules文件夹），很容易发现electron-packager的生成其实就是一个模板。每次内容变化，只是resources文件夹下的内容。如果我们不需要复制node_modules文件夹的内容，打包速度会提高很多（其实node_modules不会经常变），我开始想象把node_modules和src（代码）分开打包，这样如果以后更新，只更新src目录还是挺快的。ASAR文件在看Electron文档的时候，看到Electron支持一种叫做asar格式的文件。asar是什么格式？Github官方介绍如下：Asar是一种简单的广泛归档格式，它的工作原理类似于tar，将所有文件连接在一起而不压缩，同时具有随机访问支持。可以看出，这种文件格式只是简单地将文件组织在一起，没有进行压缩。可以看做是一个文件夹，访问里面的文件，而且只能读不能写，这点很重要。通过这种文件格式，它提供了一种将node_modules和src分别打包成node_modules.asar和src.asar的方法。应用启动时，直接require对应的src.asar文件，然后执行src.asar中的代码创建窗口和加载页面。那么应用更新只更新node_modules.asar和src.asar这两个文件。在这种情况下，整体更新粒度会降低。当然，如果你有更高的要求，你需要实现更小的粒度（对于某些代码文件级别的更新）可能需要再考虑一下，但对于我目前的场景来说已经足够好了。一个小问题一个小问题，src.asar中的代码如何找到node_modules.asar中的模块，换句话说就是如何将node_modules.asar放在模块的搜索路径上，这里是我使用的方法：require('module').globalPaths.unshift(require('path').join(process.cwd(),'resources/node_modules.asar'));只需将它添加到globalPaths并放在最前面（找到它更快）。按照这样的更新计划，项目的目录结构也需要稍微改动一下。我的项目下主要有三个文件夹：app、node_modules、src。node_modules和src就不用多说了，当前app目录下的代码是干什么的？1.首先检查是否有需要更新的文件。MD5，使用现有文件进行比较）跳到2，如果不是则跳到32。依次下载相应的文件，例如：src.asar.update、node_modules.asar.update，下载完成后直接替换旧文件3.最后require('src.asar').createApp()创建主界面，现在可以保证应用程序以最新的代码启动（只要下载没有问题）。就是这么简单的解决方案，操作到最后都没有。抱怨更新麻烦，皆大欢喜。当然，面对真实的用户场景，应该还是有很多不足的地方，以后会慢慢学习改进(╯▔＼▔)╯。
