首先你需要在個推開放着平台上注冊你的應用，以及獲得以下幾個必要的值APPID ｜APPKEY ｜ MASTERSECRET，本文假設你已經完成上述步驟以及完成客戶端SDK的集成。
原理
個推服務端api的原理非常簡單，組裝一個對象，塞進去需要的值，然后編碼一下通過http請求發送到個推的推送服務器上，后面的復雜的推送流程就全權交給個推服務器了。
當然盡管原理非常簡單，個推服務端api還是做了一些封裝，最大限度節省用戶工作量，比如組裝對象設置特定的數據結構並編碼，以及一些額外參數以完成版本的向后兼容等動作。
介紹
個推服務端sdk有多種語言支持，JAVA / Python / C# / PHP / GoLang等等，本文以JAVA版本為例介紹使用方法。
首先需要引入服務端sdk，也就是下面幾個jar包，下載地址在個推官網上有
看名字很好理解這些jar包的作用，對於前三個commons開頭的，codec是用來編碼的，httpclient是用來構造http請求的，logging處理日志的；帶sdk的三個jar自然是個推封裝的組裝請求的邏輯，以及提供對用戶開放的使用接口；最后兩個是用到的數據結構json和protobuf。
業務場景
單推——推送指定客戶端推送
IPushResult pushMessageToSingle(SingleMessage message, Target target)
業務場景：一般適用於指定某個特定用戶的推送，比如你要告訴某個用戶他租的域名再不續費就要到期啦，或者有個好友@你啦，這種和獨立用戶緊密相關的個人消息。
群推——批量指定客戶端推送
IPushResult pushMessageToList(String contentId, List targetList)
業務場景：一般適用於為某些用戶推送消息的場景，比如你提取了一批今天生日的用戶列表，給他們發送生日祝福等。
群推——指定應用名稱全客戶端推送
IPushResult pushMessageToApp(AppMessage message)
業務場景：一般適用為自己應用的所有用戶推送同一條消息，比如今年2.14情人節，本店全場5折起之類的消息。
當然以上提到的業務場景只是暫時想到的，你完全可以套用到自己的業務場景里，組合使用各個接口，完成更多元的功能。
使用方式
各個接口使用方式大同小異，如果理解了原理應該很容易融會貫通。我將結合代碼，以單推——toSingle接口來講解使用方法。
-
首先定義一些常量，我們應用的appId，appkey等值
private static String appId = "aK6jeksP5C7CsjSSEqLAA3";
private static String appKey = "tpDVam96sY8pxhwBupJ462";
private static String masterSecret = "TBokfpttQJ6aHIhBE9y867";
private static String cid = "ce018bb633066839fd0d6fb448bfcb23";
private static String url = "http://sdk.open.api.igexin.com/apiex.htm"; -
新建一個IGtPush實例，傳入調用接口網址，appkey和masterSecret
IGtPush push = new IGtPush(url, appKey, masterSecret); -
新建一個消息類型，單推一個用戶的話，使用SingleMessage
除了SingleMessage外還有ListMessage和AppMessage分別對應三個推送接口
SingleMessage message = new SingleMessage(); -
新建一個推送模版，已透傳模板為例，透傳顧名思義到達客戶端后不做任何操作，由app選擇處理
其他原生模板類型種類很多，支持各種客戶端展現效果，包括彈框下載、打開鏈接等等。模板里也可以設置響鈴震動等效果。
TransmissionTemplate template = new TransmissionTemplate();
template.setAppId(appId);
template.setAppkey(appKey);
template.setTransmissionContent("測試用的透傳文本");
template.setTransmissionType(1); -
模板設置好后塞進message里，同時可以配置這條message是否支持離線，以及過期時間等，單位毫秒
若設置離線，個推推送系統會為當前不在線的用戶緩存離線消息，個推現在支持為每個用戶緩存多條離線消息，離線時間最多三天，三天后會刪除該條離線消息
message.setData(template);
message.setOffline(true);
message.setOfflineExpireTime(1800 * 1000); -
新建一個推送目標，填入appid和clientId
單推情況下只能設置一個推送目標，toList群推時，可以設置多個目標，目前建議一批設置50個左右。
Target target = new Target();
target.setAppId(appId);
target.setClientId(cid); -
調用IGtPush實例的toSingle接口，參數就是上面我們配置的message和target
IPushResult result = push.pushMessageToSingle(message, target);
String response = result.getResponse().toString();
System.out.println("返回值：" + response);
誤區一
推送選錯接口
個推服務端adk提供給開發者三個推送接口：pushMessageToSingle/ pushMessageToList/ pushMessageToApp。從命名來看也容易區分，分別是推送單個用戶，一批用戶，一個應用的全部用戶。對於每個接口，個推服務端的處理邏輯不盡相同，在性能上也有差別。一般來說推送性能是pushMessageToApp > pushMessageToList > pushMessageToSingle。其中ToList和ToSingle的使用頻率最高。有些開發者在ToList的場景里選用ToSingle接口，這樣就會明顯影響推送效率，ToSingle是適合單推特定用戶的場景，如果推送內容相同，將推送的對象集合起來，調用ToList接口，可以明顯提升性能。但是對於適合單推的場景使用ToList又會明顯降低性能，因為如果每次推送內容不同。調用ToList之前都需要調用getContentId上傳消息體，這樣至少從http請求次數來說，已經不合算了。
誤區二
推To List接口列表太大
ToList的性能更高在某個方面來說是因為其一次上傳了更多的clientId。但是我們不建議一批列表里放太多的clientId，把雞蛋放在一個籃子里是有風險的。而且從另一方面來說，過於巨大的消息體可能會在各個層面出現意料之外的異常。目前我們建議一批列表里放置不超過100個clientId。這樣100萬的用戶，你需要調用一萬次toList接口。
誤區三
頻繁調用getContentId
在調用ToList之前，需要先調用getContentId上傳推送消息體到個推服務器並獲取一個contentId。后續調用toList只需要上傳這個contentId和clientId列表就行。這意味着，如果你需要給100萬的用戶推送相同內容的消息，每次調用ToList發送100個，那就需要循環調用1萬次ToList接口。而這中間，無需再調用getContentId！只需要復用同一個contentId！因為他們的推送消息體是一樣的。這里經常會有開發者沒有注意，每次都調用一次getContentId再去調用toList接口。這樣對推送性能會造成巨大損失，因為你不僅double了http請求次數，而且getContentId相對來說在個推服務器上也是一個耗時操作。因此，如果你現在正不小心這樣錯誤使用着個推的服務端api，請趕快調整，飛一樣的性能提升肯定會讓你眼前一亮的。