android添加减少组件_减少组件的痛苦

android添加减少组件

2010 update: Lo, the Web Performance Advent Calendar hath moved

2010年更新： Lo， Web Performance Advent Calendar已移动

Dec 6 This is the sixth in the series of performance articles as part of my 2009 performance advent calendar experiment. Stay tuned for the next articles.

12月6日，这是我的2009年性能出现日历实验一部分的系列性能文章中的第六篇。 请继续关注下一篇文章。

Last night I talked about the benefits of reducing the number of page components and the resulting elimination of HTTP overhead. A little carried away into making the case (because, surprisingly, I still meet people that are not convinced about the benefits) I didn't talk about some of the drawbacks and pain points associated with reducing the number of components. Kyle Simpson posted a comment reminding that it's not all roses (also see his blog post).

昨晚，我谈到了减少页面组件数量以及消除HTTP开销的好处。 做出了一点点努力(因为令人惊讶的是，我仍然遇到不相信其好处的人)，我没有谈论与减少组件数量相关的一些缺点和痛点。 凯尔·辛普森(Kyle Simpson)发表评论，提醒人们，玫瑰并非全部都是玫瑰(也请参阅他的博客文章)。

关于弊端 (On drawbacks)

A lot of the activities related to performance optimization have drawbacks associated with them. That's the nature of the game. Rarely an improvement is a clear win. Usually you need to sacrifice something - be it development time, maintainability, browser support, standards compliance (reluctantly), accessibility (never!). It's up to the team to decide where to draw the line. My personal favorite type of optimizations are those that (for example image optimization) are taken care of automatically, by a build process, offline (as opposed to runtime), at the stage right before deployment. But this also has drawbacks - you need to setup the build process to begin with, a build process that doesn't introduce errors, doesn't require more testing, is easy and friendly to use, doesn't take forever and so on.

与性能优化有关的许多活动都有与之相关的缺点。 这就是游戏的本质。 很少有进步是明显的胜利。 通常，您需要牺牲一些东西-开发时间，可维护性，浏览器支持，标准合规性(勉强)，可访问性(从不！)。 由团队决定在哪里划界线。 我个人最喜欢的优化类型是那些在部署之前的阶段由构建过程自动脱机(而不是运行时)处理的优化(例如，图像优化)。 但这也有缺点-您需要首先设置构建过程，该构建过程不会引入错误，不需要进行更多的测试，易于使用且友好，不会花很长时间等等。

So, drawbacks.

所以，缺点。

Here's how Jerome K. Jerome jokes about trade-offs in his Three Men in a Boat:

这里的杰罗姆K.杰罗姆如何开玩笑说他的取舍三人在船上：

"...everything has its drawbacks, as the man said when his mother-in-law died, and they came upon him for the funeral expenses"

“……一切都有其弊端，正如该名男子在其岳母去世时所说的那样，他们为了葬礼而来找他。”

It's never easy, is it?

从来都不容易，是吗？

结合产生原子成分 (Combining creates atomic components)

Say you merge three JavaScript files - 1.js, 2.js and 3.js to create all.js. A few days later you change 2.js. This invalidates all the cached versions of all.js that existing users have in their browser cache. You need to create a new bundle, say all20091206.js. Then a few more days pass and you fix a bug in 3.js. Again, you need a new bundle. Than the library (1.js) comes up with a new verison and you upgrade - yet another bundle.

假设您合并三个JavaScript文件-1.js，2.js和3.js以创建all.js。 几天后，您更改了2.js。 这会使现有用户在其浏览器缓存中拥有的all.js的所有缓存版本无效。 您需要创建一个新的捆绑包，例如all20091206.js。 然后又过了几天，您修复了3.js中的错误。 同样，您需要一个新的捆绑包。 比库(1.js)带有新版本，您可以升级-另一个捆绑包。

While first-time visitors benefit from the fewer requests, repeating visitors don't take much advantage of the cache with such frequent updates. In optimization we also say - set the expiration date in far future, but what's the point if you're going to change the component every other day.

虽然初次访问者会从较少的请求中受益，但重复访问者并不会在如此频繁的更新中充分利用缓存。 在优化中，我们还说-设置了很长的失效日期，但是如果您每隔一天要更换一次组件，那有什么意义呢？

One way to deal with this is organizational - set up a release schedule. You don't push that new feature today when you know that the library update is coming up tomorrow. Queue the changes and roll them out in batches (could be pre-defined intervals). This is important in larger organizations where more than one team may touch parts of the bundled components and push out the whole uber-component.

