Google前幾天剛發布了Android性能優化典范第2季的課程，一共20個短視頻，包括的內容大致有：電量優化、網絡優化、Android Wear上如何做優化、使用對象池來提高效率、LRU Cache、Bitmap的縮放、緩存、重用、PNG壓縮、自定義View的性能、提升設置alpha之后View的渲染性能，以及Lint、StictMode等工具的使用技巧。 下面是對這些課程的總結摘要，認知有限，理解偏差的地方請多多指教！

1) Battery Drain and Networking

對于手機程序，網絡操作相對來說是比較耗電的行為。優化網絡操作能夠顯著節約電量的消耗。在性能優化第1季里面有提到過，手機硬件的各個模塊的耗電量是不一樣的，其中移動蜂窩模塊對電量消耗是比較大的，另外蜂窩模塊在不同工作強度下，對電量的消耗也是有差異的。當程序想要執行某個網絡請求之前，需要先喚醒設備，然后發送數據請求，之后等待返回數據，最后才慢慢進入休眠狀態。這個流程如下圖所示：

在上面那個流程中，蜂窩模塊的電量消耗差異如下圖所示：

從圖示中可以看到，激活瞬間，發送數據的瞬間，接收數據的瞬間都有很大的電量消耗，所以，我們應該從如何傳遞網絡數據以及何時發起網絡請求這兩個方面來著手優化。

1.1) 何時發起網絡請求

首先我們需要區分哪些網絡請求是需要及時返回結果的，哪些是可以延遲執行的。例如，用戶主動下拉刷新列表，這種行為需要立即觸發網絡請求，并等待數據返回。但是對于上傳用戶操作的數據，同步程序設置等等行為則屬于可以延遲的行為。我們可以通過Battery Historian這個工具來查看關于移動蜂窩模塊的電量消耗。在Mobile Radio那一行會顯示蜂窩模塊的電量消耗情況，紅色的部分代表模塊正在工作，中間的間隔部分代表模塊正在休眠狀態，如果看到有一段區間，紅色與間隔頻繁的出現，那就說明這里有可以優化的行為。如下圖所示：

對于上面可以優化的部分，我們可以有針對性的把請求行為捆綁起來，延遲到某個時刻統一發起請求。如下圖所示：

經過上面的優化之后，我們再回頭使用Battery Historian導出電量消耗圖，可以看到喚醒狀態與休眠狀態是連續大塊間隔的，這樣的話，總體電量的消耗就會變得更少。

當然，我們甚至可以把請求的任務延遲到手機網絡切換到WiFi，手機處于充電狀態下再執行。在前面的描述過程中，我們會遇到的一個難題是如何把網絡請求延遲，并批量進行執行。還好，Android提供了JobScheduler來幫助我們達成這個目標。

1.2) 如何傳遞網絡數據

關于這部分主要會涉及到Prefetch（預?。┡cCompressed（壓縮）這兩個技術。對于Prefetch的使用，我們需要預先判斷用戶在此次操作之后，后續零散的請求是否很有可能會馬上被觸發，可以把后面5分鐘有可能會使用到的零散請求都一次集中執行完畢。對于Compressed的使用，在上傳與下載數據之前，使用CPU對數據進行壓縮與解壓，可以很大程度上減少網絡傳輸的時間。

想要知道我們的應用程序中網絡請求發生的時間，每次請求的數據量等等信息，可以通過Android Studio中的Networking Traffic Tool來查看詳細的數據，如下圖所示：

2) Wear & Sensors

在Android Wear上會大量的使用Sensors來實現某些特殊功能，如何在盡量節約電量的前提下利用好Sensor會是我們需要特別注意的問題。下面會介紹一些在Android Wear上的最佳實踐典范。

盡量減少刷新請求，例如我們可以在不需要某些數據的時候盡快注銷監聽，減小刷新頻率，對Sensor的數據做批量處理等等。那么如何做到這些優化呢？

首先我們需要盡量使用Android平臺提供的既有運動數據，而不是自己去實現監聽采集數據，因為大多數Android Watch自身記錄Sensor數據的行為是有經過做電量優化的。

其次在Activity不需要監聽某些Sensor數據的時候需要盡快釋放監聽注冊。

還有我們需要盡量控制更新的頻率，僅僅在需要刷新顯示數據的時候才觸發獲取最新數據的操作。

另外我們可以針對Sensor的數據做批量處理，待數據累積一定次數或者某個程度的時候才更新到UI上。

最后當Watch與Phone連接起來的時候，可以把某些復雜操作的事情交給Phone來執行，Watch只需要等待返回的結果。

更對關于Sensors的知識，可以點擊這里。

3) Smooth Android Wear Animation

