搜索引擎選型調(diào)研文檔

Elasticsearch簡介^*

Elasticsearch是一個實時的分布式搜索和分析引擎。它可以幫助你用前所未有的速度去處理大規(guī)模數(shù)據(jù)。

它可以用于全文搜索，結(jié)構(gòu)化搜索以及分析，當然你也可以將這三者進行組合。

Elasticsearch是一個建立在全文搜索引擎 Apache Lucene™ 基礎(chǔ)上的搜索引擎，可以說Lucene是當今最先進，最高效的全功能開源搜索引擎框架。

但是Lucene只是一個框架，要充分利用它的功能，需要使用JAVA，并且在程序中集成Lucene。需要很多的學習了解，才能明白它是如何運行的，Lucene確實非常復雜。

Elasticsearch使用Lucene作為內(nèi)部引擎，但是在使用它做全文搜索時，只需要使用統(tǒng)一開發(fā)好的API即可，而不需要了解其背后復雜的Lucene的運行原理。

當然Elasticsearch并不僅僅是Lucene這么簡單，它不但包括了全文搜索功能，還可以進行以下工作:

• 分布式實時文件存儲，并將每一個字段都編入索引，使其可以被搜索。

• 實時分析的分布式搜索引擎。

• 可以擴展到上百臺服務器，處理PB級別的結(jié)構(gòu)化或非結(jié)構(gòu)化數(shù)據(jù)。

這么多的功能被集成到一臺服務器上，你可以輕松地通過客戶端或者任何你喜歡的程序語言與ES的RESTful API進行交流。

Elasticsearch的上手是非常簡單的。它附帶了很多非常合理的默認值，這讓初學者很好地避免一上手就要面對復雜的理論，

它安裝好了就可以使用了，用很小的學習成本就可以變得很有生產(chǎn)力。

隨著越學越深入，還可以利用Elasticsearch更多高級的功能，整個引擎可以很靈活地進行配置。可以根據(jù)自身需求來定制屬于自己的Elasticsearch。

使用案例：

• 維基百科使用Elasticsearch來進行全文搜做并高亮顯示關(guān)鍵詞，以及提供search-as-you-type、did-you-mean等搜索建議功能。

• 英國衛(wèi)報使用Elasticsearch來處理訪客日志，以便能將公眾對不同文章的反應實時地反饋給各位編輯。

• StackOverflow將全文搜索與地理位置和相關(guān)信息進行結(jié)合，以提供more-like-this相關(guān)問題的展現(xiàn)。

• GitHub使用Elasticsearch來檢索超過1300億行代碼。

• 每天，Goldman Sachs使用它來處理5TB數(shù)據(jù)的索引，還有很多投行使用它來分析股票市場的變動。

但是Elasticsearch并不只是面向大型企業(yè)的，它還幫助了很多類似DataDog以及Klout的創(chuàng)業(yè)公司進行了功能的擴展。

Elasticsearch的優(yōu)缺點^**:

優(yōu)點

1. Elasticsearch是分布式的。不需要其他組件，分發(fā)是實時的，被叫做”Push replication”。
2. Elasticsearch 完全支持 Apache Lucene 的接近實時的搜索。
3. 處理多租戶（multitenancy）不需要特殊配置，而Solr則需要更多的高級設置。
4. Elasticsearch 采用 Gateway 的概念，使得完備份更加簡單。
5. 各節(jié)點組成對等的網(wǎng)絡結(jié)構(gòu)，某些節(jié)點出現(xiàn)故障時會自動分配其他節(jié)點代替其進行工作。

缺點

1. 只有一名開發(fā)者（當前Elasticsearch GitHub組織已經(jīng)不只如此，已經(jīng)有了相當活躍的維護者）
2. 還不夠自動（不適合當前新的Index Warmup API）

Solr簡介^*

