1.1 談?wù)勀銓?duì)Android性能優(yōu)化方面的了解？
- 啟動(dòng)優(yōu)化： application中不要做大量耗時(shí)操作，如果必須的話，建議異步做耗時(shí)操作
- 布局優(yōu)化：使用合理的控件選擇，少嵌套。（合理使用 include，merge，viewStub等使用）
- apk優(yōu)化（資源文件優(yōu)化，代碼優(yōu)化，lint檢查，.9.png，合理使用shape替代圖片，webp等）
- 性能優(yōu)化，網(wǎng)絡(luò)優(yōu)化，電量優(yōu)化
避免輪詢，盡量使用推送
應(yīng)用處于后臺(tái)時(shí)，禁用某些數(shù)據(jù)傳輸
限制訪問頻率，失敗后不要無限重連
選用合適的定位服務(wù)（GPS定位，網(wǎng)絡(luò)定位，被動(dòng)定位）
使用緩存
startActivityForResult替代發(fā)送廣播 - 內(nèi)存優(yōu)化
循環(huán)盡量不使用局部變量
避免在onDraw中創(chuàng)建對(duì)象，onDraw會(huì)被頻繁調(diào)用，容易造成內(nèi)存抖動(dòng)。循環(huán)中創(chuàng)建大的對(duì)象，也是如此。
不用的對(duì)象及時(shí)釋放
數(shù)據(jù)庫的cursor及時(shí)關(guān)閉
adapter使用緩存
注冊(cè)廣播后，在生命周期結(jié)束時(shí)反注冊(cè)
及時(shí)關(guān)閉流操作
圖片盡量使用軟引用，較大的圖片可以通過BitmapFactory縮放后再使用，并及時(shí)recycler。另外加載巨圖時(shí)不要使用setImageBitmap或setImageResourse或BitmapFactory.decodeResource，這些方法拿到的都是bitmap的對(duì)象，占用內(nèi)存較大?？梢杂肂itmapFactory.decodeStream方法配合BitmapFactory.Options進(jìn)行縮放避免static成員變量引用資源耗費(fèi)過多實(shí)例避免靜態(tài)內(nèi)部類的引用
1.2 一般什么情況下會(huì)導(dǎo)致內(nèi)存泄漏問題？
- 資源對(duì)象沒關(guān)閉造成的內(nèi)存泄漏（如： Cursor、File等）
- ListView 的 Adapter 中沒有使用緩存的ConvertView
- Bitmap 對(duì)象不在使用時(shí)調(diào)用recycle()釋放內(nèi)存
- 集合中對(duì)象沒清理造成的內(nèi)存泄漏（特別是 static 修飾的集合）
- 接收器、監(jiān)聽器注冊(cè)沒取消造成的內(nèi)存泄漏
- Activity 的 Context 造成的泄漏，可以使用ApplicationContext
- Handler 造成的內(nèi)存泄漏問題（一般由于 Handler 生命周期比其外部類的生命周期長引起的）
1.3 自定義 Handler 時(shí)如何有效地避免內(nèi)存泄漏問題？
- 自定義的靜態(tài)Handler
- 可以加一個(gè)弱引用
- 還有一個(gè)主意的就是當(dāng)你Activity被銷毀的時(shí)候如果還有消息沒有發(fā)出去就remove掉吧
- removeCallbackSandMessages去清除Message和 Runnable 加 null 寫在生命周的onDestroy()就行
1.4 哪些情況下會(huì)導(dǎo)致oom問題？
- 例如 Handler 在界面銷毀的時(shí)候消息還未發(fā)送
- File沒有關(guān)流
- 查詢到結(jié)果還沒有停止
- 內(nèi)部類持有外部類引用得不到釋放
- 不用的對(duì)象最好 null 讓 GC 回收一下
- 圖片資源什么的最好加一個(gè)軟引用
1.5 ANR 出現(xiàn)的場景以及解決方案？
在Android中，應(yīng)用的響應(yīng)性被活動(dòng)管理器（ActivityManager）和窗口管理器（Window Manager）這兩個(gè)系統(tǒng)服務(wù)所監(jiān)視。當(dāng)用戶觸發(fā)了輸入事件（如鍵盤輸入，點(diǎn)擊按鈕等）,如果應(yīng)用5秒內(nèi)沒有響應(yīng)用戶的輸入事件，那么，Android會(huì)認(rèn)為該應(yīng)用無響應(yīng)，便彈出ANR對(duì)話框。而彈出ANR異常，也主要是為了提升用戶體驗(yàn)。
解決方案是對(duì)于耗時(shí)的操作，比如訪問網(wǎng)絡(luò)、訪問數(shù)據(jù)庫等操作，需要開辟子線程，在子線程處理耗時(shí)的操作，主線程主要實(shí)現(xiàn)UI的操作。
1.6 談?wù)凙ndroid中內(nèi)存優(yōu)化的方式？
關(guān)于內(nèi)存泄漏，一般像單例模式的使用不當(dāng)、集合的操作不當(dāng)、資源的缺乏有效的回收機(jī)制、Handler、線程的使用不當(dāng)?shù)鹊榷加锌赡芤l(fā)內(nèi)存泄漏。
- 單例模式引發(fā)的內(nèi)存泄漏
原因：單例模式里的靜態(tài)實(shí)例持有對(duì)象的引用，導(dǎo)致對(duì)象無法被回收，常見為持有Activity的引用
優(yōu)化：改為持有Application的引用，或者不持有使用的時(shí)候傳遞。 - 集合操作不當(dāng)引發(fā)的內(nèi)存泄漏
原因：集合只增不減
優(yōu)化：有對(duì)應(yīng)的刪除或卸載操作 - 線程的操作不當(dāng)引發(fā)的內(nèi)存泄漏
原因：線程持有對(duì)象的引用在后臺(tái)執(zhí)行，與對(duì)象的生命周期不一致
優(yōu)化：靜態(tài)實(shí)例+弱引用(WeakReference)方式，使其生命周期一致 - 匿名內(nèi)部類/非靜態(tài)內(nèi)部類操作不當(dāng)引發(fā)的內(nèi)存泄漏
原因：內(nèi)部類持有對(duì)象引用，導(dǎo)致無法釋放，比如各種回調(diào)
優(yōu)化：保持生命周期一致，改為靜態(tài)實(shí)例+對(duì)象的弱引用方式（WeakReference） - 常用的資源未關(guān)閉回收引發(fā)的內(nèi)存泄漏
原因：BroadcastReceiver，F(xiàn)ile，Cursor，IO流，Bitmap等資源使用未關(guān)閉
優(yōu)化：使用后有對(duì)應(yīng)的關(guān)閉和卸載機(jī)制 - Handler使用不當(dāng)造成的內(nèi)存泄漏
原因：Handler持有Activity的引用，其發(fā)送的Message中持有Handler的引用，當(dāng)隊(duì)列處理Message的時(shí)間過長會(huì)導(dǎo)致Handler無法被回收
優(yōu)化：靜態(tài)實(shí)例+弱引用(WeakReference)方式
內(nèi)存溢出
原因：
- 內(nèi)存泄漏長時(shí)間的積累
- 業(yè)務(wù)操作使用超大內(nèi)存
優(yōu)化： - 調(diào)整圖像大小后再放入內(nèi)存、及時(shí)回收
- 不要過多的創(chuàng)建靜態(tài)變量
1.7 談?wù)劜季謨?yōu)化的技巧？
1、降低Overdraw（過度繪制），減少不必要的背景繪制
2、減少嵌套層次及控件個(gè)數(shù)
3、使用Canvas的clipRect和clipPath方法限制View的繪制區(qū)域
4、通過imageDrawable方法進(jìn)行設(shè)置避免ImageView的background和imageDrawable重疊
5、借助ViewStub按需延遲加載
6、選擇合適的布局類型
7、熟悉API盡量借助系統(tǒng)現(xiàn)有的屬性來實(shí)現(xiàn)一些UI效果
1.8 Android中的圖片優(yōu)化方案？
- 首先我們可以對(duì)圖片進(jìn)行二次采樣，從本質(zhì)上減少圖片的內(nèi)存占用。就是將大圖片縮小之后放入到內(nèi)存中，以實(shí)現(xiàn)減小內(nèi)存的目的
- 其次就是采用三層緩存架構(gòu)，提高圖片的訪問速度。三層緩存架構(gòu)是內(nèi)存-文件-網(wǎng)絡(luò)。內(nèi)存是訪問速度最快的部分但是分配的空間有限，所以不可能占用太多。其中內(nèi)存緩存可以采用LRU算法（最近最少使用算法），來確定要?jiǎng)h除內(nèi)存中的那些圖片，保存那些圖片。文件就是將圖片保存到本地，可以使SD卡中，也可以是手機(jī)內(nèi)部存儲(chǔ)中。網(wǎng)絡(luò)就是訪問網(wǎng)絡(luò)下載圖片，進(jìn)行圖片的加載。
- 常見的png，JPG，webp等格式的圖片在設(shè)置到UI上之前需要經(jīng)過解碼過程，而圖片采用不同的碼率，也會(huì)造成對(duì)內(nèi)存的占用不同。
- 最后一點(diǎn)，也是圖片優(yōu)化最重要的一點(diǎn)。重用Bitmap.
- 不使用Bitmap要記得實(shí)時(shí)回收，減小內(nèi)存的開銷
1.9 Android Native Crash問題如何分析定位？
- 利用breakpad，dump Native崩潰時(shí)日志信息
- 利用addr2line跟ndk-strace等工具，根據(jù)崩潰日志偏移量定位具體源碼位置
- 根據(jù)信號(hào)提示進(jìn)行具體處理
此步驟的難點(diǎn)在于：
Native Crash的時(shí)候整個(gè)app的狀態(tài)是極其不穩(wěn)定的，很可能由于保存日志（或者上報(bào)日志）等操作引起其他異常，所以此時(shí)最好fork一個(gè)子進(jìn)程來保存當(dāng)前進(jìn)程的日志。
1.10 談?wù)勗趺唇oapk瘦身？
第1條：使用一套資源
這是最基本的一條規(guī)則，但非常重要。
對(duì)于絕大對(duì)數(shù)APP來說，只需要取一套設(shè)計(jì)圖就足夠了。
鑒于現(xiàn)在分辨率的趨勢，建議取720p的資源，放到xhdpi目錄。
相對(duì)于多套資源，只使用720P的一套資源，在視覺上差別不大，很多大公司的產(chǎn)品也是如此，但卻能顯著的減少資源占用大小，順便也能減輕設(shè)計(jì)師的出圖工作量了。
注意，這里不是說把不是xhdpi的目錄都刪除，而是強(qiáng)調(diào)保留一套設(shè)計(jì)資源就夠了。
第2條：開啟minifyEnabled混淆代碼
在gradle使用minifyEnabled進(jìn)行Proguard混淆的配置，可大大減小APP大?。?/p>
android {
buildTypes {
release {
minifyEnabled true
}
}
}
在proguard中，是否保留符號(hào)表對(duì)APP的大小是有顯著的影響的，可酌情不保留，但是建議盡量保留用于調(diào)試。
詳細(xì)proguard的相關(guān)的配置和原理可自行查閱。
第3條：開啟shrinkResources去除無用資源
在gradle使用shrinkResources去除無用資源，效果非常好。
android {
buildTypes {
release {
shrinkResources true
}
}
}
第4條：刪除無用的語言資源
大部分應(yīng)用其實(shí)并不需要支持幾十種語言的國際化支持。
還好強(qiáng)大的gradle支持語言的配置，比如國內(nèi)應(yīng)用只支持中文：
android {
defaultConfig {
resConfigs "zh"
}
}
第5條：使用Tinypng有損壓縮
android打包本身會(huì)對(duì)png進(jìn)行無損壓縮，所以使用像Tinypng這樣的有損壓縮是有必要的。
重點(diǎn)是Tinypng使用智能有損壓縮技術(shù)，以盡量少的失真換來圖片大小的銳減，效果非常好，強(qiáng)烈推薦。
Tinypng的官方網(wǎng)站：TinyPNG – Compress WebP, PNG and JPEG images intelligently
第6條：使用jpg格式
如果對(duì)于非透明的大圖，jpg將會(huì)比png的大小有顯著的優(yōu)勢，雖然不是絕對(duì)的，但是通常會(huì)減小到一半都不止。
在啟動(dòng)頁，活動(dòng)頁等之類的大圖展示區(qū)采用jpg將是非常明智的選擇。
第7條：使用webp格式
webp支持透明度，壓縮比比jpg更高但顯示效果卻不輸于jpg，官方評(píng)測quality參數(shù)等于75均衡最佳。
相對(duì)于jpg、png，webp作為一種新的圖片格式，限于android的支持情況暫時(shí)還沒用在手機(jī)端廣泛應(yīng)用起來。從Android 4.0+開始原生支持，但是不支持包含透明度，直到Android 4.2.1+才支持顯示含透明度的webp，使用的時(shí)候要特別注意。
官方介紹
第8條：縮小大圖
如果經(jīng)過上述步驟之后，你的工程里面還有一些大圖，考慮是否有必要維持這樣的大尺寸，是否能適當(dāng)?shù)目s小。
事實(shí)上，由于設(shè)計(jì)師出圖的原因，我們拿到的很多圖片完全可以適當(dāng)?shù)目s小而對(duì)視覺影響是極小的。
第9條：覆蓋第三庫里的大圖
有些第三庫里引用了一些大圖但是實(shí)際上并不會(huì)被我們用到，就可以考慮用1x1的透明圖片覆蓋。
你可能會(huì)有點(diǎn)不舒服，因?yàn)槟愕膁rawable下竟然包含了一些莫名其妙的名稱的1x1圖片…
第10條：刪除armable-v7包下的so
基本上armable的so也是兼容armable-v7的，armablev7a的庫會(huì)對(duì)圖形渲染方面有很大的改進(jìn)，如果沒有這方面的要求，可以精簡。
這里不排除有極少數(shù)設(shè)備會(huì)Crash，可能和不同的so有一定的關(guān)系，請(qǐng)大家務(wù)必測試周全后再發(fā)布。
第11條：刪除x86包下的so
與第十條不同的是，x86包下的so在x86型號(hào)的手機(jī)是需要的，如果產(chǎn)品沒用這方面的要求也可以精簡。
建議實(shí)際工作的配置是只保留armable、x86下的so文件，算是一個(gè)折中的方案。
第12條：使用微信資源壓縮打包工具
微信資源壓縮打包工具通過短資源名稱，采用７zip對(duì)APP進(jìn)行極致壓縮實(shí)現(xiàn)減小APP的目標(biāo)，效果非常的好，強(qiáng)烈推薦。
詳情參考：Android資源混淆工具使用說明
原理介紹：安裝包立減1M–微信Android資源混淆打包工具建議開啟7zip，注意白名單的配置，否則會(huì)導(dǎo)致有些資源找不到，官方已經(jīng)發(fā)布AndResGuard到gradle中了，非常方便：
apply plugin:'AndResGuard'
buildscript {
dependencies {
classpath 'com.tencent.mm:AndResGuard-gradleplugin:1.1.7'
}
}
andResGuard {
mappingFile = null
use7zip = true
useSign = true
keepRoot = false
// add < your_application_id >.R.drawable.icon into whitelist.
// because the launcher will get thgge icon with his name
def packageName = <your_application_id > whiteList = [
//for your icon
packageName + ".R.drawable.icon",
//for fabric
packageName + ".R.string.com.crashlytics.*",
//for umeng update
packageName + ".R.string.umeng*",
packageName + ".R.string.UM*",
packageName + ".R.string.tb_*",
packageName + ".R.layout.umeng*",
packageName + ".R.layout.tb_*",
packageName + ".R.drawable.umeng*",
packageName + ".R.drawable.tb_*",
packageName + ".R.anim.umeng*",
packageName + ".R.color.umeng*",
packageName + ".R.color.tb_*",
packageName + ".R.style.*UM*",
packageName + ".R.style.umeng*",
packageName + ".R.id.umeng*"
]
compressFilePattern = [
"*.png",
"*.jpg",
"*.jpeg",
"*.gif",
"resources.arsc"
]
sevenzip {
artifact = 'com.tencent.mm:SevenZip:1.1.7'
//path = "/usr/local/bin/7za"
}
}
會(huì)生成一個(gè)andresguard/resguard的Task，自動(dòng)讀取release簽名進(jìn)行重新混淆打包。
第13條：使用provided編譯
對(duì)于一些庫是按照需要?jiǎng)討B(tài)的加載，可能在某些版本并不需要，但是代碼又不方便去除否則會(huì)編譯不過。
使用provided可以保證代碼編譯通過，但是實(shí)際打包中并不引用此第三方庫，實(shí)現(xiàn)了控制APP大小的目標(biāo)。
但是也同時(shí)就需要開發(fā)者自己判斷不引用這個(gè)第三方庫時(shí)就不要執(zhí)行到相關(guān)的代碼，避免APP崩潰。
第14條：使用shape背景
特別是在扁平化盛行的當(dāng)下，很多純色的漸變的圓角的圖片都可以用shape實(shí)現(xiàn)，代碼靈活可控，省去了量的背景圖片。
第15條：使用著色方案
相信你的工程里也有很多selector文件，也有很多相似的圖片只是顏色不同，通過著色方案我們能大大減輕這樣的工作量，減少這樣的文件。
借助于android support庫可實(shí)現(xiàn)一個(gè)全版本兼容的著色方案，參考代碼：DrawableLess.java
第16條：在線化素材庫
如果你的APP支持素材庫(比如聊天表情庫)的話，考慮在線加載模式，因?yàn)橥夭膸於加胁恍〉捏w積。
這一步需要開發(fā)者實(shí)現(xiàn)在線加載，一方面增加代碼的復(fù)雜度，一方面提高了APP的流量消耗，建議酌情選擇。
第17條：避免重復(fù)庫
避免重復(fù)庫看上去是理所當(dāng)然的，但是秘密總是藏的很深，一定要當(dāng)心你引用的第三方庫又引用了哪個(gè)第三方庫，這就很容易出現(xiàn)功能重復(fù)的庫了，比如使用了兩個(gè)圖片加載庫：Glide和Picasso。
通過查看exploded-aar目錄和External Libraries或者反編譯生成的APK，盡量避免重復(fù)庫的大小，減小APP大小。
第18條：使用更小的庫
同樣功能的庫在大小上是不同的，甚至?xí)沂夂艽蟆?br> 如果并無對(duì)某個(gè)庫特別需求而又對(duì)APP大小有嚴(yán)格要求的話，比較這些相同功能第三方庫的大小，選擇更小的庫會(huì)減小APP大小。
第19條：支持插件化
過去的一年，插件化技術(shù)雨后春筍一樣的都冒了出來，這些技術(shù)支持動(dòng)態(tài)的加載代碼和動(dòng)態(tài)的加載資源，把APP的一部分分離出來了，對(duì)于業(yè)務(wù)龐大的項(xiàng)目來說非常有用，極大的分解了APP大小。
因?yàn)椴寮夹g(shù)需要一定的技術(shù)保障和服務(wù)端系統(tǒng)支持，有一定的風(fēng)險(xiǎn)，如無必要（比如一些小型項(xiàng)目，也沒什么擴(kuò)展業(yè)務(wù)）就不需要了，建議酌情選擇。
第20條：精簡功能業(yè)務(wù)
這條完全取決于業(yè)務(wù)需求。
從統(tǒng)計(jì)數(shù)據(jù)分析砍掉一些沒用的功能是完全有可能的，甚至干脆去掉一些花哨的功能出個(gè)輕聊版、極速版也不是不可以的。
第21條：重復(fù)執(zhí)行第1到20條
多次執(zhí)行上述步驟，你總能發(fā)現(xiàn)一些蛛絲馬跡，這是一個(gè)好消息，不是嗎？
第22條：Facebook的redex優(yōu)化字節(jié)碼
redex是facebook發(fā)布的一款android字節(jié)碼的優(yōu)化工具，需要按照說明文檔自行配置一下。
redex input.apk -o output.apk --sign -s <KEYSTORE> -a <KEYALIAS> -p <KEYPASS>
1.11 談?wù)勀闶侨绾蝺?yōu)化App啟動(dòng)過程的？
- 把Application onCreate中要執(zhí)行的方法分為同步和異步，盡量去延遲執(zhí)行或者使用空閑線程去初始化一些方法
- 配置一個(gè)啟動(dòng)背景，避免白屏或者黑屏，然后做一個(gè)空的Activity這個(gè)Activity只做一件事,就是跳轉(zhuǎn)到真的Activity，因?yàn)閱?dòng)速度和Application onCreate的耗時(shí)和第一個(gè)Activity的繪制有關(guān),
上面都是easy的做法
- 利用redex工具優(yōu)化dex , 因?yàn)閏lass字節(jié)碼分布在不同的dex中，所以啟動(dòng)的時(shí)候必須逐個(gè)查找一些文件，他們散列分布在不同的dex中，查找起來耗時(shí)又不方便，利用redex把相關(guān)的class放在同一個(gè)dex包下，避免同一個(gè)dex包被多次查找
- 在attachBaseContext中新起一個(gè)進(jìn)程去加載mutildex可以加速App啟動(dòng)頁的打開(可能在啟動(dòng)頁中會(huì)等待，但是加速了從launcher到啟動(dòng)頁的速度)
1.12 談?wù)劥a混淆的步驟？
開啟混淆
- 查看項(xiàng)目使用的第三方哪些需要設(shè)置混淆
- 保持反射native對(duì)應(yīng)的類和方法不混淆
- 保持自定義類不混淆
- 保持實(shí)體類參與序列化的不混淆
- 系統(tǒng)組件等一些固定方法會(huì)被系統(tǒng)調(diào)用的不混淆
1.13 談?wù)凙pp的電量優(yōu)化？
優(yōu)化方案總結(jié)
(1)GPS
使用要謹(jǐn)慎，如精確度不高可用WiFi定位或者基站定位，可用
非要用的話，注意定位數(shù)據(jù)的復(fù)用和定位頻率的閾值
(2)Process和Service
按需啟動(dòng)，用完就退出
(3)網(wǎng)絡(luò)數(shù)據(jù)交互
減少網(wǎng)絡(luò)網(wǎng)絡(luò)請(qǐng)求次數(shù)和數(shù)據(jù)量
WiFi比手機(jī)網(wǎng)絡(luò)省電
(4)CPU
減少I/O操作（包括數(shù)據(jù)庫操作）
減少大量的計(jì)算
(5)減少手機(jī)硬件交互
使用頻率優(yōu)化和選擇低功耗模式
1.14 談?wù)勅绾螌?duì)WebView進(jìn)行優(yōu)化？
- 單/多進(jìn)程化：WebView在獨(dú)立的進(jìn)程里面，那么WebView的進(jìn)程崩潰不會(huì)影響到主進(jìn)程運(yùn)行；同時(shí)WebView的安全漏洞也很難影響到主進(jìn)程；如果是多進(jìn)程的話，可以使用WebView的容器池，有二次秒開的作用；不過缺點(diǎn)就是需要你做好和WebView的跨進(jìn)程通訊了
- 網(wǎng)絡(luò)優(yōu)化：我們可以讓W(xué)ebView的host和客戶端的host保持一致，那么就達(dá)到復(fù)用DNS緩存的效果；如果客戶端有針對(duì)網(wǎng)絡(luò)請(qǐng)求進(jìn)行了優(yōu)化，那么可以讓W(xué)ebView的全部網(wǎng)絡(luò)請(qǐng)求托管給客戶端
- H5離線包：這個(gè)是手Q的H5方案之一，讓客戶端提前去下載離線的H5數(shù)據(jù)包，WebView只需要加載本地H5數(shù)據(jù)包即可，這么做不僅可以避免一些http的劫持，而且跳過了WebView的建立TCP連接和H5、CCS等數(shù)據(jù)下載的過程，直接開始UI渲染，大大提高了WebView的效率
1.15 如何處理大圖的加載？
1、首先確定大圖的用途，精度需求：
- 完整顯示，對(duì)精度要求不高，圖片本身就很大
- 對(duì)精度需求比較高，不需要完整顯示
2、解決方案
- 針對(duì)第一種的處理圖片本身，按需加載（根據(jù)顯示設(shè)備本身大小進(jìn)行縮放），降低精度加載（改變圖片模式，如將ARGB8888改成RGB565,ARGB4444）,修改圖片格式（png改成webp，jpg）
- 第二種的一般采用局部加載，主要要用到的是BitmapRegionDecoder這個(gè)類decodeRegion的方法，讀取圖片指定大小的數(shù)據(jù)，然后通過移動(dòng)來動(dòng)態(tài)改變顯示區(qū)域的圖片
1.16 談?wù)勅绾螌?duì)網(wǎng)絡(luò)請(qǐng)求進(jìn)行優(yōu)化？
- 最開始的是DNS，當(dāng)我們發(fā)起一個(gè)網(wǎng)絡(luò)請(qǐng)求，首先要經(jīng)過DNS服務(wù)，將域名轉(zhuǎn)化為IP地址，為避免DNS解析異常問題，可以直接使用 IP 建立連接；
- 使用 Gzip 壓縮 Response 減少數(shù)據(jù)傳輸量；使用Protocol Buffer 代替 JSON；
- 請(qǐng)求圖片的 url 中可以添加格式、質(zhì)量、寬高等參數(shù)；使用縮略圖、使用WebP格式圖片，大圖分片傳輸；
- 使用網(wǎng)絡(luò)緩存，使用圖片加載框架；
- 監(jiān)聽設(shè)備網(wǎng)絡(luò)狀態(tài)，根據(jù)不同網(wǎng)絡(luò)狀態(tài)選擇對(duì)應(yīng)情況下的網(wǎng)絡(luò)請(qǐng)求策略：網(wǎng)絡(luò)良好和弱網(wǎng)、離線等情況下分別設(shè)計(jì)不同的請(qǐng)求策略，比如 WIFI 下一個(gè)請(qǐng)求可以獲取幾十個(gè)數(shù)據(jù)，甚至可以一次性執(zhí)行多個(gè)請(qǐng)求；而弱網(wǎng)下一個(gè)請(qǐng)求獲取幾個(gè)數(shù)據(jù)，且文本類型優(yōu)先，富文本其次，除文本數(shù)據(jù)外其它類型的數(shù)據(jù)一開始只顯示占位符；離線下事先保存請(qǐng)求數(shù)據(jù)到磁盤，在離線時(shí)從磁盤加載數(shù)據(jù)。
1.17 請(qǐng)談?wù)勅绾渭虞dBitmap并防止內(nèi)存溢出？
首先我們 要知道Bitmap內(nèi)存是怎么計(jì)算的例子：
手機(jī)屏幕大小 1080 x 1920（inTarget = 420），加載xhdpi （inDensity = 320）中的圖片 1920 x 1080，scale = 420 / 320，最總我們可以得知他的占用內(nèi)存 1418 * 2520 * 4 很明顯 被放大了。
防止內(nèi)存溢出：
- 對(duì)圖片進(jìn)行內(nèi)存壓縮；
- 高分辨率的圖片放入對(duì)應(yīng)文件夾；
- 內(nèi)存復(fù)用
- 及時(shí)回收
