「徵文」使用極光遇到過的那些事

寫在前面：年前的時候，極光社區組織了一場徵文活動 ，收到很多好的文章。如今打算和你們一塊兒分享一下這些優秀的做品 :)
做者：theks - 極光
原文：使用極光遇到過的那些事

我所在的是一個小團隊，從 2015 年末開發、運營一款供房地產經紀人使用的免費的工具 App ，使用極光差很少兩年了。在使用中遇到過一些或有趣或撓頭或無奈的事，下面摘錄一二與你們分享。

1

♤♤ 應用的最第一版本功能是單一的，只有最基本的功能，也不要求用戶註冊，因此根本就沒考慮過推送功能，就連 App 的開發也是外包給幾位前同事業餘時間搞出來的。

♤♤ 隨着功能的完善和用戶量的增長，推送功能也就提上了日程。極光在推送服務這方面作的不錯，因此就選擇了極光，固然是免費版😎。

♤♤ 我是作服務端接口的。在接下來挺長一段時間內，推送都沒有用服務端 SDK 調用 Push API ，而是咱們的運營人員登陸極光網站，手動羣推一些版本升級、活動上線之類的——當時咱們連後臺都沒有，用戶使用數據都是在友盟後臺看的——因此我就告訴安卓的開發 s ，去極光註冊個帳號和應用，而後本身參考安卓 sdk 集成進應用裏；而後把帳號給 ios 開發 p ，本身看 Appkey 、 ios 的 sdk ，也集成進 ios 版應用裏。

♤♤ 直到有一天，須要把人工審覈用戶所提交資料的結果推送給用戶，這就須要服務端代碼調用極光的推送 API ，我登陸進極光帳號一看，竟然有兩個應用，就去問 s ，在用的是哪個，回答是兩個都在用，一個是 android 平臺，另外一個 ios 平臺。當時我就不淡定了：

• 「爲何註冊兩個應用啊？不該該是一個應用推到兩個平臺嗎？」
  
• -「 p 說蘋果的推送機制跟安卓不同，因此他又註冊了一個。」
  
• 「但是極光推送是能夠選擇要推的平臺啊，當時你沒以爲有什麼不對嗎？」
  
• -「沒啊，我以爲他說的挺有道理。可能 ios 就是這樣的吧……」
  
• 「……那麼大家測試時，和運營手動推的時候是怎麼推的？」
  
• -「測試時各測各的，運營就是一樣的消息推兩次。」

♤♤ 因而，現在咱們的極光帳戶下有兩個應用，分別對應 android 和 ios 平臺，羣推消息時一個消息推兩次😭……

♤♤ 若是有剛用極光的新手看本文的話，做爲長者我能夠給一點經驗：

• 針對一個 App 申請一個極光應用就能夠了，在推送時能夠經過 setPlatform() 指定要推送的平臺。不過，若是你的開發環境和生產環境是分開的，就要注意了， ios 是能夠設定推送環境的（下文會講到），安卓就只能本身區分推送環境了。

• 爲了不開發環境的消息推送到生產環境這樣的狀況，能夠另外申請個極光應用給安卓的開發環境用，把 AppKey 寫進環境變量裏。固然也有其餘辦法，好比給不一樣環境的用戶設置不一樣的別名或標籤；可是這樣也不保險，特別是羣推或者推全部人時。

2

♤♤ 前面說了咱們是小團隊，沒有專職的測試，通常是產品兼任了測試的工做。

♤♤ 一次版本上線前內測，產品反饋說 ios 的消息推不到，但手動推送是能推到的。我檢查代碼後發現忘記改推送環境參數了，消息推送到生產環境了；而手動推時由於是可視化的界面，不容易錯過這個參數。

♤♤ 不過，雖然我知道必定有個地方能夠修改推送環境，但我找遍 Node.js 的 SDK 都沒發現怎麼改。最後看過 REST API 才知道是 setOptions 方法。在 github 上極光的 Node.js SDK 文檔是這樣寫的：

setOptions: 設置options，本方法接收5個參數，sendno(int),time_to_live(int),override_msg_id(int),apns_production(boolean),big_push_duration(int)

♤♤ 就這樣，只告訴我有這 5 個參數，卻沒有解釋這 5 個參數是什麼意思😥。