解决此问题的一种方法是组织化-设置发布时间表。 当您知道明天将要更新库时，今天就不要使用该新功能。 将更改排队，然后分批推出(可以是预定义的时间间隔)。 这在大型组织中很重要，在大型组织中，一个以上的团队可能会接触捆绑组件的一部分并推出整个超级组件。

Another way is to identify which files change relatively often and put the movable parts in a separate bundle. This way you end up with one core, slow moving component and one that changes quickly. When you change it, you at least don't invalidate the core.

另一种方法是识别哪些文件相对频繁地更改，然后将可移动部分放在单独的包中。 这样，您最终获得了一个核心，运行缓慢的组件和一个变化Swift的组件。 更改它时，至少不要使核心失效。

But in order to make such a call you need to measure and analyze. And answer the two questions:

但是，要发出这样的电话，您需要进行测量和分析。 并回答两个问题：

1. How many repeat visits do I have? Forums and online communities are more sticky for example. Other sites may be surprised how few visitors come with full cache.

   我有多少次重复访问？ 例如，论坛和在线社区更具粘性。 其他站点可能会感到惊讶，很少有访问者来使用完整的缓存。

2. Which files to put in the changing bundle? Sure not all change at the same rate. Also the rate of changes also changes. e.g. a new feature matures and has less bugs, therefore requires less updates. When do I move a piece of new code into the slow-to-change core?
   哪些文件放入更改包中？ 确保并非所有变更都以相同的速度进行。 变化率也变化。 例如，一项新功能已成熟并且具有较少的错误，因此需要较少的更新。 我什么时候应该将一段新代码移入变化缓慢的内核？

Facebook have gone a pretty scientific in this regard. David Wei And Changhao Jiang presented their system for monitoring the usage of the site and adaptively bundling features together. They show how they have (slide 26) total of 6 megs JS and 2 megs CSS. Merging all of that into one atomic component is unthinkable, so more intelligent methods are a must.

在这方面，Facebook已经变得相当科学。 David Wei和Changchang Jiang介绍了他们的系统，用于监视站点的使用情况并自适应地捆绑功能。 他们展示了如何(幻灯片26)总共有6兆JS和2兆CSS。 将所有这些合并到一个原子组件中是不可想象的，因此必须使用更智能的方法。

So the third way is to follow common user paths across the pages visited in a session and bundle together the files that the user is likely to need in his/her pattern of site navigation.

因此，第三种方法是在会话中访问的页面上遵循通用的用户路径，并将用户在其网站导航模式中可能需要的文件捆绑在一起。

Yet another way to combine stuff is to have pre- and postload bundles. One has the bare minimum to get the user interacting with the page, the other has more of the bells and whistles.

组合内容的另一种方法是具有预加载和后加载包。 一个具有使用户与页面交互的最低限度，另一个具有更多的风吹草动。

In summary, the atomic components create challenges of their own. That shouldn't be used as an excuse though. As you see, there are ways.

总而言之，原子成分会带来自身的挑战。 但是，这不应作为借口。 如您所见，有很多方法。

原子束和个人项目 (Atomic bundles and personal projects)

I doubt that the options above are really ever going to work for a personal project or a blog though. We're lazy people and since the site ain't broken... why fix it?

我怀疑上面的选项是否真的可以用于个人项目或博客。 我们很懒惰，既然网站没有损坏，为什么要修复它？

A personal project usually gets us excited initially and then the interest fades away for an extended period of time. If you don't change something now while you're into the project, then changes happen less often as the time passes. (You also forget how the code works and are reluctant to touch/break it)

个人项目通常会使我们最初感到兴奋，然后很长一段时间内，这种兴趣就消失了。 如果您现在不打算在项目中进行任何更改，那么更改会随着时间的流逝而减少。 (您也忘记了代码的工作方式，也不愿触摸/破坏它)

A good strategy to optimize a personal project is to come back to it a week of two after a major update. Things are still fresh in your head, but if you haven't changed anything in two weeks, you probably won't touch it for another year. So 'tis the time for a one-off little project - turn on gzipping, minify CSS and JS (which otherwise you changed much too often a week ago), combine components.

优化个人项目的一个好的策略是在进行重大更新后的两个星期内恢复到该项目。 事情仍然在您的脑海中浮现，但是如果您在两周内没有做出任何更改，那么您可能再一年都不会碰它。 因此，这是一个一次性的小项目的时间-打开gzipping，最小化CSS和JS(否则一周前您经常更改的次数)，合并组件。

