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

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

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

流量消耗

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

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

檢測流量消耗

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

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

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

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

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

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

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

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

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

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

交互頻率

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

請求釋放

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

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

請求速度

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

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

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

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

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

請求質(zhì)量

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

服務(wù)器壓力

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

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

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

網(wǎng)絡(luò)安全

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

APP抓包

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

DNS劫持

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

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

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

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

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

服務(wù)器安全

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