月度归档：2016年03月

减少GC开销的5个编码技巧

资料

来源：互联网

在 这篇文章中，我们来了解一下让代码变得高效的五种技巧，这些技巧可以使我们的垃圾收集器（GC）在分配内存以及释放内存上面，占用更少的CPU时间，减少 GC的开销。当内存被回收的时候，GC处理很长时间经常会导致我们的代码中断（又叫做"stop the world"）。

背景

GC用来处理大量的短期的对象的分配（试想打开一个web页面，一旦页面被加载之后，被分配内存的大部分对象都会被废弃）。

GC使用一个被称作"新生代"堆空间来完成这件事情。"新生代"是用来存放新建对象的堆内存。每一个对象都有一个"age"（存储在对象的头信息 中），用来定义存放很多没有被回收的垃圾集合。一旦一个确定的"age"到达，对象就会被复制到堆中的另一块空间，这个空间被称作"幸存者空间"或者"老 年代空间"。（译者注：实际上幸存者空间位于新生代空间中，原文有误，不过这里暂时按照原文来翻译，更详细的内容请点击成为JavaGC专家Part I - 深入浅出Java垃圾回收机制）

虽然这样很有效，但是还是有很大代价的。减少临时分配的数量确实可以帮助我们增加吞吐量，尤其是在大规模数据的环境下，或者资源有限制的app中。

下面的五种代码方式可以更加有效的利用内存，并且不需要花费很多的时间，也不会降低代码可读性。

1、避免隐式的String字符串

String字符串是我们管理的每一个数据结构中不可分割的一部分。它们在被分配好了之后不可以被修改。比如"+"操作就会分配一个链接两个字符串的新的字符串。更糟糕的是，这里分配了一个隐式的StringBuilder对象来链接两个String字符串。

例如：

a = a + b;// a and b are Strings

编译器在背后就会生成这样的一段儿代码：

StringBuilder temp =newStringBuilder(a).

temp.append(b);

a = temp.toString();// 一个新的 String 对象被分配

// 第一个对象 "a" 现在可以说是垃圾了

它变得更糟糕了。

让我们来看这个例子：

String result = foo() + arg;

result += boo();

System.out.println("result = " + result);

在这个例子中，背后有三个StringBuilders 对象被分配 - 每一个都是"+"的操作所产生，和两个额外的String对象，一个持有第二次分配的result，另一个是传入到print方法的String参数，在看似非常简单的一段语句中有5个额外的对象。

试想一下在实际的代码场景中会发生什么，例如，通过xml或者文件中的文本信息生成一个web页面的过程。在嵌套循环结构，你将会发现有成百上千的对象被隐式的分配了。尽管VM有处理这些垃圾的机制，但还是有很大代价的 - 代价也许由你的用户来承担。

解决方案：

减少垃圾对象的一种方式就是善于使用StringBuilder 来建对象，下面的例子实现了与上面相同的功能，然而仅仅生成了一个StringBuilder 对象，和一个存储最终result 的String对象。

StringBuilder value =newStringBuilder("result = ");

value.append(foo()).append(arg).append(boo());

System.out.println(value);

通过留心String和StringBuilder被隐式分配的可能，可以减少分配的短期的对象的数量，尤其在有大量代码的位置。

2、计划好List的容量

像ArrayList这样的动态集合用来存储一些长度可变化数据的基本结构。ArrayList和一些其他的集合（如HashMap、 TreeMap），底层都是通过使用Object[]数组来实现的。而String（它们自己包装在char[]数组中），char数组的大小是不变的。 那么问题就出现了，如果它们的大小是不变的，我们怎么能放item记录到集合中去呢？答案显而易见：分配更多的数组。

看下面的例子：

List<Item> items =newArrayList<Item>();

for(inti =0; i < len; i++)

{

Item item = readNextItem();

items.add(item);

}

len的值决定了循环结束时items 最终的大小。然而，最初，ArrayList的构造器并不知道这个值的大小，构造器会分配一个默认的Object数组的大小。一旦内部数组溢出，它就会被一个新的、并且足够大的数组代替，这就使之前分配的数组成为了垃圾。

如果执行数千次的循环，那么就会进行更多次数的新数组分配操作，以及更多次数的旧数组回收操作。对于在大规模环境下运行的代码，这些分配和释放的操作应该尽可能从CPU周期中剔除。

解决方案：

无论什么时候，尽可能的给List或者Map分配一个初始容量，就像这样：

List<MyObject> items =newArrayList<MyObject>(len);

因为List初始化，有足够的容量，所有这样可以减少内部数组在运行时不必要的分配和释放。如果你不知道确定的大小，最好估算一下这个值的平均值，添加一些缓冲，防止意外溢出。

3、使用高效的含有原始类型的集合

当前版本的Java编译器对于含有基本数据类型的键的数组以及Map的支持，是通过"装箱"来实现的 - 自动装箱就是将原始数据装入一个对应的对象中，这个对象可被GC分配和回收。

这个会有一些负面的影响。Java可以通过使用内部数组实现大多数的集合。对于每一条被添加到HashMap中的key/value记录，都会分配 一个存储key和value的内部对象。当处理map的时候非常可怕，这意味着，每当你放一条记录到map中的时候，就会有一次额外的分配和释放操作发 生。这很可能导致数量过大，而不得不重新分配新的内部数组。当处理有成百上千条甚至更多记录的Map时，这些内部分配的操作将会使GC的成本增加。

