android訪問網路優化

Ⅰ android網路優化(二)DNS解析錯誤 備用域名頂上

網路不通，能訪問其他網路，但是訪問不了我們app，你覺得我們跟客戶說網路不好，客戶會信嗎？
這就可能 我們域名解析可能不成功
先簡單看圖了解一下DNS解析

這樣我們就可以減少網路失敗導致我們的原因！

Ⅱ Android性能優化總結

常用的Android性能優化方法：

一、布局優化：

1）盡量減少布局文件的層級。

層級少了，繪制的工作量也就少了，性能自然提高。

2）布局重用 <include標簽>

3）按需載入：使用ViewStub,它繼承自View,一種輕量級控制項，本身不參與任何的布局和繪制過程。他的layout參數里添加一個替換的布局文件，當它通過setVisibility或者inflate方法載入後，它就會被內部布局替換掉。

二、繪制優化：

基於onDraw會被調用多次，該方法內要避免兩類操作：

1）創建新的局部對象，導致大量垃圾對象的產生，從而導致頻繁的gc，降低程序的執行效率。

2）不要做耗時操作，搶CPU時間片，造成繪制很卡不流暢。

三、內存泄漏優化：

1）靜態變數導致內存泄漏   比較明顯

2）單例模式導致的內存泄漏 單例無法被垃圾回收，它持有的任何對象的引用都會導致該對象不會被gc。

3）屬性動畫導致內存泄漏  無限循環動畫，在activity中播放，但是onDestroy時沒有停止的話，動畫會一直播放下去，view被動畫持有，activity又被view持有，導致activity無法被回收。

四、響應速度優化：

1）避免在主線程做耗時操作 包括四大組件，因為四大組件都是運行在主線程的。

2）把一些創建大量對象等的初始化工作放在頁面回到前台之後，而不應該放到創建的時候。

五、ListView的優化：

1）使用convertView，走listView子View回收的一套：RecycleBin 機制

主要是維護了兩個數組，一個是mActiveViews,當前可見的view,一個是mScrapViews，當前不可見的view。當觸摸ListView並向上滑動時，ListView上部的一些OnScreen的View位置上移，並移除了ListView的屏幕范圍，此時這些OnScreen的View就變得不可見了，不可見的View叫做OffScreen的View，即這些View已經不在屏幕可見范圍內了，也可以叫做ScrapView，Scrap表示廢棄的意思，ScrapView的意思是這些OffScreen的View不再處於可以交互的Active狀態了。ListView會把那些ScrapView（即OffScreen的View）刪除，這樣就不用繪制這些本來就不可見的View了，同時，ListView會把這些刪除的ScrapView放入到RecycleBin中存起來，就像把暫時無用的資源放到回收站一樣。

當ListView的底部需要顯示新的View的時候，會從RecycleBin中取出一個ScrapView，將其作為convertView參數傳遞給Adapter的getView方法，從而達到View復用的目的，這樣就不必在Adapter的getView方法中執行LayoutInflater.inflate()方法了。

RecycleBin中有兩個重要的View數組，分別是mActiveViews和mScrapViews。這兩個數組中所存儲的View都是用來復用的，只不過mActiveViews中存儲的是OnScreen的View，這些View很有可能被直接復用；而mScrapViews中存儲的是OffScreen的View，這些View主要是用來間接復用的。

2）使用ViewHolder避免重復地findViewById

3)快速滑動不適合做大量非同步任務，結合滑動監聽，等滑動結束之後載入當前顯示在屏幕范圍的內容。

4）getView中避免做耗時操作，主要針對圖片：ImageLoader來處理(原理：三級緩存)

5）對於一個列表，如果刷新數據只是某一個item的數據，可以使用局部刷新，在列表數據量比較大的情況下，節省不少性能開銷。

六、Bitmap優化：

1）減少內存開支：圖片過大，超過控制項需要的大小的情況下，不要直接載入原圖，而是對圖片進行尺寸壓縮，方式是BitmapFactroy.Options 采樣，inSampleSize 轉成需要的尺寸的圖片。

2）減少流量開銷：對圖片進行質量壓縮，再上傳伺服器。圖片有三種存在形式：硬碟上時是file，網路傳輸時是stream，內存中是stream或bitmap，所謂的質量壓縮，它其實只能實現對file的影響，你可以把一個file轉成bitmap再轉成file，或者直接將一個bitmap轉成file時，這個最終的file是被壓縮過的，但是中間的bitmap並沒有被壓縮。bitmap.compress(Bitmap.CompressFormat.PNG,100,bos);

七、線程優化：

使用線程池。為什麼要用線程池？