♤♤ 因此作服務端開發的小夥伴們，不要只看 Java 、PHP、C#、Node.js 這些語言的服務端 SDK ，雖然它有文檔還有示例，但它只是對 REST API 的封裝，看 REST API 的文檔仍是頗有必要的。

3

♤♤ 某天，運營提出了需求，要寫一個系統服務按期推送消息，內容是對用戶在過去一段時間的 App 使用狀況總結，好比發佈了多少產品，有多少瀏覽量、點贊量、電話量，和同城市的平均值以及比較，用戶點擊通知欄消息會跳轉到應用內一個界面查看更多詳情以及圖表之類。

♤♤ 因爲每一個用戶的推送內容都不同，就只能使用別名來單個推送。而悲催的極光免費套餐對推送速度有限制，單個消息推送速度是每分鐘限制600條（就是調用接口的速度，忘記在哪兒看到的了，好像是在QQ官方的開發者羣裏？），極光的技術建議最好本身限制推送速度，我就只好增長了延時。並且通知欄每條消息就那麼一兩行再去掉標題也顯示不了多少內容，相似的像支付寶「年度帳單」 之類的每每就是羣推一條通知，用戶點進去看詳情。

♤♤ 我找到管運營的老闆 y總，痛陳利弊以後，他說：帶膠布（大丈夫），我們應用目前用戶數很少，能送達的就更少了，就這麼先推着吧……

♤♤ 能夠預見地，當某天咱們的用戶數增加到一成天也推不完的時候，這個消息就再也沒有推過（事實上是爲了減輕服務器負擔，沒讓服務自動跑，而是手動在閒暇時啓動，我常常忘記推了23333）。

♤♤ 還有一個略坑的地方就是，極光的免費版套餐在 Report Api 提供的功能比收費版要少，沒有送達的緣由比較複雜，尤爲是安卓，沒法知道用戶是卸載了應用仍是沒有啓動應用（接收服務），因此沒法標記哪些用戶是死的、沒法送達的——下次就不推這個用戶了。

♤♤ 像這樣把全部用戶單個推一遍的事最好不要作，能羣推就儘可能羣推吧，羣推全部人也只是調一次接口。雖然免費套餐羣推速度也有共享每秒 20 萬條的限制，但也足夠用了，免費的就不用奢求太多啦。

4

♤♤ 仍是推送消息數量的問題。應用增長了內容運營，不久後推廣、客服夥伴們反饋，有用戶以爲推送太頻繁，把通知權限給關了。

♤♤ 但是事實上咱們的推送並很少，在沒有版本升級喚醒、活動上線的等特殊狀況下，大概每週羣推一次。想來想去只有小編會天天推消息了，一問小編，小編說她天天推三四次，除了早上定時發一次外，每次有新文章發佈就會推😰。

♤♤ 推送多了，問題也跟着來了：ios 還好，因爲推送機制與安卓不一樣，只要有網絡基本都能到達；但安卓是要接收服務在運行的狀況下才能收到，如今的手機廠商的某某 UI 、某某 OS 之類的訂製安卓系統，連同助手、管家類的安全軟件，一般是不給第三方應用後臺運行的權限的。也就意味着你下次再打開這個 APP 以前是不會收到推送的；因此極光有一個可選參數：

time_to_live: int 離線消息保留時長(秒) 推送當前用戶不在線時，爲該用戶保留多長時間的離線消息，以便其上線時再次推送。默認86400（1天），最長10天。設置爲0表示不保留離線消息，只有推送當前在線的用戶能夠收到。

♤♤ 就在你打開應用的這一刻，全部的離線消息叮咚叮咚都來了。

♤♤ 有用戶就說，爲何每次打開大家應用都有四五條未讀消息啊，我想說那是你長時間沒有打開應用了，積存的離線消息。

♤♤ 幸虧咱們用的是極光的免費套餐，留存的離線消息數量只有5條，若是是 vip 套餐能夠保留 100 條離線消息那該多壯觀啊。這就是所謂的因禍得福，焉知非福吧😎。

♤♤ 固然這是咱們推送的失誤，直接手動羣推的話就用了默認參數，離線消息保留一天。像運營內容、文章資訊這樣的不重要的消息，應該只推線上用戶或者離線保留時間短一些；像資料審覈結果這樣比較重要的消息，就應該保留長一些。