一种常见的情况就是保存一个原始类型（如id）和一个对象之间的映射。由于Java的HashMap设计只能包含对象类型（而非原始类型），这意味着，每个map的插入操作都可能分配一个额外的对象来存储原始类型（即装箱）。

Integer.valueOf 方法缓存在-128 - 127之间的数值，但是对于范围之外的每一个数值，除了内部的key/value记录对象之外，一个新的对象也将会分配。这很可能超过了GC对于map三 倍的开销。对于一个C++开发者来说，这真是让人不安的消息，在C++中，STL 模板可以非常高效地解决这样的问题。

很幸运，这个问题将会在Java的下一个版本得到解决。到那时，这将会被一些提供基本的树形结构(Tree)、映射（Map），以及List等Java的基本类型的库迅速处理。我强力推荐Trove，我已经使用很长时间了，并且它在处理大规模的代码时真的可以减小GC的开销。

4、使用数据流（Streams）代替内存缓冲区（in-memory buffers）

在服务器应用程序中，我们操作的大多数的数据都是以文件或者是来自另一个web服务器或DB的网络数据流的形式呈现给我们。大多数情况下，传入的数据都是序列化的形式，在我们使用它们之前需要被反序列化成Java对象。这个过程非常容易产生大量的隐式分配。

最简单的做法就是通过ByteArrayInputStream,ByteBuffer 把数据读入内存中，然后再进行反序列化。

这是一个糟糕的举动，因为完整的数据在构造新的对象的时候，你需要为其分配空间，然后立刻又释放空间。并且，由于数据的大小你又不知道，你只能猜测 - 当超过初始化容量的时候，不得不分配和释放byte[]数组来存储数据。

解决方案非常简单。像Java自带的序列化工具以及Google的Protocol Buffers等，它们可以将来自于文件或网络流的数据进行反序列化，而不需要保存到内存中，也不需要分配新的byte数组来容纳增长的数据。如果可以的 话，你可以将这种方法和加载数据到内存的方法比较一下，相信GC会很感谢你的。

5、List集合

不变性是很美好的，但是在大规模情境下，它就会有严重的缺陷。当传入一个List对象到方法中的情景。

当方法返回一个集合，通常会很明智的在方法中创建一个集合对象（如ArrayList），填充它，并以不变的集合的形式返回。

有些情况下，这并不会得到很好的效果。最明显的就是，当来自多个方法的集合调用一个final集合。因为不变性，在大规模数据情况下，会分配大量的临时集合。

这种情况的解决方案将不会返回新的集合，而是通过使用单独的集合当做参数传入到那些方法代替组合的集合。

例子1（低效率）：

List<Item> items =newArrayList<Item>();

for(FileData fileData : fileDatas)

{

// 每一次调用都会创建一个存储内部临时数组的临时的列表

items.addAll(readFileItem(fileData));

}

例子2：

List<Item> items =

newArrayList<Item>(fileDatas.size() * avgFileDataSize *1.5);

for(FileData fileData : fileDatas)

{

readFileItem(fileData, items);// 在内部添加记录

}

在例子2中，当违反不变性规则的时候（这通常应该被遵守），可以节省N个list的分配（以及任何临时数组的分配）。这将是对你GC的一个大大的优惠。

WordPress的Action加载顺序

资料

写WordPress代码时需要不停的与hooks（actions and filters）打交道，filter就像茶壶的过滤嘴，茶壶在哪它就在哪，顺序问题不那么重要。而action是一种行为，比如掀起壶盖和盖上壶盖之间 就可以放一个action，在这个action里可以放茶叶，不掀起壶盖是不可以放茶叶的，所以actions执行的顺序很重要。

 

钩子Hooks

钩子是让一段代码与另一段代码做交互的方法。它们是插件、主题与WordPress内核做交互的基础，当然WordPress内核里也广泛使用了。

钩子有两种：Actions和Filters。使用它们，你必须写一个回调函数，然后将它注册到WordPress关联到特定action或filter。

Filters让你可以在WordPress运行的时候修改一段数据的值。传入给回调函数的变量修改后被返回。它们是独立工作的，不会影响到函数外部的东西。

Actions则相反，允许你增加或修改WordPress的运行。回调函数会运行在WordPress运行到特定点的时候，可以做一些任务，比如：输出显示给用户、插入数据到数据库。

WordPress提供了许多钩子供你使用，你也可以自定义一些供其他开发者来修改你的插件或主题。

 

Actions

Actions钩子提供了函数一种方法可以让其他函数挂靠上来，然后额外的代码就可以在WordPress内核、插件、主题运行到特定点的时候执行了。

它们通过调用add_action()函数来工作，传入两个参数：你要挂靠的钩子名称、要运行的回调函数。比如：

<?php add_action( 'init', 'do_some_stuff' ); ?>

以上语句中，自定义do_some_stuff()函数会在WordPress运行init操作的时候被调用。

可以去代码参考的hook部分查看更多可用的action。如你经验丰富，对WordPress内核十分熟悉，可以直接去源代码里找合适的action。

示例