Solr（讀作“solar”）是Apache Lucene項目的開源企業(yè)搜索平臺。其主要功能包括全文檢索、命中標示、分面搜索、動態(tài)聚類、數(shù)據(jù)庫集成，以及富文本（如Word、PDF）的處理。Solr是高度可擴展的，并提供了分布式搜索和索引復制。Solr是最流行的企業(yè)級搜索引擎，Solr4 還增加了NoSQL支持。

Solr是用Java編寫、運行在Servlet容器（如 Apache Tomcat 或Jetty）的一個獨立的全文搜索服務器。 Solr采用了 Lucene Java 搜索庫為核心的全文索引和搜索，并具有類似REST的HTTP/XML和JSON的API。Solr強大的外部配置功能使得無需進行Java編碼，便可對 其進行調(diào)整以適應多種類型的應用程序。Solr有一個插件架構(gòu)，以支持更多的高級定制。

因為2010年 Apache Lucene 和 Apache Solr 項目合并，兩個項目是由同一個Apache軟件基金會開發(fā)團隊制作實現(xiàn)的。提到技術(shù)或產(chǎn)品時，Lucene/Solr或Solr/Lucene是一樣的。

Solr的優(yōu)缺點

優(yōu)點

1. Solr有一個更大、更成熟的用戶、開發(fā)和貢獻者社區(qū)。
2. 支持添加多種格式的索引，如：HTML、PDF、微軟 Office 系列軟件格式以及 JSON、XML、CSV 等純文本格式。
3. Solr比較成熟、穩(wěn)定。
4. 不考慮建索引的同時進行搜索，速度更快。

缺點

1. 建立索引時，搜索效率下降，實時索引搜索效率不高。

Elasticsearch與Solr的比較^*

當單純的對已有數(shù)據(jù)進行搜索時，Solr更快。

當實時建立索引時, Solr會產(chǎn)生io阻塞，查詢性能較差, Elasticsearch具有明顯的優(yōu)勢。

隨著數(shù)據(jù)量的增加，Solr的搜索效率會變得更低，而Elasticsearch卻沒有明顯的變化。

綜上所述，Solr的架構(gòu)不適合實時搜索的應用。

實際生產(chǎn)環(huán)境測試^*

下圖為將搜索引擎從Solr轉(zhuǎn)到Elasticsearch以后的平均查詢速度有了50倍的提升。

Elasticsearch 與 Solr 的比較總結(jié)

• 二者安裝都很簡單；
• Solr 利用 Zookeeper 進行分布式管理，而 Elasticsearch 自身帶有分布式協(xié)調(diào)管理功能;
• Solr 支持更多格式的數(shù)據(jù)，而 Elasticsearch 僅支持json文件格式；
• Solr 官方提供的功能更多，而 Elasticsearch 本身更注重于核心功能，高級功能多有第三方插件提供；
• Solr 在傳統(tǒng)的搜索應用中表現(xiàn)好于 Elasticsearch，但在處理實時搜索應用時效率明顯低于 Elasticsearch。

Solr 是傳統(tǒng)搜索應用的有力解決方案，但 Elasticsearch 更適用于新興的實時搜索應用。

其他基于Lucene的開源搜索引擎解決方案^*

1. 直接使用 Lucene

說明：Lucene 是一個 JAVA 搜索類庫，它本身并不是一個完整的解決方案，需要額外的開發(fā)工作。

優(yōu)點：成熟的解決方案，有很多的成功案例。apache 頂級項目，正在持續(xù)快速的進步。龐大而活躍的開發(fā)社區(qū)，大量的開發(fā)人員。它只是一個類庫，有足夠的定制和優(yōu)化空間：經(jīng)過簡單定制，就可以滿足絕大部分常見的需求；經(jīng)過優(yōu)化，可以支持 10億+ 量級的搜索。