Post-launch one-off optimization sprints don't work in bigger organizations and projects, but they can be a "cost"-effective way to optimize a small, personal site.

发布后的一次性优化冲刺在较大的组织和项目中不起作用，但是它们可以成为优化小型个人站点的“节省成本”方法。

合并组件是额外的步骤 (Merging components is an extra step)

Scenario 1: why merge now when in the p.m. I'll work that thing again? Scenario 2: I have to move to another task in the p.m. and I barely have the time to fix this bug before lunch, let alone to combine components and stuff.

方案1：为什么现在要合并，当我在下午再次处理该东西时？ 方案2：我必须在下午进行另一项工作，而且我几乎没有时间在午餐前修复此错误，更不用说将组件和东西组合在一起了。

Merging components is boring, there's nothing particularly challenging to it. How hard could it be?

合并组件很无聊，没有什么特别的挑战。 它能有多难？

$ cat 1.js 2.js 3.js > all.js

And it's an extra step.

这是一个额外的步骤。

Any extra work you introduce, any extra step has a great chance of being skipped. That gradually forgotten.

您介绍的任何额外工作，任何额外步骤都很有可能被跳过。 那逐渐被遗忘了。

That's why there are two options for the optimizations:

这就是为什么有两个优化选项的原因：

1. Make them easy to do. Otherwise no one's going to do it.
   使它们易于执行。 否则，没人会这样做。

2. Make them harder to not do it

   让他们很难不这样做

What I mean is for example take the few minutes to create a script for this new project or feature. The script minifies, combines and pushes to the server. All that with one command line. And especially if you do it several times a day, you can keep one console open and just hit ARROW UP + ENTER to repeat the command after you're done with a change. Two keyboard strokes sure beats opening up an ftp program, logging in, navigating your HDD, navigating the server... tens of clicks easily.

例如，我的意思是花几分钟时间为此新项目或功能创建脚本。 该脚本将最小化，合并并推送到服务器。 所有这些仅需一个命令行。 特别是如果您一天执行几次，则可以使一个控制台保持打开状态，并在完成更改后按ARROW UP + ENTER重复该命令。 敲击两个键盘肯定能打败ftp程序，登录，浏览HDD，浏览服务器……轻松点击数十下。

To summarize: it's best not to underestimate the laziness, we shouldn't ignore the fact that we're lazy, but embrace it. Make the right thing easy and the wrong thing hard.

总结一下：最好不要小看懒惰，我们不应该忽略我们懒惰的事实，而应该拥抱它。 使正确的事情变得容易而错误的事情变得困难。

运行时合并 (Run-time merging)

It's best to keep the static components static. Static is simple, static is fast. But sometimes in the interest of merging, minification and so on in a very dynamic (or technically lacking) environment, you may resort to dynamic file bundling. Sometimes also the little pieces can be merged in so many combinations that dynamic components make sense.

最好使静态组件保持静态。 静态简单，静态快速。 但是有时为了在一个非常动态(或技术上缺乏)的环境中进行合并，缩小等操作，您可能会求助于动态文件捆绑。 有时，这些小片段也可以合并成如此多的组合，以使动态组件有意义。

Take for example the combo handler script used by YUI. You have a combo script at: http://yui.yahooapis.com/combo which simply takes a list of files to merge, finds them on the disk and spits them out with the correct Expires header.

以YUI使用的组合处理程序脚本为例。 您在以下位置有一个combo脚本：http://yui.yahooapis.com/combo，该脚本只获取要合并的文件列表，在磁盘上找到它们，然后使用正确的Expires标头将其吐出。

For example here's a URL produced by the dependency configurator:

例如，这是依赖性配置器生成的URL：

http://yui.yahooapis.com/combo?3.0.0/build/yui/yui-min.js&3.0.0/build/oop/oop-min.js&3.0.0/build/event-custom/event-custom-min.js&3.0.0/build/attribute/attribute-base-min.js&3.0.0/build/base/base-base-min.js

http://yui.yahooapis.com/combo ? 3.0.0/build/yui/yui-min.js & 3.0.0/build/oop/oop-min.js & 3.0.0/build/event-custom/event-custom-min.js & 3.0.0/build/attribute/attribute-base-min.js & 3.0.0/build/base/base-base-min.js

The little pieces that make up the YUI library can be combined in so many ways that pre-merging all possible bundles is not an option.

