javascript是widgets应用的瓶颈吗?

关注

原创最新推荐文章于 2026-10-13 18:30:00 发布 409 阅读 AI 写同款· GEO 优化 ›

QtWebEngine性能优化实战：解决WebGL卡顿与渲染瓶颈在桌面应用开发中，图形渲染性能是影响用户体验的关键因素。QtWebEngine作为基于Chromium的浏览器引擎，其底层通过Blink渲染引擎和Skia图形库处理网页内容，并借助ANGLE层实现OpenGL ES到DirectX的转换以支持GPU加速。这一技术架构在复杂WebGL可视化场景下可能面临转换开销、驱动兼容性和进程间通信等性能瓶颈。从工程实践角度，开发者需要掌握从环境诊断到代码优化的全链路调优方法，包括使用Chromium Tracing进行性能分析、调整图形后端参数、优化WebGL绘制调用以及阅读详情

　　在过去的一年或者现在，互联网已经显示出，因widgets的使用而呈现爆炸式趋势。widget如今已是大行其道，当然也少不了“2007年将是widget年”这样的呼声。

　　随着网络的发展，blogger数量飞速增长，很多blogger都很关注自己blog的美化，在这种需求下面，出现了很多提供wdgets服务的网站，只要把相应的widgets代码插入blog相应位置，就可以得到漂亮的效果。

　　在物理学上有种现象叫非线性振动。当不同的力量相互作用时，其结果并非线性的进行叠加，而是难以预测。而这在软件行业也不例外——当将许多的组件放堆在一块的时候，最后连自己都弄不明白到底想要做什么了。在blog上，加载了许多widgets的页面，每个组件都是独立的运作，以达到充分的吸引浏览者的目的。然而，结果往往是，这种看似丰富而其实是杂乱无章的东西，不但让浏览者很厌恶，同时，使blogger也是疲于维护与整理，最后大家都失望。

二、 bloggers——受害者

一个互联网widget最值得描述的，就是迷你式（傻瓜式）的应用程序，将功能添加到网页、blog等。如果喜欢某一个widget，只要简单的复制和粘贴代码到网页的html程序内，相片的列表、新闻、视频、广告、mp3播放器以及丰富的计数器等就会出在页面相关的位置！还可以对它进行命名。

widgets宣称可以使网站更加的漂亮化。而对于追求开放与个性化的blogger而言，这无疑是天大的福音。于是blogger们纷纷在自己的blog上加上了许多漂亮的wedgets，如flicker，twitter，sphere等等。如下所示：

请将下面的html代码复制到您的页面中：请注意，为了保证即使twitter.com没有加载的情况下不影响您的页面加载，请从第二行开始复制，即从<script type=”text/javascript”…>开始，复制到页面的底部，在</body>中上。

图1.在blog上加载widgets的代码示意图

如果对html及blogging平台有一定了解的话，在blog中加入widgets是件很容易的事情。只需要将html代码复制到相关网页的代码中去。有些时候，需要将代码插入到html文档的头部，但这并没有难度。此外，还可以利用一些辅助工具进行安装widgets，如可以采用widgetbox平台来进行辅助安装。

安装widgets是如此的简单，于是blogger们纷纷来者不拒，让widgets在自己的blog中遍地开花。然而否极泰来，乐极生悲，这常常导致页面加载的时候加长，会降低网站速度。在比较好的情况下，使用的widgets 来自一个稳定快速的服务器；比较糟糕的是你使用的 widgets 来自一个不稳定的服务器，那对网站的影响就会很大。不管是上面两种情况的那一种，完成网站的加载和渲染都取决于第三方服务器上的代码运行速度，即使是一个成熟稳定的widgets，它也需要时间来反应，这仍然会造成网站加载速度的减慢。

三、 javascript widgets

实现widgets的主流技术有flash和javascript。flah widgets有它自身的问题。例如感觉很笨重，大小不可改变及不能操作dom模型。当然，这并不是仅仅flash widgets的缺陷，javascript widgets也难以脱俗。

大多数使用widgets 的方式有两种：raw 式嵌入或 javascript 式嵌入。

raw 式嵌入通常是提供一个 object/embed 代码，来直接实现一个 flash widget，这种方法的优点是它可以在不允许使用 javascript 式嵌入的网站上运行；缺点是：许多人不喜欢把 object/embed 代码直接放在他们的页面上；另外有些widgets 不是基于flash 的；最后widgets 的作者不能对已嵌入的widgets 进行太大修改变化。

javascript 式嵌入使用了脚本，包括远程部署代码进入用户的网站，优点是：它更简洁也更灵活，它的缺点是：它或多或少的增加了网站加载时间，而且一旦出现问题，网站加载时间将成倍的增加。

javascript从一开始就被设计成一种轻量级的便于操作html文档但互操作性最小化的客户端语言。但从以往技术发展的曲线来看，javascript正在向一种web编程语言发展。从ajax到widgets，javascript被应用到许多它所适应范围边际上的项目中去。由于，问题就开始出现了。

程序员对javascript最大的诟病莫过于它的单线程模式。javascript里是没有线程的，当然你可以尝使用settimeout来试试（这个函数的功能是延时执行某一个函数）。但这并不是真正意见上的多线程。这意味着javascript中的代码只能是顺序的执行，没有并发性（当然除了ajax调用之外）。于是，当任何时候，一段javascript代码片段在加载或执行的时候，其它什么事情都干不了。这和下图所示的现象是不是一样呢？