Android Material Design風格的應用采用了大量的動畫來進行UI切換，優化動畫的性能不僅能夠提升用戶體驗還可以減少電量的消耗，下面會介紹一些簡單易行的方法。

在Android里面一個相對操作比較繁重的事情是對Bitmap進行旋轉，縮放，裁剪等等。例如在一個圓形的鐘表圖上，我們把時鐘的指針摳出來當做單獨的圖片進行旋轉會比旋轉一張完整的圓形圖的所形成的幀率要高56%。

另外盡量減少每次重繪的元素可以極大的提升性能，假如某個鐘表界面上有很多需要顯示的復雜組件，我們可以把這些組件做拆分處理，例如把背景圖片單獨拎出來設置為一個獨立的View，通過setLayerType方法使得這個View強制用Hardware來進行渲染。至于界面上哪些元素需要做拆分，他們各自的更新頻率是多少，需要有針對性的單獨討論。

如何使用Systrace等工具來查看某些View的渲染性能，在前面的章節里面有提到過，感興趣的可以點擊這里。

對于大多數應用中的動畫，我們會使用PropertyAnimation或者ViewAnimation來操作實現，Android系統會自動對這些Animation做一定的優化處理，在Android上面學習到的大多數性能優化的知識同樣也適用于Android Wear。想要獲取更多關于Android Wear中動畫效果的優化，請點擊WatchFace這個范例。

4) Android Wear Data Batching

在Android Training里面有關于Wear上面如何利用Wearable API與Phone進行溝通協作的課程（詳情請點擊這里）。因為Phone的CPU與電量都比Wear要強大，另外Phone還可以直接接入網絡，而Wear要接入網絡則相對更加困難，所以我們在開發Wear應用的時候需要盡量做到把復雜的操作交給Phone來執行。例如我們可以讓Phone來獲取天氣信息，然后把數據返回Wear進行顯示。更進一步，在之前的性能優化課程里面我們有學習過如何使用JobScheduler來延遲批量處理任務，假設Phone收到來自Wear的其中一個任務是每隔5分鐘檢查一次天氣情況，那么Phone使用JobScheduler執行檢查天氣任務之后，先判斷這次返回的結果和之前是否有差異，僅僅當天氣發生變化的時候，才有必要把結果通知到Wear，或者僅僅把變化的某一項數據通知給Wear，這樣可以更大程度上減少Wear的電量消耗。

下面我們總結一下如何優化Wear的性能與電量：

僅僅在真正需要刷新界面的時候才發出請求

盡量把計算復雜操作的任務交給Phone來處理

Phone僅僅在數據發生變化的時候才通知到Wear

把零碎的數據請求捆綁一起再進行操作

5) Object Pools

在程序里面經常會遇到的一個問題是短時間內創建大量的對象，導致內存緊張，從而觸發GC導致性能問題。對于這個問題，我們可以使用對象池技術來解決它。通常對象池中的對象可能是bitmaps，views，paints等等。關于對象池的操作原理，不展開述說了，請看下面的圖示：

使用對象池技術有很多好處，它可以避免內存抖動，提升性能，但是在使用的時候有一些內容是需要特別注意的。通常情況下，初始化的對象池里面都是空白的，當使用某個對象的時候先去對象池查詢是否存在，如果不存在則創建這個對象然后加入對象池，但是我們也可以在程序剛啟動的時候就事先為對象池填充一些即將要使用到的數據，這樣可以在需要使用到這些對象的時候提供更快的首次加載速度，這種行為就叫做預分配。使用對象池也有不好的一面，程序員需要手動管理這些對象的分配與釋放，所以我們需要慎重地使用這項技術，避免發生對象的內存泄漏。為了確保所有的對象能夠正確被釋放，我們需要保證加入對象池的對象和其他外部對象沒有互相引用的關系。

6) To Index or Iterate?

遍歷容器是編程里面一個經常遇到的場景。在Java語言中，使用Iterate是一個比較常見的方法?？墒窃贏ndroid開發團隊中，大家卻盡量避免使用Iterator來執行遍歷操作。下面我們看下在Android上可能用到的三種不同的遍歷方法：

使用上面三種方式在同一臺手機上，使用相同的數據集做測試，他們的表現性能如下所示：

從上面可以看到for index的方式有更好的效率，但是因為不同平臺編譯器優化各有差異，我們最好還是針對實際的方法做一下簡單的測量比較好，拿到數據之后，再選擇效率最高的那個方式。

7) The Magic of LRU Cache

這小節我們要討論的是緩存算法，在Android上面最常用的一個緩存算法是LRU(Least Recently Use)，關于LRU算法，不展開述說，用下面一張圖演示下含義：

