RN友盟推送
簡述下這篇文章的背景歷史，一個老專案因為打算用ReactNative重構，所以重新用ReactNative弄了友盟推送。友盟官網上也有了ReactNative版的各種庫，這點感覺友盟棒棒噠（但是有件事我一定要吐槽一下）。其實說是友盟RN版的，其實所有的庫都和原來iOS的一樣，就是多了幾個JS類，負責在RN中橋接它們的庫，不過這個也是正常的。那麼所謂的RN版友盟推送，其實也就和普通推送差不多。
但是，我經過親身實驗，覺得開發文件還是很不清楚的，尤其是蘋果更新了iOS10以後，推送方法就和有病一樣要區分iOS10之前和之後。具體配置就不說了，這個網上內容很多，按照文件上的小心配置，注意不要少了依賴庫，就沒什麼問題。我主要覺得蛋疼的點是下面這個需求：
獲取推送內容的userInfo
我們知道友盟推送在官網上可以配置，標題，內容，二級標題等等，更為複雜的也有，暫時不討論。我們是想在配置中新增自定義引數，通過推送獲取到這個引數。那麼，友盟的文件來了-----------------
如圖所示啊，下面這個方法是iOS10以下才走，但是上面那個方法什麼都沒說，我用的測試版本是iOS10以上，確實兩個方法都不走。
再看圖
這個就是友盟給所有的獲取資訊的方法了，後兩個的方法介紹人家寫的非常明白：
一.處理前臺收到通知的代理方法（的確，我記得前兩年友盟還不支援蘋果手機在前臺的情況下收到推送的，現在已經支援了，這個方法是走的，手機在前臺，只要推送訊息一來，就自動執行這個方法。）
二.處理後臺點選通知的代理方法（咦，和前面那個有點不一樣哦，說明說是點選通知的代理方法，經過實際測驗也是，手機在後臺收到推送後，不走這個方法，當點選以後才收到這個方法）
這我就不開心了，那這些方法根本就不夠全面呀，我們先來看一共有多少種情況：
這樣我們將實際使用者的推送行為分為以下6種情況分別由A，B，C，D，E，F來代替。由於我們暫時只研究iOS10以上的情況，我們把上面友盟給出的IOS10的方法定義為方法一，方法二。
A情況 使用者前臺收到推送訊息，不點選推送欄訊息。 那麼很自然的走了方法一
B情況 使用者前臺收到推送訊息，並且點選了推送欄訊息。此時會走兩個方法，沒錯，先走方法一，後走方法二，也就是所謂的後臺點選其實前臺點選也是走這個方法
C情況 使用者後臺收到推送訊息，不點選推送欄訊息。此時什麼方法也不走
D情況 使用者後臺收到推送訊息，點選推送欄訊息。此時走方法二。
E情況 使用者App殺死的情況，點選推送欄訊息進入，此時走方法二。
F情況 使用者App殺死的情況，點選應用圖示進入，此時什麼方法也不走。
我明明記得以前1個方法都搞定了，現在是怎麼肥事！大兄得！
那麼事情沒有結束，我當然會問友盟客服了，我想讓他來拯救我這顆千瘡百孔的心靈，於是友盟客服告訴我，其實C情況也並不是友盟方法不會走，C情況可以走友盟的靜默推送，而且標重點：靜默推送在友盟的推送後臺配置是無法進行的，需要你們伺服器來推送並且要傳1個引數@“content-aviliable=1”。
看文件
怎麼個事，你們文件不是告訴我當app沒有啟動或者被殺掉的時候將無法收到靜默推送嗎！哦哦，那就應該是@“app沒有啟動”這句話不等於app在後臺的情況，那你app沒有啟動和被殺死不就是1個意思了嘛！！你還用毛線或者！這友盟的文件感覺像閱讀理解啊！
再看文件：
你剛剛不是讓我傳@“content-aviliable”引數麼，你們文件說不應該包含其他欄位，這是怎麼回事……而且這個方法
-(void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo fetchCompletionHandler:(void (^)(UIBackgroundFetchResult))completionHandler
複製程式碼你不是寫的iOS10以下走這個方法嗎？你們友盟的靜默推送不支援iOS10以上？
好了，文章寫完了。沒錯，可能看完的你有些疑惑，我們公司後臺還沒有弄這些東西，所以我也無法給出最新的實驗成果。如果你有好的答案請告訴我。
中間還有一些RN的東西，下次再記錄。完。