图 2.javascript 中的“单线程”

这意味着，一行行额外加载的javascript代码往往导致整个页面加载速度的降低。而这正是在blog社区正在发生着的问题。那办法或是解决出路在哪呢？

四、 javascript widgets能加速吗？

遗憾的是，世上并没有通万病的解药。至今还没在给javascript widgets加速的简单而快速的方法。但是一些组织或公司正在尝试使用一些复合的技术来对加快页面的加载速度。但旧问题还没解决，这种混合的技术又带来了新的问题，可谓一物生一物，雪上加霜。但javascript作为客户编程的一种主流及主要的技术，在必要从行业或是领域的角度来考虑解决这一问题的办法。下面是一些javascript设计们似乎应该考虑的若干建义及设想：

（1） javascript区分执行

经常碰到的一个问题是所有的javascript都想立即运行，独木桥人人想过。那么，我们是不是可以这么设计，在页面加载的时候，对那些不怎么改变页面的javascript代码，是不是可以等到页面最终加载完后最执行呢？这样，页面的可见内容就可以快速出来。但遗憾的是，所有的浏览器都没在这样实现。

（2）最小化加载时的代码

众所周知，任何页面加载时运行的代码都会降低页面的展现速度。加载时运行的代码越小，页面就越快速出来。而另一个相关的问题是，在整个页面查找某些内容。这往往容易导致无回应脚本对话框的出现，任何javascript代码运行超过几秒钟(如5秒)就会发生这种错误。而使用timouts来将很长的javascript代码分开执行，也许是一条不二的选择，当然人人认为这样做也会很痛苦。

（3）采用不同的urls来平衡请求

在比较好的情况下，你使用的widgets 来自一个稳定快速的服务器；比较糟糕的是你使用的widgets 来自一个不稳定的服务器，那对你的网站的影响就会很大。一些widgets一般都给出相同的url，如 www.mycoolwidget.com。当许多的请求者对同一台widgets服务器并发请求时，服务器的负载就成了问题。最好的办法是给出不同的urls，例如，server1.mycoolwidget.com, server2.mycoolwidget.com等。虽然他们还是指向同一个域，但长远来看，这无疑是一个化解拥挤的好办法。

（4）使用标准类库

在软件行业最痛苦的事情莫过于重复发明轮子。因为javascript很容易出错，而又不像java那样提供丰富的类库，但是像prototype 以其高效性，正在成为标准类库。prototype 1.6刚发布了。prototype由于富在经验的javascript人员开发，因此此类库的价值非常高。

（5）容器化

如果不知道widgets谁将使用或会使用在哪，还在哪些其它的widgets已经安装了，如果没有这些信息，使用javascript变得比较困难。但javascript爱好者不用悲观，因为还在很多事情可以做。

如果我们看一看java 社区，这样类似的问题已经被解决了很多次了。真可谓是相见恨晚。大名鼎鼎的applets、servlets及企业级javabeans，其实这些东西和widgets相比，最大的区别在于，前者被一个容器来管理，而widgets没有。这就是问题的解决办法。

容器提供各种基础的服务及接口之间的通信。它负责处理加载、卸载、回调、单击、提示等内容，这些开发人员喜爱而非技术人员厌恶听到的东西。总的来说，javascript需要一个容器来将javascript的有序变成无序。

（6） wedje

提供一个raw 式嵌入还是必要的，因为不是每个网站都允许使用 javascript 式嵌入，但是如果widgets 是使用在人们自己网站或blog上，javascript 式嵌入仍然是一个更理想方法。所以，为了兼容这两种方式，设想一种新的方案：wedje（widget enabled dom javascript embedding）。

standard document.write：大多数的 javascript式嵌入是简单的使用 document.write 来把代码写入页面，问题是，如果widgets 服务器停了，其余网站就不能运行widgets 了，直到 javascript自己停止，很多人误以为可以对其使用延迟属性来防止这种事情的发生，但延迟属性完全阻止了 document.write ，所以它不是一个好的解决办法。

延迟 innerhtml 代码：另外一种javascript式嵌入的方法是加入帐号机制，增加一个延迟参数来加载javascript，在script 加载完后使用 innerhtml 来写入。这似乎很不错，但在实际中，不同的浏览器的效果都不同。

五、小结

在过去的一年或者现在，互联网已经显示出，因widgets的使用而呈现爆炸式状态。widget如今已是大行其道，也有很多关于“2007年将是widget年”的呼声。它首先对于网站（widget提供方）的推广是很有益处的，甚至可以说是不二的营销手段。widgets和javascript工具变得越来越酷及使用更方面时，想要变得更好时，却发现没有基本的基础性的东西来支撑。blog变得越来越慢了，这得归咎于越来越多的widgets和javascript的滥用。而要求blogger们理解各种widgets混合使用会导致的问题，这似乎超出了blogger们的心理防线。

此外，我们需要在发布widgets时，要求按一定标准和准则。最好的参照软件行业中已有的成功经验。java社区有很多成功且很值得借鉴的经验。