LRU Cache的基礎構建用法如下：

為了給LRU Cache設置一個比較合理的緩存大小值，我們通常是用下面的方法來做界定的：

使用LRU Cache時為了能夠讓Cache知道每個加入的Item的具體大小，我們需要Override下面的方法：

使用LRU Cache能夠顯著提升應用的性能，可是也需要注意LRU Cache中被淘汰對象的回收，否者會引起嚴重的內存泄露。

8) Using LINT for Performance Tips

Lint是Android提供的一個靜態掃描應用源碼并找出其中的潛在問題的一個強大的工具。

例如，如果我們在onDraw方法里面執行了new對象的操作，Lint就會提示我們這里有性能問題，并提出對應的建議方案。Lint已經集成到Android Studio中了，我們可以手動去觸發這個工具，點擊工具欄的Analysis -> Inspect Code，觸發之后，Lint會開始工作，并把結果輸出到底部的工具欄，我們可以逐個查看原因并根據指示做相應的優化修改。

Lint的功能非常強大，他能夠掃描各種問題。當然我們可以通過Android Studio設置找到Lint，對Lint做一些定制化掃描的設置，可以選擇忽略掉那些不想Lint去掃描的選項，我們還可以針對部分掃描內容修改它的提示優先級。

建議把與內存有關的選項中的嚴重程度標記為紅色的Error，對于Layout的性能問題標記為黃色Warning。

9) Hidden Cost of Transparency

這小節會介紹如何減少透明區域對性能的影響。通常來說，對于不透明的View，顯示它只需要渲染一次即可，可是如果這個View設置了alpha值，會至少需要渲染兩次。原因是包含alpha的view需要事先知道混合View的下一層元素是什么，然后再結合上層的View進行Blend混色處理。

在某些情況下，一個包含alpha的View有可能會觸發改View在HierarchyView上的父View都被額外重繪一次。下面我們看一個例子，下圖演示的ListView中的圖片與二級標題都有設置透明度。

大多數情況下，屏幕上的元素都是由后向前進行渲染的。在上面的圖示中，會先渲染背景圖(藍，綠，紅)，然后渲染人物頭像圖。如果后渲染的元素有設置alpha值，那么這個元素就會和屏幕上已經渲染好的元素做blend處理。很多時候，我們會給整個View設置alpha的來達到fading的動畫效果，如果我們圖示中的ListView做alpha逐漸減小的處理，我們可以看到ListView上的TextView等等組件會逐漸融合到背景色上。但是在這個過程中，我們無法觀察到它其實已經觸發了額外的繪制任務，我們的目標是讓整個View逐漸透明，可是期間ListView在不停的做Blending的操作，這樣會導致不少性能問題。

如何渲染才能夠得到我們想要的效果呢？我們可以先按照通常的方式把View上的元素按照從后到前的方式繪制出來，但是不直接顯示到屏幕上，而是使用GPU預處理之后，再又GPU渲染到屏幕上，GPU可以對界面上的原始數據直接做旋轉，設置透明度等等操作。使用GPU進行渲染，雖然第一次操作相比起直接繪制到屏幕上更加耗時，可是一旦原始紋理數據生成之后，接下去的操作就比較省時省力。

如何才能夠讓GPU來渲染某個View呢？我們可以通過setLayerType的方法來指定View應該如何進行渲染，從SDK 16開始，我們還可以使用
ViewPropertyAnimator.alpha.withLayer來指定。如下圖所示：

另外一個例子是包含陰影區域的View，這種類型的View并不會出現我們前面提到的問題，因為他們并不存在層疊的關系。

為了能夠讓渲染器知道這種情況，避免為這種View占用額外的GPU內存空間，我們可以做下面的設置。

通過上面的設置以后，性能可以得到顯著的提升，如下圖所示：

10) Avoiding Allocations in onDraw

我們都知道應該避免在onDraw方法里面執行導致內存分配的操作，下面講解下為何需要這樣做。

首先onDraw方法是執行在UI線程的，在UI線程盡量避免做任何可能影響到性能的操作。雖然分配內存的操作并不需要花費太多系統資源，但是這并不意味著是免費無代價的。設備有一定的刷新頻率，導致View的onDraw方法會被頻繁的調用，如果onDraw方法效率低下，在頻繁刷新累積的效應下，效率低的問題會被擴大，然后會對性能有嚴重的影響。

如果在onDraw里面執行內存分配的操作，會容易導致內存抖動，GC頻繁被觸發，雖然GC后來被改進為執行在另外一個后臺線程(GC操作在2.3以前是同步的，之后是并發)，可是頻繁的GC的操作還是會影響到CPU，影響到電量的消耗。