组成YUI库的小片段可以以多种方式组合，以致无法预合并所有可能的捆绑包。

As part of YUI3, there was a PHP loader recently released which you can use to host your own combo solution - doesn't have to do anything with YUI. Or you can roll your own combo script, how hard could be to have a script that merges a number of files. Check Ed Eliot's script for inspiration/borrowing.

作为YUI3的一部分，最近发布了一个PHP加载程序，您可以使用它来承载您自己的组合解决方案-无需对YUI做任何事情。 或者，您也可以滚动自己的组合脚本，以使脚本具有合并多个文件的难度。 检查Ed Eliot的脚本以获取灵感/借鉴。

SmartOptimizer is another open source project that you can use for comboing, minification and so on.

SmartOptimizer是另一个开源项目，可用于组合，缩小等。

If you do create your own combo script, don't forget to store the merged results in disk cache directory, so you don't have to re-merge the same bundles over and over.

如果您确实创建了自己的组合脚本，请不要忘记将合并的结果存储在磁盘缓存目录中，因此不必一遍又一遍地重新合并相同的捆绑软件。

CSS精灵很痛苦 (CSS sprites are a pain)

While combining text source files like CSS and JS is fairly trivial, creating sprites is a pain. Not only you have to create the image, but them get the coordinates and write the CSS rules. Then when an element in the sprite changes, it may affect the others and you may have to move them around, then update the CSS. Luckily there are tools.

虽然将CSS和JS之类的文本源文件组合起来非常简单，但是创建精灵却很麻烦。 不仅您必须创建图像，而且它们还可以获取坐标并编写CSS规则。 然后，当精灵中的某个元素发生更改时，它可能会影响其他元素，您可能需要四处移动它们，然后更新CSS。 幸运的是有工具。

Here are some tools and resources that should help with the sprites. CSS sprites are an excellent way to reduce HTTP components, especially when it comes to tiny icons, those that are sometimes smaller than the HTTP request/response headers needed to download them. It's a technique that is still underused.

这里有一些应该帮助精灵的工具和资源。 CSS Sprites是减少HTTP组件的一种极好的方法，尤其是在涉及微小图标时，这些图标有时小于下载它们所需的HTTP请求/响应标头。 这是一种尚未得到充分利用的技术。

• Intro to CSS sprites by Chris Coyier, includes a how-to for the SpriteMe tool

  Chris CoyierCSS Sprite简介，包括SpriteMe工具的使用方法

• SpriteMe - bookmarklet tool by Steve Souders

  SpriteMe -Steve Souders的书签工具

• Cool runnings - the sprite generation service behind spriteme.org

  出色的运行-spriteme.org背后的sprite生成服务

• SpriteGen - sprite generation tool

  SpriteGen-精灵生成工具

• SmartSprites is an interesting project - a downloadable tool that looks for specific instructions you leave in your normal CSS file

  SmartSprites是一个有趣的项目-一个可下载的工具，可查找您留在普通CSS文件中的特定指令

• Spritr - another online tool

  Spritr-另一个在线工具

And now, re-introducing CSSSprites.com 🙂

现在，重新引入CSSSprites.com🙂

CSSSprites.com (CSSSprites.com)

CSSSprites.com is a fun weekend project I did two and a half years ago. Back then I was even more convinced that this technique is wildly underused, still considered unstable by many people, although it was fearlessly in use by prominent sites such as yahoo.com. There was also a bit of lack of understanding how to build sprites and also, just like today, it's just a pain to create them.

CSSSprites.com是我两年半前做的一个有趣的周末项目。 那时，我甚至更加坚信，尽管该技术已被yahoo.com等著名网站毫不畏惧地使用，但仍未被广泛使用，仍然被许多人认为是不稳定的。 也有些缺乏对如何构建精灵的理解，就像今天一样，创建它们也很痛苦。

So I wanted to raise awareness of the technique by creating an online tool for sprites generation, probably the first tool (which explains why I was able to get such a domain name). The idea was just to let people know that this technique exists, it's not rocket science and you can start quickly by using the tool. The tool was actually quite ugly and I posted a comment on css-tricks.com asking if anyone wants to contribute a skin.

因此，我想通过创建一个用于生成精灵的在线工具(可能是第一个工具)来提高对该技术的认识(这说明了为什么我能够获得这样的域名)。 这个想法只是让人们知道这种技术的存在，而不是火箭科学，您可以使用该工具快速入门。 该工具实际上很丑陋，我在css-tricks.com上发表了评论，询问是否有人要做出皮肤。