如果你想为Loop修改MySQL查询语句，你可以挂靠到pre_get_posts操作上。比如，你可以将指定CPT包含到搜索中：

<?php
function search_filter( $query ) {
    if ( ! is_admin() && $query->is_main_query() ) {
        if ( $query->is_search ) {
            $query->set( 'post_type', array( 'post', 'movie' ) );
        }
    }
}
add_action( 'pre_get_posts', 'search_filter' );
?>

还有比如，你想添加标签到HTML的<head>里，你可以挂靠到wp_head操作上。

<?php
function prevent_google_maps_resize() {
    echo '<meta name="viewport" content="initial-scale=1.0, user-scalable=no" />';
}
add_action( 'wp_head', 'prevent_google_maps_resize' );
?>

非常重要的一个 url地址， 关于wordpress的

https://github.com/66beta/plugin-handbook-chs/blob/master/4.Hooks.md

 

 

WordPress中的actions

actions可以理解为一组在系统加载到某一时刻要执行的functions集合，使用do_action()添加，例如我们经常用到的get_header()函数，是这样定义的

1
2
3
4
5
6
7
8
9
10
11
12
13
function get_header( $name = null ) {
    do_action( 'get_header', $name );
    $templates = array();
    if ( isset($name) )
        $templates[] = "header-{$name}.php";
    $templates[] = 'header.php';
    // Backward compat code will be removed in a future release
    if ('' == locate_template($templates, true))
        load_template( ABSPATH . WPINC . '/theme-compat/header.php');
}

函数第二行用do_action()注册了一个action，叫做get_header

1
do_action( 'get_header', $name );

如果我们在functions.php中或者插件中写

1
add_action('get_header','my_fun')

my_fun()这个函数就会在do_action的位置执行，而不是在functions.php运行的位置执行。

Actions的执行顺序

了解WordPress中actions的执行顺序，可以知晓在这个action执行时，是否已经具备某些资源，例如登陆用户信心、例如插件API等。

要了解Actions的执行顺序，可以安装一个开发人员的插件WordPress Hook Sniffer,该插件不仅能告知actions的加载顺序，还能知道当前页面add_action操作有哪些，remove_action操作有哪些，还有filters信息。

这个simply-show-hooks插件也很好， 用来显示hook。

用这个插件查看了安装默认主题时action的执行顺序，捡了一些重要的记录下来，红色字体标记了一下比较重要的阶段。

muplugins_loaded （最先加载的action）

registered_taxonomy

registered_post_type

(加载所有激活的插件的文件，这是插件代码被执行的位置)

plugins_loaded

sanitize_comment_cookies

setup_theme

(载入当前主题的functions.php，functions.php中没有用add_filter或add_action添加的函数在这里被执行)

after_setup_theme (这个钩子看着眼熟吧，默认主题开头就有)

auth_cookie_malformed

auth_cookie_valid

set_current_user (这里执行了wp_set_current_user()函数，全局变量$current_user产生)

init

widgets_init

register_sidebar

wp_register_sidebar_widget

wp_default_scripts

wp_default_styles

admin_bar_init

add_admin_bar_menus

wp_loaded

parse_request

send_headers

parse_query

pre_get_posts

posts_selection

wp

template_redirect

加载激活的主题的模板（例如index.php、page.php等）

get_header

wp_head

wp_enqueue_scripts

wp_print_styles

wp_print_scripts

wp_print_scripts

get_footer

wp_footer

从上面的列表中可以看出一些问题：

  • 插件文件比主题的functions.php加载更早
  • 插件加载时，wp_set_current_user()尚未执行，因此在插件文件的body中无法直接获取用户信息
  • init和after_setup_theme的区别是，后者执行时尚未调用wp_set_current_user()，没有授权用户信息
  • 加 载主题模板文件发生在最后阶段，此阶段中不管是插件的代码还是functions.php中的代码都已执行，这样我们就不奇怪为什么在 single.php中调用query_posts()会增加查询次数，query_posts()大约在pre_get_posts的位置就执行完了， 等程序执行到single.php时，如果调用query_posts，只能推翻前面的结果重新查一遍。我们还能看出，避免这个问题的方法就是在 functions.php中使用filters函数（posts_join, posts_groupby等）更改query_posts的查询参数，因为functions.php早于query_posts执行，方法可以参考《自定义WordPress查询的4种方法》中的第三种方法。

理解万岁

与其枯燥的去记忆什么时候该用哪个action，不如理解一下WordPress的启动过程，了解actions加载的顺序，记忆几个比较重要的过程，例如哪些actions发生在插件代码执行以后，哪些actions发生在functions.php加载以后。

WordPress中wp_enqueue_script加载JavaScript

资料

在 WordPress 中加载 JavaScript 最好使用 wp_enqueue_script() 函数以减少问题提高效率

WordPress 本身以及主题和插件通常需要加载一些 JavaScript 来实现某些特殊功能。为了最大限度地保证兼容性，不至于出现 JavaScript 失效的情况，所以一般在页头加载 JavaScript 文件。但是根据 Yahoo 开发者论坛的建议，加载 JavaScript 应该尽量在页尾以提高页面的显示（响应、渲染）速度。本文根据作者的使用经验介绍几个相关插件，并说明如何在某些特殊页面仍然在页头加载 JavaScript。

 

