Electron: 移动支持

我认为 atom-shell 主要是为 atom 文本编辑器构建的，所以我不希望它支持移动平台。 HTML5 移动应用程序有 Phonegap 和 Cordova。

是的，但它是关于从 node.js 模块共享代码和访问低级资源

对于移动平台，几乎所有 atom-shell 的 API 都不适用，所以我认为我们永远不会支持移动平台。

也许你们至少可以通过（以某种方式）检测环境（在运行时或在构建期间指定）来很好地使用 Cordova 等，以便 Electron API 在我们不知道的情况下简单地调用 Cordova 模块（或本机代码）。 那将是非常棒的。

+1 @trusktr

@trusktr听起来像是一个很棒的第 3 方模块，可以为 Cordova 提供兼容性垫片

我真的希望这会发生。 我认为网络平台的未来需要朝着这个方向发展，这样我们才能编写真正的跨平台应用程序。 我真的希望这不被排除在外。

我不敢相信它已经是 2016 年了，仍然没有这样的事情。

@emin93这不是建设性的，正如@zcbenz已经指出的那样，将 Electron API 移植到移动设备几乎是不可能的。
如果没有关于如何实现它的至少某种建议，您就不能仅仅要求功能。

@YuriSolovyov我不是直接指电子。 实际上没有其他选择，这让我感到沮丧。 但是，是的，你是对的，这实际上不是讨论这个问题的正确地方。

用于移动设备的电子会非常棒。 我开发了一些 Electron 应用程序并且喜欢这个框架，但我每天都希望我们能看到它也能在移动设备上运行。

唯一显示端到端跨平台支持（IOS、Android、Windows、OSX、Linux）的跨平台框架是Xamarin ，但需要用 C# 编写代码。 如果微软现在拥有 Xamarin 并且在将节点移植到他们自己的 JS 引擎方面也取得了长足的进步，如果 Xamarin 允许 JS 代码，我不会感到惊讶。

我真的希望一些企业赞助商能够参与资助这样一个用于移动的电子端口/分支，最终将被纳入同一个框架，这样我们就可以拥有一个完整的基于 JS 的跨平台应用程序开发框架。

感谢 Electron 团队的出色工作！

与@cjfromthesea的原始问题相呼应，有人能解释一下 Electron 在移动设备上的 API 存在的问题吗（也许是 @zcbenz）？ 通过一些一般性的指导，我自己和其他人可能会开始思考通过破解和修补来解决问题的方法。 我已经处理了一点 jxcore-cordova，但是一些指导会很好。 有哪些障碍？

@lastmjs一个巨大的障碍是 Electron 使用了 iOS 不支持的 V8。 这意味着 Chromium 和 Node.js 也无法在 iOS 上运行，而这三个是 Electron 的主要组件。

IOS 的新 chromium 版本于 1 月发布， node.app或许可以为 node.js 解决问题。 鉴于支持 V8，Android 应该不是问题。
同时，我们可以编写一份关于如何将 Cordova 与 electron 用于 IOS 的文档（因为我真的需要这些，我很乐意提供帮助）。

@noelmace iOS 版 Chrome 不使用 Chromium 引擎，因为 Apple 不允许这样做。 它只是像 Safari 使用它的 WKWebView，但具有不同的 UI。

@emin93 Apply 是否允许使用任何自定义解释器，例如 node.app？

我有几个问题我很想从这个线程中的人那里得到想法——

• 您是否正在寻找构建_一个可以在任何地方运行的应用程序_？
  
  
  
  • 后续问题，是否有桌面应用程序（不是网络应用程序）也是移动应用程序的示例？
  
  
• 或者您是否正在寻找电子应用程序构建_体验_但在移动设备上？
  
  
  
  • 后续问题，这与 Cordova/PhoneGap（或其他）有何不同？
  
  

我肯定在寻找一款可以在任何地方运行的应用程序。 一个代码库，一个 Web 平台，任何环境。

优秀的移动/桌面/网络应用程序示例，屏幕大小和设备并不重要，但您可能需要相同的功能：

