⑴ Android源碼解析Window系列第（一）篇---Window的基本認識和Activity的載入流程
您可能聽說過View ,ViewManager,Window,PhoneWindow,WindowManager,WindowManagerService,可是你知道這幾個類是什麼關系，幹嘛用的。概括的來說，View是放在Window中的，Window是一個抽象類，它的具體實現是PhoneWindow，PhoneWindow還有個內部類DecorView，WindowManager是一個interface，繼承自ViewManager，它是外界訪問Window的入口，，提供了add/remove/updata的方法操作View，WindowManager與WindowManagerSerice是個跨進程的過程，WindowManagerService的職責是對系統中的所有窗口進行管理。如果您不太清楚，建議往下看，否則就不要看了。
Android系統的Window有很多種，大體上來說，Framework定義了三種窗口類型；
這就是Framework定義了三種窗口類型，這三種類型定義在WindowManager的內部類LayoutParams中，WindowManager講這三種類型 進行了細化，把每一種類型都用一個int常量來表示，這些常量代表窗口所在的層，WindowManagerService在進行窗口疊加的時候，會按照常量的大小分配不同的層，常量值越大，代表位置越靠上面， 所以我們可以猜想一下，應用程序Window的層值常量要小於子Window的層值常量，子Window的層值常量要小於系統Window的層值常量。 Window的層級關系如下所示。
上面說了Window分為三種，用Window的type區分，在搞清楚Window的創建之前，我們需要知道怎麼去描述一個Window，我們就把Window當做一個實體類，給我的感覺，它必須要下面幾個欄位。
實際上WindowManager.LayoutParams對Window有很詳細的定義。
提取幾個重要的參數
Window是一個是一個抽象的概念，千萬不要認為我們所看到的就是Window,我們平時所看到的是視圖，每一個Window都對應著一個View，View和Window通過ViewRootImpl來建立聯系。有了View，Window的存在意義在哪裡呢，因為View不能單獨存在，它必須依附著Window，所以有視圖的地方就有Window,比如Activity,一個Dialog,一個PopWindow,一個菜單，一個Toast等等。
通過上面我們知道視圖和Window的關系，那麼有一個問題，是先有視圖，還是先有Window。這個答案只有在源碼中找了。應用程序的入口類是ActivityThread，在ActivityThread中有performLaunchActivity來啟動Activity，這個performLaunchActivity方法內部會創建一個Activity。
如果activity不為null,就會調用attach,在attach方法中通過PolicyManager創建了Window對象，並且給Window設置了回調介面。
PolicyManager的實現類是Policy
這樣Window就創建出來了， 所以先有Window，後有視圖，視圖依賴Window存在 ，再說一說視圖（Activity）為Window設置的回調介面。
Activity實現了這個回調介面，當Window的狀態發生變化的時候，就會回調Activity中實現的這些介面，有些回調介面我們還是熟悉的，dispatchTouchEvent，onAttachedToWindow，onDetachedFromWindow等。
下面分析view是如何附屬到window上的，通過上面可以看到，在attach之後就要執行callActivityOnCreate，在onCreate中我們會調用setContentView方法。
getWindow獲取了Window對象，Window的具體實現類是PhoneWindow,所以要看PhoneWindow的setContentView方法。
這里涉及到一個mContentParent變數，他是一個DecorView的一部分，DecorView是PhoneWindow的一個內部類，我先介紹一下關於DecorView的知識。
DecorView是Activity的頂級VIew，DecorView繼承自FrameLayout,在DecorView中有上下兩個部分，上面是標題欄，下面是內容欄，我們通過PhoneWindow的setContentView所設置的布局文件是加到內容欄（mContentParent）裡面的，View層的事件都是先經過DecorView在傳遞給我們的View的。
OK在回到setContentView的源碼分析，我們可以得到Activity的Window創建需要三步。
- 1、 如果沒有DecorView，在installDecor中創建DecorView。
- 2、將View添加到decorview中的mContentParent中。
- 3、回調Activity的onContentChanged介面。
先看看第一步，installDecor的源碼
installDecor中調用了generateDecor，繼續看
直接給new一個DecorView，有了DecorView之後，就可以載入具體的布局文件到DecorView中了，具體的布局文件和系統和主題有關系。
在看第二步，將View添加到decorview中的mContentParent中。
直接將Activity視圖加到DecorView的mContentParent中，最後一步，回調Activity的onContentChanged介面。在Activity中尋找onContentChanged方法，它是個空實現，我們可以在子Activity中處理。
到此DecorView被創建完畢，我們一開始從Thread中的handleLaunchActivity方法開始分析，首先載入Activity的位元組碼文件，利用反射的方式創建一個Activity對象，調用Activity對象的attach方法，在attach方法中，創建系統需要的Window並為設置回調，這個回調定義在Window之中，由Activity實現，當Window的狀態發生變化的時候，就會回調Activity實現的這些回調方法。調用attach方法之後，Window被創建完成，這時候需要關聯我們的視圖，在handleLaunchActivity中的attach執行之後就要執行handleLaunchActivity中的callActivityOnCreate，在onCreate中我們會調用setContentView方法。通過setContentView，創建了Activity的頂級View---DecorView,DecorView的內容欄（mContentParent）用來顯示我們的布局。 這個是我們上面分析得到了一個大致流程，走到這里，這只是添加的過程，還要有一個顯示的過程，顯示的過程就要調用handleLaunchActivity中的handleResumeActivity方法了。最後會調用makeVisible方法。
這裡面首先拿到WindowManager對象，用tWindowManager 的父介面ViewManager接收，ViewManager可以
最後調用 mDecor.setVisibility(View.VISIBLE)設置mDecor可見。到此，我們終於明白一個Activity是怎麼顯示在我們的面前了。
參考鏈接：
http://blog.csdn.net/feiclear_up/article/details/49201357
⑵ 求一段linux操作系統源代碼分析
Linux內核的配置系統由三個部分組成，分別是：
Makefile：分布在 Linux 內核源代碼中的 Makefile，定義 Linux 內核的編譯規則；
配置文件（config.in）：給用戶提供配置選擇的功能；
配置工具：包括配置命令解釋器（對配置腳本中使用的配置命令進行解釋）和配置用戶界面（提供基於字元界面、基於 Ncurses 圖形界面以及基於 Xwindows 圖形界面的用戶配置界面，各自對應於 Make config、Make menuconfig 和 make xconfig）。
這些配置工具都是使用腳本語言，如 Tcl/TK、Perl 編寫的（也包含一些用 C 編寫的代碼）。本文並不是對配置系統本身進行分析，而是介紹如何使用配置系統。所以，除非是配置系統的維護者，一般的內核開發者無須了解它們的原理，只需要知道如何編寫 Makefile 和配置文件就可以。所以，在本文中，我們只對 Makefile 和配置文件進行討論。另外，凡是涉及到與具體 CPU 體系結構相關的內容，我們都以 ARM 為例，這樣不僅可以將討論的問題明確化，而且對內容本身不產生影響。
2． Makefile
2.1 Makefile 概述
Makefile 的作用是根據配置的情況，構造出需要編譯的源文件列表，然後分別編譯，並把目標代碼鏈接到一起，最終形成 Linux 內核二進制文件。
由於 Linux 內核源代碼是按照樹形結構組織的，所以 Makefile 也被分布在目錄樹中。Linux 內核中的 Makefile 以及與 Makefile 直接相關的文件有：
Makefile：頂層 Makefile，是整個內核配置、編譯的總體控制文件。
.config：內核配置文件，包含由用戶選擇的配置選項，用來存放內核配置後的結果（如 make config）。
arch/*/Makefile：位於各種 CPU 體系目錄下的 Makefile，如 arch/arm/Makefile，是針對特定平台的 Makefile。
各個子目錄下的 Makefile：比如 drivers/Makefile，負責所在子目錄下源代碼的管理。
Rules.make：規則文件，被所有的 Makefile 使用。
用戶通過 make config 配置後，產生了 .config。頂層 Makefile 讀入 .config 中的配置選擇。頂層 Makefile 有兩個主要的任務：產生 vmlinux 文件和內核模塊（mole）。為了達到此目的，頂層 Makefile 遞歸的進入到內核的各個子目錄中，分別調用位於這些子目錄中的 Makefile。至於到底進入哪些子目錄，取決於內核的配置。在頂層 Makefile 中，有一句：include arch/$(ARCH)/Makefile，包含了特定 CPU 體系結構下的 Makefile，這個 Makefile 中包含了平台相關的信息。
位於各個子目錄下的 Makefile 同樣也根據 .config 給出的配置信息，構造出當前配置下需要的源文件列表，並在文件的最後有 include $(TOPDIR)/Rules.make。
Rules.make 文件起著非常重要的作用，它定義了所有 Makefile 共用的編譯規則。比如，如果需要將本目錄下所有的 c 程序編譯成匯編代碼，需要在 Makefile 中有以下的編譯規則：
%.s: %.c
$(CC) $(CFLAGS) -S $< -o $@
有很多子目錄下都有同樣的要求，就需要在各自的 Makefile 中包含此編譯規則，這會比較麻煩。而 Linux 內核中則把此類的編譯規則統一放置到 Rules.make 中，並在各自的 Makefile 中包含進了 Rules.make（include Rules.make），這樣就避免了在多個 Makefile 中重復同樣的規則。對於上面的例子，在 Rules.make 中對應的規則為：
%.s: %.c
$(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(CFLAGS_$(*F)) $(CFLAGS_$@) -S $< -o $@
2.2 Makefile 中的變數
頂層 Makefile 定義並向環境中輸出了許多變數，為各個子目錄下的 Makefile 傳遞一些信息。有些變數，比如 SUBDIRS，不僅在頂層 Makefile 中定義並且賦初值，而且在 arch/*/Makefile 還作了擴充。
常用的變數有以下幾類：
1） 版本信息
版本信息有：VERSION，PATCHLEVEL, SUBLEVEL, EXTRAVERSION，KERNELRELEASE。版本信息定義了當前內核的版本，比如 VERSION=2，PATCHLEVEL=4，SUBLEVEL=18，EXATAVERSION=-rmk7，它們共同構成內核的發行版本KERNELRELEASE：2.4.18-rmk7
2） CPU 體系結構：ARCH
在頂層 Makefile 的開頭，用 ARCH 定義目標 CPU 的體系結構，比如 ARCH:=arm 等。許多子目錄的 Makefile 中，要根據 ARCH 的定義選擇編譯源文件的列表。
3） 路徑信息：TOPDIR, SUBDIRS
TOPDIR 定義了 Linux 內核源代碼所在的根目錄。例如，各個子目錄下的 Makefile 通過 $(TOPDIR)/Rules.make 就可以找到 Rules.make 的位置。
SUBDIRS 定義了一個目錄列表，在編譯內核或模塊時，頂層 Makefile 就是根據 SUBDIRS 來決定進入哪些子目錄。SUBDIRS 的值取決於內核的配置，在頂層 Makefile 中 SUBDIRS 賦值為 kernel drivers mm fs net ipc lib；根據內核的配置情況，在 arch/*/Makefile 中擴充了 SUBDIRS 的值，參見4）中的例子。
4） 內核組成信息：HEAD, CORE_FILES, NETWORKS, DRIVERS, LIBS
Linux 內核文件 vmlinux 是由以下規則產生的：
vmlinux: $(CONFIGURATION) init/main.o init/version.o linuxsubdirs
$(LD) $(LINKFLAGS) $(HEAD) init/main.o init/version.o
--start-group
$(CORE_FILES)
$(DRIVERS)
$(NETWORKS)
$(LIBS)
--end-group
-o vmlinux
可以看出，vmlinux 是由 HEAD、main.o、version.o、CORE_FILES、DRIVERS、NETWORKS 和 LIBS 組成的。這些變數（如 HEAD）都是用來定義連接生成 vmlinux 的目標文件和庫文件列表。其中，HEAD在arch/*/Makefile 中定義，用來確定被最先鏈接進 vmlinux 的文件列表。比如，對於 ARM 系列的 CPU，HEAD 定義為：
HEAD := arch/arm/kernel/head-$(PROCESSOR).o
arch/arm/kernel/init_task.o
表明 head-$(PROCESSOR).o 和 init_task.o 需要最先被鏈接到 vmlinux 中。PROCESSOR 為 armv 或 armo，取決於目標 CPU。 CORE_FILES，NETWORK，DRIVERS 和 LIBS 在頂層 Makefile 中定義，並且由 arch/*/Makefile 根據需要進行擴充。 CORE_FILES 對應著內核的核心文件，有 kernel/kernel.o，mm/mm.o，fs/fs.o，ipc/ipc.o，可以看出，這些是組成內核最為重要的文件。同時，arch/arm/Makefile 對 CORE_FILES 進行了擴充：
# arch/arm/Makefile
# If we have a machine-specific directory, then include it in the build.
MACHDIR := arch/arm/mach-$(MACHINE)
ifeq ($(MACHDIR),$(wildcard $(MACHDIR)))
SUBDIRS += $(MACHDIR)
CORE_FILES := $(MACHDIR)/$(MACHINE).o $(CORE_FILES)
endif
HEAD := arch/arm/kernel/head-$(PROCESSOR).o
arch/arm/kernel/init_task.o
SUBDIRS += arch/arm/kernel arch/arm/mm arch/arm/lib arch/arm/nwfpe
CORE_FILES := arch/arm/kernel/kernel.o arch/arm/mm/mm.o $(CORE_FILES)
LIBS := arch/arm/lib/lib.a $(LIBS)
5） 編譯信息：CPP, CC, AS, LD, AR，CFLAGS，LINKFLAGS
在 Rules.make 中定義的是編譯的通用規則，具體到特定的場合，需要明確給出編譯環境，編譯環境就是在以上的變數中定義的。針對交叉編譯的要求，定義了 CROSS_COMPILE。比如：
CROSS_COMPILE = arm-linux-
CC = $(CROSS_COMPILE)gcc
LD = $(CROSS_COMPILE)ld
......
CROSS_COMPILE 定義了交叉編譯器前綴 arm-linux-，表明所有的交叉編譯工具都是以 arm-linux- 開頭的，所以在各個交叉編譯器工具之前，都加入了 $(CROSS_COMPILE)，以組成一個完整的交叉編譯工具文件名，比如 arm-linux-gcc。
CFLAGS 定義了傳遞給 C 編譯器的參數。
LINKFLAGS 是鏈接生成 vmlinux 時，由鏈接器使用的參數。LINKFLAGS 在 arm/*/Makefile 中定義，比如：
# arch/arm/Makefile
LINKFLAGS :=-p -X -T arch/arm/vmlinux.lds
6） 配置變數CONFIG_*
.config 文件中有許多的配置變數等式，用來說明用戶配置的結果。例如 CONFIG_MODULES=y 表明用戶選擇了 Linux 內核的模塊功能。
.config 被頂層 Makefile 包含後，就形成許多的配置變數，每個配置變數具有確定的值：y 表示本編譯選項對應的內核代碼被靜態編譯進 Linux 內核；m 表示本編譯選項對應的內核代碼被編譯成模塊；n 表示不選擇此編譯選項；如果根本就沒有選擇，那麼配置變數的值為空。
2.3 Rules.make 變數
前面講過，Rules.make 是編譯規則文件，所有的 Makefile 中都會包括 Rules.make。Rules.make 文件定義了許多變數，最為重要是那些編譯、鏈接列表變數。
O_OBJS，L_OBJS，OX_OBJS，LX_OBJS：本目錄下需要編譯進 Linux 內核 vmlinux 的目標文件列表，其中 OX_OBJS 和 LX_OBJS 中的 "X" 表明目標文件使用了 EXPORT_SYMBOL 輸出符號。
M_OBJS，MX_OBJS：本目錄下需要被編譯成可裝載模塊的目標文件列表。同樣，MX_OBJS 中的 "X" 表明目標文件使用了 EXPORT_SYMBOL 輸出符號。
O_TARGET，L_TARGET：每個子目錄下都有一個 O_TARGET 或 L_TARGET，Rules.make 首先從源代碼編譯生成 O_OBJS 和 OX_OBJS 中所有的目標文件，然後使用 $(LD) -r 把它們鏈接成一個 O_TARGET 或 L_TARGET。O_TARGET 以 .o 結尾，而 L_TARGET 以 .a 結尾。
⑶ github desktop怎麼看源碼
打開一個repository
然後Repository - Open in Visual Studio Code
只能這樣用VSCode來看，對於只是看別人的源代碼的話，真的就像樓上說的一樣，看起來不錯實際上沒卵用
本質上就是你從網頁上下下來的代碼自己用別的編輯器打開而已，還多了一道步驟
這個東西真正好用的點在於你可以直觀看到項目每次更新多了少了哪些代碼，以及對你自己電腦上大量需要託管的代碼管理起來比較方便
⑷ Netty 源碼解析 ——— ChannelConfig 和 Attribute
嗯，本文與其說是ChannelConfig、Attribute源碼解析，不如說是對ChannelConfig以及Attribute結構層次的分析。因為這才是它們在Netty中使用到的重要之處。
在 Netty 源碼解析 ——— 服務端啟動流程 (下) 中說過，當我們在構建NioServerSocketChannel的時候同時會構建一個NioServerSocketChannelConfig對象賦值給NioServerSocketChannel的成員變數config。
而這一個NioServerSocketChannelConfig是當前NioServerSocketChannel配置屬性的集合。NioServerSocketChannelConfig主要用於對NioServerSocketChannel相關配置的設置(如，網路的相關參數配置)，比如，配置Channel是否為非阻塞、配置連接超時時間等等。
NioServerSocketChannelConfig其實是一個ChannelConfig實例。ChannelConfig表示為一個Channel相關的配置屬性的集合。所以NioServerSocketChannelConfig就是針對於NioServerSocketChannel的配置屬性的集合。
ChannelConfig是Channel所需的公共配置屬性的集合，如，setAllocator(設置用於channel分配buffer的分配器)。而不同類型的網路傳輸對應的Channel有它們自己特有的配置，因此可以通過擴展ChannelConfig來補充特有的配置，如，ServerSocketChannelConfig是針對基於TCP連接的服務端ServerSocketChannel相關配置屬性的集合，它補充了針對TCP服務端所需的特有配置的設置setBacklog、setReuseAddress、setReceiveBufferSize。
DefaultChannelConfig作為ChannelConfig的默認實現，對ChannelConfig中的配置提供了默認值。
接下來，我們來看一個設置ChannelConfig的流程：
serverBootstrap.option(ChannelOption.SO_REUSEADDR, true);
我們可以在啟動服務端前通過ServerBootstrap來進行相關配置的設置，該選項配置會在Channel初始化時被獲取並設置到Channel中，最終會調用底層ServerSocket.setReuseAddress方法來完成配置的設置。
ServerBootstrap的init()方法：
首先對option和value進行校驗，其實就是進行非空校驗。
然後判斷對應的是哪個常量屬性，並進行相應屬性的設置。如果傳進來的ChannelOption不是已經設定好的常量屬性，則會列印一條警告級別的日誌，告知這是未知的channel option。
Netty提供ChannelOption的一個主要的功能就是讓特定的變數的值給類型化。因為從』ChannelOption<T> option』和』T value』可以看出，我們屬性的值類型T，是取決於ChannelOption的泛型的，也就屬性值類型是由屬性來決定的。
這里，我們可以看到有個ChannelOption類，它允許以類型安全的方式去配置一個ChannelConfig。支持哪一種ChannelOption取決於ChannelConfig的實際的實現並且也可能取決於它所屬的傳輸層的本質。
可見ChannelOption是一個Consant擴展類，Consant是Netty提供的一個單例類，它能安全去通過』==』來進行比較操作。通過ConstantPool進行管理和創建。
常量由一個id和name組成。id：表示分配給常量的唯一數字；name：表示常量的名字。
如上所說，Constant是由ConstantPool來進行管理和創建的，那麼ConstantPool又是個什麼樣的類了？
首先從constants中get這個name對應的常量，如果不存在則調用newConstant()來構建這個常量tempConstant，然後在調用constants.putIfAbsent方法來實現「如果該name沒有存在對應的常量，則插入，否則返回該name所對應的常量。(這整個的過程都是原子性的)」，因此我們是根據putIfAbsent方法的返回來判斷該name對應的常量是否已經存在於constants中的。如果返回為null，則說明當前創建的tempConstant就為name所對應的常量；否則，將putIfAbsent返回的name已經對應的常量值返回。(注意，因為ConcurrentHashMap不會允許value為null的情況，所以我們可以根據putIfAbsent返回為null則代表該name在此之前並未有對應的常量值)
正如我們前面所說的，這個ConstantPool<ChannelOption<Object>> pool(即，ChannelOption常量池)是ChannelOption的一個私有靜態成員屬性，用於管理和創建ChannelOption。
這些定義好的ChannelOption常量都已經存儲數到ChannelOption的常量池(ConstantPool)中了。
注意，ChannelOption本身並不維護選項值的信息，它只是維護選項名字本身。比如，「public static final ChannelOption<Integer> SO_RCVBUF = valueOf("SO_RCVBUF");」👈這只是維護了「SO_RCVBUF」這個選項名字的信息，同時泛型表示選擇值類型，即「SO_RCVBUF」選項值為Integer。
好了，到目前為止，我們對Netty的ChannelOption的設置以及底層的實現已經分析完了，簡單的來說：Netty在初始化Channel時會構建一個ChannelConfig對象，而ChannelConfig是Channel配置屬性的集合。比如，Netty在初始化NioServerSocketChannel的時候同時會構建一個NioServerSocketChannelConfig對象，並將其賦值給NioServerSocketChannel的成員變數config，而這個config(NioServerSocketChannelConfig)維護了NioServerSocketChannel的所有配置屬性。比如，NioServerSocketChannelConfig提供了setConnectTimeoutMillis方法來設置NioServerSocketChannel連接超時的時間。
同時，程序可以通過ServerBootstrap或Boostrap的option(ChannelOption<T> option, T value)方法來實現配置的設置。這里，我們通過ChannelOption來實現配置的設置，ChannelOption中已經將常用的配置項預定義為了常量供我們直接使用，同時ChannelOption的一個主要的功能就是讓特定的變數的值給類型化。因為從』ChannelOption<T> option』和』T value』可以看出，我們屬性的值類型T，是取決於ChannelOption的泛型的，也就屬性值類型是由屬性來決定的。
一個attribute允許存儲一個值的引用。它可以被自動的更新並且是線程安全的。
其實Attribute就是一個屬性對象，這個屬性的名稱為AttributeKey<T> key，而屬性的值為T value。
我們可以通過程序ServerBootstrap或Boostrap的attr方法來設置一個Channel的屬性，如：
serverBootstrap.attr(AttributeKey.valueOf("userID"), UUID.randomUUID().toString());
當Netty底層初始化Channel的時候，就會將我們設置的attribute給設置到Channel中：
如上面所說，Attribute就是一個屬性對象，這個屬性的名稱為AttributeKey<T> key，而屬性的值為T value。
而AttributeKey也是Constant的一個擴展，因此也有一個ConstantPool來管理和創建，這和ChannelOption是類似的。
Channel類本身繼承了AttributeMap類，而AttributeMap它持有多個Attribute，這些Attribute可以通過AttributeKey來訪問的。所以，才可以通過channel.attr(key).set(value)的方式將屬性設置到channel中了(即，這里的attr方法實際上是AttributeMap介面中的方法)。
AttributeKey、Attribute、AttributeMap間的關系：
AttributeMap相對於一個map，AttributeKey相當於map的key，Attribute是一個持有key(AttributeKey)和value的對象。因此在map中我們可以通過AttributeKey key獲取Attribute，從而獲取Attribute中的value(即,屬性值)。
Q：ChannelHandlerContext和Channel都提供了attr方法，那麼它們設置的屬性作用域有什麼不同了？
A：在Netty 4.1版本之前，它們兩設置的屬性作用域確實存在著不同，但從Netty 4.1版本開始，它們兩設置的屬性的作用域已經完全相同了。
若文章有任何錯誤，望大家不吝指教:)
聖思園《精通並發與Netty》
⑸ Feign源碼解析二
本文會基於Feign源碼，看看Feign到底是怎麼實現遠程調用
上文中，我們的 user-service 服務需要調用遠程的 order-service 服務完成一定的業務邏輯，而基本實現是order-service提供一個spi的jar包給user-service依賴，並且在user-service的啟動類上添加了一個註解
這個註解就是@EnableFeignClients，接下來我們就從這個註解入手，一步一步解開Feign的神秘面紗
該註解類上的注釋大概的意思就是：
掃描那些被聲明為 Feign Clients (只要有 org.springframework.cloud.openfeign.FeignClient 註解修飾的介面都是Feign Clients介面)的介面
下面我們繼續追蹤源碼，看看到底什麼地方用到了這個註解
利用IDEA的查找調用鏈快捷鍵，可以發現在.class類型的文件中只有一個文件用到了這個註解
OK，下面主要就是看這個類做了什麼
通過UML圖我們發現該類分別實現了 ImportBeanDefinitionRegistrar ， ResourceLoaderAware 以及 EnvironmentAware 介面
這三個介面均是spring-framework框架的spring-context模塊下的介面，都是和spring上下文相關，具體作用下文會分析
總結下來就是利用這兩個重要屬性，一個獲取應用配置屬性，一個可以載入classpath下的文件，那麼FeignClientsRegistrar持有這兩個東西之後要做什麼呢？
上面將bean配置類包裝成 FeignClientSpecification ，注入到容器。該對象非常重要，包含FeignClient需要的 重試策略 ， 超時策略 ， 日誌 等配置，如果某個FeignClient服務沒有設置獨立的配置類，則讀取默認的配置，可以將這里注冊的bean理解為整個應用中所有feign的默認配置
由於 FeignClientsRegistrar 實現了 ImportBeanDefinitionRegistrar 介面，這里簡單提下這個介面的作用
我們知道在spring框架中，我們如果想注冊一個bean的話主要由兩種方式：自動注冊/手動注冊
知道了 ImportBeanDefinitionRegistrar 介面的作用，下面就來看下 FeignClientsRegistrar 類是何時被載入實例化的
通過IDEA工具搜索引用鏈，發現該類是在註解@EnableFeignClients上被import進來的，文章開始的圖片中有
這里提下@Import註解的作用
該註解僅有一個屬性value，使用該註解表明導入一個或者多個@Configuration類，其作用和.xml文件中的<import>等效，其允許導入@Configuration類，ImportSelector介面/ImportBeanDefinitionRegistrar介面的實現，也同樣可以導入一個普通的組件類
注意，如果是XML或非@Configuration的bean定義資源需要被導入的話，需要使用@ImportResource註解代替
這里我們導入的FeignClientsRegistrar類正是一個ImportBeanDefinitionRegistrar介面的實現
FeignClientsRegistrar重寫了該介面的 registerBeanDefinitions 方法，該方法有兩個參數註解元數據 metadata 和bean定義注冊表 registry
該方法會由spring負責調用，繼而注冊所有標注為@FeignClient註解的bean定義
下面看registerBeanDefinitions方法中的第二個方法，在該方法中完成了所有@FeignClient註解介面的掃描工作，以及注冊到spring中，注意這里注冊bean的類型為 FeignClientFactoryBean ，下面細說
總結一下該方法，就是掃描@EnableFeignClients註解上指定的basePackage或clients值，獲取所有@FeignClient註解標識的介面，然後將這些介面一一調用以下 兩個重要方法 完成 注冊configuration配置bean 和注冊 FeignClient bean
斷點位置相當重要
BeanDefinitionBuilder definition = BeanDefinitionBuilder.genericBeanDefinition(FeignClientFactoryBean.class);
這里是利用了spring的代理工廠來生成代理類，即這里將所有的 feignClient的描述信息 BeanDefinition 設定為 FeignClientFactoryBean 類型，該類繼承自FactoryBean，因此這是一個代理類，FactoryBean是一個工廠bean，用作創建代理bean，所以得出結論，feign將所有的 feignClient bean定義的類型包裝成 FeignClientFactoryBean
最終其實就是存入了BeanFactory的beanDefinitionMap中
那麼代理類什麼時候會觸發生成呢？ 在spring 刷新容器時 ，會根據beanDefinition去實例化bean，如果beanDefinition的beanClass類型為代理bean，則會調用其 T getObject() throws Exception; 方法生成代理bean，而我們實際利用注入進來的FeignClient介面就是這些一個個代理類
這里有一個需要注意的點，也是開發中會遇到的一個 啟動報錯點
如果我們同時定義了兩個不同名稱的介面 （同一個包下/或依賴方指定全部掃描我們提供的 @FeignClient ），且這兩個 @FeignClient 介面註解的 value/name/serviceId 值一樣的話，依賴方拿到我們的提供的spi依賴，啟動類上 @EnableFeignClients 註解掃描能同時掃描到這兩個介面，就會 啟動報錯
原因就是Feign會為每個@FeignClient註解標識的介面都注冊一個以serviceId/name/value為key，FeignClientSpecification類型的bean定義為value去spring注冊bean定義，又默認不允許覆蓋bean定義，所以報錯
官方提示給出的解決方法要麼改個@FeignClient註解的serviceId，name，value屬性值，要麼就開啟spring允許bean定義覆寫
至此我們知道利用在springboot的啟動類上添加的@EnableFeignClients註解，該註解中import進來了一個手動注冊bean的 FeignClientsRegistrar注冊器 ，該注冊器會由spring載入其 registerBeanDefinitions方法 ，由此來掃描所有@EnableFeignClients註解定義的basePackages包路徑下的所有標注為@FeignClient註解的介面，並將其注冊到spring的bean定義Map中，並實例化bean
下一篇博文中，我會分析為什麼我們在調用（@Resource）這些由@FeignClient註解的bean的方法時會發起 遠程調用