1、從「為每個任務分配一個線程」轉換到「在線程池中執行任務」

2、通過重用現有的線程而不是創建新線程，可以處理多個請求在創建銷毀過程中產生的巨大開銷

3、當使用線程池時，在請求到來時間 ，不用等待系統重新創建新的線程，而是直接復用線程池中的線程，這樣可以提高響應性。

4、通過和適當調整線程池的大小 ，可以創建足夠多的線程以使處理器能夠保持忙碌狀態，同時還可以防止過多線程相互競爭資源而使應用程序耗盡內存或者失敗。

5、一個App裡面所有的任務都放在線程池中執行後，可以統一管理 ，當應用退出時，可以把程序中所有的線程統一關閉，避免了內存和CPU的消耗。

6、如果這個任務是一個循環調度任務，你則必須在這個界面onDetach方法把這個任務給cancel掉，如果是一個普通任務則可cancel，可不cancel，但是最好cancel

7、整個APP的總開關會在應用退出的時間把整個線程池全部關閉。

八、一些性能優化建議：

1）避免創建過多對象，造成頻繁的gc

2)不要過多使用枚舉，枚舉佔用的空間比整型大很多

3）字元串的拼接使用StringBuffer、StringBuilder來替代直接使用String,因為使用String會創建多個String對象，參考第一條。

4）適當使用軟引用，（弱引用就不太推薦了）

5）使用內存緩存和磁碟緩存。

Ⅲ 如何通過技術優化讓 Android 程序變得流暢

Android APP優化的幾點考量：

高效的使用多線程

1.在後台取消一些線程中的動作

App運行過程中所有的操作都默認在主線程（UI線程）中進行的，這樣App的響應速度就會受到影響。會導致程序陷入卡頓、死掉甚至會發生系統錯誤。

為 了加快響應速度，需要把費時的操作（比如網路請求、資料庫操作或者復雜的計算）從主線程移動到一個單獨的線程中。最高效的方式就是在類這一級完成這項操作，可以使用AsyncTask或者IntentService來創建後台操作。

2.保持響應不發生ANR

從UI線程中移除費時操作這個方式還可以防止用戶操作出現系統不響應（ANR）對話框。需要做的就是繼承AsyncTask來創建一個後台工作線程，並實現doInBackground()方法。

3.在線程中初始化查詢操作

當查詢操作正在後台處理時，展示數據也不是即時的，可以使用CursorLoader對象來加快速度，這個操作可以使Activity和用戶之間的互動不受影響。

使用這個對象後， App會為ContentProvider初始化一個獨立的後台線程進行查詢，當查詢結束後就會給調用查詢的Activity返回結果。

4.其它需要注意的方面

使用StrictMode來檢查UI線程中可能潛在的費時操作；

使用一些特殊的工具如Safe.ijiami、Systrace或者Traceview來尋找在你的應用中的瓶頸；

優化設備的電池壽命

對於電池使用來說，主要費電情況如下：

更新數據時經常喚醒程序；

用EDGE或者3G來傳遞數據；

文本數據轉換，進行非JIT正則表達式操作。

5.優化網路

如果沒有網路連接，讓應用跳過網路操作；只在有網路連接並且無漫遊的情況下更新數據；

選擇兼容的數據格式，把含有文本數據和二進制數據的請求全部轉化成二進制數據格式請求；

使用高效的轉換工具，多考慮使用流式轉換工具，少用樹形的轉換工具；

為了更快的用戶體驗，減少重復訪問伺服器的操作；

如果可以的話，使用framework的GZIP庫來壓縮文本數據以高效使用CPU資源。

其他的優化方面還有低內存實現UI效果，優化的方面有很多，需要逐步來進行。

Ⅳ android性能優化07-電量網路優化

當用戶有一段時間未觸摸應用並且應用沒有以下表現，則Android系統就會使應用進入空閑狀態

系統提供了一個可配置的白名單，將部分免除低電耗模式和應用待機模式優化的應用列入其中，app可以使用網路並保留部分喚醒鎖定，其他限制任然受限

PowerManager.() 來檢查應用當前是否在豁免白名單中。

對話框方式，跳轉方式意義不大

以前有Battery Historian 等其他工具；8.0以上用energy profiler 即可，看下cpu的情況和各種電量模式下的狀態些，可以選中區域看

keep-alive 保持socket的長鏈接
http1.1上面同時發送多個請求：串列可以共用，並行還是得走3次握手
http2 用多路復用解決了並行問題
okhttp3以上支持http2
需要服務端配合，如果服務端不開啟keep-alive 無用

Ⅳ 如何通過技術優化讓 Android 程序變得流暢