那么簡單解決頻繁分配內存的方法就是把分配操作移動到onDraw方法外面，通常情況下，我們會把onDraw里面new Paint的操作移動到外面，如下面所示：

11) Tool: Strict Mode

UI線程被阻塞超過5秒，就會出現ANR，這太糟糕了。防止程序出現ANR是很重要的事情，那么如何找出程序里面潛在的坑，預防ANR呢？很多大部分情況下執行很快的方法，但是他們有可能存在巨大的隱患，這些隱患的爆發就很容易導致ANR。

Android提供了一個叫做Strict Mode的工具，我們可以通過手機設置里面的開發者選項，打開Strict Mode選項，如果程序存在潛在的隱患，屏幕就會閃現紅色。我們也可以通過StrictModeAPI在代碼層面做細化的跟蹤，可以設置StrictMode監聽那些潛在問題，出現問題時如何提醒開發者，可以對屏幕閃紅色，也可以輸出錯誤日志。下面是官方的代碼示例：

public void onCreate { if (DEVELOPER_MODE) { StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder .detectDiskReads .detectDiskWrites .detectNetwork // or .detectAll for all detectable problems .penaltyLog .build); StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder .detectLeakedSqlLiteObjects .detectLeakedClosableObjects .penaltyLog .penaltyDeath .build); } super.onCreate; }

12) Custom Views and Performance

Android系統有提供超過70多種標準的View，例如TextView，ImageView，Button等等。在某些時候，這些標準的View無法滿足我們的需要，那么就需要我們自己來實現一個View，這節會介紹如何優化自定義View的性能。

通常來說，針對自定義View，我們可能犯下面三個錯誤：

Useless calls to onDraw：我們知道調用View.invalidate會觸發View的重繪，有兩個原則需要遵守，第1個是僅僅在View的內容發生改變的時候才去觸發invalidate方法，第2個是盡量使用ClipRect等方法來提高繪制的性能。

Useless pixels：減少繪制時不必要的繪制元素，對于那些不可見的元素，我們需要盡量避免重繪。

Wasted CPU cycles：對于不在屏幕上的元素，可以使用Canvas.quickReject把他們給剔除，避免浪費CPU資源。另外盡量使用GPU來進行UI的渲染，這樣能夠極大的提高程序的整體表現性能。

最后請時刻牢記，盡量提高View的繪制性能，這樣才能保證界面的刷新幀率盡量的高。

13) Batching Background Work Until Later

優化性能時大多數時候討論的都是如何減少不必要的操作，但是選擇何時去執行某些操作同樣也很重要。在第1季以及上一期的性能優化之電量篇里面，我們有提到過移動蜂窩模塊的電量消耗模型。為了避免我們的應用程序過多的頻繁消耗電量，我們需要學習如何把后臺任務打包批量，并選擇一個合適的時機進行觸發執行。下圖是每個應用程序各自執行后臺任務導致的電量消耗示意圖：

因為像上面那樣做會導致浪費很多電量，我們需要做的是把部分應用的任務延遲處理，等到一定時機，這些任務一并進行處理。結果如下面的示意圖：

執行延遲任務，通常有下面三種方式：

AlarmManager：使用AlarmManager設置定時任務，可以選擇精確的間隔時間，也可以選擇非精確時間作為參數。除非程序有很強烈的需要使用精確的定時喚醒，否者一定要避免使用他，我們應該盡量使用非精確的方式。

SyncAdapter：我們可以使用SyncAdapter為應用添加設置賬戶，這樣在手機設置的賬戶列表里面可以找到我們的應用。這種方式功能更多，但是實現起來比較復雜（Google官方培訓課程）

JobSchedulor：這是最簡單高效的方法，我們可以設置任務延遲的間隔，執行條件，還可以增加重試機制。

14) Smaller Pixel Formats

常見的png,jpeg,webp等格式的圖片在設置到UI上之前需要經過解碼的過程，而解壓時可以選擇不同的解碼率，不同的解碼率對內存的占用是有很大差別的。在不影響到畫質的前提下盡量減少內存的占用，這能夠顯著提升應用程序的性能。

Android的Heap空間是不會自動做兼容壓縮的，意思就是如果Heap空間中的圖片被收回之后，這塊區域并不會和其他已經回收過的區域做重新排序合并處理，那么當一個更大的圖片需要放到heap之前，很可能找不到那么大的連續空閑區域，那么就會觸發GC，使得heap騰出一塊足以放下這張圖片的空閑區域，如果無法騰出，就會發生OOM。如下圖所示：

所以為了避免加載一張超大的圖片，需要盡量減少這張圖片所占用的內存大小，Android為圖片提供了4種解碼格式，他們分別占用的內存大小如下圖所示：