缺點：需要額外的開發(fā)工作。所有的擴展，分布式，可靠性等都需要自己實現(xiàn)；非實時，從建索引到可以搜索中間有一個時間延遲，而當前的“近實時”(Lucene Near Real Time search)搜索方案的可擴展性有待進一步完善

• Katta

說明：基于 Lucene 的，支持分布式，可擴展，具有容錯功能，準實時的搜索方案。

優(yōu)點：開箱即用，可以與 Hadoop 配合實現(xiàn)分布式。具備擴展和容錯機制。

缺點：只是搜索方案，建索引部分還是需要自己實現(xiàn)。在搜索功能上，只實現(xiàn)了最基本的需求。成功案例較少，項目的成熟度稍微差一些。因為需要支持分布式，對于一些復雜的查詢需求，定制的難度會比較大。

• Hadoop contrib/index

說明：Map/Reduce 模式的，分布式建索引方案，可以跟 Katta 配合使用。

優(yōu)點：分布式建索引，具備可擴展性。

缺點：只是建索引方案，不包括搜索實現(xiàn)。工作在批處理模式，對實時搜索的支持不佳。

• LinkedIn 的開源方案

說明：基于 Lucene 的一系列解決方案，包括 準實時搜索 zoie ，facet 搜索實現(xiàn) bobo ，機器學習算法 decomposer ，摘要存儲庫 krati ，數(shù)據(jù)庫模式包裝 sensei 等等

優(yōu)點：經(jīng)過驗證的解決方案，支持分布式，可擴展，豐富的功能實現(xiàn)

缺點：與 linkedin 公司的聯(lián)系太緊密，可定制性比較差

• Lucandra

說明：基于 Lucene，索引存在 cassandra 數(shù)據(jù)庫中

優(yōu)點：參考 cassandra 的優(yōu)點

缺點：參考 cassandra 的缺點。另外，這只是一個 demo，沒有經(jīng)過大量驗證

• HBasene

說明：基于 Lucene，索引存在 HBase 數(shù)據(jù)庫中

優(yōu)點：參考 HBase 的優(yōu)點

缺點：參考 HBase 的缺點。另外，在實現(xiàn)中，lucene terms 是存成行，但每個 term 對應的 posting lists 是以列的方式存儲的。隨著單個 term 的 posting lists 的增大，查詢時的速度受到的影響會非常大

轉(zhuǎn)載：http://blog.csdn.net/jameshadoop/article/details/44905643

0.以下在系統(tǒng)CentOS 6.3 x86_64上操作

1.試圖運行程序，提示"libc.so.6: version `GLIBC_2.14' not found",原因是系統(tǒng)的glibc版本太低，軟件編譯時使用了較高版本的glibc引起的：

[ghui@StuOS bin]$ pwd /var/VMdisks/cross/mingw32/bin [ghui@StuOS bin]$ ls lrelease     QtCore4.dll         QtNetwork4.dll      QtSql4.dll     QtXml4.dll moc          QtDeclarative4.dll  QtOpenGL4.dll       QtSvg4.dll     rcc phonon4.dll  QtGui4.dll          QtScript4.dll       QtTest4.dll    uic qmake        QtMultimedia4.dll   QtScriptTools4.dll  QtWebKit4.dll [ghui@StuOS bin]$ ./qmake  ./qmake: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./qmake)  

[ghui@StuOS bin]$ strings /lib64/libc.so.6 |grep GLIBC_ GLIBC_2.2.5 GLIBC_2.2.6 GLIBC_2.3 GLIBC_2.3.2 GLIBC_2.3.3 GLIBC_2.3.4 GLIBC_2.4 GLIBC_2.5 GLIBC_2.6 GLIBC_2.7 GLIBC_2.8 GLIBC_2.9 GLIBC_2.10 GLIBC_2.11 GLIBC_2.12 GLIBC_PRIVATE