下面先简单介绍几个相关的优化 JavaScript 的 WordPress 插件及特点，然后演示如何处理一些特殊情况。

一. 优化JavaScript的WordPress插件

我曾经用过 WP Minify、Autoptimize、JavaScript to Footer这三个插件，下面一一介绍其特点。

1. WP Minify

这个插件将 Minify 引擎整合到 WordPress 中。一经启用，该插件就能够合并和压缩你的 JS 和 CSS 文件来提高页面的加载速度。

WP Minify 能够抓取生成的 WordPress 页面中的 JS/CSS 文件，将文件列表传递给 Minify 引擎。Minify 引擎处理后返回一个加强、精简并经过压缩的 JavaScript 或样式表文件（CSS），由 WP Minify 将其替换到 WordPress 页头中。

其主要特点是：

  • 易于使用；
  • 对 JavaScript、CSS 和 HTML 均有效；
  • 提供了调试工具；
  • 能够处理外部 JS 和 CSS 文件；
  • 能够排除指定 JS 和 CSS 文件；
  • 能够指定处理后的 JS 和 CSS 文件的位置（页头或页尾，甚至别的地方）；
  • 可对处理后的 JS 和 CSS 文件添加过期时间等。

以前使用免费空间的时候，因为速度慢，我曾经利用这个插件在 K2 主题下的一个漏洞来减少访问网站时需要下载的内容量（详见给基于WordPress + K2 Theme的网站加速）。

当 WordPress 3.1 测试版出来后，我发现 WP Minify 与之不兼容，会导致网站无法正确加载。

2. Autoptimize

也许将来 WP Minify 升级后会解决不兼容问题，但是我等不及了。后来找到了 Autoptimize 这个具有类似功能的插件，而且这个插件操作更简单。

Autoptimize 整合、精简并压缩所有的 JS 和 样式表（CSS）文件，增加缓存过期标志。然后将样式表文件放到页头（同样是为了提高页面加载效率），并将 JS 文件放到页尾。它还能够精简 HTML 代码，给你的页面瘦身。不过我觉得给 HTML 页面瘦身作用不是很明显，只要你的服务器开启了 Gzip 压缩特性就没必要这么做了。

默认情况下，Autoptimize 会按照上面介绍的方式优化所有 HTML/CSS/JavaScript 。

我个人觉得，Autoptimize 是比 WP Minify 更好用的 WordPress 优化插件。

3. JavaScript to Footer

这个插件写的非常简洁。我查看了源代码，完成任务的代码只有 6 个 WordPress 函数（见下文），也就是 6 行。所以这个插件从创建之后就怎么更新过。我一开始就因为见它最后更改日期还停留在2009年9月22日，所以把它给忽略了。

但是它仅仅优化 JavaScript 的加载位置，也就是将所有在 WordPress 中正确声明了的 Javascript 文件都给移到页面末尾来加载。它没有对 HTML 代码和 CSS 样式表文件作任何处理。

根据 JavaScript to Footer 的源代码，它使用下面的 6 行代码来完成工作：

remove_action('wp_head', 'wp_print_scripts');
remove_action('wp_head', 'wp_print_head_scripts', 9);
remove_action('wp_head', 'wp_enqueue_scripts', 1);
add_action('wp_footer', 'wp_print_scripts', 5);
add_action('wp_footer', 'wp_enqueue_scripts', 5);
add_action('wp_footer', 'wp_print_head_scripts', 5);

如果有需要，可以在某个特定 WordPress 模板的 wp_head() 函数前加入下面的代码，将上述过程逆转过来，也就是使之失效，恢复成了本来的加载位置：

remove_action('wp_footer', 'wp_print_scripts', 5);
remove_action('wp_footer', 'wp_enqueue_scripts', 5);
remove_action('wp_footer', 'wp_print_head_scripts', 5);
add_action('wp_head', 'wp_print_scripts');
add_action('wp_head', 'wp_print_head_scripts', 9);
add_action('wp_head', 'wp_enqueue_scripts', 1);

当然只是说某些特定的页面模板，如果是所有页面，那干脆禁用该插件好了

二. 使用方法

相信对于大多数 WPer 来说，看了前面的介绍就知道如何选择自己需要的优化插件并合理使用了。无非是基于以下三个方面来考虑：

  1. 你的页面模板中是否使用了大量的 HTML 注释、空格、空行等标记？如果没有，那么你就不需要为了一点点（开启 Gzip 压缩时通常 1% 以下）的带宽节省而使用 HTML 精简功能；
  2. 你的页面中是否加载了多个 CSS 样式表文件？如果没有，你也不需要通过插件来精简和整合 CSS 样式表，手工精简和整合 CSS 样式表比使用插件更加简单有效；
  3. 基于 WordPress 默认会在页头中加载 JavaScript，一般的 WordPress 网站都需要对 JS 的加载位置进行优化。但是如果你大部分的页面也都需要在页面头部加载 JS 以保证不会出现 JS 失效的情况，那你就不能进行这样的优化了。

在我看来，WP Minify 就不需要了，原因在前面已经说过了。那么剩下的 Autoptimize 和 JavaScript to Footer 可以选用其一或者两者配合使用（如果是配合使用，当然是使用前者的 HTML 和 CSS 精简/整合功能，而使用后者的 JS 位置控制功能，因为后者就这一个功能）。我只需要控制 JS 的加载位置，所以就选择了 JavaScript to Footer。因为我的页面中也就四五个 JS 文件，又是放到页尾加载，我觉得没必要进行整合。

