說到APP優(yōu)化，我們也可以從很多方面進行優(yōu)化，從包大小、頁面流暢度、內(nèi)存占用、數(shù)據(jù)緩存、網(wǎng)絡數(shù)據(jù)安全等等來優(yōu)化加固我們的APP，每一個點展開又有很多需要將的，我以前也專門寫了一篇關于APP性能優(yōu)化的博文，如下：

《iOS-性能優(yōu)化的那些事》

在移動端APP網(wǎng)絡優(yōu)化也是APP性能優(yōu)化的一個非常重要的一個點，而且99.99%的APP都會伴隨著網(wǎng)絡交互； 在此，我將對APP網(wǎng)絡優(yōu)化和網(wǎng)絡安全做一個詳細的總結，主要從流量、質(zhì)量、安全方面去說，如要結構點如下：

流量消耗

先說一個親身經(jīng)歷過得事情，以前在一家公司開發(fā)了一款APP，有一點客服反饋有個上海老大爺打電話過來罵人，手機裝了我們的APP，一個晚上用掉人家一兩個G；后來公司也主動幫人家承擔了這部分的流量資費，關鍵是15年流量資費還很高的，這個APP當然不是我寫的，是安卓的小伙伴！

即使流量現(xiàn)在價格不是很貴了，但是盡可能的幫用戶節(jié)省流浪也是非常應該的！

檢測流量消耗

相信大家在開發(fā)APP的時候肯定會做一些埋點和日志上報的功能，我們也可以把網(wǎng)絡請求的監(jiān)控也做進去，我們可以檢測用戶在一段時間內(nèi)的流量消耗，計算流量的均值和峰值等等，并上報流量接口，這些我們在日志或者埋點系統(tǒng)里面都可以記錄，然后上傳給服務端，然后進行數(shù)據(jù)分析，找出流量消耗的不足之處。

數(shù)據(jù)緩存

說到緩存，這也是一個非常大的一個點，有時間也可以展開說，我平時的博客關于緩存也講到很多，緩存的一個非常重要的好處就是提好了頁面加載速度，提高用戶的使用體驗；但是緩存也可以替用戶節(jié)省流量的消耗。 APP數(shù)據(jù)的緩存無非是列表接口的緩存、WebView的緩存，關于WebView的緩存我也單獨寫過，如下：

《iOS-WKWebView緩存并保證實時性》

《iOS-UIWebView緩存并保證實時性》

我們還可以做資源包下發(fā)預制加載等，這里也不展開了！

數(shù)據(jù)壓縮

關于數(shù)據(jù)壓縮，這邊主要想講的就是資源文件的數(shù)據(jù)壓縮了，主要在網(wǎng)絡上傳和網(wǎng)絡下載方面；

1.數(shù)據(jù)上傳 比如上傳圖片數(shù)據(jù)的時候是不是需要原圖高清圖，現(xiàn)在相機的像素都高，我們是不是可以搞了壓縮一下圖片或者視頻再上傳，就像微信發(fā)送圖片的時候，用戶可以選擇壓縮或者原圖；

2.數(shù)據(jù)下載 下載目前也是APP的大頭了，一般APP都是請求下載的數(shù)據(jù)比較多；我們在加載資源的時候可以選擇加載壓縮資源，比如微信的朋友圈，小圖的時候我們可以加載縮略圖，要是點擊查看大圖的時候才考慮加載大圖原圖；

交互頻率

數(shù)據(jù)交互如果比較頻繁會消耗用戶的流量，而且用戶體驗不好，還有一個非常重要的原因就是頻繁的網(wǎng)絡請求也會比較損耗手機的電量；所以我們可以合并一些能合并的網(wǎng)絡請求，比如日志上報的時候。

請求釋放