• 铬合金
• 火狐
• 松弛
• 邮箱
• 谷歌相册
• 谷歌地图

并非上述所有应用程序都必须具有使用本机可执行文件运行的桌面版本，但它们确实在浏览器中具有桌面版本。 对我来说，当然这取决于具体情况，但通常我希望我的应用程序成为我的应用程序，无论它在什么设备上。 我尽可能在所有设备上争取相同的功能。 为什么不？ 我希望 Chrome 在我的桌面上的工作方式与在我的 Android、iPhone 或平板电脑上的工作方式相同，对于 Firefox、slack、谷歌地图也是如此。 当谷歌地图的功能有时是特定于平台的时，我觉得很难过。 回到 Chrome，我希望能够查看源代码甚至使用调试器，即使在我的手机上也是如此。 我有时认为我们没有先见之明来适当地限制我们的应用程序的功能。 如果有人确实想要在手机上的应用程序的桌面版本上运行的功能怎么办？ 这些应用程序当然应该是响应式的，但在我看来，核心功能应该尽可能保持不变。

谢谢@lastmjs。 我刚刚编辑了我的问题，因为我在想但没有具体说明的是桌面应用程序，它们也是移动应用程序，但不是网络应用程序。 我认为这是一个重要的区别。

但我认为核心功能应尽可能保持不变

在这里大声思考：Electron 为常见的本地桌面应用程序行为创建了一个 API——似乎如果你也添加到移动设备中，所有这些之间的共同点将会缩小。 基于桌面和移动之间的共同点的应用程序最终可能在任何地方都可以工作，但它的移动体验和桌面体验都低于标准？

您所说的常见本机桌面应用程序行为是否主要基于 UI？ 我可以看到本地菜单和其他行为可能无法很好地翻译。 对我来说最大的好处是拥有一个统一的运行时，我可以在其中访问 Node.js 和 Chromium API，并且说运行时可以部署到所有主要平台。 Electron 和 Cordova 在某种程度上为不同的平台做同样的事情，减去你可能一直在谈论的 UI 功能。 使用 Cordova，您拥有一个可以部署到几个主要移动操作系统的代码库，据说移动操作系统在功能上与主要桌面操作系统没有太大区别。 操作系统管理进程及其资源，并授予对进程可能需要的硬件的访问权限。 移动操作系统和桌面操作系统之间没有太大的根本区别。 随着浏览器开始拥有硬件 API，Web 平台在所有主要环境中部署的能力变得越来越普遍。 所以在我看来，Cordova 和 Electron 完成了大致相同的任务，但在不同的操作系统上，说操作系统没有根本的不同，那么为什么不将它们结合起来呢？ 😃

@jlord

我为移动和桌面构建，并希望添加来自@lastmrs和@noelmace 的评论

以下是我对它如何适用于每个人的想法。

electron 公开的 API 必须根据它是移动设备还是桌面设备而有所不同。 因此，开发人员有责任进行运行时环境检测（电子层提供）以根据环境上下文调用不同的 API。
再次明确，这取决于开发人员做正确的事情

就 UI 方面而言，再次由开发人员来做正确的事情。 我在所有桌面和移动项目中都使用聚合物，而正确地做到这一点取决于我。
我还使用 golang 在桌面和移动设备上编写我需要的任何编译的东西来访问任何硬件。

在构建时，我为台式机（amd 64 等）和移动设备（android 或 iOS）打包，为每个操作系统和芯片架构制作单独的包。 我对电子也是如此。 这使我可以根据需要进行编译时间差异，因为某些代码是硬件相关的。
我仍然可以在所有构建中包含相同的代码并进行运行时嗅探，这就是电子为我提供环境上下文的地方。

它提供的好处是设计时和编译时的通用工具。 这对开发人员来说是一个巨大的生产力提升，因为您可以安装 electron 并运行引导 bash 脚本来安装 iOS 和 android 位，以及编写 hello world 以及打包和部署到桌面和移动设备。

