總結好的消息推送SDK的四大關鍵點，咱們是認真的!

一個好的消息推送SDK應該具有穩定、易用、安全、小巧靈活等特色。個推做爲國內第三方推送市場的早期進入者，一直致力於爲開發者提供高效穩定的推送SDK。通過多年的打磨和創新，個推沉澱了豐厚的技術經驗。這期文章將從「小」、「穩」、「好用」以及「安全」四個角度分享個推推送SDK的技術經驗。

1 小

1.1 65535限制

好的消息推送SDK首要需考慮到包體的小巧靈活性。爲何選擇更小體積的包體？從代碼層面來看，是因爲系統的「65535限制」。如上圖（左）所示，咱們的程序最終會生成dex文件，dex文件主要由如下幾部分組成：header（標頭）、一連串的ids（標識符列表）、data（數據區）以及link_data（靜態連接文件中使用的數據）。細看上圖(右），它包含了一個method_ids_size字段，該字段的主要做用是定義個數。根據谷歌的定義，uint是一個16位的short類型，最長長度是65535。若是將dex工程反編譯，會生成不少smali的文件，再去看smali裏的函數調用（好比invoke direct {***} 函數名@BBB），會發現調用的地址其實就是剛纔unit裏定義的偏移量計算得出的。所以，這個函數地址最多也只能有65535個。

1.2 如何使包體體積變小

如何減少包體的體積，能夠從如下幾個方面考慮：

（1）自研，不嵌套：在研發SDK時，不建議開發者在SDK內嵌套一系列框架，例如三方網絡框架、db框架或任務調度框架等。咱們主張開發者選擇最核心的一部分進行自主研發。

（2）代碼優化：從算法層面，在效果相同的狀況下，可適當減小代碼的行數；對於有默認賦值的變量不須要進行初始化賦值；選擇合適的字符串拼接方式，建議使用StringBuilder方法拼接字符串，能夠解決字符串頻繁修改帶來的內存消耗，也有利於減小包體體積大小。

（3）追求實用，放棄完美：SDK包體應當追求實用性，以完善主功能爲主，其餘相對次要的部分能夠適當減小時間或精力投入，放棄完美主義思惟。

（4）代碼混淆：藉助代碼混淆實現更小體積的包體，且不易被逆向。

1.3 省電省流量

省電省流量是「小」的另外一個方面。做爲一款好的消息推送SDK，應該對流量和電量有嚴格的限制，不然會出現手機發燙、高耗電提醒、流量浪費、內置SDK APP難以上架等問題。針對上述問題，咱們能夠經過Lock殺手，智能心跳、自定義協議、鏈路合併、按需活躍等方式儘量地下降SDK對電量以及流量形成的消耗。

（1）Lock殺手：代碼中WiFiLock、WakeLock等會強制喚醒APP，致使APP產生較大耗電量。在不影響功能的前提下，咱們應儘可能減小或者不用該類鎖。

（2）智能心跳：應根據不一樣的運營商、網絡狀態等,選擇不一樣的心跳策略，而且根據不一樣的應用場景探索心跳的最大邊界，儘可能延長心跳週期，減小電量和網絡的消耗。

（3）自定義協議：市場上經常使用的json、xml、甚至PB協議，都有比較好的兼容擴展性，但一樣也帶來了空間浪費的問題，自定義協議能夠充分利用空間，精確利用每個byte甚至bit，極簡化封裝，承載最大的信息量，減小流量和電量浪費。

（4）鏈路合併：當一個設備有多個APP的推送鏈路同時活躍時，咱們會運用合併鏈路技術，將使用「個推 SDK」的 APP 之間的長鏈接鏈路進行合併，減小流量電量的浪費。

2 穩

2.1 提高穩定性

在實際應用中，開發者可能會遇到ANR、OOM、Crash、內存泄露、閃退等棘手的問題，爲了打造好的消息推送SDK，咱們須要經過持續的迭代和優化來將錯誤最小化。

（1）作好代碼管理：除了藉助SVN、GIT等工具作好代碼託管外，開發者還需遵循必定的代碼規範，藉助相似gerrit等工具進行代碼review，使用verify流程。在保證機器找不到問題的前提下，再用人眼去辨別是否符合業務邏輯。

（2）自動化測試：自動化測試能夠大幅提高迴歸測試的效率，很是適合敏捷的開發過程。此外，自動化測試能夠替代大量的手工機械重複性操做，測試工程師能夠把更多的時間花在更全面的用例設計和新功能測試上。

（3）運用代碼模塊化等小技巧：代碼模塊化能以最少的模塊、零部件，更快速地知足更多的個性化需求。異常處理能夠提升系統的容錯性，讓程序更加穩定。代碼檢測能及時發現程序中的缺陷和錯誤，好比檢測內存是否泄露，是否有安全漏洞等，保證代碼質量。

（4）線上灰度：實際場景中，咱們很難去覆蓋全部的環境，例如機型、網絡等，須要經過線上用戶的反饋去驗證代碼的健壯性。所以在產品大規模推向用戶以前，咱們須要進行少許的真實用戶測試，即灰度上線來幫助減小風險。

（5）日誌系統：系統有問題是必然的，在儘可能保持系統穩定的前提下，要考慮容錯性。當問題發生時，須要第一時間以最快的速度排查，所以須要有一套完整的日誌系統。此外，平時咱們也能夠經過日誌系統的撥測檢測系統的健壯性，能夠在用戶反饋以前及時發現並解決問題。

2.2 兼容性

兼容性也是保證好的消息推送SDK穩定性的一個重要條件，主要考慮如下幾個方面：

（1）接口兼容：每次版本更新後，對外接口要儘量保持不變。對於改動較大的接口，可使用 @Deprecated 註解對老接口進行標記，而且作新接口調用的兼容，而不是直接刪除老接口。

（2）主鍵兼容：當主鍵發生變動（例如去掉service、provider）時，部分老的安卓系統會有組件緩存，運行時直接告知「類」找不到。建議在AndroidManifest中保留聲明，且對應「類」進行代碼空實現，以減小發生crash的機率。

（3）安卓系統兼容：可以使用Build.VERSION.SDK_INT作API區分。

（4）真機兼容：能夠藉助雲測等平臺進行兼容性測試。

3 好用

SDK的易用性能夠從下面幾個方面考慮：

（1）接入簡單：接入SDK時有集成demo直接能夠運行，且接入文檔清晰、步驟簡單，最好能實現一鍵集成。

（2）保持核心優點：一款好的消息推送SDK，咱們主要考慮及時性、到達率、穩定性和準確性。例如，新聞媒體類APP對推送的及時性要求較高；通知類推送（如轉帳信息）會特別注重消息的到達率；穩定性指的是要保證推送SDK在不一樣環境下的正常運行，尤爲是11.11等高併發場景；準確性主要針對廣告營銷類推送，須要在合適的時間、合適的地點和合適的場景把合適的內容推送給合適的人。其中，關於如何保證穩定性，能夠從多線路、多IDC、熱備份等角度考慮。① 多線路調整：例如預埋三線域名，作一些輪詢策略，防止域名被劫持。② 多IDC設置：除了域名被劫持外，還可能遇到網絡攻擊，物理性損壞的狀況。設置多IDC一方面是爲了實現分流，另外一方面也下降了風險。③ 熱備份：系統處於正常運轉狀態下的備份，一旦系統出現問題，能夠快速恢復。

（3）多樣化需求：經過豐富的畫像標籤，對用戶進行場景化的智能推送，知足用戶的多樣化需求。

（4）策略可控：咱們還提供靜默時間、推送控量、短信補量、定時展現等附加功能，知足客戶的實際使用場景。

$4 安全

SDK開發過程當中，咱們還須要注意安全性。安全性不只僅表明網絡數據交互的安全、本地數據存儲的安全，也涉及到 SDK 的加固、混淆、第三方安全軟件審覈等。

其中，咱們重點講解SDK的加固。目前安卓平臺SDK絕大部分都是Java語言編寫，容易被反編譯。SDK若是隻是進行了簡單的混淆，很容易被窺探到內部實現細節，此外還可能存在SDK被二次打包、植入惡意廣告等現象。所以，咱們須要對SDK進行加固，以提高安全性。

如上圖所示，SDK的加固主要是Java層面和so層面的操做。Java層面能夠進行SSR IR指令轉換或者作Java2C處理，把實現細節放入native中；so層面能夠作一些扁平化、虛假控制等來混淆代碼，也能夠經過指令替換、指令跳轉邏輯來增長逆向難度。此外，也能夠經過常量字符串加密加固SDK，這是目前較爲簡單實用的一種方式。

總結來講，其實開發一款好的消息推送SDK並不難，難的是如何讓本身開發的SDK在複雜的環境下穩定運行，這須要咱們對 SDK 的架構有比較清晰的認知，並不斷迭代和優化。但願本文能爲各位開發者在實際操做中提供必定幫助。