[ghui@StuOS bin]$ rpm -qa |grep glibc glibc-static-2.12-1.80.el6_3.6.x86_64 glibc-headers-2.12-1.80.el6_3.6.x86_64 glibc-common-2.12-1.80.el6_3.6.x86_64 glibc-devel-2.12-1.80.el6_3.6.x86_64 glibc-static-2.12-1.80.el6_3.6.i686 glibc-devel-2.12-1.80.el6_3.6.i686 glibc-2.12-1.80.el6_3.6.i686 glibc-2.12-1.80.el6_3.6.x86_64 

3.可以看到最高只支持2.12版本，所以考慮編譯解決這個問題：

       b.這里解壓到/var/VMdisks/glibc-2.14/

[ghui@StuOS bin]$ cd /var/VMdisks/glibc-2.14/ [ghui@StuOS glibc-2.14]$ pwd /var/VMdisks/glibc-2.14 [ghui@StuOS glibc-2.14]$ ls abilist            config.h.in           intl           README.libm abi-tags           config.log            io             resolv aclocal.m4         config.make.in        libc-abis      resource aout               configure             libidn         rt argp               configure.in          libio          Rules assert             conform               LICENSES       scripts autom4te.cache     CONFORMANCE           locale         setjmp bits               COPYING               localedata     shadow BUGS               COPYING.LIB           login          shlib-versions build              cppflags-iterator.mk  mach           signal CANCEL-FCT-WAIVE   crypt                 Makeconfig     socket CANCEL-FILE-WAIVE  csu                   Makefile       soft-fp catgets            ctype                 Makefile.in    stdio-common ChangeLog          debug                 Makerules      stdlib ChangeLog.1        dirent                malloc         streams ChangeLog.10       dlfcn                 manual         string ChangeLog.11       elf                   math           sunrpc ChangeLog.12       extra-lib.mk          misc           sysdeps ChangeLog.13       extra-modules.mk      NAMESPACE      sysvipc ChangeLog.14       FAQ                   NEWS           termios ChangeLog.15       FAQ.in                nis            test-skeleton.c ChangeLog.16       gmon                  NOTES          time ChangeLog.17       gnulib                nptl           timezone ChangeLog.2        grp                   nptl_db        tls.make.c ChangeLog.3        gshadow               nscd           version.h ChangeLog.4        hesiod                nss            Versions.def ChangeLog.5        hurd                  o-iterator.mk  wcsmbs ChangeLog.6        iconv                 po             wctype ChangeLog.7        iconvdata             posix          WUR-REPORT ChangeLog.8        include               PROJECTS ChangeLog.9        inet                  pwd conf               INSTALL               README  

[ghui@StuOS glibc-2.14]$ mkdir build

[ghui@StuOS glibc-2.14]$ cd build 

[ghui@StuOS build]$ ../configure --prefix=/opt/glibc-2.14 [ghui@StuOS build]$ make -j4  [ghui@StuOS build]$ sudo make install [sudo] password for ghui:   

[ghui@StuOS bin]$ export LD_LIBRARY_PATH=/opt/glibc-2.14/lib:$LD_LIBRARY_PATH 

[ghui@StuOS glibc-2.14]$ cd /var/VMdisks/cross/mingw32/bin/ 

from:http://www.jameswxx.com/%E4%B8%AD%E9%97%B4%E4%BB%B6/%E8%A7%A3%E5%86%B3dubbo%E9%97%AE%E9%A2%98%EF%BC%9Aforbid-consumer/

線下環(huán)境經(jīng)常出現(xiàn)類似這種異常：

com.alibaba.dubbo.rpc.RpcException: Forbid consumer 10.0.53.69 access service com.kuaidadi.op.api.pay.service.PayChannelConfigRemoteService from registry 10.0.50.150:2181 use dubbo version 2.5.3, Please check registry access list (whitelist/blacklist).