安卓程序並不能完完全全變得像iOS那樣流程，這是安卓本身的設計的限制。安卓程序的後台運行是真的後台運行，就算你關了程序，但是程序還是會在後台運行的。所以，安卓註定會越用越卡，這是避免不了的，我們能做的只有盡量優化一下，以下是一些建議。
1.優化APP設計。減少代碼冗餘.比如重復性的代碼可以寫在函數里,每次只需調用同一塊代碼.更不要為實現一個功能而圖方便引入一個龐大的庫(有很多功能可能用不上,卻降低執行代碼的效率)
2.用戶要經常釋放內存。某些功能在用不上時絕對不要霸佔著寶貴的內存空間。
3.多了解一下計算機工作原理的知識,理解實現同一功能的兩段代碼背後運行效率的區別。

Ⅵ Android性能優化之網路優化DNS和HttpDNS知識詳解

前言小計

本文已在在公眾號【Android開發編程】發表

一、什麼是DNS

二、DNS域名結構

1、DNS域名命名

2、域名的分級

域名可以劃分為各個子域，子域還可以繼續劃分為子域的子域，這樣就形成了頂級域名、二級域名、三級域名等

頂級域名可以分為三大類：

國家頂級域名：cn、us、uk等

通用域名：常見的有7個，com、net、org、e、int、gov、mil

方向域名： arpa,用於將ip地址轉為域名

域名伺服器

域名伺服器按照由高到低進行層次劃分：

注意： 一個域名伺服器所負責的范圍，稱為區

三、域名解析過程

域名解析的重要兩點：

以上兩點是域名解析的重要兩步。但是這並不是解析ip地址的完整過程，如果瀏覽器的緩存中有該域名對應的ip地址，就不需要向本地域名伺服器請求了等等。下面來看詳細過程:

例如要解析：www.example.com該域名的ip地址;

四、DNS安全和優化

1、dns安全問題

2、DNS優化

DNS解析是一個漫長的過程，那麼它的優化有哪些？

1、網頁端

用戶在請求請求某個鏈接之前，瀏覽器先嘗試解析該鏈接的域名再將其進行緩存。

可以這樣做：

(1) 在伺服器中響應設置X-DNS-Prefetch-Control的值為on啟動預解析

(2) 在HTML中，

(3) 在head中加入link標簽：

如

不過現在的Chrome瀏覽器會自動將當前頁面的所有帶href的dns都prefetch一遍。需要手動添加上面的link標簽的場景是：你後面訪問的域名不在當前頁面的所有鏈接中;

正確使用link標簽的姿勢：

域名收斂:建議將靜態資源只放在一個域名下面，可以減少DNS的請求

2、客戶端

HttpDNS

HttpDNS是使用HTTP協議向阿里雲的HTTPDNS伺服器的80埠直接進行請求，代替傳統的DNS協議向LDNS伺服器的53埠進行請求。從而可以繞過LDNS，可以避免運行商的域名劫持和調度不精準的問題;

五、HttpDNS介紹

總結：

網路優化的知識點很多，今天主要介紹了dns的知識點

下次繼續介紹Android網路優化的具體實現方案

Ⅶ 針對Android的性能優化集中哪些方面

一、概要：

本文主要以Android的渲染機制、UI優化、多線程的處理、緩存處理、電量優化以及代碼規范等幾方面來簡述Android的性能優化

二、渲染機制的優化：

大多數用戶感知到的卡頓等性能問題的最主要根源都是因為渲染性能。

Android系統每隔16ms發出VSYNC信號，觸發對UI進行渲染， 如果每次渲染都成功，這樣就能夠達到流暢的畫面所需要的60fps，為了能夠實現60fps，這意味著程序的大多數操作都必須在16ms內完成。

*關於JobScheler的更多知識可以參考http://hukai.me/android-training-course-in-chinese/background-jobs/scheling/index.html

七、代碼規范

1）for loop中不要聲明臨時變數，不到萬不得已不要在裡面寫try catch。

2）明白垃圾回收機制，避免頻繁GC，內存泄漏，OOM(有機會專門說)

3）合理使用數據類型，StringBuilder代替String，少用枚舉enum，少用父類聲明(List,Map)

4）如果你有頻繁的new線程，那最好通過線程池去execute它們，減少線程創建開銷。

5）你要知道單例的好處，並正確的使用它。

6）多用常量，少用顯式的"action_key"，並維護一個常量類，別重復聲明這些常量。

7）如果可以，至少要弄懂設計模式中的策略模式，組合模式，裝飾模式，工廠模式，觀察者模式，這些能幫助你合理的解耦，即使需求頻繁變更，你也不用害怕牽一發而動全身。需求變更不可怕，可怕的是沒有在寫代碼之前做合理的設計。