三. 特殊情况处理

虽然将 JavaScript 文件都放到页面末尾加载对于页面加载速度很有帮助，但是请注意，所谓页面末尾指的是在 WordPress 的 wp_footer() 函数中调用，这个函数通常刚好位于页面的 </body> 标签前面（当然是末尾了）。

有时候我们可能会在 wp_footer 函数出现之前就需要用到某些 JavaScript，比如 jquery.js 文件。

这样的情况也是很常见的。比如我单独创建了一个链接页面，在这个页面中我使用了 jQuery 方法来获取链接网站的 favicon。很显然，我只需要在这唯一一个页面使用这部分代码，所以将这段代码直接放在这个页面模板中是最好的做法。问题来了：这部分内容显然是在 wp_footer 之前出现的，那么这段代码就在 jquery.js 文件之前出现了，导致该代码段实际上无法工作，因为调用 jQuery 方法的代码段必须比 jquery.js 文件后加载。

从上面的情景中就很容易理解我所说的特殊情况了。在我的Buzz和站外资源 2 个特殊页面里，我在自建的页面模板中加载了一些特殊的 JavaScript 代码（详见将Buzz输出整合进网页和为WordPress创建个性化链接页面）。

那么如何处理这种特殊情况呢？其实也很简单。以上面的情景为例，既然我们需要先调用 jquery.js 文件，那我们就在该代码段之前直接输出需要的 jquery.js 文件，不使用 wp_enqueue_script() 函数，而改用 wp_print_scripts() 函数。

wp_enqueue_script() 与 wp_print_scripts() 的区别是：wp_enqueue_script() 是告诉 WordPress “我在这个页面上需要用到某个 JavaScript 文件，你可要记得加载啊”。WordPress 默认在 wp_head() 中处理，而我们改为在 wp_footer() 中处理。wp_print_scripts() 则直接在你使用此方法的位置输出需要的 JavaScript 文件，而不是加入到 WordPress 的处理任务中。

如果我们在页面的中间使用，

 <?php wp_print_scripts('jquery'); ?>

直接输出了 jquery.js 文件（通常是其压缩版本 jquery.min.js），那么即使其它的插件或者什么东西使用，

 <?php wp_enqueue_script('jquery'); ?>

告诉 WordPress 需要加载 jquery.js，WordPress 在 wp_footer() 中处理的时候也会先检查前面是不是已经有了，如果有了就不会再重新加载一次。

四. 结论

在 WordPress 中加载 JavaScript 最好使用 wp_enqueue_script() 函数以减少问题提高效率。如果不是有这些特殊情况要处理，使用 Autoptimize 显然比较好，它全面完成任务而且使用简单。

但是如果使用的主题本身已经很简洁了，那么 JavaScript to Footer 更简单高效，也就更好。

本文发表于水景一页。

介绍几个JS和CSS压缩合并插件

资料

由于添加各种功能的代码和 wordpress插件 ，会导致JS和CSS增多，影响了wordpress博客的加载速度。虽然可以用代码来对JS和CSS进行压缩合并，可是对初学者不是那么简单，很容易出错。因此介绍几个JS 和CSS 压缩合并插件，方便初学者进行优化。

Better WordPress Minify

Better WordPress Minify 是将Minify引擎集成到wordpress博客上，一旦被启用，它将合并和压缩所有的 JS 和 CSS 文件，从而降低网页的加载时间。

Better WordPress Minify插件使用很简单。安装并启用插件后，会自动压缩合并你的JS和CSS文件。当然你可以在设置页面中，进行如下更细致的设置。

  • 删除不必要的空格与空行。
  • 合并多个CSS或JavaScript文件。
  • 自动缩小的JS文件。
  • 自动缩小CSS文件。
  • 并提供gzip压缩。
  • 缩小代码bloginfo（）样式表？
  • 缩小网址。
  • 缓存目录。

30453013_1

 

 

wordpress 插件下载  Better WordPress Minify 插件 wordpress.org (160.0 KB, 30 次)

JS & CSS Optimizer

JS & CSS Optimizer 是一款JS和CSS优化插件，可以把多个JS和CSS文件合并到一个文件上，降低HTTP请求的次数。

30453013_3

 

30453013_4

 

wordpress 插件下载  js-css-script-optimizer 插件 wordpress.org  下载 (160.0 KB, 17 次)

Scripts Gzip

Scripts Gzip 也是一款wordpress js,css压缩合并插件，根据需要重写CSS文件的url()。

30453013_5

 

 

wordpress 插件下载  scripts-gzip 插件 wordpress.org  下载 (46.5 KB, 10 次)

HeaderJS Loader

HeaderJS Loader 是一款可以通过 Head JS 来选择加载JS文件的wordpress插件。

30453013_6

wordpress 插件下载  headjs-loader 插件 wordpress.org  下载 (5.3 KB, 7 次)

External Files Organizer

External Files Organizer 可以自动对css和js进行压缩合并，生成wp_head()和wp_footer()。

wordpress 插件下载  external-files-optimizer 插件 wordpress.org  (4.6 KB, 8 次)

