整整三個月沒更新博客了，這也是我開始正式工作的三個月，android開發雖然以前也接觸過一點，但是過的時間太久了基本沒印象了所以這段時間都在工作加學習，工作主要就是在做android渠道接入，接近兩個月時間了感覺自己也算是比較有了一些心得了，終於可以寫點東西了。
手遊行業的火爆是不需要說太多了，除了忠實的遊戲玩家，很少還有人守在電腦前玩PC遊戲了，而很多我們耳熟能詳的遊戲諸如夢幻西遊、熱血傳奇、穿越火線等也都推出或即將推出手遊版，騰訊網易暢遊盛大等巨頭也紛紛發力，都想在手遊領域立於不敗之地。一款遊戲的品質如何那自然取決於策劃和研發人員，而這款遊戲在上線後是否能夠成功，還是看推廣做的如何，是否覆蓋各個渠道，我們公司最近做的一款遊戲，幾乎就把各個渠道接了個遍。沒辦法，得渠道者得天下。在國內android平臺有着衆多渠道，沒有哪個渠道在用戶體驗上有絕對的優勢，這就導致遊戲開發人員對每個渠道都必須足夠的重視。
渠道的接入有個特點，技術實現不難但極端麻煩，遊戲客戶端與服務端的聯調、遊戲服務端與渠道的數據校驗以及遊戲客戶端本身在接入渠道SDK時都會出現許多問題，但是經過這麼長時間的摸索，我發現各個渠道在接入過程中出現的問題都是類似的，效率也就隨之提高，比如我接的第一個渠道花了近一週的時間才大體完成，而現在我一般一到兩天就能結束一個渠道的接入。我們去百度上搜索“手遊渠道接入”，幾乎找不到任何技術層面的文章，可能是衆多大神不屑於寫這方面，也可能確實沒什麼技術含量，但我個人看來確實還是有很多問題需要注意的，相信也有很多像我一樣的新手朋友剛開始時肯定會蒙圈，那麼這篇文章就作爲我的一個總結，以及給跟我一樣的新手朋友做個導向，順便給沒接觸過手遊渠道接入的朋友也做個介紹，大神請無視，就醬。
一個手遊渠道接入的完整流程分爲三部分：商務溝通、技術接入、提交審覈，作爲一隻程序猿我當然只做第二部分，但經過多次與商務同事及渠道人員溝通，對其它流程也有所瞭解，那麼我接下來就總結一個完整的渠道接入流程。
一．商務溝通
我們拿到一個渠道接入文檔後，最先看到的一般就是接入說明，這裏要進行的是到渠道後臺申請appId等渠道參數，參數個數以及參數名各個渠道都不相同，一般除了appId還會有appkey、payKey等等，appId與應用是一對一的關係,一個 appId只能分配給一個應用使用。若多個應用使用一個 appId會導致不能正常計費,影響收入;還會導致 SDK 升級失敗、各項統計數據出錯等。程序中的 appId必須和平臺申請時填寫的包名對應起來,否則會提示應用被禁用,程序沒有審覈通過也是一樣。具體的參數當你在渠道後臺申請了之後都會有詳細的說明，這裏要做的就是拿到這些參數，接下來我們要用到的。
二．技術接入
這一部分是一個渠道接入的核心環節了，渠道SDK的接入主要是參照渠道給的SDK文檔，一般的文檔都會分爲兩個主要的部分：登錄和支付，任何渠道都會有這兩個部分，此外還可能有會註銷、上報數據、懸浮窗、啓動閃屏等特殊要求，如果渠道的SDK文檔中有提到這些要求，作爲技術人員我們是一定要滿足的，否則可能會無法通過渠道的審覈，下面我就逐個地介紹一下。
1.登錄
登錄流程大致如下：
首先調用渠道方提供的登錄接口進行登錄，一般情況下這個接口會有三個回調，分別是登錄成功、登錄失敗、登錄取消，之所以說一般情況下，是因爲有些渠道比較個性，有的渠道是沒有提供登錄取消接口的，有的渠道登錄的回調監聽也不是在登錄接口裏面，這就需要我們仔細地閱讀渠道文檔，嚴格按照渠道的方式寫碼。
登錄成功後渠道會返回給遊戲客戶端一個驗證ticket（任何渠道都會返回），有些渠道還會返回一個渠道用戶ID，這時需要做的是將這個ticket傳給遊戲服務器，遊戲服務器拿到這個ticket後再到渠道服務器進行校驗，這個過程是防止有人冒充登錄，校驗成功後遊戲服務器需要通知遊戲客戶端，此時客戶端進入遊戲。
登錄過程中的技術問題主要出在以下幾點：
(1)初始化失敗。絕大多數渠道都會提供一個初始化接口，這個接口一定要在登錄前調用，一般需要在這個接口傳遞在渠道後臺申請的appId和appKey，如果參數不對會導致初始化失敗，也就無法登錄成功。
(2)資源文件、jar包、mainfest配置出錯，有些渠道在mainfest配置裏有appKey等參數，拷貝之後一定要改成當前應用的參數值。
(3)服務端校驗未通過，一般情況下如果資源及配置確認沒問題，那基本就是服務端校驗沒通過導致登錄失敗，此時要檢查客戶端傳給服務端的ticket是否正確。
2.支付
支付流程大致如下：
首先調用渠道方的支付接口，與登錄不同的是，這個支付接口是需要傳一些參數給渠道的。這些參數可以從遊戲服務的獲取，一定有的參數是支付的訂單號，可能有的是商品名稱、單價等。支付就涉及到錢的問題，那麼就要考慮到安全，所以大多渠道這個支付流程是需要加密的，渠道服務器收到渠道請求後會通知遊戲服務器爲這個用戶發貨，此時遊戲客戶端需要與遊戲服務端進行校驗，以防渠道方惡意通知發貨，校驗成功後遊戲服務器進行發貨，客戶端進行訂單查詢，用戶可以收到購買的商品。
支付過程中的技術問題主要出在以下幾點：
(1)調用渠道支付接口時參數傳錯，不要小瞧這個參數問題，很多渠道在支付時都需要很多參數，有一個參數不對就會導致支付失敗，而很多時候我們根本看不出錯誤出在哪。需要注意的幾個參數：訂單號一定要傳渠道方的訂單號、金額注意渠道要求的是元還是分、支付通知地址是否需要在客戶端傳遞(支付通知地址即渠道通知的服務器地址)。而很多時候問題也是出現在渠道方，比如我之前接過的一個渠道，一直支付失敗，卡了20天，最終發現是有一個參數必須傳null，而渠道文檔上並未對此作出說明。所以有時候如果出了問題而又找不出原因那麼一定要及時與渠道方溝通，避免浪費時間。
(2)無法調起支付界面或者直接崩潰，這種情況一般是資源文件、jar包、mainfest配置出錯，這裏需要注意的是assets目錄下的文件一定要手動拷貝到遊戲工程中。
(3)客戶端付款但遊戲服務端未發貨，這種情況可能是支付通知地址填寫錯誤，支付通知地址一般有兩種方式填寫：一是寫在渠道後臺，二是在支付時由客戶端傳給渠道方，具體情況按渠道要求，有些渠道在支付的參數裏看起來沒有要傳支付地址，但實際上是要寫在附加參數裏，這就需要與渠道溝通才能確定了。
(4)服務端校驗未通過，爲防止渠道惡意通知發貨，遊戲服務端與遊戲客戶端是需要校驗的，這個校驗一般使用己方的訂單號，所以在校驗時注意要將己方的訂單號傳給遊戲服務端，而不能傳渠道的訂單號。
(5)點擊商品後提示“無法支付”，這個問題是很常見的，有可能是資源沒有拷貝，也可能是商品沒有在渠道方創建，有些渠道是需要在它們後臺逐個創建商品的，創建之後會分配一個商品id，在調用支付接口時將這個商品id傳給渠道，這樣才能調起支付頁面。
(6)未修改包後綴名，每個渠道都會要求修改包後綴名，這個最好在調試階段就要改好，否則會導致各種問題。
3.註銷
如果渠道提供了註銷接口，那麼在註銷時我們就一定要調用這個接口。
有些渠道沒有提供註銷接口，而是提供了切換賬號接口。我們知道遊戲裏面是有註銷選項的，玩家點了註銷應該回到登錄界面，而如果渠道沒有提供註銷接口，我們就要在玩家選擇註銷後做一個標記，等玩家再次登錄的時候就不要在調用登錄接口，而是調用註銷賬號接口，這樣行爲上是滿足了需求的。
4.添加閃屏
遊戲閃屏就是當玩家點擊遊戲圖標進入遊戲時跳出的畫面。這個接入過程如果仔細一些，資源配置等都不缺少，那麼一般是不會出問題的，當然如果你有一個地方不注意就可能會導致程序崩潰。需要說明的是很多渠道都要求把閃屏加在第一屏，否則是不能通過渠道審覈的。
5.懸浮窗
這個地方是經常出現問題的，懸浮窗裏面有一個重要的功能是切換賬號，有些渠道會單獨設置一個懸浮窗切換賬號的監聽和回調，而有些渠道就直接把回調設置在登錄的回調裏，這時還需要遊戲客戶端在登錄時做一個判斷，是登錄的回調還是使用懸浮窗切換賬號的回調。
三．提交審覈
接入完成後，需要提交至渠道後臺審覈，審覈通過後才能上線，如果接入過程中嚴格按照渠道的要求進行，那麼一般都會通過的。
四．更新SDK
渠道的SDK是需要不定期更新的，不更新就不能使用，這也是渠道接入最頭疼的地方，更新的時候首先要細讀文檔，查找哪些地方有變動，哪些是新加入的功能，哪些接口不能再使用，這裏要注意，有些渠道廢除的接口雖然不能再使用，但是在代碼中是不會報錯的，而當你運行到這裏時程序就會崩潰。再有要注意渠道參數是否更改，如果需要重新在渠道進行配置那麼參數可能就會改變，記得在代碼中也要隨之修改。
一個渠道的完整接入流程就大致是這樣，接入的過程比較簡單，但是後期的更新是很繁瑣的，對此我們可以考慮使用第三方的SDK更新，一般只要一次接入，後面的更新都是由第三方SDK來做，節省的時間是相當可觀的。並且不再需要關心渠道方的任何接口與數據交互，只需要接入第三方SDK的接口即可，詳細方法可以到各家第三方SDK的官網上查看。