隨著解碼占用內存大小的降低，清晰度也會有損失。我們需要針對不同的應用場景做不同的處理，大圖和小圖可以采用不同的解碼率。在Android里面可以通過下面的代碼來設置解碼率：

15) Smaller PNG Files

盡量減少PNG圖片的大小是Android里面很重要的一條規范。相比起JPEG，PNG能夠提供更加清晰無損的圖片，但是PNG格式的圖片會更大，占用更多的磁盤空間。到底是使用PNG還是JPEG，需要設計師仔細衡量，對于那些使用JPEG就可以達到視覺效果的，可以考慮采用JPEG即可。我們可以通過Google搜索到很多關于PNG壓縮的工具，如下圖所示：

這里要介紹一種新的圖片格式：Webp，它是由Google推出的一種既保留png格式的優點，又能夠減少圖片大小的一種新型圖片格式。關于Webp的更多細節，請點擊這里。

16) Pre-scaling Bitmaps

對bitmap做縮放，這也是Android里面最遇到的問題。對bitmap做縮放的意義很明顯，提示顯示性能，避免分配不必要的內存。Android提供了現成的bitmap縮放的API，叫做createScaledBitmap，使用這個方法可以獲取到一張經過縮放的圖片。

上面的方法能夠快速的得到一張經過縮放的圖片，可是這個方法能夠執行的前提是，原圖片需要事先加載到內存中，如果原圖片過大，很可能導致OOM。下面介紹其他幾種縮放圖片的方式。

inSampleSize能夠等比的縮放顯示圖片，同時還避免了需要先把原圖加載進內存的缺點。我們會使用類似像下面一樣的方法來縮放bitmap：

另外，我們還可以使用inScaled，inDensity，inTargetDensity的屬性來對解碼圖片做處理，源碼如下圖所示：

還有一個經常使用到的技巧是inJustDecodeBounds，使用這個屬性去嘗試解碼圖片，可以事先獲取到圖片的大小而不至于占用什么內存。如下圖所示：

17) Re-using Bitmaps

我們知道bitmap會占用大量的內存空間，這節會講解什么是inBitmap屬性，如何利用這個屬性來提升bitmap的循環效率。前面我們介紹過使用對象池的技術來解決對象頻繁創建再回收的效率問題，使用這種方法，bitmap占用的內存空間會差不多是恒定的數值，每次新創建出來的bitmap都會需要占用一塊單獨的內存區域，如下圖所示：

為了解決上圖所示的效率問題，Android在解碼圖片的時候引進了inBitmap屬性，使用這個屬性可以得到下圖所示的效果：

使用inBitmap屬性可以告知Bitmap解碼器去嘗試使用已經存在的內存區域，新解碼的bitmap會嘗試去使用之前那張bitmap在heap中所占據的pixel data內存區域，而不是去問內存重新申請一塊區域來存放bitmap。利用這種特性，即使是上千張的圖片，也只會僅僅只需要占用屏幕所能夠顯示的圖片數量的內存大小。下面是如何使用inBitmap的代碼示例：

使用inBitmap需要注意幾個限制條件：

在SDK 11 -> 18之間，重用的bitmap大小必須是一致的，例如給inBitmap賦值的圖片大小為100-100，那么新申請的bitmap必須也為100-100才能夠被重用。從SDK 19開始，新申請的bitmap大小必須小于或者等于已經賦值過的bitmap大小。

新申請的bitmap與舊的bitmap必須有相同的解碼格式，例如大家都是8888的，如果前面的bitmap是8888，那么就不能支持4444與565格式的bitmap了。

我們可以創建一個包含多種典型可重用bitmap的對象池，這樣后續的bitmap創建都能夠找到合適的“模板”去進行重用。如下圖所示：

Google介紹了一個開源的加載bitmap的庫：Glide，這里面包含了各種對bitmap的優化技巧。

18) The Performance Lifecycle

大多數開發者在沒有發現嚴重性能問題之前是不會特別花精力去關注性能優化的，通常大家關注的都是功能是否實現。當性能問題真的出現的時候，請不要慌亂。我們通常采用下面三個步驟來解決性能問題。

我們可以通過Android SDK里面提供的諸多工具來收集CPU、GPU、內存、電量等性能數據。

通過上面的步驟，我們獲取到了大量的數據，下一步就是分析這些數據。工具幫我們生成了很多可讀性強的表格，我們需要事先了解如何查看表格的數據，每一項代表的含義，這樣才能夠快速定位問題。如果分析數據之后還是沒有找到問題，那么就只能不停的重新收集數據，再進行分析，如此循環。

定位到問題之后，我們需要采取行動來解決問題。解決問題之前一定要先有個計劃，評估這個解決方案是否可行，是否能夠及時的解決問題。

