?OSS.Social是個(gè)開源的社交網(wǎng)站接口集成項(xiàng)目，當(dāng)前也有很多其他不錯(cuò)的項(xiàng)目，不過始終沒有我想要的那種簡單清晰，只能擼起袖子，從頭打造一個(gè)。當(dāng)前正在進(jìn)行的是對微信項(xiàng)目的開發(fā)，這里把對接口的整理，設(shè)計(jì)的思路，和項(xiàng)目的代碼實(shí)現(xiàn)方式做一個(gè)概要分享。

代碼下載地址：【github】  【開源中國】

一. 模塊劃分

?微信對外開放的接口已經(jīng)非常的多，再加上時(shí)間演進(jìn)的原因，可以說甚至有點(diǎn)雜亂。不過在大模塊上基本上還是很清晰的。

?這里針對已有的微信接口（排除支付，會在OSS.PayCenter中開源），根據(jù)接口的功能范圍，我把當(dāng)前接口主要分為以下：授權(quán)接口，功能接口，實(shí)時(shí)消息接口 三個(gè)主要模塊，每個(gè)模塊下又有子項(xiàng)，如下圖（在線查看，可以看到各個(gè)子項(xiàng)）：

 

1. 實(shí)時(shí)消息模塊（Msg文件夾）

?　　主要處理實(shí)時(shí)消息的交互，在消息中又分為普通消息和事件消息。事件消息是非常重要的一個(gè)模塊，在后續(xù)的諸多功能中起到了一個(gè)消息中樞的作用，很多重要通知都是通過這個(gè)功能推送過來的。如果接觸過消息隊(duì)列的同學(xué)，可能會發(fā)現(xiàn)這個(gè)事件消息就像是我們業(yè)務(wù)系統(tǒng)中的消息中心模塊。

2. 公眾號功能模塊（Offcial文件夾）

　　?這個(gè)模塊主要是公眾號的一些功能接口，主要針對的對象是公眾號賬戶，這類接口都有一個(gè)共同的地方，調(diào)用時(shí)需要全局accessToken。在這個(gè)模塊中，我又根據(jù)接口的功能對象，將功能進(jìn)行相應(yīng)的拆分，有了如上圖的劃分。

3. 社交接口模塊

?這個(gè)模塊是最常見的模塊，主要針對的對象都是單一用戶，在像微博，豆瓣，以及所有稍微有一定規(guī)模用戶群體的社交網(wǎng)站都會有這些功能，各家性質(zhì)不同，接口也不一，但都會有如 Oauth 授權(quán)接口，像新浪會有發(fā)送微博等功能，微信當(dāng)前主要是授權(quán)和獲取用戶基本信息。

二. 消息模塊的設(shè)計(jì)實(shí)現(xiàn)方式

　　消息模塊是微信接口中最重要的一塊功能，除了普通的消息之外，它的事件消息可以說完全是一個(gè)我們消息隊(duì)列中心，及時(shí)將各種事件push到業(yè)務(wù)方服務(wù)器上，方便我們快速處理。簡單介紹下消息模塊的實(shí)現(xiàn)方式。

a.  調(diào)用展示：

?　　下圖是消息模塊的調(diào)用展示，兩種模式，一種是最基本的模式，實(shí)體和執(zhí)行事件委托（event delegate）都是已經(jīng)封裝好的，處理邏輯就好。 另外一種是高級模式，實(shí)體和處理方法調(diào)用注冊方法

 

b.  設(shè)計(jì)思路（見下方流程圖）

? 消息模塊中主要處理的是實(shí)時(shí)的消息接收和回復(fù)。發(fā)起方是由微信調(diào)用，接收方處理消息執(zhí)行并響應(yīng)。在整個(gè)處理過程中，不管是普通消息還是事件消息，都會經(jīng)歷一個(gè)完整的生命周期，在這個(gè)周期里包含了：接收=》解析=》業(yè)務(wù)邏輯執(zhí)行=》封裝消息 =》回復(fù)

?針對當(dāng)前生命周期，接收和回復(fù)都是通用的，主要是業(yè)務(wù)邏輯的不同， 在這個(gè)模塊中我們采用Handler的處理方式，由主入口進(jìn)入，針對不同的消息類型采用對應(yīng)的解析，執(zhí)行和封裝。

?也就是說開發(fā)者需要關(guān)心的只是 接收實(shí)體，執(zhí)行邏輯方法和返回實(shí)體。對于微信提供的基礎(chǔ)消息類型來說，這里就非常清晰了，預(yù)先定義好對應(yīng)的接收實(shí)體，和相應(yīng)的處理方法委托，調(diào)用時(shí)給對應(yīng)的委托添加具體執(zhí)行方法即可。在OSS.Social的項(xiàng)目中，我的實(shí)現(xiàn)方式是，通過泛型獲取接收實(shí)體，通過定義事件類型的委托，作為業(yè)務(wù)邏輯方法，開發(fā)者只需要在業(yè)務(wù)方法中返回需要的消息類型即可。（為何使用事件類型委托 ，在代碼講解章節(jié)將會講解），具體方式見上圖的基礎(chǔ)調(diào)用方式。

?同時(shí)，除了微信自身提供的基礎(chǔ)消息類型之外，我們還需要考慮到后續(xù)的事件消息擴(kuò)展，這里強(qiáng)調(diào)一下擴(kuò)展的必要性，微信的事件消息會有很多 ，同時(shí)可能隨時(shí)會有新的字段調(diào)整等，像卡券中渠道等字段。也就是說我們需要一個(gè)高級的消息處理模式，開發(fā)者能夠自己定義接收實(shí)體，以及相應(yīng)的自定義事件類型。

?消息生命周期執(zhí)行時(shí)，我們需要知道的是： 對應(yīng)的消息類型名稱，對應(yīng)的實(shí)體類型，和事件方法。三個(gè)元素齊全才能完成整個(gè)生命周期，也就是說我們需要開發(fā)者在開發(fā)時(shí)傳入以上信息，底層框架能提供保存的功能，事件執(zhí)行時(shí)根據(jù)對應(yīng)消息類型，實(shí)例化對應(yīng)的消息實(shí)體，傳入執(zhí)行事件。在OSS.Social 項(xiàng)目中，我采用的方式是提供Register方法，底層使用ConcurrentDictionary字典保存對應(yīng)的類型和方法，在解析過程中通過CreateInstance反射獲取對應(yīng)的消息實(shí)體，傳入委托方法。

?這里沒有把所有的事件消息全部封裝，而是提供了一個(gè)高級消息處理模式。其一：我們要的是簡單，清晰，擴(kuò)展強(qiáng)，全部封裝起來不僅代碼臃腫，給調(diào)用者也造成一定的限制。其次：主要是一個(gè)個(gè)全寫完，估計(jì)這雙手要擼禿皮了。

?

?這個(gè)模塊的主要思路就是把過程流程化，明確需要哪幾個(gè)步驟，然后每個(gè)步驟可能的情況進(jìn)行細(xì)化。這里只是提供了一個(gè)簡單的概要思路，后續(xù)會有針對當(dāng)前章節(jié)的詳細(xì)講解。

c. 流程圖

 

感興趣的同學(xué)可以去下載源碼查看，歡迎貢獻(xiàn)。后邊其他部分，以及相關(guān)的代碼講解都會慢慢放出來，希望大家一塊學(xué)習(xí)進(jìn)步！

 

微信公眾號：