8）View中設置緩存屬性.setDrawingCache為true.

9）cursor的使用。不過要注意管理好cursor,不要每次打開關閉cursor.因為打開關閉Cursor非常耗時。Cursor.require用於刷cursor.

10）採用SurfaceView在子線程刷新UI,避免手勢的處理和繪制在同一UI線程（普通View都這樣做）

11）採用JNI，將耗時間的處理放到c/c++層來處理

12）有些能用文件操作的，盡量採用文件操作，文件操作的速度比資料庫的操作要快10倍左右

13）懶載入和緩存機制。訪問網路的耗時操作啟動一個新線程來做，而不要再UI線程來做

14）如果方法用不到成員變數，可以把方法申明為static，性能會提高到15%到20%

15）避免使用getter/setter存取field，可以把field申明為public，直接訪問

16）私有內部類要訪問外部類的field或方法時,其成員變數不要用private，因為在編譯時會生成setter/getter,影響性能。可以把外部類的field或方法聲明為包訪問許可權

17）合理利用浮點數，浮點數比整型慢兩倍

18）針對ListView的性能優化，ListView的背景色與cacheColorHint設置相同顏色，可以提高滑動時的渲染性能。ListView中getView是性能是關鍵，這里要盡可能的優化。

getView方法中要重用view；getView方法中不能做復雜的邏輯計算，特別是資料庫操作，否則會嚴重影響滑動時的性能

19）不用new關鍵詞創建類的實例，用new關鍵詞創建類的實例時，構造函數鏈中的所有構造函數都會被自動調用。但如果一個對象實現了Cloneable介面，我們可以調用它的clone()方法。

clone()方法不會調用任何類構造函數。在使用設計模式（Design Pattern）的場合，如果用Factory模式創建對象，則改用clone()方法創建新的對象實例非常簡單。例如，下面是Factory模式的一個典型實現：

20）public static Credit getNewCredit() {
return new Credit();
}
改進後的代碼使用clone()方法，如下所示：
private static Credit BaseCredit = new Credit();
public static Credit getNewCredit() {
return (Credit) BaseCredit.clone();
}
上面的思路對於數組處理同樣很有用。

21）乘法和除法

考慮下面的代碼：

22）ViewPager同時緩存page數最好為最小值3，如果過多，那麼第一次顯示時，ViewPager所初始化的pager就會很多，這樣pager累積渲染耗時就會增多，看起來就卡。

23）每個pager應該只在顯示時才載入網路或資料庫(UserVisibleHint=true)，最好不要預載入數據，以免造成浪費

24）提高下載速度：要控制好同時下載的最大任務數，同時給InputStream再包一層緩沖流會更快(如BufferedInputStream)

25）提供載入速度：讓服務端提供不同解析度的圖片才是最好的解決方案。還有合理使用內存緩存，使用開源的框架

引用：Android性能優化的淺談

Ⅷ Android-網路優化

APP的優化是任重而道遠的過程，必須在意每一個環節，否者當你想要優化的時候，發現到處都是坑，已經不知道填補哪裡了，所以我們必須一點一滴的做起。

網路優化

正常一條網路請求需要經過的流程是這樣：

①DNS 解析，請求DNS伺服器，獲取域名對應的 IP 地址。

②與服務端建立連接，包括 tcp 三次握手，安全協議同步流程。

③連接建立完成，發送和接收數據，解碼數據。

這里有明顯的三個優化點：

①直接使用 IP 地址，去除 DNS 解析步驟。

②不要每次請求都重新建立連接，復用連接或一直使用同一條連接(長連接)或合並介面。

③壓縮數據，減小傳輸的數據大小。

DNS優化

DNS：它的作用是根據域名查出IP地址。

DNS 完整的解析流程很長，會先從本地系統緩存取，若沒有就到最近的 DNS 伺服器取，若沒有再到主域名伺服器取，每一層都有緩存，但為了域名解析的實時性，每一層緩存都有過期時間。

DNS的缺點：

①緩存時間設置得長，域名更新不及時，設置得短，大量 DNS 解析請求影響請求速度。

②域名劫持，容易被中間人攻擊，或被運營商劫持，把域名解析到第三方 IP 地址，據統計劫持率會達到7%。

③DNS 解析過程不受控制，無法保證解析到最快的IP。

④一次請求只能解析一個域名。

HTTPDNS

原理很簡單，就是自己做域名解析的工作，通過 HTTP 請求後台去拿到域名對應的 IP 地址，直接解決上述所有問題。

HTTPDNS的好處總結就是：

