这是一个创建于 3396 天前的主题，其中的信息可能已经有所发展或是发生改变。
谢谢
 | 1 loading 2016-08-27 11:49:21 +08:00 via Android 包大 界面要做好，很繁琐 Xp 不支持 |
 | 2 giuem 2016-08-27 11:49:39 +08:00 via iPhone 体积大 |
 | 3 nicevar 2016-08-27 11:56:30 +08:00 via iPhone 优缺点参考 Atom 了，明显的缺点就是太吃 CPU 多消耗点地球能源，冬天使用能保暖，夏天热死狗 |
 | 4 oa414 2016-08-27 12:06:46 +08:00  1 包大 有个脑洞：多个应用共用一个大版本的 release ，安装包检测系统有没有 libElectron 1.X ，如果有就复用，没有就下载。这样应用可以做到几百 K 。 感觉 Electron 更像一个解释运行的环境，没必要每个应用自己打包集成。 现在做 Electron 的开发，在网上学习一些代码，每个项目 npm install 以下，系统里面就有几十个 100M+ 的 Electron.app .... |
 | 5 SourceMan 2016-08-27 12:09:36 +08:00 via iPhone 体积大，就这一个缺点了 |
| 6 loading 2016-08-27 12:19:25 +08:00 via Android 建议先做 web app 然后再考虑打包 |
 | 7 dphdjy 2016-08-27 15:46:25 +08:00 via Android @oa414 好方法，不过基本不可能，因为 atom 的应用太少，主流的几个还有魔改的。 不过可以试试写个 atom 的应用打包工具，然后把下载放在这部分。 在顺手开个商店。。。 生态也有了。。。 然后发现商店只有屈指可数的几个应用。。。 |
 | 8 dibage 2016-08-27 18:22:21 +08:00 @dphdjy 不是不可能，个人已经在半年之前已经实现（现在已经不怎么用 electron 了） 原理很简单，把你的 app 打包成 asar ，然后用 electron 的 api （或者自己封装）去加载即可。 这样可以扩展到其他方面，比如做个 electron 的 app 应用市场，提供一些基础的 nodejs 模块，这样的话自己写的应用，排除 node_modules 以及 electron 资源，打包后的大小就非常满意了。 （本来之前是有打算做这个市场的，但是精力不足，如果 v 友有兴趣的可以交流交流 |
 | 9 regent 2016-08-27 18:33:13 +08:00 via iPhone 体积大，流畅度一般 |
| 10 oa414 2016-08-27 18:45:49 +08:00 @dibage 有过类似的想法，不过还没有动手... 我的想法是做一个原生的 GUI 启动器 /shell 脚本，检测 ~/.electron 有没有 Electron.app, 然后下载 asar 包和图标这些，然后通过链接文件生成应用的 XXX.app 。 关于公共模块，类似动态更新，加密源码这样子的，个人觉得还是适合做成开源的库，一方面打包也没多大，一方面 Electron 生态目前还算很小... 或许可以 brew 或者类似的工具集成以下，做成 brew electron install user/repo 这样子的 brew 的插件 另外，想为 Electron 加入更多原生的模块，发现想为 Electron 本身添加一个模块或者贡献代码的要求挺高的。 node 这一块内容不多，但是魔改的 libchromium 和相关的 cpp 库... 编译一下要从 s3 下载几个 G 的文件，还有各种依赖和环境要求，至今没有编译成功... |
 | 11 hst001 2016-08-27 19:02:57 +08:00 都什么年代了，体积大根本不是问题 真要说缺点，就是耗资源（其实这年代耗点内存可以忽略了），但还算比较流畅 |
 | 12 dibage 2016-08-27 19:04:20 +08:00 @oa414 其实如果要求不是很大，技术以及成本不是那么到位的话，没必要去研究修改源码＋如何编译这类问题，因为我们关心的是 app 层。 参考 chrome 的 app （包括安装＋执行＋ api 等方面），其实如果弄的话优势还是挺好的。虽然传闻 chrome 已经抛弃 app 功能。 所以跟你的想法类似，做个 gui 启动器（ shell 脚本＋终端安装的方式就没必要了，毕竟已经有 node+npm ），然后做个在线的 app 市场，用户只需要点击安装即可把 app 下载回来并安装到本地使用。 不过这中间有个难点问题（在开发的时候会遇到），就是启动 app 的时候，是寄生于主进程还是重新启动一个新进程（如果是使用 api 直接加载 asar 执行，那么问题就出来了：菜单栏无法做到独立（在 mac 中测试），以及一些变量污染等等细节，都是挺麻烦的。。 |
 | 13 DoraJDJ 2016-08-27 19:07:03 +08:00 via Android 最明显的就是体积大，若要写一个小程序，最好还是用 cli 或者是其他的 GUI 库。 |
