使用 source-all 开发时 qooxdoo 运行缓慢
qooxdoo is slow to run when developing with source-all
运行时:
python generate.py source-all
我在我的应用程序中获取了所有库。这一切都很好。
运行应用程序时,qooxdoo 会单独加载所有 classes。
我想使用 qooxdoo 作为在线开发工具,最后只运行构建。此外,当在开发模式下同时运行服务器和客户端时,它在分别加载每个 class qooxdoo 时运行缓慢。
我可以改为包含 http://cdnjs.cloudflare.com/ajax/libs/qooxdoo/4.1/q.min.js 或服务器软件库文件夹中的本地副本,并且仅用于开发运行:
python generate.py source
使用 source-all 创建的构建分别加载每个 class、框架和应用程序 class 都是相似的 - 即它一个接一个地加载数百个框架 classes (上次我检查时,它还加载了应用程序代码未使用的框架 classes)。
作为解决方法,框架开发人员创建了作业源混合。这个与 source-all 一样工作,但创建并加载所有框架 classes 的串联,而不是每个 class 单独(我认为它也缩小了框架 classes) .使用 source-hybrid 而不是 source-all 应该会显着提高加载速度。
(如果框架开发人员能够向构建*作业添加一个选项以生成源映射,那就太好了。但目前生成器中还没有。)
首先我想澄清一下术语,因为我觉得问题有些含糊。
条款
Qooxdoo generator的执行单元是一个job,例如info 作业被调用为 ./generator.py info
。涉及依赖管理的作业(查找应用程序 class 如何依赖于来自应用程序、框架和第三方库的其他 classes)产生一个 target .目标可能包括原始 classes 原样(按完整路径)、构建部分(一组串联的 classes,可以优化,加上一些元数据和可选数据),或混合二。目标由网络浏览器通过 loader.
加载
源目标
源目标作业是用于开发(编写代码)的依赖管理手段。有3个这样的。
With the source job all the classes of the application are in their original source form, and their files are directly loaded from their original paths on the file system.
目标仅包含来自应用程序、框架和库的实际依赖项。所有 classes 按原样加载(数百个请求)。您甚至可能在某些浏览器中从 file://
加载它时遇到加载问题(例如,在等待 AUT 加载的时间不够长的测试运行程序中)。
source-all will include all known classes, be they part of your application, the qooxdoo framework, or any other qooxdoo library or contribution you might be using.
目标包括来自应用程序、框架和声明库的所有现有 classes。所有 classes 按原样加载(数百个请求,超过 source 作业)。加载问题比 source 作业更多。
source-hybrid
(which is default default-job
)
The source-hybrid job concatenates the contents of the classes that make up the application into a few files parts, only leaving your own application classes separate. Having the other class files (framework, libraries, contribs) chunked together you get the loading speed of nearly the build version, while at the same time retaining the accessibility of your own application files for debugging.
目标仅包含来自应用程序、框架和库的实际依赖项。所有非应用程序 classes 都连接成部分(一打或两个)。应用程序 class 按原样加载,其余部分从部分加载。提供最佳加载性能。
构建目标
只有一个构建目标作业,build
. However depending on configuration it can produce a single-file build or partial(多文件,通常是几个文件)构建。与源目标不同,构建目标的文件经过优化(缩小)并用于生产部署。
在线开发
有用于在线开发的示例应用程序,playground(SDK 中的application/playground
)。让我们从其 config.json
.
中查看相关工作
"playground-compile" :
{
"extend" : [ "libraries" ],
//...
"include" :
[
"${APPLICATION}.*",
"qx.*"
],
"exclude" :
[
"qx.test.*",
"qx.dev.unit.*",
//..
],
//...
},
"build-script" :
{
"extend" : [ "playground-compile" ],
//...
},
"source" :
{
"extend" : [ "playground-compile" ],
//...
}
正如您在上面看到的,对于这两个目标,所有 qooxdoo classes(测试和开发 classes 除外)都包含在内,因此您可以在 playground 片段中使用它们。一般来说是你的情况。其余的取决于您拥有的在线开发类型和您对它的要求。您可以将其基于 source-hybrid(更易于调试)或构建目标(加载速度更快)。您可能会混合一些自定义配置,将其基于 playground 的配置。
需要注意的一件重要事情是,如果您打算编写比 playground 代码片段复杂得多的代码,并以 class 相互依赖的代码实现,那么您将需要自己处理依赖管理(即以正确的顺序加载 classes)。如果您的 "online" 代码处理框架的子集,例如处理表格数据,则只包含子集是有意义的(例如 qx.ui.table.*
而不是 qx.*
)。供您参考,playground 的单文件构建目标是 2.1MB(~550kB gzipped)。
其他
q.min.js
是 qxWeb。它是 jQuery/jQueryUI-like 库。基本上,从应用程序开发的角度来看,qxWeb 与正常的 Qooxdoo 流程无关。
运行时:
python generate.py source-all
我在我的应用程序中获取了所有库。这一切都很好。
运行应用程序时,qooxdoo 会单独加载所有 classes。
我想使用 qooxdoo 作为在线开发工具,最后只运行构建。此外,当在开发模式下同时运行服务器和客户端时,它在分别加载每个 class qooxdoo 时运行缓慢。
我可以改为包含 http://cdnjs.cloudflare.com/ajax/libs/qooxdoo/4.1/q.min.js 或服务器软件库文件夹中的本地副本,并且仅用于开发运行:
python generate.py source
使用 source-all 创建的构建分别加载每个 class、框架和应用程序 class 都是相似的 - 即它一个接一个地加载数百个框架 classes (上次我检查时,它还加载了应用程序代码未使用的框架 classes)。
作为解决方法,框架开发人员创建了作业源混合。这个与 source-all 一样工作,但创建并加载所有框架 classes 的串联,而不是每个 class 单独(我认为它也缩小了框架 classes) .使用 source-hybrid 而不是 source-all 应该会显着提高加载速度。
(如果框架开发人员能够向构建*作业添加一个选项以生成源映射,那就太好了。但目前生成器中还没有。)
首先我想澄清一下术语,因为我觉得问题有些含糊。
条款
Qooxdoo generator的执行单元是一个job,例如info 作业被调用为 ./generator.py info
。涉及依赖管理的作业(查找应用程序 class 如何依赖于来自应用程序、框架和第三方库的其他 classes)产生一个 target .目标可能包括原始 classes 原样(按完整路径)、构建部分(一组串联的 classes,可以优化,加上一些元数据和可选数据),或混合二。目标由网络浏览器通过 loader.
源目标
源目标作业是用于开发(编写代码)的依赖管理手段。有3个这样的。
With the source job all the classes of the application are in their original source form, and their files are directly loaded from their original paths on the file system.
目标仅包含来自应用程序、框架和库的实际依赖项。所有 classes 按原样加载(数百个请求)。您甚至可能在某些浏览器中从 file://
加载它时遇到加载问题(例如,在等待 AUT 加载的时间不够长的测试运行程序中)。
source-all will include all known classes, be they part of your application, the qooxdoo framework, or any other qooxdoo library or contribution you might be using.
目标包括来自应用程序、框架和声明库的所有现有 classes。所有 classes 按原样加载(数百个请求,超过 source 作业)。加载问题比 source 作业更多。
source-hybrid
(which is default default-job
)
The source-hybrid job concatenates the contents of the classes that make up the application into a few
filesparts, only leaving your own application classes separate. Having the other class files (framework, libraries, contribs) chunked together you get the loading speed of nearly the build version, while at the same time retaining the accessibility of your own application files for debugging.
目标仅包含来自应用程序、框架和库的实际依赖项。所有非应用程序 classes 都连接成部分(一打或两个)。应用程序 class 按原样加载,其余部分从部分加载。提供最佳加载性能。
构建目标
只有一个构建目标作业,build
. However depending on configuration it can produce a single-file build or partial(多文件,通常是几个文件)构建。与源目标不同,构建目标的文件经过优化(缩小)并用于生产部署。
在线开发
有用于在线开发的示例应用程序,playground(SDK 中的application/playground
)。让我们从其 config.json
.
"playground-compile" :
{
"extend" : [ "libraries" ],
//...
"include" :
[
"${APPLICATION}.*",
"qx.*"
],
"exclude" :
[
"qx.test.*",
"qx.dev.unit.*",
//..
],
//...
},
"build-script" :
{
"extend" : [ "playground-compile" ],
//...
},
"source" :
{
"extend" : [ "playground-compile" ],
//...
}
正如您在上面看到的,对于这两个目标,所有 qooxdoo classes(测试和开发 classes 除外)都包含在内,因此您可以在 playground 片段中使用它们。一般来说是你的情况。其余的取决于您拥有的在线开发类型和您对它的要求。您可以将其基于 source-hybrid(更易于调试)或构建目标(加载速度更快)。您可能会混合一些自定义配置,将其基于 playground 的配置。
需要注意的一件重要事情是,如果您打算编写比 playground 代码片段复杂得多的代码,并以 class 相互依赖的代码实现,那么您将需要自己处理依赖管理(即以正确的顺序加载 classes)。如果您的 "online" 代码处理框架的子集,例如处理表格数据,则只包含子集是有意义的(例如 qx.ui.table.*
而不是 qx.*
)。供您参考,playground 的单文件构建目标是 2.1MB(~550kB gzipped)。
其他
q.min.js
是 qxWeb。它是 jQuery/jQueryUI-like 库。基本上,从应用程序开发的角度来看,qxWeb 与正常的 Qooxdoo 流程无关。