在APP開發(fā)的過程中，一般就是一進入頁面就進行網(wǎng)絡請求，然后等待結束加載數(shù)據(jù)，但是比如網(wǎng)絡請求比較緩慢（可能是數(shù)據(jù)量比較大，也有可能是網(wǎng)絡狀況不好），用戶不想等了，直接返回頁面銷毀了，但是我們的大部分網(wǎng)絡請求是單獨封裝的，但是網(wǎng)絡請求還在繼續(xù)請求中，這里數(shù)據(jù)、性能、內(nèi)存、電量的問題就出來了，所以大家在封裝網(wǎng)絡請求的時候要把頁面銷毀就取消網(wǎng)絡請求的場景考慮進去！

網(wǎng)絡質(zhì)量

請求速度

網(wǎng)絡請求的速度是影響用戶體驗的一個非常重要的原因，所以服務端也要想著來提高api的交互速度，為此我們可以通過下面的幾個方案來優(yōu)化交互速度，如下：

a.域名合并，減少了DNS調(diào)用次數(shù)，降低了DNS劫持風險；

b.ip直連，去除DNS的解析步驟；

c.api緩存，比如redis緩存；

d.數(shù)據(jù)資源壓縮上傳；

請求質(zhì)量

監(jiān)控網(wǎng)絡請求質(zhì)量和請求速度，然后記錄日志進行上報，監(jiān)控完整的網(wǎng)絡請求鏈路；

服務器壓力

api的設計也要考慮到api的壓力以及服務器的壓力，防止因為壓力太大導致接口掛掉，從而影響用戶的體驗；

數(shù)據(jù)處理

服務端在給APP端提供數(shù)據(jù)的時候，避免讓APP端進行數(shù)據(jù)處理或者運算，比較APP的內(nèi)存資源和運算資源有限，不要過度消耗浪費APP資源； 比如，我上家公司的用戶信息里面有用戶的年齡，但是服務端給的不是直接的年齡數(shù)據(jù)，而是給的生日時間戳，需要APP端自己去計算年齡，但是我們知道 NSDateFormatter又是重大內(nèi)存開銷對象，在列表處理的時候又比較消耗內(nèi)存，所以建議關于運算的一些東西最好在服務端計算好，這種不僅僅保證APP的性能問題，還是一種安全問題！

網(wǎng)絡安全

我們在APP端的網(wǎng)絡安全問題一般是APP抓包、DNS劫持、服務器安全，詳細如下：

APP抓包

說到抓包，侵入者可以選擇抓取數(shù)據(jù)來竊密APP的關鍵數(shù)據(jù)，然后模擬請求，做一些APP不好控制的事情，在此我們可以使用Https進行網(wǎng)絡請求，還可以禁止網(wǎng)絡請求設置代碼； 還可以把請求頭和請求體進行加密傳輸，多一次保證！ 但是需要說明一點的是，沒用絕對的安全，只要是人設計的加密就有人設計解密，窺視心里在作怪！

DNS劫持

DNS劫持，由于域名解析為IP這個過程中，其解析是基于UDP 協(xié)議實現(xiàn)，所以報文是明文狀態(tài)，可能會在請求過程中被監(jiān)測，然后攻擊者做一些自己的處理，比如返回假的IP地址或者什么都不做使請求失去響應，其效果就是對特定的網(wǎng)絡不能反應或訪問的是假網(wǎng)址。根本原因就是以下兩點：

a.惡意攻擊，攔截運營商的解析過程，把自己的非法東西嵌入其中。

b.運營商為了利益或者一些其他的因素，允許一些第三方在自己的鏈接里打打廣告之類的。

如何防止DNS劫持？ 可以通過上面我說的IP直連，自己在APP解析！ 推薦一篇寫的比較詳細的關于DNS的，如下：

《APP網(wǎng)絡優(yōu)化之DNS優(yōu)化實踐》

服務器安全

服務器安全可以從物理安全和網(wǎng)絡安全來說 a.物理安全，服務器要考慮比如斷電、斷網(wǎng)等情況下導致的安全問題； b.網(wǎng)絡安全，防止服務器被攻擊、被爬蟲等問題； 所以，服務器的備份機制和數(shù)據(jù)備份機制和重要，還要限制同一IP的請求次數(shù)和間隔等；