我不知道 Google 团队已将 iOS 的 chrome 更新为多进程。 看到这个我超级兴奋。

如果我能提供任何帮助，我很乐意提供帮助。

对于我的许多项目来说，这也是一个巨大的改进。 一个人已经必须根据它是否移动来对 UI 进行更改，也可以进行任何其他检测/更改。

我不认为拥有两个独立的 API 是一个好主意（@joeblew99）。 对于最终用户，我认为如果 Electron 让它的 API 在 Cordova 或 Node 之上工作会更好，这样最终用户只需要知道一个 API（Electron API）。 然后，如果 API 未涵盖某些内容，最终用户可以根据需要深入使用 Node 或 Cordova。

另外，我认为对于 Electron 来说，定义如何使用在任何一种情况下（Cordova 或直接在 Node 上）都可以工作的 NPM 工作流非常重要。 即，Electron 必须定义它的构建系统以兼容两者，使用 NPM（ES6 模块也会很好），这样最终用户就不必担心如何为每个构建系统。 显然，Node 案例已经处理完毕，但可能需要额外的工作才能使 NPM 在 Cordova 中正常工作。

请注意，在 Cordova 中 Node.js API 不可用，因此 Electron 需要使用在 Cordova 中工作的替代方案来填充一些本机 Node.js 模块，类似于 Browserify 为浏览器所做的。 这将有助于创建统一的 API，因为如果 Electron API 未涵盖某些内容，那么至少填充库意味着用户可以回退到在幕后调用 Cordova API 的基于节点的 API。

polyfill 的需要正是我认为从 API 路由开始更明智的做法。 它不必是一个单独的 API，只是某些功能无法立即使用。 如果您通过并使其 100% 兼容，那么当在路上添加新功能时，它是一个更大的野兽。

我还想指出，Android 和 IOS 不再只是移动设备。 我正在做的项目在安卓电视上看起来很棒，而且我不明白为什么 Github 不想让 Atom 在电视或平板电脑上运行。

好点，它不再与屏幕大小有关，我们开始处理通用操作系统。

我对 Android 上 Electron 的状态感到困惑？

它是正在积极考虑的事情还是仅仅是正在谈论的事情？

使 Electron 应用程序成为 PhoneGap 或 Cordova 应用程序的有效目标大约容易 1000 倍！
IE。 cordova platform add electron-osx electron-win electron-linux

@purplecabbage当然，但是你失去了控制整个浏览器堆栈的所有额外好处。

回复：Node.js Polyfills。

我们应该开始列出所需的 _native_ polyfills 才能使其工作。 Browserify 已经拥有 Node.js Core 的 _lot_ 的纯 Web 版本。 我能想到的唯一需要的是：

• dns
• net
• fs

还要别的吗？

全局对象：

• __目录名
• __文件名
• 过程

@purplecabbage看起来这 3 个有 browserify 实现。 https://github.com/substack/browserify-handbook#__dirname。 我们是否应该根据设备赋予它们不同的值？

是的，__dirname 和 __filename 不是什么大问题。
进程是browserify中的准系统，我们不想支持事件吗？
https://github.com/defunctzombie/node-process/blob/master/browser.js

对于与 electron.js 共享代码的 Native Mobile 应用程序，我认为最好的方法是通过将 Electron.js 与 NativeScript 结合来探索路线 - http://github.com/NativeScript/NativeScript。

我们（NativeScript 团队）正在计划创建一个示例演示应用程序，如果您有兴趣，请对此问题发表评论 - https://github.com/NativeScript/NativeScript/issues/2695

实际上，已经有 Angular 2 高级种子可以实现这一点 - https://github.com/NathanWalker/angular2-seed-advanced。 但是 angular 2 绝不是实现这种解决方案的必要条件。

这是有道理的吗？

我认为关键是您的团队已经完成了添加原生 API 的工作。 我完全赞成你的想法。

@valentinstoychev这是一个非常有趣的想法，尽管它基本上意味着任何电子应用程序都必须重做它的整个 UI，对吗？ 如果你们能以某种方式包含libchromiumcontent来创建类似于electron的webview ，那将非常有趣。 然后在一个应用程序中使用两者会更容易。