CSSSprites.com: BEFORE

CSSSprites.com：之前

CSSSprites.com: AFTER

CSSSprites.com：之后

Luckily, Chris Coyier who runs css-tricks.com responded and sent me a skin. It was exactly 2 years minus 2 days ago.

幸运的是，运行css-tricks.com的Chris Coyier做出了回应，并给了我一张皮肤。 恰好是2年减去2天前。

(I remember January 2nd 2008 right after new year's, I was writing a list of things I want to accomplish in 2008. It was a list of unfinished projects actually. I decided I was sick of not finishing projects so 2008 would be the year of completion. I wasn't going to start anything new until I finish all abandoned projects. Needless to say, as all new year resolutions, it didn't work. I actually started something pretty cool and at the same time never finished csssprites.com with Chris' skin)

(我记得新年刚过，2008年1月2日，我写了一份我要在2008年完成的事情的清单。实际上，这是一份未完成的项目的清单。我认为我讨厌不完成项目，所以2008年将是完成，我不会，直到我完成所有被遗弃的项目，新的开始什么。不用说，所有新的一年的决议，也没有工作，我真正开始的东西很冷静，并在同一时间没有完成csssprites.com克里斯的皮肤)

So today, after two years of procrastination, I sat down and updated the site. Additional kick in the behind was that few days ago I had to take the site down, because the exceptionally reliable host site5.com in their care for the well being of the sites on the shared hosting, shut down all my sites, including this blog, because csssprites.com was consuming too much resources. I had to take it down. Today it's proudly back up hosted by dreamhost, the all-hero host that survived the smush.it explosion.

所以今天，经过两年的拖延，我坐下来更新了网站。 后面的另一个问题是几天前我不得不关闭该网站，因为异常可靠的主机site5.com为了维护共享主机上站点的正常运行，请关闭我的所有站点，包括该博客，因为csssprites.com正在消耗过多资源。 我不得不把它取下来。 今天，它由Dreamhost托管，它是在smush.it爆炸中幸存下来的全英雄主机，对此感到自豪。

What's new in the tool?

该工具有什么新功能？

• nicer skin!

  皮肤更好！

• the old "skin" is sill available

  旧的“皮肤”可用

• some options - padding between sprite elements, background color, border size, choice of top vs. left alignment of the elements
  一些选项-Sprite元素之间的填充，背景色，边框大小，元素顶部与左侧对齐的选择
• no more gifs are being generated
  不再生成GIF
• the generated PNG is optimized with pngout and pngcrush
  生成的PNG使用pngout和pngcrush进行了优化
• upgrade to YUI3
  升级到YUI3

So give it a spin and comment with any problems/wishes and so on. I haven't posted the code yet, it's not in a presentable statge, plus the "core" of it, the generation of the sprite image, is already out there.

因此，试一下它，并对任何问题/希望等发表评论。 我还没有发布代码，它不在适当的状态中，而且它的“核心”即精灵图像的生成已经在那里。

那是所有人 (That's all folks)

When I talked about optimizing personal project above, I had in mind sites like csssprites.com. Currently it's not optimized at all - it's a sprites tool that doesn't use sprites. But that's because I only worked one evening on it and it's probably broken here and there. I intend to revise it in a few weeks when it stabilizes.

当我在上面谈论优化个人项目时，我想到了csssprites.com之类的网站。 目前，它根本没有进行优化-这是一个不使用精灵的精灵工具。 但这是因为我只在其中工作了一个晚上，而且它可能在这里和那里都坏了。 我打算在几周内稳定下来进行修改。

So, parting words - combining components into atomic dowanloads is not without drawbacks, just like most other performance optimizations. But this doesn't mean we shouldn't do it. Care and analysing users' behavior is a way to optimize the process of optimizing but meanwhile just go with your feeling and look at the metrics to see if you were right. Rinse, repeat. When in doubt - err on the side of less HTTP requests.

因此，与大多数其他性能优化一样，分词-将组件组合到原子下载中并非没有缺点。 但这并不意味着我们不应该这样做。 关心和分析用户的行为是优化过程的一种方法，但与此同时，您可以根据自己的感受并查看指标以查看是否正确。 冲洗，重复。 如有疑问，请减少HTTP请求的数量。

Tell your friends about this post on Facebook and Twitter

在Facebook和Twitter上告诉您的朋友有关此帖子的信息

翻译自: https://www.phpied.com/the-pain-points-of-having-fewer-components/

android添加减少组件