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
没有安全性可言,代码都是明文展示的,别人拿到你的包分分钟能开发个和你一模一样的
|