Android WebView 小部件和 iOS 上的等价物怎么样？ 事实上，Android 已经是 chromium 了。 :)

@hadees是的，我们的想法是使用 NativeScript 为 iOS 和 Android 实现一次移动 UI，并使用电子为桌面实现一次。 其他一切——数据、模型、业务逻辑、服务、数据访问都应该是一样的。

这里有两点需要注意。

首先，在使用 electron.js 和 NativeScript 进行构建时，您将使用几乎相同的技能集（意味着一个团队可以将其用于桌面、Web 和移动）——都是 JavaScript/TypeScript/CSS。 如果你愿意，你可以使用 Angular 2。 对于样式，您将为 NativeScript 和电子使用 CSS。 _所以通常唯一不同的是 UI 标记_。 甚至布局也应该很熟悉，因为我们下个月将发布 FlexBox 布局。 其他一切都是可重用的代码，最重要的是可重用的技能。 工具部分也应该熟悉，因为我们在 NativeScript 中使用的是 Chrome Devtools...

这里要注意的第二件事是，您实际上希望为移动设备和桌面设备提供不同的 UI，对吧。 因此，在许多/大多数情况下，UI 部分无论如何都不会被重用，并且应该有所不同。

我相信这是一个非常引人入胜的故事，我们将很快对其进行探索并展示一个真实的例子。 我希望看到实际的代码和实际的应用程序将有助于弄清楚是否值得探索。

在任何情况下，最终的应用程序（或多个应用程序）都将使用原生 UI。 我认为这就是使该解决方案独一无二且值得探索的原因。 被黑客入侵也很便宜，因为无需对 electron.js 和 NativeScript 进行任何更改。 从第一个解决方案开始，我们可能会发现可以存在更紧密协作的领域。

我在 Cordova 的桌面和移动 GUI 上使用了聚合物。 科尔多瓦
支持桌面和移动。

对我来说，关键是使用 grpc 作为绑定技术。 这让很多
更容易，因为客户端和服务器可以互操作。

对于所有我只需要一个 grpc 代理插件来充当中间人

2016 年 9 月 10 日星期六 08:17 Valentin Stoychev， notifications @github.com
写道：

@hadees https://github.com/hadees是的，这个想法是实现
移动 UI 一次用于 iOS 和 Android，使用 NativeScript，一次用于桌面
使用电子。 其他一切——数据、模型、业务逻辑、服务，
数据访问应该相同。

这里有两点需要注意。

首先，您将使用几乎相同的_skillset_（意味着一个团队可以
使用 electron.js 构建时，使其适用于桌面、Web 和移动设备
NativeScript - 都是 JavaScript/TypeScript/CSS。 您可以使用 Angular 2
如果你喜欢。 对于样式，您将为 NativeScript 和
电子。 _所以通常唯一不同的是用户界面
标记_。 当我们发布 FlexBox 时，即使是布局也应该很熟悉
下个月布局。 其他一切都是可重用的代码，最重要的是
可重复使用的技能。

这里要注意的第二件事是你实际上想要有不同的
移动和桌面的用户界面，对。 因此，在许多/大多数情况下，UI
部分无论如何都不会被重用，应该有所不同。

我相信这是一个非常引人入胜的故事，我们将探索它并
很快就会展示一个真实的例子。 我希望看到实际的代码和
实际的应用程序将有助于弄清楚是否值得探索。

在任何情况下，最终的应用程序（或多个应用程序）都将使用原生 UI。
我认为这就是使该解决方案独一无二且值得探索的原因。 它
被黑客入侵也很便宜，因为不需要对
electron.js 和 NativeScript。 从第一个解决方案开始，我们
可能会发现可以存在更紧密合作的领域。

—
你收到这个是因为你被提到了。
直接回复此邮件，在 GitHub 上查看
https://github.com/electron/electron/issues/562#issuecomment -246093147，
或使线程静音
https://github.com/notifications/unsubscribe-auth/ALcac7syNn7D8eztsREVxIyrrl7mBJs4ks5qokuQgaJpZM4CVUMK
.