public List<Invoker<T>> doList(Invocation invocation) {

 if (forbidden ) {

     throw new RpcException(RpcException.FORBIDDEN_EXCEPTION , ” Forbid consumer “ +  NetUtils. getLocalHost() + ” access service “ +        getInterface().getName() + ” from registry “ + getUrl().getAddress() + ” use dubbo version “ + Version.getVersion() + “, Please check registry access list (whitelist/blacklist).”);

}

private void refreshInvoker(List<URL> invokerUrls){

   if (invokerUrls != null && invokerUrls.size() == 1 && invokerUrls.get(0) != null && Constants.EMPTY_PROTOCOL .equals(invokerUrls.get(0).getProtocol())) {

            this.forbidden = true; // 禁止訪問

            this.methodInvokerMap = null; // 置空列表

            destroyAllInvokers(); // 關(guān)閉所有Invoker

   }

意思是如果invokerUrls的size為1，并且url的協(xié)議頭是Constants.EMPTY_PROTOCOL時，則設置forbidden為false，Constants.EMPTY_PROTOCOL的值是empty。

 

 

refreshInvoker方法什么時候被調(diào)用呢？當某個服務的provider有變化時就會被調(diào)用，例如zookeeper上某個服務的provider目錄里的內(nèi)容發(fā)生變化，則zk監(jiān)聽器會被觸發(fā)，由于provider的數(shù)量會發(fā)生變化，例如有一個新的provider啟動了，有一個provider下線了，所以必須刷新本地的對provider的連接，具體邏輯就在refreshInvoker方法里，這個方法的調(diào)用棧如下：

可以確定的是，zookeeper推送的URL的protocol部分不可能無緣無故變成了empty，肯定是由某個地方更改了，于是看一下Constants.EMPTY_PROTOCOL到底有哪些地方調(diào)用了，如下：

見圖中紅色圈圈部分，當zookeeper初次訂閱或者訂閱的信息有變更時，都會觸發(fā)toUrlsChanged方法，看看這個方法內(nèi)部都做了什么，完整代碼如下：

     private List<URL> toUrlsWithEmpty(URL consumer, String path, List<String> providers) {

        List<URL> urls = toUrlsWithoutEmpty(consumer, providers);

        if (urls == null || urls.isEmpty()) {

           int i = path.lastIndexOf(‘/’ );

          String category = i < 0 ? path : path.substring(i + 1);

          URL empty = consumer.setProtocol(Constants.EMPTY_PROTOCOL ).addParameter(Constants. CATEGORY_KEY, category);

            urls.add(empty);

        }

        return urls;

    }

可見如果toUrlsWithoutEmpty的結(jié)果是空或者size為0，則強制返回一個protocol為empty的url，看來源頭就在這里了。傳入的List<String> providers實際上就是最新的服務提供者信息，當某個服務沒有任何provider時，providers就變?yōu)橐粋€size為o的List了，導致返回一個協(xié)議頭為empty的url，進而導致forbidden為true，屏蔽了consumer調(diào)用。

毫無疑問，現(xiàn)在Gradle已經(jīng)成為java世界最火的構(gòu)建工具，風頭已經(jīng)蓋過了冗余的ant，落后的maven。Gradle是以Groovy語言編寫的一套構(gòu)建腳本的DSL，由于Groovy語法的優(yōu)雅，所以導致Gradle天生就有簡潔、可讀性強、靈活等特性。

Gradle的命令行功能也非常強大。本人從maven轉(zhuǎn)到Gradle，深深被gradle強大的命令行功能折服。通過命令行來實現(xiàn)Gradle的各種特性，就像魔法師在表演魔法一樣。

• 日志輸出。 Gradle中的日志有6個層級。從高到低分別是 ERROR（錯誤信息）、QUIET（重要信息）、WARNGING（警告信息）、LIFECYCLE（進程信息）、INFO（一般信息）、DEBUG（調(diào)試信息）。在執(zhí)行g(shù)radle task時可以適時的調(diào)整信息輸出等級，以便更方便的觀看執(zhí)行結(jié)果。

-q(或--quiet)是啟用重要信息級別，該級別下只會輸出自己在命令行下打印的信息及錯誤信息。

-i(或--info)則會輸出除debug以外的所有信息。

-d（或--debug)會輸出所有日志信息。