19) Tools not Rules

雖然前面介紹了很多調試的方法，處理技巧，規范建議等等，可是這并不意味著所有的情況都適用，我們還是需要根據當時的情景做特定靈活的處理。

20) Memory Profiling 101

圍繞Android生態系統，不僅僅有Phone、還有Wear、TV、Auto等。對這些不同形態的程序進行性能優化，都離不開內存調試這個步驟。這節中介紹的內容大部分和Android性能優化典范與Android性能優化之內存篇重合，不展開了。

根據官方說明，Redmi Note 11 Pro/Pro+其實是增強快充和屏幕的Note 9 Pro換代款，而非注重性能的Redmi Note 10 Pro繼承人。

放在近1年前發布的Note 9 Pro面前，Redmi Note 11 Pro+自然是大幅升級。而放在Note 10 Pro面前，升級屏幕、相機規格和充電，SoC從天璣1100換成天璣920，這個取舍是否值得呢？我們現在就看看。

家族規格對比：

外觀與配件

“不環?！?件套：120W快充頭、數據線、卡針、清水殼。

K40 Pro、Redmi Note 11 Pro+、Redmi Note 10 Pro↑

雖然可能是E2 Pro材質，但Redmi Note 11 Pro+和K40 Pro（E4材質）都是6.67英寸的三星AMOLED屏幕+360Hz觸控采樣+銀圈裝飾的小開孔。很難不懷疑，是否用了同一塊蓋板？

左下Redmi Note 11 Pro+，右上K40 Pro，右下Redmi Note 10 Pro↑

Redmi Note 11 Pro+的外觀亮點是后蓋。AG玻璃大法好！這是無論怎么做都有質感的材料。

外觀上最大的爭議點在于果味的直邊中框，所幸不是蘋果那種“手術刀般的中框”。Redmi Note 11 Pro+有做弧形過度，利用“帕拉提斯克（Plastic）”中框，做出了“屏幕、墊圈、中框、墊圈、背蓋”的5層夾心效果。中框磨砂，前后玻璃過渡區域都是仿拋光的亮面，“極盡奢華”?？ú邸㈦娫存I（集成指紋識別）都略有色差，很多細節都讓我覺得，前代Note 10 Pro是臺成功把塑料機身做得精致順眼的手機。

小米10 Ultra、Redmi Note 11 Pro+、小米11 Ultra ↑

Redmi K40 Pro、Redmi Note 11 Pro+、Redmi Note 10 Pro ↑

攝像頭依然是小米10 Ultra+小米11 Ultra的混血設計，機身變薄，顯得攝像頭更加突出。直邊設計有更高的內部利用率，更容易把邊框做窄，光影折射更整潔，但只有拿著它的手在哭泣。

指紋識別：識別速度和前代接近，但進系統的動畫慢半拍，希望后期OTA一下；

外放：對稱式雙揚，音質無法和音樂手機小米10系列比，但音量夸張，最低一格的音量也明顯比普通手機大，能讓你輕松成為廣場上最靚的仔；

震動：X軸線性馬達，回彈還算緊致，力度偏小。

充電：千元無敵120W

充電是Redmi Note 11系列的主推賣點。Redmi品牌首個120W產品，竟然不是K系列的，Surprise！而更值得驕傲的是，Redmi Note 11 Pro+和黑鯊4s系列一樣，支持100W QC5，兼容性比MIX 4都好，Surprise again！

Redmi Note 11 Pro+官配的120W快充頭是老朋友MDY-12-ED，有9V 3A、11V 6A和20V 6A多個檔位，魔改針腳的USB-A口，標配6A線材，小米10 Ultra和小米MIX4用的都是它。

Redmi Note 11 Pro+是第15款搭載120W快充的手機，也是首臺千元級的120W機型。此前14款120W手機散落在5個品牌，全都是旗艦產品：

小米家3臺：小米10 Ultra、小米MIX 4、小米11T Pro；

iQOO有4臺：iQOO 5 Pro、iQOO 7、iQOO 8、iQOO 8 Pro

黑鯊有4臺：黑鯊4/4 Pro、黑鯊4S/4S Pro（包括高達版）

紅魔有2臺：紅魔6 Pro、紅魔6S Pro（包括戰地迷彩板）

nubia Z30 Pro

Redmi Note 11 Pro+的4500mAh雙電芯+120W快充，室溫23度，系統顯示電量，從1%到100%耗時16分58秒，26分鐘斷充。

表上峰值功率96.4W，維持2分鐘左右；隨后4.5分鐘緩慢降到87W；70W 3分鐘；60W 2分鐘；然后緩慢下降到11W；20分鐘左右降到5.2W，有6分鐘的恒壓充電。