NativeScript 并不是 Electron 移动支持的真正选择，因为
它完全将范式从 Web 技术转移到 JavaScript
本机小部件的绑定。 本质上，我们将不再是
“Electron”，因为 Electron 的核心是一个浏览器堆栈，它暴露
浏览器上下文的 Node.js _inside_，这就是使 Electron
电子。

NativeScript + Node.js 绑定可以被认为是完全不同的
项目。

首先，在使用 electron.js 和 NativeScript 进行构建时，您将使用几乎相同的技能集（意味着一个团队可以将其用于桌面、Web 和移动）——都是 JavaScript/TypeScript/CSS。

不一定正确，因为使用 NativeScript 你必须有一些
了解本机小部件的行为方式，无论事实如何
你正在用 JavaScript 编码。 这意味着在不知情的情况下
小部件，并且不知道如何修改这些小部件绑定
本机代码，然后做一些自定义变得非常困难，这是
Web 堆栈中的纯 JS/HTML/CSS 并非如此，因为使用 Web 堆栈
修改内部意味着在您已经在的相同环境中修改相同类型的代码，而不必担心外语。

这里要注意的第二件事是，您实际上希望为移动设备和桌面设备提供不同的 UI，对吧。 因此，在许多/大多数情况下，UI 部分无论如何都不会被重用，并且应该有所不同。

使用 Electron（带有基于 Web 的前端）的好处之一是
我们编写了一个代码，它的行为几乎_完全相同_
到处。 NativeScript 并非总是如此，它
试图用一种语言连接完全不同的技术集。

我个人更喜欢在任何地方使用 web-ui 的想法，
与各地不同的原生 UI 相比。 有些人认为原生 UI
比 Web UI 要好得多。 在某种程度上是对的，事实就是如此
与不了解网络完整基础的开发人员一起使用。 但是，随着
正确使用 Web API 实际上我们可以制作出漂亮的 UI。 网络正在变得巨大
进步。 WebGL 是一个巨大的跨平台...

_/#!/_JoePea

2016 年 9 月 9 日星期五晚上 11:17，Valentin Stoychev < [email protected]

写道：

@hadees https://github.com/hadees是的，这个想法是实现
移动 UI 一次用于 iOS 和 Android，使用 NativeScript，一次用于桌面
使用电子。 其他一切——数据、模型、业务逻辑、服务，
数据访问应该相同。

这里有两点需要注意。

首先，您将使用几乎相同的_skillset_（意味着一个团队可以
使用 electron.js 构建时，使其适用于桌面、Web 和移动设备
NativeScript - 都是 JavaScript/TypeScript/CSS。 您可以使用 Angular 2
如果你喜欢。 对于样式，您将为 NativeScript 和
电子。 _所以通常唯一不同的是用户界面
标记_。 当我们发布 FlexBox 时，即使是布局也应该很熟悉
下个月布局。 其他一切都是可重用的代码，最重要的是
可重复使用的技能。

这里要注意的第二件事是你实际上想要有不同的
移动和桌面的用户界面，对。 因此，在许多/大多数情况下，UI
部分无论如何都不会被重用，应该有所不同。

我相信这是一个非常引人入胜的故事，我们将探索它并
很快就会展示一个真实的例子。 我希望看到实际的代码和
实际的应用程序将有助于弄清楚是否值得探索。

在任何情况下，最终的应用程序（或多个应用程序）都将使用原生 UI。
我认为这就是使该解决方案独一无二且值得探索的原因。 它
被黑客入侵也很便宜，因为不需要对
electron.js 和 NativeScript。 从第一个解决方案开始，我们
可能会发现可以存在更紧密合作的领域。

—
你收到这个是因为你被提到了。
直接回复此邮件，在 GitHub 上查看
https://github.com/electron/electron/issues/562#issuecomment -246093147，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AASKzg6ISiScLgMY1lz83Ff3MxHq3e0Mks5qokuPgaJpZM4CVUMK
.