常用Maven插件介绍

资料

Maven本质上是一个插件框架，它的核心并不执行任何具体的构建任务，所有这些任务都交给插件来完成，例如编译源代码是由 maven-compiler-plugin完成的。进一步说，每个任务对应了一个插件目标（goal），每个插件会有一个或者多个目标，例如maven-compiler-plugin的compile目标用来编译位于src/main/java/目录下的主源码，testCompile目标用来编译位于 src/test/java/目录下的测试源码。

用户可以通过两种方式调用Maven插件目标。第一种方式是将插件目标与生命周期阶段 （lifecycle phase）绑定，这样用户在命令行只是输入生命周期阶段而已，例如Maven默认将maven-compiler-plugin的compile目标与 compile生命周期阶段绑定，因此命令mvn compile实际上是先定位到compile这一生命周期阶段，然后再根据绑定关系调用maven-compiler-plugin的compile目 标。第二种方式是直接在命令行指定要执行的插件目标，例如mvn archetype:generate 就表示调用maven-archetype-plugin的generate目标，这种带冒号的调用方式与生命周期无关。

认识上述 Maven插件的基本概念能帮助你理解Maven的工作机制，不过要想更高效率地使用Maven，了解一些常用的插件还是很有必要的，这可 以帮助你避免一不小心重新发明轮子。多年来Maven社区积累了大量的经验，并随之形成了一个成熟的插件生态圈。Maven官方有两个插件列表，第一个列 表的GroupId为org.apache.maven.plugins，这里的插件最为成熟，具体地址 为：http://maven.apache.org/plugins/index.html。第二个列表的GroupId为 org.codehaus.mojo，这里的插件没有那么核心，但也有不少十分有用，其地址为：http://mojo.codehaus.org /plugins.html。

部分插件列表

Core plugins
clean
compiler
deploy
failsafe
install
resources
site
surefire
verifier

Packaging types/tools
ear
ejb
jar
rar
war
app-client/acr
shade
source
Reporting plugins
changelog
changes
checkstyle
doap
docck
javadoc
jdeps
jxr
linkcheck
pmd
project-info-reports
surefire-report
Tools
ant
antrun
archetype
assembly
dependency
enforcer
gpg
help
invoker
jarsigner
patch
pdf
plugin
release
remote-resources
repository
scm
scm-publish
stage
toolchains

接下来笔者根据自己的经验介绍一些最常用的Maven插件，在不同的环境下它们各自都有其出色的表现，熟练地使用它们能让你的日常构建工作事半功倍。

 

maven-antrun-plugin

http://maven.apache.org/plugins/maven-antrun-plugin/

maven- antrun-plugin能让用户在Maven项目中运行Ant任务。用户可以直接在该插件的配置以Ant的方式编写Target， 然后交给该插件的run目标去执行。在一些由Ant往Maven迁移的项目中，该插件尤其有用。此外当你发现需要编写一些自定义程度很高的任务，同时又觉 得Maven不够灵活时，也可以以Ant的方式实现之。maven-antrun-plugin的run目标通常与生命周期绑定运行。

 

maven-archetype-plugin

http://maven.apache.org/archetype/maven-archetype-plugin/

Archtype 指项目的骨架，Maven初学者最开始执行的Maven命令可能就是mvn archetype:generate，这实际上就是让maven-archetype-plugin生成一个很简单的项目骨架，帮助开发者快速上手。可 能也有人看到一些文档写了mvn archetype:create， 但实际上create目标已经被弃用了，取而代之的是generate目标，该目标使用交互式的方式提示用户输入必要的信息以创建项目，体验更好。 maven-archetype-plugin还有一些其他目标帮助用户自己定义项目原型，例如你由一个产品需要交付给很多客户进行二次开发，你就可以为 他们提供一个Archtype，帮助他们快速上手。

 

maven-assembly-plugin

http://maven.apache.org/plugins/maven-assembly-plugin/

maven- assembly-plugin的用途是制作项目分发包，该分发包可能包含了项目的可执行文件、源代码、readme、平台脚本等等。 maven-assembly-plugin支持各种主流的格式如zip、tar.gz、jar和war等，具体打包哪些文件是高度可控的，例如用户可以 按文件级别的粒度、文件集级别的粒度、模块级别的粒度、以及依赖级别的粒度控制打包，此外，包含和排除配置也是支持的。maven-assembly- plugin要求用户使用一个名为assembly.xml的元数据文件来表述打包，它的single目标可以直接在命令行调用，也可以被绑定至生命周 期。

maven-dependency-plugin

http://maven.apache.org/plugins/maven-dependency-plugin/

maven- dependency-plugin最大的用途是帮助分析项目依赖，dependency:list能够列出项目最终解析到的依赖列 表，dependency:tree能进一步的描绘项目依赖树，dependency:analyze可以告诉你项目依赖潜在的问题，如果你有直接使用到 的却未声明的依赖，该目标就会发出警告。maven-dependency-plugin还有很多目标帮助你操作依赖文件，例如 dependency:copy-dependencies能将项目依赖从本地Maven仓库复制到某个特定的文件夹下面。

 

maven-enforcer-plugin

http://maven.apache.org/plugins/maven-enforcer-plugin/

