我知道这可能听起来很疯狂，但是听我说......
假设您有一款游戏，并且想要更新它（为季节性主题添加新功能/重新制作/添加LTM等）现在，而不是编辑您的代码，然后等待您的应用市场提供商（Google / Microsoft / Apple等）批准更新并推出更改，为什么不：
eval() s）这样，除非您想要更改与数据库相关的代码，否则不需要软件更新，您只需更新数据库即可更改应用程序在其生效时所执行的操作。
我的问题：为什么没有这样做？
例如：
Fortnite（真正的游戏）通常有LTM（限时模式），可以使用几周，然后删除。一般来说，软件更新大约为5GB，除非宽带速度快，否则需要花费大量时间。如果代码是从数据库中提取然后执行的，则不需要进行这些更新，并且更改可能是即时的。编辑 :(回应关闭投票）
我正在寻找事实和统计数据来支持原因，而不仅仅是纯粹的意见。像'我认为这将是好/坏......'的答案是不需要的（这就是为什么有评论）;答案就像是'这将是好的/坏的，因为这个事实表明......'更好，更理想。
答案 0 :(得分：0)
您建议的方法几乎没有挑战。
将所有内容放入数据库将增加db的大小。但这种做法影响很大。
如果db中存在所有代码，是否可以对软件进行反编译并获得连接代码的方法？
eval的性能开销太大。预编译代码针对各自的运行时进行了优化
多个版本？如果您想拥有多个版本的软件，该怎么办？
存在更新的主要原因是它们易于维护，灵活，并允许开发人员发布速度最快的优化工具。
答案 1 :(得分：0)
- 将所有代码放入数据库
- 从代码文件中删除所有现有代码
- 添加可以从数据库运行代码的代码（读入它和eval（）s）
我的问题：为什么没有这样做？
这正是每个游戏的运作方式。
每次启动游戏时，可执行二进制游戏引擎（您在步骤3中描述）已经从＆＃34;数据库＆＃34;中读取了其余代码（通常是一些嵌入式语言，如LUA）。 （文件系统）和＆＃34; evals＆＃34; （解释）它运行游戏，以及水平几何，纹理，声音和音乐等资产。
您正在谈论在引擎及其数据之间引入一层抽象（真实数据库）来隐藏您的一些资产，但数据库将其数据存储在文件系统上 ，所以你真的没有获得任何东西，你只是改变了数据在休息时编码的方式并在运行时查询，并在两种情况下都引入了 ton 的开销。 / p>
另一方面，您通过这种方式故意通过应用审核流程欺骗自己的方式，无论您遇到什么样的实际技术问题都没有实际意义，因为您的应用不会被允许进入应用商店。应用审核流程的全部内容是阻止用户向用户发送未经验证的未审核代码，如果您的程序显然是为了规避这一点，那么您的应用将被拒绝。
Fortnite（真正的游戏）通常有LTM（限时模式），可以使用几周，然后删除。一般来说，软件更新大约为5GB，除非宽带速度快，否则需要花费大量时间。
Fotenite将有一个小的二进制可执行文件，它是游戏引擎。对这个二进制文件的更新将占该5GB的一小部分。其余的将是某种解释/嵌入式语言，描述游戏的等级（也是一小部分），然后是其余部分（几何，纹理，声音，音乐）的资产。
如果代码是从数据库中提取然后执行的，则不需要进行这些更新，并且更改可能是即时的
这没有任何意义。如果将整个5GB从文件系统移动到数据库中，则仍需要传输大约5GB的数据库更新。数据库中的5GB数据仍然作为文件系统上的5GB数据存在，只是您无法再直接访问它。无论您如何存储，都必须围绕完全相同数量的数据进行转移。