@trusktr我完全同意。 我认为开发人员在寻找本地化方面投入了太多的精力。 本机甚至不是一个一致的理想。 在过去十年中，移动界面发生了数十次变化，甚至从一部安卓手机到另一部都不一致。

让您的应用在用户可能访问它的所有平台上看起来一致是一个更好的标准。 让他们学习两组 UI 符号和信号只是为了在他们的 iPhone 和 Windows 工作机器上操作应用程序是可怕的。

https://blog.chromium.org/2017/01/open-sourcing-chrome-on-ios.html

从历史上看，由于平台需要额外的复杂性，iOS 版 Chrome 的代码与 Chromium 项目的其余部分是分开的。 经过多年的仔细重构，所有这些代码都重新加入 Chromium 并被移动到开源存储库中。

由于iOS平台的限制，所有浏览器都必须建立在WebKit渲染引擎之上。 对于 Chromium，这意味着同时支持 WebKit 和 Blink，这是 Chrome 用于其他平台的渲染引擎。 这造成了一些额外的复杂性，我们希望避免将其放入 Chromium 代码库中。

鉴于 Chrome 对开源代码的承诺，我们在过去几年中花费了大量时间进行必要的更改，以便将 Chrome for iOS 的代码上传到 Chromium。 今天，上游已经完成，开发人员可以像编译其他版本的 Chromium 一样编译 iOS 版本的 Chromium。 由于 Chrome for iOS 的所有测试都可供整个 Chromium 社区使用，并且在签入代码时自动运行，因此开发速度也更快了。

https://blog.chromium.org/2017/01/open-sourcing-chrome-on-ios.html

第一步大？ :]

但这并不意味着什么，因为铬是不允许放在苹果商店的。

但在 android 中，现在非常需要它。

使用 cordova 和默认 webview 进行开发是地狱，英特尔已经废弃 Crosswalk，这是英特尔的 chromium webview 端口作为 android 的默认 webview。
https://crosswalk-project.org/blog/crosswalk-final-release.html

问题：

• 由于不同的供应商做不同的事情，默认的 webview 不可靠。直到 android 6.0 才稳定，只有 20% 的手机使用。
• 不是每个人都在做 android 固件或软件包更新，尤其是在 3G 昂贵的带宽受限区域。

我们能做的：

• 电子 API 无法移植到 chrome（正如@zcbenz在 2014 年所说）
• chromuim for android 和 chromium webview for android 现在完全开源： https ://www.chromium.org/developers/how-tos/android-build-instructions
• 我们可以分叉并继续维护人行横道（这基本上是 chromium 到 android 的端口，限制较少） https://github.com/crosswalk-project ，它已经很稳定了。
• 我们的经验表明，具有良好 JS 框架的 crosswalk 和 cordova 可以提供接近原生的性能（Emberjs / React / Angular /Vue）。
  https://github.com/crosswalk-project/cordova-plugin-crosswalk-webview

我们需要 crosswalk 的贡献者和维护者，这可能是您正在寻找的人。

好消息

相关新闻， @orangemocha将 Node.js 新移植到 iOS http://www.janeasystems.com/blog/node-js-meets-ios/

所以唯一需要做的就是确保移动浏览器支持电子如果通过@mikeal发布的链接进行模拟？

现在在 iOS 上发布其他 JS VM 是否合法？ 还是苹果仍然要求你使用他们的？

@trusktr运送不生成可执行代码的虚拟机并不违反应用商店指南。 我们之前已经在应用商店中获得过这样的应用（虽然使用的是 SpiderMonkey 而不是 ChakraCore）。

我们可以重新打开这个 issue 来继续讨论 electron 未来是否会有支持的移动框架？

我支持这个。 需要做什么？ 我很高兴开始测试或破解这个小方向。