120W的手機對比↑

與正常手機對比↑

Redmi Note 11 Pro+表現比全球首發120W的小米10 Ultra更好，稍弱于同代120W旗艦。

但畢竟是120W快充，和65/66/67W快充根本不在一個維度上?！八⒀赖臅r間充電就夠出門”和“洗澡的時間充電就夠出門”，是完全兩種概念。而三星的滿血25W就更不用說了（上圖墊底的那條）。

屏幕：Redmi Note系列史上最頂

Redmi Note 11 Pro+搭載了Redmi Note系列史上規格和表現都最好的屏幕，三星AMOLED，硬屏，側看略有彩虹紋，360Hz觸控采樣，沒有類DC調光開關。素質雖干不過K40，但是同價位段大佬。

它和Note 10 Pro的屏幕，是一眼就能看出來的巨大差別，拍照取景時會更加深有體會。

K40 Pro、Redmi Note 11 Pro+、Redmi Note 10 Pro最高亮度對比↑

亮度很夠，均勻度一般：亮度在正午太陽也基本夠用。自動全白激發亮度646尼特，局部1041尼特。手動全白414尼特，局部602尼特，此時四角亮度421/413/421/419尼特，均勻度一般。

色準：生動和艷麗模式都有點太艷，色準一般。原色模式的色準雖不如K40 Pro，但接近小米11 Ultra，比我們手上的小米11都好，Amazing！干翻友商！

生動模式（出廠默認）：覆蓋98.4%P3色域，色溫7382K，伽瑪2.6，平均灰階2.9，P3平均色偏3，最大4.7。sRGB平均色偏4.4，最大7.1；

鮮艷模式：色準直接放飛了。覆蓋106.5% P3色域，144.5%的sRGB色域，色溫7392K，伽瑪2.59，平均灰階3，P3平均色偏3.2，最大5.7。sRGB平均色偏5.6，最大9.6；

標準模式：色準表現不錯。覆蓋99.7%的sRGB色域，色溫6292K，伽瑪2.34，平均灰階2，平均色偏1.8，最大3.5。

拍照：1億像素HM2

畢竟Note 11 Pro/11 Pro+是Note 9 Pro的欽定繼承人，拍照也是核心賣點之一：

1.08億像素S5KHM2，0.7μm，9in1成2.1μm，1/1.52"，雙原生ISO，F1.89光圈；

800萬像素超廣角，S5K4H7，1.12μm，1/4''，F2.2；

200萬像素的戰術微距，1600萬像素F2.45的前置攝像頭。

拍照體驗：三星這顆HM2是9合1輸出成1200W，Redmi Note 11 Pro+的拍照速度和正常的1200萬像素手機沒有多少分別。因主攝HDR不積極，超廣角也沒有自動夜景，Redmi Note 11 Pro+拍照體驗甚至比很多國產旗艦都好。沒光學防抖，光線變差后成片率會有明顯的下降。但因為有更好的屏幕，取景和拍照體驗完爆了Note 10 Pro/Note 9 Pro。

實際畫質，有點出乎預料，結論就是Note 10 Pro真的是好機器。希望后期能給Note 11 Pro OTA一下算法。要說明的是：

Note 10 Pro主攝是6400W，0.7μm的OV64B40，和老朋友GW3規格接近，輸出是1600W；

Note 11 Pro+的HM2用了更短的焦距，視野大，但會損失辨析力；

兩臺機的超廣角傳感器雖不同，但都是1.12μm的800W，都沒自動夜景，除白平衡都不太準外，表現非常接近。

超廣角對比

---

超廣角1

超廣角1，中央放大

超廣角2，中央放大

超廣角3

超廣角3，中央放大

超廣角4

2倍變焦

---

畫面細節接近，但Note 10 Pro銳化更用力，畫面不如Note 11 Pro+自然。

2倍變焦1，中央放大

2倍變焦2，中央放大

2倍變焦3，中央放大

主攝對比

---

Redmi Note 11 Pro+白平衡稍準，動態范圍也更大一些，但沒能吊打0.7μm的6400W機型，也是在我們的預料之外?！按髲V角+1200W”的搭配，讓辨析力偏弱，HDR觸發也很不積極。而Redmi Note 11 Pro+超廣角的自動HDR還是很積極的，不知道是考慮到1億像素的算法壓力，還是因為其他原因。

主攝樣張大小對比，1600W對1200W

主攝對比1

主攝對比2

主攝對比3

主攝對比3，中央放大

主攝對比4

主攝對比4，中央放大

主攝對比5

主攝對比6

主攝對比6，中央放大

主攝對比7