在 一个稍大一点的组织或团队中，你无法保证所有成员都熟悉Maven，那他们做一些比较愚蠢的事情就会变得很正常，例如给项目引入了外部的 SNAPSHOT依赖而导致构建不稳定，使用了一个与大家不一致的Maven版本而经常抱怨构建出现诡异问题。maven-enforcer- plugin能够帮助你避免之类问题，它允许你创建一系列规则强制大家遵守，包括设定Java版本、设定Maven版本、禁止某些依赖、禁止 SNAPSHOT依赖。只要在一个父POM配置规则，然后让大家继承，当规则遭到破坏的时候，Maven就会报错。除了标准的规则之外，你还可以扩展该插 件，编写自己的规则。maven-enforcer-plugin的enforce目标负责检查规则，它默认绑定到生命周期的validate阶段。

 

maven-help-plugin

http://maven.apache.org/plugins/maven-help-plugin/

maven- help-plugin是一个小巧的辅助工具，最简单的help:system可以打印所有可用的环境变量和Java系统属性。 help:effective-pom和help:effective-settings最 为有用，它们分别打印项目的有效POM和有效settings，有效POM是指合并了所有父POM（包括Super POM）后的XML，当你不确定POM的某些信息从何而来时，就可以查看有效POM。有效settings同理，特别是当你发现自己配置的 settings.xml没有生效时，就可以用help:effective-settings来验证。此外，maven-help-plugin的 describe目标可以帮助你描述任何一个Maven插件的信息，还有all-profiles目标和active-profiles目标帮助查看项目 的Profile。

maven-release-plugin

http://maven.apache.org/plugins/maven-release-plugin/

maven- release-plugin的用途是帮助自动化项目版本发布，它依赖于POM中的SCM信息。release:prepare用来准备版本发布，具体的 工作包括检查是否有未提交代码、检查是否有SNAPSHOT依赖、升级项目的SNAPSHOT版本至RELEASE版本、为项目打标签等等。 release:perform则 是签出标签中的RELEASE源码，构建并发布。版本发布是非常琐碎的工作，它涉及了各种检查，而且由于该工作仅仅是偶尔需要，因此手动操作很容易遗漏一 些细节，maven-release-plugin让该工作变得非常快速简便，不易出错。maven-release-plugin的各种目标通常直接在 命令行调用，因为版本发布显然不是日常构建生命周期的一部分。

 

maven-resources-plugin

http://maven.apache.org/plugins/maven-resources-plugin/

为 了使项目结构更为清晰，Maven区别对待Java代码文件和资源文件，maven-compiler-plugin用来编译Java代码，maven- resources-plugin则用来处理资源文件。默认的主资源文件目录是src/main/resources，很多用户会需要添加额外的资源文件 目录，这个时候就可以通过配置maven-resources-plugin来实现。此外，资源文件过滤也是Maven的一大特性，你可以在资源文件中使 用${propertyName}形式的Maven属性，然后配置maven-resources-plugin开启对资源文件的过滤，之后就可以针对不 同环境通过命令行或者Profile传入属性的值，以实现更为灵活的构建。

 

maven-surefire-plugin

http://maven.apache.org/plugins/maven-surefire-plugin/

可 能是由于历史的原因，Maven 2/3中用于执行测试的插件不是maven-test-plugin，而是maven-surefire-plugin。其实大部分时间内，只要你的测试 类遵循通用的命令约定（以Test结尾、以TestCase结尾、或者以Test开头），就几乎不用知晓该插件的存在。然而在当你想要跳过测试、排除某些 测试类、或者使用一些TestNG特性的时候，了解maven-surefire-plugin的一些配置选项就很有用了。例如 mvn test -Dtest=FooTest 这样一条命令的效果是仅运行FooTest测试类，这是通过控制maven-surefire-plugin的test参数实现的。

 

build-helper-maven-plugin

http://mojo.codehaus.org/build-helper-maven-plugin/

Maven 默认只允许指定一个主Java代码目录和一个测试Java代码目录，虽然这其实是个应当尽量遵守的约定，但偶尔你还是会希望能够指定多个 源码目录（例如为了应对遗留项目），build-helper-maven-plugin的add-source目标就是服务于这个目的，通常它被绑定到 默认生命周期的generate-sources阶段以添加额外的源码目录。需要强调的是，这种做法还是不推荐的，因为它破坏了 Maven的约定，而且可能会遇到其他严格遵守约定的插件工具无法正确识别额外的源码目录。

build-helper-maven-plugin的另一个非常有用的目标是attach-artifact，使用该目标你可以以classifier的形式选取部分项目文件生成附属构件，并同时install到本地仓库，也可以deploy到远程仓库。

 

exec-maven-plugin

http://mojo.codehaus.org/exec-maven-plugin/

exec- maven-plugin很好理解，顾名思义，它能让你运行任何本地的系统程序，在某些特定情况下，运行一个Maven外部的程序可能就是最简单的问题解 决方案，这就是exec:exec的 用途，当然，该插件还允许你配置相关的程序运行参数。除了exec目标之外，exec-maven-plugin还提供了一个java目标，该目标要求你 提供一个mainClass参数，然后它能够利用当前项目的依赖作为classpath，在同一个JVM中运行该mainClass。有时候，为了简单的 演示一个命令行Java程序，你可以在POM中配置好exec-maven-plugin的相关运行参数，然后直接在命令运行 mvn exec:java 以查看运行效果。

 

