1 爲什麼追求包體體積小
好的消息推送SDK首要需考慮到包體的小巧靈活性。爲什麼選擇更小體積的包體？對於商務人員來說，包體體積小，他們更容易接受。對於技術人員來說，他們在開發產品時，普遍追求“代碼少、功能全”，這是來自程序員的代碼潔癖。而從代碼層面來看，主要是由於系統的“65535限制”。
如上圖（左）所示，我們的程序最終會生成dex文件，dex文件主要由以下幾部分組成：header（標頭）、一連串的ids（標識符列表）、data（數據區）以及link_data（靜態鏈接文件中使用的數據）。細看上圖(右），它包含了一個method_ids_size字段，該字段的主要作用是定義個數。根據谷歌的定義，uint是一個16位的short類型，最長長度是65535。如果將dex工程反編譯，會生成很多smali的文件，再去看smali裏的函數調用（比如invoke direct {***} 函數名@BBB），會發現調用的地址其實就是剛纔unit裏定義的偏移量計算得出的。因此，這個函數地址最多也只能有65535個。當然，谷歌給了我們一個巧妙的方式繞過該限制，就是通過分包，方式也簡單，在AS的配置中加上multidex選項即可。
2 如何使包體體積變小
如何減小包體的體積，可以從以下幾個方面考慮：
（1）自研，不嵌套：在研發SDK時，不建議開發者在SDK內嵌套一系列框架，例如三方網絡框架、db框架或任務調度框架等。我們主張開發者選擇最核心的一部分進行自主研發。
（2）代碼優化：從算法層面，在效果相同的情況下，可適當減少代碼的行數；對於有默認賦值的變量不需要進行初始化賦值；選擇合適的字符串拼接方式，建議使用StringBuilder方法拼接字符串，可以解決字符串頻繁修改帶來的內存消耗，也有利於減少包體體積大小。
（3）追求實用，放棄完美：SDK包體應當追求實用性，以完善主功能爲主，其他相對次要的部分可以適當減少時間或精力投入，放棄完美主義思維。
（4）代碼混淆：藉助代碼混淆實現更小體積的包體，且不易被逆向。
3 省電省流量
省電省流量是“小”的另一個方面。作爲一款好的推送SDK，應該對流量和電量有嚴格的限制，否則會出現手機發燙、高耗電提醒、流量浪費、內置SDK APP難以上架等問題。針對上述問題，我們可以通過Lock殺手，智能心跳、自定義協議、鏈路合併、按需活躍等方式儘可能地降低SDK對電量以及流量造成的消耗。
（1）Lock殺手：代碼中WiFiLock、WakeLock等會強制喚醒APP，導致APP產生較大耗電量。在不影響功能的前提下，我們應儘量減少或者不用該類鎖。
（2）智能心跳：應根據不同的運營商、網絡狀態等,選擇不同的心跳策略，並且根據不同的應用場景探索心跳的最大邊界，儘量延長心跳週期，減少電量和網絡的消耗。
（3）自定義協議：市場上常用的json、xml、甚至PB協議，都有比較好的兼容擴展性，但同樣也帶來了空間浪費的問題，自定義協議可以充分利用空間，精確利用每一個byte甚至bit，極簡化封裝，承載最大的信息量，減少流量和電量浪費。
（4）鏈路合併：當一個設備有多個APP的推送鏈路同時活躍時，我們會運用合併鏈路技術，將使用“個推 SDK”的 APP 之間的長連接鏈路進行合併，減少流量電量的浪費。
作者：個推高級研發總監 公瑾