813
移動端SDK優化的特點與經驗分享
內容來源：2017年5月25日，極光高級Android工程師王可為在“極光開發者沙龍”進行《移動端SDK優化的特點與經驗分享》演講分享。IT大咖說作為獨家視頻合作方，經主辦方和講者審閱授權發布。
閱讀字數：2098 | 4分鍾閱讀
SDK和APP的差別
重複造輪子
我們做APP開發的有這樣一句話：“不要重複造輪子。”意思就是希望快速迭代，每個APP有自己獨有的功能。基礎業務可以直接用別人已經做好的框架或第三方的包導入進來，但業務代碼一定要做自己獨有的。
在體積大小上，SDK和APP就有明顯差異。APP的核心代碼隻需做上麵一小塊，但這樣做的結果是一個APP本身大小有幾十兆甚至一百多兆，用戶可以接受。而SDK需要做得小，體積在幾百K以內，才是開發者能接受的。
所以SDK不能直接用別人的“輪子”。做基礎業務的話，像網絡、數據庫可以用Android原生的API來做，這樣能把體積控製在較小的範圍內，APP開發者才會用較小的包去做他們的業務。它的好處就是保持代碼的精簡，並且內部可見，方便調試和修改。
為了體積，以及優化架構和性能上，我們要“重複造輪子”。
配置
APP隻需要開發者根據自己的需求寫一份配置列表。
SDK的權限則是交給開發者，開發者具體用的什麼權限或版本，我們是無法控製的，隻能通過指引說明的形式告訴他們如何配置。
所以我們要考慮配置做到盡量簡便、友好、靈活。
升級
一個APP如果要升級，開發新版本上架到應用商場把它替換下來，或是推送更新通知，保證用戶較快地用到新版本，同時在線版本範圍比較小，老版本占有率慢慢降低。
而SDK不是直接上架市場，是需要開發者主動去拿文件，集成到自己的工程，再上架到市場。有些開發者幾個月之後才做更新，甚至有的從不更新，這個情況導致同時存在很多個曆史久遠的老版本，這個問題會要求我們做很多兼容性的考慮，所以可靠性和性能考慮的份量是比新功能要重的。
極光SDK的架構優化
舊架構
2016年之前極光推的主要是兩個SDK，一個是Jpush，一個是JMessage。
舊架構的推送跟IM是兩個獨立的SDK，存在很多種冗餘代碼。缺點是占用空間大，有重複操作，占用了通道和線程資源，還有就是冗餘代碼的升級管理非常麻煩。
新架構
我們在拓展業務後還新增了統計和分享，針對多條業務線的考慮，我們做了架構調整，把業務跟核心做了分層。
JCore負責核心通用的功能，上層SDK各自在JCore之上運行自有業務，使結構更加清晰，利於拓展共享資源，減少重複動作，針對性做基礎優化更加方便。
實際開發中需要考慮的
在和服務器通信的時候，從協議的製定上要考慮兼容不同的組件和同時在線的不同版本。在代碼設計上涉及到的策略類要采取策略模式，方便替換更優策略。
核心組件和上層的組件拆分成兩個，針對升級不同步的問題需要有更多的接口，要簡潔，適應變化。
以及關於各個組件之間的通信，通過命令模式，把動作抽象成為可傳出的對象，實現分發和緩衝。
在Android開發的工程設計中，由於被拆分為兩個包，一些接口難免會暴露出來，但是為了起到保護代碼的作用，又不能完全暴露。所以在方便和保護之間要做取舍權衡。
因為引入了很多組件，在打包、編譯腳本的時候可以用到Jenkins+Gradle，編寫腳本，做集成，可以自動打出多個包。
極光SDK的性能優化
多進程與多線程
多線程是語言的基本功，通常情況業務是在主線程執行，但是在移動端主線程任務過重會卡頓影響到用戶體驗，要盡量克製。所以在占用資源比較多、耗時的情況下要另外多開一個線程。
在Android應用的設計理念上，進程是非常寶貴的資源，它盡量不把進程管理交給開發者，而是讓係統去處理。
如果是單進程的應用，做的任務很多，內存占用數高，派多個進程可以分擔上麵的一部分任務資源到另一個進程，避免占用資源太高被回收。另外一個好處是，在後台跑的主進程因為一些無法預測的原因被係統回收掉了，在主進程的任務依然可以繼續執行下去。
開了多進程以後內存空間是獨立的，可能在主進程是初始化的，但在子進程上未被初始化。寫代碼的時候沒有意識到，在運行的時候就出乎意料了。這就是數據不同步會造成的問題。
數據不同步是主進程和線進程都能遇到的問題，如何巧妙利用它的性能又不出錯，我個人經常用雙重檢查鎖，看上去代碼更複雜，但有利於性能更好地運行，並且不容易出現數據不同步的問題。
由於變量在多進程時是不同步的，所以跨進程共享的變量，需要通過進程間通信的機製，把變量的讀和寫均放到同一個進程中，雖然會帶來一點性能損耗，但是這樣才能保證數據正確性。
儲存方式
同一個進程下，可以做一次讀取多次使用。
寫的操作可以批量提交。
使用內存級別儲存，響應更快。
跨進程的批量讀取和提交。
拆分存儲區。
長鏈接優化
我們做極光推送，推送主要的任務都是在長鏈接裏。客戶端和服務器進行通訊，先要進行接入服務。
我們有一個SIS服務，就是另外開辟服務器去找當時的設備，它介入哪一個IP，接入哪個端口有更快的響應，我們會下發一個列表給客戶端，讓它們自己去嚐試。
要做性能優化，可以先把列表緩存在本地，如果失敗了再用SIS下發的地址。然後寫一些選擇的策略，優先選擇可用的，排除不可用的。
在接入服務這部分，會把當時的狀況上報給服務器，讓服務器根據這些上報的數據反饋做調整。
我的分享到此結束，謝謝大家！
編者：IT大咖說，歡迎關注“itdakashuo”，@IT大咖說 ，轉載請標明版權和出處。
最後更新：2017-08-22 23:32:33