①Local DNS 劫持：由於 HttpDns 是通過 IP 直接請求 HTTP 獲取伺服器 A 記錄地址，不存在向本地運營商詢問domain 解析過程，所以從根本避免了劫持問題。

②DNS 解析由自己控制，可以確保根據用戶所在地返回就近的 IP 地址，或根據客戶端測速結果使用速度最快的IP。

③一次請求可以解析多個域名。

PS：HTTPDNS 幾乎成為中大型 APP 的標配。解決了第一個問題， DNS 解析耗時的問題，順便把DNS 劫持也解決了。

連接優化

連接建立耗時的問題，這里主要的優化思路是復用連接，不用每次請求都重新建立連接，如何更有效率地復用連接，可以說是網路請求速度優化里最主要的點了。

keep-alive ：

HTTP 協議里有個 keep-alive，HTTP1.1默認開啟，一定程度上緩解了每次請求都要進行TCP三次握手建立連接的耗時。原理是請求完成後不立即釋放連接，而是放入連接池中，若這時有另一個請求要發出，請求的域名和埠是一樣的，就直接拿出連接池中的連接進行發送和接收數據，少了建立連接的耗時。 實際上現在無論是客戶端還是瀏覽器都默認開啟了keep-alive，對同個域名不會再有每發一個請求就進行一次建連的情況，純短連接已經不存在了。

但有 keep-alive 的連接一次只能發送接收一個請求，在上一個請求處理完成之前，無法接受新的請求。若同時發起多個請求，就有兩種情況：

①若串列發送請求，可以一直復用一個連接，但速度很慢，每個請求都要等待上個請求完成再進行發送。

②若並行發送請求，那麼只能每個請求都要進行tcp三次握手建立新的連接。

多路復用

對並行請求的問題，新一代協議 HTTP2 提出了多路復用去解決。 HTTP2 的多路復用機制一樣是復用連接，但它復用的這條連接支持同時處理多條請求，所有請求都可以並發在這條連接上進行，也就解決了上面說的並發請求需要建立多條連接帶來的問題。

多路復用把在連接里傳輸的數據都封裝成一個個stream，每個stream都有標識，stream的發送和接收可以是亂序的，不依賴順序，也就不會有阻塞的問題，接收端可以根據stream的標識去區分屬於哪個請求，再進行數據拼接，得到最終數據。Android 的開源網路庫OKhttp默認就會開啟keep-alive ，並且在Okhttp3以上版本也支持了 HTTP2。

數據壓縮

傳輸數據大小的問題。數據對請求速度的影響分兩方面，一是壓縮率，二是解壓序列化反序列化的速度。目前最流行的兩種數據格式是 json 和 protobuf，json 是字元串，protobuf 是二進制，即使用各種壓縮演算法壓縮後，protobuf 仍會比 json 小，數據量上 protobuf 有優勢，序列化速度 protobuf 也有一些優勢 。

除了選擇不同的序列化方式（數據格式）之外，Http可以對內容（也就是body部分）進行編碼，可以採用gzip這樣的編碼，從而達到壓縮的目的。如在開源網路庫OKhttp的 BridgeInterceptor 中會自動為我們開啟gzip解壓的支持。

其他優化方式

1、使用webp代替png/jpg。

2、不同網路的不同圖片下發，如（對於原圖是300x300的圖片）：

（1）2/3G使用低清晰度圖片：使用100X100的圖片;

（2）4G再判斷信號強度為強則使用使用300X300的圖片，為中等則使用200x200，信號弱則使用100x100圖片;

（3）WiFi網路：直接下發300X300的圖片

3、不同需求的不同圖片下發，如（對於原圖是300x300的圖片），若實際只需要25X25，則向伺服器請求該尺寸的圖片

4、http開啟緩存,根據應用的實際情況並和協商緩存方案。什麼情況下讀取緩存，針對部分介面直接採取長緩存機制。通過緩存時間控制緩存的使用。

5. 通過okhttp攔截器設置，模擬網路環境，讓你更好的找到發現問題。

Ⅸ 如何對Android進行性能優化

不知道你是說對系統優化還是什麼app優化，

系統優化就只能找底層人員的了，我也不是很了解。

app優化的話，大體有以下幾個方面

1. ui優化，去除累贅的布局，優化初始化的速度，提高apk流暢性。

2. 網路交互優化，好的網路和數據處理方式決定了app的體驗性能。

3. 檢查內存是否有泄漏，人們常說的anr詳細。

如何你問的是android手機優化。

平常人只能下載手機管家這種軟體進行清除內存，垃圾，卸載無用的apk，保持android系統的流暢性。