jetty-maven-plugin

http://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin

在 进行Web开发的时候，打开浏览器对应用进行手动的测试几乎是无法避免的，这种测试方法通常就是将项目打包成war文件，然后部署到Web容器 中，再启动容器进行验证，这显然十分耗时。为了帮助开发者节省时间，jetty-maven-plugin应运而生，它完全兼容 Maven项目的目录结构，能够周期性地检查源文件，一旦发现变更后自动更新到内置的Jetty Web容器中。做一些基本配置后（例如Web应用的contextPath和自动扫描变更的时间间隔），你只要执行 mvn jetty:run ，然后在IDE中修改代码，代码经IDE自动编译后产生变更，再由jetty-maven-plugin侦测到后更新至Jetty容器，这时你就可以直接 测试Web页面了。需要注意的是，jetty-maven-plugin并不是宿主于Apache或Codehaus的官方插件，因此使用的时候需要额外 的配置settings.xml的pluginGroups元素，将org.mortbay.jetty这个pluginGroup加入。

versions-maven-plugin

http://mojo.codehaus.org/versions-maven-plugin/

很 多Maven用户遇到过这样一个问题，当项目包含大量模块的时候，为他们集体更新版本就变成一件烦人的事情，到底有没有自动化工具能帮助完成这件 事情呢？（当然你可以使用sed之类的文本操作工具，不过不在本文讨论范围）答案是肯定的，versions-maven- plugin提供了很多目标帮助你管理Maven项目的各种版本信息。例如最常用的，命令 mvn versions:set -DnewVersion=1.1-SNAPSHOT 就能帮助你把所有模块的版本更新到1.1-SNAPSHOT。该插件还提供了其他一些很有用的目标，display-dependency- updates能告诉你项目依赖有哪些可用的更新；类似的display-plugin-updates能告诉你可用的插件更新；然后use- latest-versions能自动帮你将所有依赖升级到最新版本。最后，如果你对所做的更改满意，则可以使用 mvn versions:commit 提交，不满意的话也可以使用 mvn versions:revert 进行撤销。

 

小结
本文介 绍了一些最常用的Maven插件，这里指的“常用”是指经常需要进行配置的插件，事实上我们用Maven的时候很多其它插件也是必须的，例如 默认的编译插件maven-compiler-plugin和默认的打包插件maven-jar-plugin，但因为很少需要对它们进行配置，因此不在 本文讨论范围。了解常用的Maven插件能帮助你事倍功半地完成项目构建任务，反之你就可能会因为经常遇到一些难以解决的问题而感到沮丧。本文介绍的插件 基本能覆盖大部分Maven用户的日常使用需要，如果你真有非常特殊的需求，自行编写一个Maven插件也不是难事，更何况还有这么多开放源代码的插件供 你参考。

本文的这个插件列表并不是一个完整列表，读者有兴趣的话也可以去仔细浏览一下Apache和Codehaus Mojo的Maven插件列表，以的到一个更为全面的认识。最后，在线的Maven仓库搜索引擎如http://search.maven.org/也能 帮助你快速找到自己感兴趣的Maven插件。

另外的一些插件：

maven-site-plugin

maven-site-plugin是一个负责为Java项目生成静态HTML网站的插件。这个插件非常的有用，里面可以嵌入各种插件，比如用来对代码检查bug的findbugs,检查代码风格的checkstyle,生成testng测试报告的surefire等。先来看一下关于这个插件的配置的一个例子：

CheckStyle
请注意，checkstyle可以接受一个定制的规则文件，比如我这里的叫my_checkstyle.xml。这是从eclipse中导出的。

其实自己编辑这份xml文档也可以，语法规则还是很简单的。
有一个Maven插件可以帮助我对Java代码进行格式化，这个插件不属于maven-site-plugin管理，但是很有用。看我下面的配置：
这个插件需要一个从Eclipse导出的代表当前Eclipse编码风格的xml文件（你也可以手动编辑）：
maven-java-formatter-plugin 对于我可是帮了大忙，我不用Eclipse开发，每次只要执行mvn clean compile，就会自动格式化我的Java代码。然后稍作修改，就满足CheckStyle的规则了。原来还用过一个叫做jalopy，那东西现在要付钱了，免费版本我记得并不好用。

Javadoc plugin
现在聊聊生成Java文档。maven-javadoc-plugin可以根据注释，自动生成文档。但是如果你还想要在文档里面看到UML静态结构图，需要制定使用UmlGraph.在我的Ubuntu下面，需要事先做一些准备工作：
1.下载UmlGraph 并安装，可以参考这里的文档：

http://www.umlgraph.org/doc/install.html (javadoc tool已经在安装jdk的时候装好了)

2.apt-get install graphviz
3.apt-get install plotutils

测试报告
要想使用surefire-report-plugin产生报告，还需要在site-plugin之外配置一个maven-surefire-plugin，里面指定了testng.xml，因为我用TestNG开发测试程序。

现在执行一下mvn clean site

会编译，测试，扫描代码，生成html文件.最后通过浏览器打开target/site/下面的project-reports.html。仔细看看，Java社区多么规范，Maven多么方便啊。