U8SDK最新視頻教程已經遷移至B站：https://space.bilibili.com/15265144
題記：很多做游戲開發的人，估計都或多或少地接過渠道SDK，什么UC，當樂，91，小米，360……據統計國內市場當前不下於100家渠道，還包括一些沒有SDK的小渠道。每個渠道SDK接入的方法呢，多是大同小異。但是，正是這些小異，又讓SDK的接入，產生了無窮無盡的變數。所以，接入SDK之前，如果你沒有經驗，或者沒有被SDK坑過，那么當你看到這系列文章的時候，你很幸運，你可以避免這一切了。如果你之前被坑過，而且還在繼續被坑着，那么現在，就是你解脫的時刻。
完成一個SDK的接入並沒有多少技術含量，但是能接入100個SDK，而且能做到維護容易，結構清晰，安全可靠，一勞永逸就不是那么容易的事情了。這也是為什么，世面上出現了那么多打包工具的介紹，SDK接入方法的介紹…..而且，還各不相同。
隨着手游的爆發，做手游的多了，被坑的人多了，那么總會有一些能人異士不甘其苦，開始發動腦筋，去尋求一套既可以服務於自身，也可以服務於他人的統一SDK接入框架。俗話說，有痛苦，就會有需求。所以，SDK接入這個小市場（或者這個市場也很不小）就涌現出了，像棱鏡SDK，AnySDK，易接等這樣專門做SDK接入的公司或者機構。他們自認為，他們是時代的拯救者。他們的出現，會給廣大還在忍受着苦逼SDK接入的童鞋們帶來一片光明。然而，事實上呢？
這套統一的SDK接入框架本身，就有着和實際情形相矛盾的地方。因為，他們都無一例外地要求，游戲開發商在接入他們那個抽象框架時，服務器端的登陸認證，和支付回調都走他們的服務器。但是，就是這一點，讓幾乎所有的游戲開發商望而卻步。為什么呢？因為，對於游戲開發商來說，還有什么比用戶數據和支付數據更重要呢？讓這些數據走別人的服務器過一趟，豈不是比讓他們的老婆放在別人的家里睡兩晚更加難受呢？
但是，像棱鏡SDK，AnySDK那一套東西，還真的很好。不用呢，又有點心痛的感覺。那么問題來了，能不能自己來實現並維護一套像棱鏡SDK，或者AnySDK那樣的框架，作為公司自己的統一SDK接入解決方案呢？答案是，當然可以。只不過，自己需要苦逼那么一次，之后就解脫了。因為第一次，每個渠道SDK還是要自己接入的。但是，想到這些東東都是自己的，自己開發，自己維護，一個字：踏實。哦，錯了，是兩個字。
本系列教程，我們就來從頭到尾，實現一套類似棱鏡SDK，或者AnySDK的那么一套東西。那么，我們先來分析一下，接入一個SDK，我們需要做實現哪些東西。
1、首先，客戶端需要接入多款SDK，為了能夠多款游戲重用，我們不可以在游戲里面直接去接入每個SDK，而是需要將游戲和SDK接入分離。
2、上面既然說了SDK接入和游戲分離，那么我們就需要抽象出一個SDK接入框架，游戲只需要接入這個框架即可，然后每個渠道SDK來實現這個框架。
3、我們需要實現一個打包工具，不可能100個渠道包，手動一個一個去點擊打包，那是會死人的。
4、服務器端，同樣得，為了支持多款游戲，我們需要一個統一的用戶登錄認證中心，和一個統一的支付中心。
所以，我們這套東西，應該有以下幾個部分：
1、統一SDK接入框架
2、各個SDK接入實現
3、一鍵打包工具
4、統一的登陸認證中心和支付中心
好，整體的思路有了，我們這好歹也是和棱鏡SDK，AnySDK差不多牛逼的玩意，怎么可以沒有名字呢？我們姑且叫他 U8 SDK吧。現在，就讓我們再來分析下，一般SDK接入都有兩大部分。一部分是登陸，一部分是支付。那么我們的u8 sdk自然也一樣，我們需要把整個登陸的流程，和整個支付的流程給好好規划一下。
我們先看登陸流程，如果不使用這套框架，直接接入SDK，登陸的流程是什么樣呢？我們這里可以看下UC SDK他的登陸流程圖：
1.“游戲客戶端”調用“SDK 客戶端”的登錄功能，“SDK 客戶端”引導用戶輸入 用戶名密碼，當用戶使用“UC 賬號”登錄時，“SDK 客戶端”調用“SDK 服務器” 接口進行身份驗證；
2.“SDK 服務器”密碼驗證通過后返回sid 及用戶相關信息（包括：ucid、用戶昵 稱等）；
3.“游戲客戶端”在“SDK 客戶端”回調通知后，可向“SDK 客戶端”獲取sid；
5.“游戲服務器”可向“SDK 服務器”請求驗證sid（調用用戶會話驗證接口，詳見《UC 優視游戲SDK 開發參考說明書-服務器接口》）；
6.“SDK 服務器”將sid 的驗證結果和對應的ucid 返回給“游戲服務器”；
7.“游戲服務器”將sid 的驗證結果及ucid、用戶昵稱返回給“游戲客戶端”
那么，我們現在要加入我們統一的登陸認證中心，而且，我們這個框架，本身就是針對多款游戲的，所以，我們不可以讓游戲服務器直接和每個渠道的SDK 服務器進行交互，所以我們增加一個統一登陸認證服務器，姑且叫U8 Server。那么，我們就設計一下u8 sdk的登陸認證流程：
1、客戶端接入抽象SDK框架，根據當前具體是哪個SDK渠道，調用登陸界面，然后傳入用戶名和密碼，進行SDK登陸操作
2、SDK登陸成功，會返回sid等信息
3、游戲客戶端可以通過SDK抽象層的接口，獲取到這個sid
4、游戲客戶端拿着這個sid以及接入之前向u8 server申請的appid,渠道號等信息，Http訪問u8 server進行登陸認證。
5、u8 server 根據當前傳遞的appid, 渠道號，去對應的SDK服務器進行認證
6、SDK服務器認證成功，會返回SDK服務器那邊的用戶信息
7、U8 Server拿到用戶信息，生成一個u8 server統一的用戶信息並存儲。然后，緊接着返回給客戶端一個有效的token。
8、客戶端拿着這個token，去訪問游戲服務器(多數是游戲登陸服務器)
9、游戲服務器，拿着這個token去u8 server 進行登陸認證。
10、u8 server 判定token有效，則返回給游戲服務器當前用戶的用戶信息
11、游戲服務器拿到用戶信息，證明當前登陸成功，返回給客戶端服務器列表等數據，登陸成功。
我們再看一個登陸認證的順序圖，可以更直觀地看到這個流程的順序：
通過這個新的登陸流程和之前老的登陸流程進行一個簡單的對比，大家就可以看出。老的登陸認證流程，對於每一款游戲的服務器，都需要和每個渠道SDK進行交互。但是新的流程，每個游戲服務器只需要和U8 Server 進行交互就可以了，全部由U8 Server進行第三方SDK的登陸認證操作。同樣的，每開發一款游戲，客戶端也只需要接入抽象的SDK接入層，而不再需要去接入每個渠道的SDK了。所有客戶端的操作，和服務器端的操作，都只需要做那么一次就OK了。
那么，接下來，我們再來看看支付流程，如果不使用這套框架，我們直接接入SDK，支付是什么樣子，我們以UC SDK為例：
1.“游戲客戶端”調用“SDK 客戶端”API 接口，提交充值信息； “SDK 客戶端”引導用戶選擇不同的充值方式，輸入充值金額。
2.“SDK 客戶端”將sid、gameid、serverid 以及對應的充值信息提交給“SDK 服務器”；
3.“SDK 服務器”接收充值請求后，將返回對應“訂單號”給“SDK 客戶端”；
4.“SDK 客戶端”將回調通知“游戲客戶端”對應的充值“訂單號”；
5.“游戲客戶端”將接收到的“訂單號”及相關的游戲角色信息（由游戲自行決定） 提交給“游戲服務器”；
6.“SDK 服務器”在處理完充值請求后，將通過異步方式通知“游戲服務器”充值 結果。
7.“游戲服務器”向“SDK 服務器”返回是否成功接收充值結果的標志（SUCCESS或FAILURE）。充值結果的成功或失敗與此處的接收標志無關，不論充值是否成功，只 要“游戲服務器”能夠接收並識別充值結果通知，都應該向”SDK 服務器“返回成功標 志（SUCCESS）
那么，我們現在要加入我們統一的支付中心，同樣針對多款游戲的，所以，我們不可以讓游戲服務器直接和每個渠道的SDK 服務器進行交互，我們也增加一個統一支付服務器，我們把支付中心的功能也加到U8 Server里。我們再看下新的支付流程：
1、游戲客戶端，首先請求游戲服務器要充值
2、游戲服務器拿着該用戶的id和一些支付成功之后需要原樣返回的數據，去訪問U8 Server申請訂單號
3、U8 Server生成一個唯一的訂單號，同時數據庫中生成一條訂單記錄，狀態是正在支付狀態
4、游戲服務器將訂單號返回給客戶端
5、游戲客戶端，拿到訂單號之后，帶着訂單號以及游戲里充值相關的數據，調用SDK抽象接口的支付接口，調用對應的SDK支付界面，進行充值操作。
6、當前SDK的渠道實現在調用SDK支付界面之前，需要把剛剛的訂單號，放到渠道SDK支付參數的自定義參數中。這個每個渠道都是一樣的。
7、渠道SDK支付成功，立馬返回一個狀態
8、同時，渠道SDK服務器會異步通知游戲開發商設置的支付回調地址。注意，游戲接入的時候，這個回調地址要設置到u8 server提供的一個地址。
9、u8 server收到充值回調，根據驗證結果等判定，立馬給渠道SDK服務器返回一個成功或者失敗的狀態。
10、然后u8 server根據自定義參數中的orderID，查詢到對應的訂單信息，再根據訂單信息，獲取到當前用戶信息和對應的游戲信息，然后調用接入游戲之前，游戲服務器提供給u8 server的支付回調地址。這個回調地址，游戲服務器只需要提供一個給u8 server就可以了。因為游戲服務器只和u8 server交互。
11、游戲服務器收到回調，驗證成功與否，里面返回給u8 server一個成功或者失敗的信息。同時，給對應的玩家加游戲幣。
這樣，大家通過對比兩個支付流程圖，可以清晰地發現，新的流程，可以做到只接入一次，后面多款游戲，可以共同使用。那么這個就作為我們這個框架的支付流程。我們再發個順序圖，可以更直觀地看下整個流程：
所以，通過對整個框架需要實現的功能的分析，我們設計了一套可以實現統一SDK登陸認證和支付中心的架構。那么接下來，我們就會具體的來實現每一個部分。包括抽象的SDK接入框架，游戲客戶端怎么接入這個抽象的SDK接入框架，各個渠道SDK怎么整合到這個SDK框架中來，怎么實現一鍵打包工具，怎么實現這個統一的登陸認證中心和支付中心。
本文出自 優優網事，轉載時請注明出處及相應鏈接。