| 14 oa414 2016-08-27 19:55:58 +08:00 @dibage 因为曾经了解一点 macOS 开发的皮毛，发现有的想法或者需求，比如控制窗口的一些行为， Cocoa 只需要一两行，而 Electron 下完全做不了因为没封装。。 关于多个应用，我的想法应该还是模拟成多个 App 。这样，无论是在命令行下用 open -a ， Finder 检索，进程独立这些都很方便。 感觉这样下去。。。就变成了一个 ChromeOS 的虚拟机。。 |
| 15 dibage 2016-08-27 20:06:54 +08:00 via Android @oa414 哈哈 是的。可能这么做最后下场就是 chrome app 不过按照你所说的，用原生代码比较容易实现，那么可以考虑考虑 react-native for osx ，只不过跟 electron 比起来还是有很多劣势。 说到 chrome os ，还真是可以拿 electron 来封装，做个 web os 。 虽然性能以及实用性 安全性等都不是很理想… |
 | 16 1990andy 2016-08-27 20:42:03 +08:00 via iPhone VScode 就是这么开发的 |
| 17 dphdjy 2016-08-27 22:08:31 +08:00 via Android @dibage 我说的不可能是指 达到 VC ， net 什么的装机覆盖。而且本身被使用量极低，并不会有人愿意接入这种库，自己维护更加安全可靠 |
 | 18 zsx 2016-08-27 22:36:47 +08:00 Electron 每个版本都有 API 改动……就算 API 没改动，用 node-gyp 编译出来的 C++模块也只能对应相应版本 [版本号要严格对应] 的 Electron ，等于你还要下载一大堆。 |
 | 19 exoticknight 2016-08-27 23:05:25 +08:00 不支持 xp 感觉没了 好吧还是要视开发什么应用的前提下 |
| 20 oa414 2016-08-28 06:57:22 +08:00 1 @dibage 学过 react-native 的 hello world 和学过一点点 react 以及 其他 MVVM 框架，觉得也是一种思路。不过，我觉得现在在 PC 上性能问题倒不是很大，先用浏览器引擎渲染也可以接受。 但 React-native 同样重点在 view ，涉及到之外的一些东西还是要写很多 RCTXXXX ，而且移动端基本应用生命周期靠系统调度，而 PC 上权限大，可以干很多东西，比如做个 CleanMyMac 之类的 App ，可能需要一点原生 API 的内容才能写好。 PC 端上原生 GUI App 开发的资料和大厂的支持、以及社区活跃度都少很多。。。也没有大厂愿意去推动。如果资料充足，社区活跃，写一个不跨平台 app 也并不是很难， OSX 和 iOS 开发还是很像的，但是 NSXXX 比 UIXXX 的资料少太多。此外估计像 Qt ， GTK 的坑也不少，虽然只写过 VB ，但是觉得写 GUI 应用最舒服的或许是在 windows 下吧 ... |
 | 21 xuanyi0926 2019-06-17 15:11:19 +08:00 没有安全性可言，代码都是明文展示的，别人拿到你的包分分钟能开发个和你一模一样的 |
Select Language