@OtterCode创建一个名为 electron-mobile 的存储库并开始在那里进行黑客攻击是否有意义？ 我可以看到规划和准备示例应用程序的必要步骤，以便开始弄清楚需要做什么。 是否有更高级别的电子 API 库，我们可以模拟以开始使用？ （API 文档、构建目标等）

@OtterCode和我创建的任何感兴趣的人， https://github.com/gabrielcsapo/electron-mobile ，如果有人感兴趣，我可以将您添加为所有者，我们可以开始为 iOS 和 Android 构建前进的道路电子的目标。

三星Dex等产品， http://www.samsung.com/global/galaxy/apps/samsung-dex/
将此作为 IMO 可行的请求（至少对于 Android 而言）。

这绝对是非常可行的。 例如，来自 Google Play 的应用程序“Termux”在应用程序中为我们提供了一个完整的基于 Debian 的终端。 我们可以apt-get install任何我们需要的东西（Node、Vim、Git 等，只要我们安装的东西支持设备的 CPU 架构）。 完全有可能让 Electron 在自己的应用沙盒环境中运行，类似于 Termux。

Termux 无需 root 手机即可工作，它将所有内容安装在应用程序沙箱中，我们甚至可以将外部存储符号链接到 Termux 中的“主文件夹”，并使用 Termux 提供的所有命令行工具在外部存储中工作。

我们可以在浏览器中打开 Node.js 应用程序，在本地主机上，直接在 Termux 中提供服务。

它绝对可以用 Electron 做这样的事情。

我真的希望这会发生，我在之前的项目中使用了 ElectronJS，这是一个独立的基于桌面的计算机化系统。 Electron 非常棒，现在一家公司想雇用我，他们想创建移动应用程序，他们正在考虑使用 PhoneGap，因为他们不想承担不同平台（iOS/Android）的多个团队的麻烦，有一个万能的解决方案是非常棒的，我希望 ElectronJS 可以有一个支持移动的版本，这样我就不必在不同的平台和语言之间切换，有时真的很累。

react-native 不是这个问题的永久解决方案

@aprilmintacpineda您是否已经研究过渐进式 Web 应用程序？ https://developers.google.com/web/progressive-web-apps/

@Serkan-devel 是的，我有，当我在这里看到这个问题时，我不知道渐进式网络应用程序。 我决定改用 react-native。

@aprilmintacpineda你仍然可以尝试 PWA， https: //youtube.com/watch?v=vhg01Ml-8pI。 它在桌面上也有帮助

如何将nodejs-mobile与Chromium集成？ 这似乎是在浏览器环境中将 Node 带入移动设备的最接近的解决方案，类似于 Electron 为桌面所做的。

（我知道PWA 今天能做什么，还有 Cordova 等框架可以将 Web 应用程序包装到移动应用程序中，但 PWA 无法访问 OS 级别的文件系统或嵌入 HTTP 服务器，而 Cordova 只是一个矫枉过正对于我当前的项目，更不用说 Android 和 iOS 的设置和构建过程。）

一个可分发的集成了 Node 的移动浏览器包将使开发变得像使用 Electron 开发桌面应用程序一样简单，我相信这就是使 Electron 如此受欢迎的原因。 许多代码也可以重用，而不是为移动设备编写完全不同的代码。

我是一名 Web 开发人员，在构建系统/本机应用程序方面没有专业知识，更不用说将复杂的浏览器与 Node 集成，所以任何指针都将不胜感激。 如果您有专业知识并想帮助创建这样的项目，我们非常欢迎您做出贡献。

虽然这是可能实现的，但我认为如果我们真的应该这样做，我们应该三思而后行。 在我使用电子的桌面应用程序上，我遇到了延迟，尤其是 css 动画。 如果有原生选项，我宁愿选择原生，原生有很多东西可以提供。 或者也许试试 PWA。 它很棒，但还不能替代应用程序，但我认为它有一个美好的未来。

标记

https://github.com/dna2github/dna2oslab

可以在android上运行良好的nodejs

它不完全像 Electron，但对于任何想要使用 Node.js 构建 Android 应用程序的人来说，这个库似乎在我的测试中运行良好。