各位看官大家好，經(jīng)過第一篇 手游SDK — 第一篇（序言）的大體介紹，想必大家應該是對手游SDK有了大體的概念。廢話少說，下面歡迎大家跟我走進客戶端架構篇，慢慢分析如何搭建一個符合業(yè)務需求的SDK架構方案。PS：說明下，由于本人的水平有限，該架構的設計及實現(xiàn)都是基于工作的業(yè)務需求及開發(fā)經(jīng)驗的總結，有不足的地方還希望大家可以留言指正。
架構設計的業(yè)務場景：
1、基于前文的介紹，游戲SDK最大的業(yè)務場景就是需要對接N多的應用渠道，這個是國內特有的，海外一般只有Google和App Store兩個平臺。所以如何快速、方便的接入渠道SDK及后期的維護SDK就是設計時需要考慮的問題了。
2、SDK的業(yè)務場景更多的會集中在賬號、支付及數(shù)據(jù)收集這里，賬號體系細分的話，又會有不同的登錄邏輯、綁定邏輯、切換邏輯。如：手機游戲通常分網(wǎng)游和休閑游戲，網(wǎng)游一般會有賬號的登錄、注冊等入口，而休閑游戲更多的處理是以手機設備信息來做用戶的區(qū)分或者通過隨機生成一個賬號，走游客賬號登錄；賬號入口又可以細分是否有用戶的界面，無用戶界面的話，怎么處理用戶的登錄方式及登錄、綁定、切換邏輯；支付的話，國內常用的有微信、支付寶等三方支付，還有運營商的短信支付，而且在運營商在不同的省份又會有不同管控，需要我們開發(fā)者做后臺開關去做控制；數(shù)據(jù)收集的平臺通常不只有一家，不同的游戲是不同的公司，對應的數(shù)據(jù)平臺也不一樣，怎么去做差異化處理；在此基礎上，后期的話，還有額外的運營需求都需要添加功能。
3、SDK的功能插拔，可能某款游戲上架國內渠道需要提供這個功能，上架Google平臺又必須拔出掉該功能或者新增另外功能；游戲游戲需要SDK提供Google支付，有些游戲又只要微信支付，或者都要，但是要優(yōu)先級，先彈出微信支付，沒有微信支付自動彈出支付寶支付等等。
4、除了跟業(yè)務相關的需求外，還需要考慮一個比較重要的事情就是，游戲如何方便、快速地接入游戲SDK？業(yè)內的通用做法是通過游戲打包系統(tǒng)，批量的打游戲SDK包。（這塊后續(xù)會跟大家講解下及實現(xiàn)原理）
PS：業(yè)務場景太多了，業(yè)務邏輯也很復雜，會導致項目可能會因為需求分化成小項目越來越嚴重，同時不同的人員維護開發(fā)同步的問題也會暴露出來，沉積的業(yè)務代碼也越來越多，越難維護，這也是我思考SDK架構的設計的原因及初衷了，能不能用一個通用SDK的架構來統(tǒng)一化處理這些問題？
好了，這個問題，我也有了自己的答案，希望與各位看官分享。
架構設計圖
廢話不多說，反手就是一張架構設計圖 (圖丑，各位看官莫吐槽哈。)
我這圖跟常規(guī)的設計不太一樣哈，參考的是Android系統(tǒng)架構的設計，通俗易懂，當然了，也說明了我的水平局限性了。
架構設計分析
回歸正題，這個架構設計跟大家平?？吹降腗VC、MVP、MMVP等常見的架構設計是不太一樣的，但是是基于傳統(tǒng)的MVC模式來思考設計的。下面我會詳細跟大家說說設計的思路。
第一部分：架構的分層設計：
架構設計的初體驗
在這里我就不多說什么是MVC架構了，網(wǎng)上相關的博客也比較多。下面大家先看下下面這張圖：
在這張圖里面將MVC的模塊用框框進行了劃分分類，方便大家理解。
Model層：
數(shù)據(jù)來源model，在游戲SDK里面，數(shù)據(jù)的來源更多的基于第三方的，可以分為兩類：
1、ChannelModel：渠道SDKModel，各個渠道的功能接口，如登錄、支付、社區(qū)、浮窗等；
2、FunctionPluginModel：功能插件Model，如微信的登錄、支付、分享；Google的登錄、支付；Bugly日志收集等；
View層：
視圖層，在游戲SDK里面，更多的講對外的API接口，這里的視圖就相對弱化些，我這里勉強將它歸納為View層。而且這里要注意的就是接口設計問題，接口如果設計對外輸出后，就千萬盡量不要修改。
Controller層：
控制層，在游戲SDK里面，會有很多的業(yè)務常見，需要我們開發(fā)人員做好需求的開關控制和邏輯控制，在這里大體分為兩類：
1、業(yè)務邏輯控制層：將相關的業(yè)務邏輯處理在該層處理，不同的Project有不同的業(yè)務邏輯，額外說明下，project就是項目，如國內SDK項目，海外SDK項目，聚合SDK項目等。
2、功能邏輯控制層：功能邏輯層，主要是面對Project服務的，將具體的功能實現(xiàn)，對project暴露邏輯接口，方便project對功能邏輯的調用及控制。具體實現(xiàn)project不需要關心。
架構設計的業(yè)務詳解
上面跟大家分析了下，架構設計的大體模塊劃分，下面從業(yè)務的邏輯分析下，SDK架構的業(yè)務實現(xiàn)。請看下圖：
在這張圖里，也用框框進行的邏輯劃分，大體分為四層：
API功能接口層：
該層是對外提供接口，面向游戲開發(fā)者的，提供SDK的功能接口，如常見的初始化、登錄、支付、綁定、訂閱、數(shù)據(jù)上報、顯示浮窗、隱藏浮窗、退出等。這里的接口設計需要注意的地方就是，對外的接口一旦對外提供，就盡量不要修改(這個坑，我踩過 -.- ~~)，且該層的代碼不要混淆處理，所以在該層的代碼不要做邏輯實現(xiàn)，避免被篡改。
業(yè)務邏輯層：
該層是SDK對接API層的，是不同project項目的實現(xiàn)層，在這里通過project配置文件來配置不同的項目。API層持有Project的引用，通過配置，選擇不同的項目project實現(xiàn)。如：Project有多個項目：聚合SDKProject、公版SDKProject、海外SDKProject等，多個項目時，每個項目都有不同的業(yè)務邏輯，不同的功能實現(xiàn)，對游戲的API接口是不變的，這時就可以通過配置來切換不同的Project，在不改變接口的情況實現(xiàn)換SDK包的功能。
注意：該層還有一個額外的Channel層，該層是三方渠道層，更多是針對聚合SDK項目的業(yè)務。也是通過channel配置文件來配置不同的channel入口的。
功能邏輯層：
該層是SDK的功能實現(xiàn)層，是SDK的核心層，對接Project層的，為不同的Project項目提供功能接口。這里采用組件化的思想，細分為各個功能組件，每個組件之間是相互獨立的，方便后續(xù)業(yè)務量大之后將組件抽離處理，單獨做成一個獨立的項目。如登錄SDK、支付SDK等。
注意：這里的功能不做任何的業(yè)務邏輯，只做功能實現(xiàn)，業(yè)務邏輯放到project層處理，通常與服務的交互也會在這層處理。這里會有一個三方的plugin層，主要是封裝三方的功能插件，通過配置提供給Logic對應的功能，如微信插件，有登錄、支付等。
PS：這個的配置文件的實現(xiàn)原理是通過反射實現(xiàn)的。還有說明下，這么處理的好處是，后續(xù)的游戲打包可以通過選擇不同的Project、channel、plugin來快速打項目包、渠道包、及功能包。（打包篇細講）
基礎庫
該層是整個SDK的基礎，封裝通用的基礎功能，網(wǎng)絡庫、數(shù)據(jù)解析、日志輸出、IO流、文件加解密等。這里的基礎庫，會封裝一些流行的框架，需要注意的是，流行的框架幾年會有被淘汰的風險，所以盡量做封裝處理，不然替換一個框架，上層的SDK都需要修改。
PS：基礎庫的話，建議分為業(yè)務基礎庫和框架基礎庫、UI基礎庫，方便后續(xù)的隔離和替換。避免后續(xù)基礎庫越來越臃腫。而且基礎庫不要輕易修改，不要輕易修改。切記!
總結
由于最近項目比較趕，這個系列的博客有點耽擱了。而且由于商業(yè)機密，項目的代碼也不能開源出來，后續(xù)我會做一個精簡版的項目框架給各位分享，也方便理解。
手游SDK —第三篇（SDK架構設計代碼實現(xiàn)篇（上）- 基礎庫）
手游SDK —第四篇（SDK架構設計代碼實現(xiàn)篇（下）- 項目需求開發(fā)）
如果覺得我的文章對你有幫助，請隨意贊賞。您的支持將鼓勵我繼續(xù)創(chuàng)作！