比如一個build.gradle有這樣一個task。

task hello << {      println 'hello world!' }

加入-q與不加-q的輸出結(jié)果不同。

$ gradle hello :hello hello world!  BUILD SUCCESSFUL  Total time: 3.546 secs $ gradle -q hello hello world!

• 堆棧跟蹤。如果執(zhí)行g(shù)radle task失敗時，如果想得到更詳細的錯誤信息，那么就可以使用-s(或--stacktrace)來輸出詳細的錯誤堆棧。你還可以使用-S(或--full-stacktrace)來輸出全部堆棧信息，不過一般不推薦這樣做，因為gradle是基于groovy語言，而groovy作為一門動態(tài)語言可能會輸出與你的錯誤代碼毫不相關(guān)的信息。

• 跳過指定的測試。如果你在執(zhí)行build的時候想跳過test task，那么可以使用-x命令。

$ gradle build -x test :compileJava UP-TO-DATE :processResources UP-TO-DATE :classes UP-TO-DATE :jar UP-TO-DATE :assemble UP-TO-DATE :check :build  BUILD SUCCESSFUL  Total time: 3.529 secs

• 繼續(xù)執(zhí)行task而忽略前面失敗的task。默認情況下，如果有某個task失敗，后續(xù)的task就不會繼續(xù)執(zhí)行。但是有時候我們想運行所有的task來一次性得到所有的構(gòu)建錯誤，那么我們可以使用--continue命令。使用--continue命令后即使遇到某些task失敗也不會停止后續(xù)task的執(zhí)行。但是需要注意的是如果某個task失敗了，那么依賴于這個task的其他task依舊不會執(zhí)行，因為這會帶來不安全的因素。

• 調(diào)用task時使用短名或縮寫。如果一個task的名稱過長，那么調(diào)用時可以只輸入部分名稱即可調(diào)用，無需輸入全名。

task helloWorld << {      println 'hello world!' }

比如調(diào)用helloWorld可以通過全名調(diào)用、前綴調(diào)用或首字母調(diào)用。

$ gradle -q helloWorld hello world! $ gradle -q hell hello world! $ gradle -q hW hello world!

• 使用指定的gradle文件調(diào)用task。默認情況下，如果你調(diào)用gradle task，那么首先會尋找當前目錄下的build.gradle文件,以及根據(jù)settings.gradle中的配置尋找子項目的build.gradle。但是有時候我們想指定使用某個gradle文件，那么可以使用-b命令。 比如當前目錄有個子目錄subproject1,里面有個叫hello.gradle。

task helloWorld << {      println 'hello world!' }

那么在當前目錄可以使用以下命令調(diào)用這個task。

$ gradle -b subproject1/hello.gradle  helloWorld :helloWorld hello world!  BUILD SUCCESSFUL  Total time: 3.752 secs

• 使用指定的項目目錄調(diào)用task。前面已經(jīng)說過，執(zhí)行g(shù)radle的task默認會在當前目錄尋找build.gradle及settings.gradle文件。如果我們想在任何地方執(zhí)行某個項目的task，那么可以使用-p來指定使用的項目。

gradle -q -p learnGradle helloWorld

這條命令是調(diào)用learnGradle這個項目下的helloWorld task。

• 顯示task之間的依賴關(guān)系。眾所周知，使用gradle tasks可以列出當前所有可被使用的task，但是并沒有顯示task之間的依賴關(guān)系。我們可以加上--all來顯示 task的依賴關(guān)系。

$ gradle tasks --all ………………  Other tasks ----------- task0     task1     task2     task3  …………