主攝對比7，中央放大

主攝對比8

主攝對比8，中央放大

主攝對比9

主攝對比9，中央放大

主攝對比10

主攝對比11

主攝對比12

主攝對比13

主攝對比13，中央放大

系統與性能：首發天璣920

截稿到10月31日，Redmi Note 11 Pro+系統是MIUI 12.5.3，DRM L1和Google框架都有了（好評?。?，但還沒像Note 10 Pro那樣跟進MIUI 12.5增強版。

這時候可能會有圣經吟唱，但Redmi Note 11 Pro+實際流暢度其實不錯，略超預期。不過想想也是，就算是天璣920，也全面壓制驍龍765G/768G（發哥的刀法也越來越好了）。

天璣920是臺積電6nm工藝，CPU部分2x2.5G A78+6x2.0G A55，GPU是Mali-G68 MC4 950MHz。新構架加高頻，CPU單核表現不錯，GPU也不算很弱，壓驍龍768G/765G一頭?？赡芤蚋咄ǖ腻仯?56GB UFS 2.2，Redmi Note 11 Pro+存儲性能還比小米Civi(778G)強一些。

雖然天璣920的CPU多核和GPU，完全不是Redmi 10X Pro那顆天璣820的對手，但Note 11 Pro+的CPU單核更強，系統流暢度明顯好于Redmi 10X Pro（當然一部分是MIUI的鍋）。詳細測試對比如下。

CPU性能：

GPU性能：

閃存讀寫性能：

空載、單大核、雙大核烤機

CPU單烤、GPU單烤、雙烤

Redmi Note 11 Pro+基礎功耗略微偏高，屏幕最低亮度，飛行模式，基礎功耗0.73W左右。2個2.5G A78大核的功耗高于預期，CPU MIX2烤單大核，整機2W左右；烤雙大核整機3.4W；烤6顆小核整機1.5W。CPU全核烤機整機4.85W，單烤GPU（MADD+ADD）維持在整機2.1W出頭。

這價位段下，Redmi Note 11 Pro+的散熱配置還OK。室溫23.4度，CPU+GPU雙烤整機6.2W，前6分鐘穩如直線，隨后降到5.7W。屏幕最高亮度雙烤，整機峰值也才7W，隨后就6.2W，10分鐘后才掉到4.3W。

室溫23.3度，《和平精英》HDR高清+極限幀數+抗鋸齒，PUBG Tool強開60幀，Redmi Note 11 Pro+跑30分鐘能基本維持在60幀，表現略超預期。

Redmi Note 11 Pro+該版本固件調度明顯是性能向的（也可能是還沒調好，或者我們這臺有問題），均衡模式下清空后臺，靜置手機，小核經常會6核全開，維持2.0GHz，點兩下屏幕又會飆回來，影響了后續的續航成績。

續航與發熱

室溫23.4度，20分鐘的《和平精英》（HDR高清+極限幀數，PUBG Tool強開60幀+抗鋸齒），正反面最高溫都是41.4度，配上塑料中框，體感溫熱。

4500mAh電池，經30分鐘《和平精英》（HDR高清+極限幀數，PUBG Tool強開60幀+抗鋸齒）、30分鐘B站1080P視頻播放、30分鐘微博短視頻、各30分鐘的Wi-Fi和5G沖浪，共2.5小時的續航測試后，剩余電量69%。中端機下游水平，持平一加9R(870)、榮耀Magic3 Pro(888+)，可能雙電芯和天璣920得各背一半的鍋。

總結

當年Redmi Note 9 Pro主打的是拍照，注定它不會是追求性價比的產品。而到Redmi Note 11 Pro+上，Redmi再加了120W快充，賣點變成屏幕+快充+拍照（拍照其實和前代拉不開距離），但SoC變成天璣920。估計天璣920整個生命周期里，Redmi Note 11 Pro+也會是外圍配置最好的機型。

和Note 10 Pro放在一起對比，其實就是外圍配置和性能之間的選擇，情況有點像K40游戲增強版和K40之間的定位區別。Note 10 Pro的性能，和Note 11 Pro/Pro+的周邊配置能不能兼得？可以，等下一代Note 12/13吧，或者加錢。。。Redmi Note 11 Pro+的對手，除了性能更強的Note 10 Pro，它頭頂還懸著老大哥RedmiK40……

對于玩機用戶，我們永遠建議在同樣的預算下，優先把SoC堆上去。但對于很多用戶，外觀、屏幕、拍照、充電這些外圍可能更容易觸動他們。

市場上能有定位不同的產品，總歸是好的。要是所有廠商都只搞狹義上的性價比產品，所有入門機除了SoC都一無是處，那就太沒勁了。