♤♤ 不知道極光的 vip 套餐狀況怎樣，我以爲即便能保留 100 條離線消息，用戶在長時間未使用 App 的狀況下突然打開就彈幾十上百條消息，用戶體驗也不會好。最好能夠設定保留離線消息的數量，而後給消息設定優先級，好比最多保留 5 條消息，超過 5 條時把優先級低的給頂掉，剩下的 5 條是優先級高的、用戶不該該錯過的消息。

♤♤ 不過安卓 App 不能後臺運行就推不到，這是安卓系統的問題，相信極光也沒有好的解決辦法，最近在考慮針對小米、華爲手機用戶，使用官方的系統推送服務 SDK 了。其實開發人員也不想集成多個推送 SDK ，有個想法就是極光能不能代替第三方 App 在小米、華爲的系統中註冊推送服務，極光就像個適配器，自動識別客戶端手機型號使用不一樣的推送通道。

5

♤♤ 咱們知道，極光的 ios 、安卓 SDK 能夠設置別名和標籤以便做爲用戶標識來推送。別名只能設置一個，每每用來做爲惟一性的標識，好比用戶 id ；而標籤能夠設置多個，在文檔裏 setAlias 和 setTags 都有這樣的說明：

須要理解的是，這個接口是覆蓋邏輯，而不是增量邏輯。即新的調用會覆蓋以前的設置。

♤♤ 好比打標籤時，若是想在舊的標籤數組基礎上增長一個新的標籤字符串，就應該傳一個新數組帶上全部的舊標籤和新標籤做爲參數。

♤♤ 不過，聽說 setAlias 和 setTags 也會互相覆蓋，也就是說，若是已經打了別名（不管有沒有設置過標籤），當你調用 setTags 時，別名會丟失，只有新設置的標籤生效。這就有點不符合正常的思惟習慣了：別名覆蓋別名，標籤覆蓋標籤是能夠理解的，都是用新的覆蓋舊的；別名和標籤互相覆蓋就讓人摸不着頭腦了。對應的是，還有另外一個方法 setAliasAndTags ，若是想同時設置別名和標籤，就只能調用這個方法了。

♤♤ 這個只是聽說，我沒作過安卓和ios的開發，不清楚是否是這樣。有一次咱們的APP ios版打標籤時就丟了別名，還好發現得比較早，在提交審覈前修復了。

6

♤♤ 隨着版本迭代、功能的完善增多，s 的經驗和姿式愈來愈豐富，漸漸成長爲老司機。因爲他之前是作Java Web 的，就更多的支持後臺的開發，安卓的開發就漸漸地交給了新司機 d 。

♤♤ 某個版本開始，要增強新註冊用戶的粘度，好比註冊三天內的用戶，推送消息讓他們使用隱藏較深、可能沒用過的功能。客戶端按註冊日期設置了標籤，測試時沒發現問題就上線了。

♤♤ 幾天後才發現問題：安卓的新註冊用戶推不到。我找 d 少：

• 「一樣的接口，爲何人家 ios 沒問題，就你安卓出了問題？」 這是我質問客戶端們的金句，若是隻有 ios 或安卓一方出問題，我這樣說的時候他們一般無語凝噎了。
  
• -「……j 哥，你這樣說我就無言以對了。」
  
• 「確定是你標籤打錯了唄。」
  
• -「不可能，我當時還把標籤的值都打印出來了，你也看到了的。」
  
• 「你如今調試，我看看你的代碼。」

♤♤ 果真發現了問題：拼註冊日期字符串的時候，取月份用了.getMonth()方法，而這獲得的值是 0-11 。測試時沒發現問題是由於直接用這個錯誤的值測的。

• d少很差意思地說： -「j哥，要不我改了吧，立刻發個新版本。」
  
• 「這個版本已經上線好幾天了，目前已經打了錯誤標籤的人怎麼辦？他們不升級app的話這個標籤永遠是錯的。」

♤♤ 幸虧安卓和ios註冊成了兩個極光應用，將錯就錯吧。例如 ios 推標籤20161231，安卓推20161131（11 月也有 31 號了，😥汗……）；ios 推20170101，安卓就推20170001。我太機智了。也再次說明了因禍得福，焉知非福啊。

後記

原本標題想用《那些年，使用極光踩過的那些坑》，不過想一想並不全是坑，有些坑也不關極光的事。
12 月底的時候就看到這個活動了，磨磨蹭蹭直到昨晚才抽空打了這麼多字。

歡迎關注知乎專欄：極光日報