從上面可以看出task0依賴task1、task2及task3。

• 查看指定階段的依賴關(guān)系。使用gradle dependencies 可以查看項目中包的依賴關(guān)系。不過是列出了所有階段的依賴，如果項目中依賴復雜的話看起來有點頭痛。那么可以使用--configuration來查看指定階段的依賴情況。

$ gradle -q dependencies  ------------------------------------------------------------ Root project ------------------------------------------------------------  archives - Configuration for archive artifacts. No dependencies  compile - Compile classpath for source set 'main'. No dependencies  default - Configuration for default artifacts. No dependencies  runtime - Runtime classpath for source set 'main'. No dependencies  testCompile - Compile classpath for source set 'test'. \--- junit:junit:4.11      \--- org.hamcrest:hamcrest-core:1.3  testRuntime - Runtime classpath for source set 'test'. \--- junit:junit:4.11      \--- org.hamcrest:hamcrest-core:1.3

使用gradle -q dependencies --configuration testCompile可以只查看testComiple的依賴。

$ gradle -q dependencies --configuration testCompile  ------------------------------------------------------------ Root project ------------------------------------------------------------  testCompile - Compile classpath for source set 'test'. \--- junit:junit:4.11      \--- org.hamcrest:hamcrest-core:1.3

• 查看指定dependency的依賴情況。 假如我想查看項目中有沒有引入junit，那些階段引入了junit，那么可以使用dependecyInsight來查看。

$ gradle dependencyInsight --dependency junit --configuration testCompile :dependencyInsight junit:junit:4.11 \--- testCompile

注意dependencyInsight默認只會查看compile階段的依賴，如果要查看其他階段可以使用--configuration來指定。

• 使用--profile命令行可以產(chǎn)生build運行時間的報告。該報告存儲在build/report/profile目錄，名稱為build運行的時間。

$ gradle build --profile :compileJava UP-TO-DATE :processResources UP-TO-DATE :classes UP-TO-DATE :jar UP-TO-DATE :assemble UP-TO-DATE :compileTestJava UP-TO-DATE :processTestResources UP-TO-DATE :testClasses UP-TO-DATE :test UP-TO-DATE :check UP-TO-DATE :build UP-TO-DATE  BUILD SUCCESSFUL  Total time: 3.726 secs

然后在build/report/profile目錄下可以看到build的report。

這個報表非常有用，尤其是在在縮短build時間時可以快速定位那些耗時長的task。

• 試運行build。如果你想知道某個task執(zhí)行時那些task會被一起執(zhí)行，但是你又不想真正的執(zhí)行這些task，可以使用-m來試運行。

$ gradle -m build :compileJava SKIPPED :processResources SKIPPED :classes SKIPPED :jar SKIPPED :assemble SKIPPED :compileTestJava SKIPPED :processTestResources SKIPPED :testClasses SKIPPED :test SKIPPED :check SKIPPED :build SKIPPED  BUILD SUCCESSFUL  Total time: 3.53 secs

這樣我們可以一目了然的看到那些task被執(zhí)行了，又不需要花太多的時間。

• Gradle的圖形界面。

其實Gradle自帶一個圖形界面來讓習慣gui操作的人來操作Gradle。打開方式很簡單。

$ gradle --gui

這樣就會彈出一個gui界面。

通過這個gui界面可以很方面的執(zhí)行g(shù)radle的各種命令，還可以將常用的命令保存為favorites。該gui的配置信息默認被存儲在當前項目的gradle-app.setting文件中。

注意使用gradle --gui會阻塞當前終端，可以使用gradle --gui&來實現(xiàn)后臺運行。

• 重新編譯Gradle腳本。第一次運行Gradle命令，會在項目更目錄下生成一個.gradle目錄來存放編譯后的腳本。只有當構(gòu)建腳本發(fā)生修改時采用重新編譯。我們可以使用--recompile-scripts來強行重新編譯。