androidwebp詳解

㈠ android 圖片質量壓縮和尺寸壓縮有什麼區別

‍

這個方法用來將特定格式的壓縮圖片寫入輸出流（OutputStream）中，當然例如輸出流與文件聯系在一起，壓縮後的圖片也就是一個文件。如果壓縮成功則返回true，其中有三個參數：

format是壓縮後的圖片的格式，可取值：Bitmap.CompressFormat .JPEG、~.PNG、~.WEBP。

quality的取值范圍為[0,100]，值越小，經過壓縮後圖片失真越嚴重，當然圖片文件也會越小。（PNG格式的圖片會忽略這個值的設定）

stream指定壓縮的圖片輸出的地方，比如某文件。

上述方法還有一個值得注意的地方是：當用BitmapFactory decode文件時可能返回一個跟原圖片不同位深的圖片，或者丟失了每個像素的透明值（alpha），比如說，JPEG格式的圖片僅僅支持不透明的像素。文章android圖片壓縮在文末提到的下面這點可能就是這個原因：

當調用bitmap.compress(CompressFormat.JPEG, 100, fos);保存為圖片時發現圖片背景為黑色，如下圖：

下面是質量壓縮的代碼：

(Bitmapbmp,Filefile){

ByteArrayOutputStreambaos=newByteArrayOutputStream();

intoptions=80;//個人喜歡從80開始,

bmp.compress(Bitmap.CompressFormat.JPEG,options,baos);

while(baos.toByteArray().length/1024>100){

baos.reset();

options-=10;

bmp.compress(Bitmap.CompressFormat.JPEG,options,baos);

}

try{

FileOutputStreamfos=newFileOutputStream(file);

fos.write(baos.toByteArray());

fos.flush();

fos.close();

}catch(Exceptione){

e.printStackTrace();

}

}

這段代碼來自Android圖片壓縮總結，我根據自己的需求改了改，但是大同小異，所以就直接貼了。

隨著代碼中的option逐漸變小，我們可以在logcat中列印baos的大小來查看圖片的大小。我們也可以去掉while的循環條件，一直壓縮下去看效果，最終一張照片可能就由原來的3、4M變成了幾百K甚至幾百B了。我在試的過程中將option設置成100，壓縮後偶爾會出現一張3、4M的圖片經過壓縮後竟變成了6、7M，這里還是有點困惑，不知道為什麼。

隨後，我想把這個壓縮後的圖片（1、200KB）填充到ImageView中時卻失敗了，logcat中提示圖片過大！這就是文章開頭提到的問題，雖然我們通過質量壓縮使File形式的圖片文件縮小了，但是並沒有改變圖片的寬高，原先是1080*1920解析度的圖片經壓縮後還是1080*1920，而File格式轉換成Bitmap格式進入到內存中時，內存是根據圖片的像素數量來給圖片分配內存大小的，還是有好幾M，因此填充ImageView失敗。

順便提一下，可以用bitmap.getByteCount()獲取存儲bitmap像素的內存大小，但是KITKAT（Android 4.4版本）以後用getAllocateByteCount()獲取。一般情況下，後者返回值比前者大，比如，當bitmap被重用去decode另外更小的bitmaps時，或者被人為地配置一下屬性值，比如setWidth()、setHeight()、reconfigure()時，如果bitmap不做以上操作，二者的返回值應該是一樣的。（譯文，不太懂）

二、尺寸壓縮

特點: 通過設置采樣率, 減少圖片的像素, 達到對內存中的Bitmap進行壓縮

我們主要通過BitmapFactory中的decodeFile方法對圖片進行尺寸壓縮：

publicstaticBitmapdecodeFile(StringpathName,BitmapFactory.Optionsopts)

public static Bitmap decodeFile (String pathName, BitmapFactory.Options opts)

其中有兩個參數：

pathName是圖片文件的路徑。

opts 就是所謂的采樣率，它里邊有很多屬性可以設置，我們通過設置屬性來達到根據自己的需要，壓縮出指定的圖片。其中比較常用的屬性有：

booleaninJustDecodeBounds—— 如果設置為true，則只讀取bitmap的寬高，而忽略內容。

intinSampleSize—— 如果>1，調用decodeFile方法後，就會得到一個更小的bitmap對象（已壓縮）。比如設置為2，那麼新Bitmap的寬高都會是原Bitmap寬高的1/2,總體大小自然就是原來的1/4了，以此類推。

booleaninPurgeable—— 如果設置為true，壓縮後的圖片像素占的內存將會在系統清理內存的時候被回收掉，當像素的信息再次被用到時將會自動重新decode該像素（比如getPixels()時）。（慎用！重復decode可以會造成UI的卡頓，API level 21 已棄用）

booleaninInputShareable—— 與inPurgeable配合使用，如果inPurgeable設置成false，自動忽略此值，如果inPurgeable為true，此值決定是否該bitmap能分享引用給輸入數據（inputstream，array等），或者必須進行深拷貝。API level 21 已棄用。（這是譯文，不太理解！！！）

下面是一段實現的代碼

privateBitmapsizeCompres(Stringpath,intrqsW,intrqsH){

//用option設置返回的bitmap對象的一些屬性參數

finalBitmapFactory.Optionsoptions=newBitmapFactory.Options();

options.inJustDecodeBounds=true;//設置僅讀取Bitmap的寬高而不讀取內容

BitmapFactory.decodeFile(path,options);//獲取到圖片的寬高，放在option里邊

finalintheight=options.outHeight;//圖片的高度放在option里的outHeight屬性中

finalintwidth=options.outWidth;

intinSampleSize=1;

if(rqsW==0||rqsH==0){

options.inSampleSize=1;

}elseif(height>rqsH||width>rqsW){

finalintheightRatio=Math.round((float)height/(float)rqsH);

finalintwidthRatio=Math.round((float)width/(float)rqsW);

inSampleSize=heightRatio<widthRatio?heightRatio:widthRatio;

options.inSampleSize=inSampleSize;

}

returnBitmapFactory.decodeFile(path,options);//主要通過option里的inSampleSize對原圖片進行按比例壓縮

}

private Bitmap sizeCompres(String path, int rqsW, int rqsH) {

// 用option設置返回的bitmap對象的一些屬性參數

final BitmapFactory.Options options = new BitmapFactory.Options();

options.inJustDecodeBounds = true;// 設置僅讀取Bitmap的寬高而不讀取內容

BitmapFactory.decodeFile(path, options);// 獲取到圖片的寬高，放在option里邊

final int height = options.outHeight;//圖片的高度放在option里的outHeight屬性中

final int width = options.outWidth;

int inSampleSize = 1;

if (rqsW == 0 || rqsH == 0) {

options.inSampleSize = 1;

} else if (height > rqsH || width > rqsW) {

final int heightRatio = Math.round((float) height / (float) rqsH);

final int widthRatio = Math.round((float) width / (float) rqsW);

inSampleSize = heightRatio < widthRatio ? heightRatio : widthRatio;

options.inSampleSize = inSampleSize;

}

return BitmapFactory.decodeFile(path, options);// 主要通過option里的inSampleSize對原圖片進行按比例壓縮

}

上面就是簡單的質量壓縮與尺寸壓縮。

㈡ 針對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應用添加背景應該使用什麼樣的圖片格式，每個格式的的優勢在哪

原創回答：《轉載前請註明 from 網路知道-smile烏龜的回答》

先說結論；

1. 大的ViewGroup（Rl，FL ,LL，Cl等）布局背景應該設PNG

2. 小的view（Button，Recyclerview子item）的背景應該用WebP格式

3. 類似16*16的表情圖 也應該用WebP，也可考慮PNG

在研究圖片之前，首先搞明白三個問題：

像素點：計算機學科中，圖片由一個一個像素點組成，像素點有兩種ARGB和RGB，A，讀作「alpha」，中文「透明度」的含義。

圖片格式：JPEG 有損壓縮

優點 :壓縮過程中損失像素少（為什麼要壓縮？後文會說）

缺點:有損耗壓縮會使原始圖片數據質量下降(像素點變少了)

PNG無損壓縮

優點：更優化的網路傳輸顯示

（PNG圖像在瀏覽器上採用流式瀏覽，即使經過交錯處理的圖像會在完全下載之前提供瀏覽者一個基本的圖像內容，然後再逐漸清晰起來。它允許連續讀出和寫入圖像數據，這個特性很適合於在通信過程中顯示和生成圖像）

支持透明效果

體積小適合網路傳輸，請求服務端的圖片，節省流量

WebP 谷歌（google）開發的一種旨在加快圖片載入速度的圖片格式

優點:「在質量相同的情況下，WebP格式圖像的體積要比JPEG格式圖像小40%」

「WebP
的優勢體現在它具有更優的圖像數據壓縮演算法，能帶來更小的圖片體積，而且擁有肉眼識別無差異的圖像質量；同時具備了無損和有損的壓縮模式、Alpha
透明以及動畫的特性，在向JPEG 和 PNG 上的轉化效果都非常優秀、穩定和統一」

WebP應用比較優秀的：騰訊旗下 QQ空間客戶端，QQ客戶端，微信客戶端等

WebP圖片常用轉換工具：智圖，iSparta等

圖片壓縮：

以Android 為例，任何展示圖片的View控制項，載入圖片的時候，都需要為圖片申請內存，通常圖片越大，申請的內存越大，Android系統限制了每個App的運行內存，一般為32MB-200M左右，為了優化App性能，必須對圖片進行壓縮：壓縮圖片尺寸

通過壓縮圖片尺寸，解決App運行時申請過多內存，被系統殺死的情況。

總結： JPEG是有損壓縮，PNG是無損壓縮，

當UI切了一張匹配實際手機屏幕大小的圖片時 可以使用JPEG（不需要壓縮圖片）

當UI給的圖片過大，需要程序員手動壓縮時，考慮PNG

當UI給的圖片過於離譜，不可理喻，導致APK包過大，用戶反映耗費流量過多時，考慮使用WebP，而且WebP同PNG，JPEG是可以互轉的

（PS：請求自服務端的圖片資源，其實也是UI給的）

參考和補充：

1. 圖片格式，JPEG PNG WebP from網路
   

2. http://isux.tencent.com/introction-of-webp.html

3. http://www.cnblogs.com/xiangism/p/5311314.html

4. WebP圖片常用轉換工具：智圖，iSparta 等

5. 官方WebP解析庫https://github.com/alexey-pelykh/webp-android-backport

㈣ 問答：Android P都更新了哪些功能

Android P的新功能特性集中在了UI、通知體驗、室內定位、圖像存儲幾個方面，解決了之前一直存在的痛點。例如WiFi RTT一定程度上彌補了蜂窩網路在室內環境下的定位問題，HEIC圖像格式則重點解決了存儲容量問題。同時，Android P也在通知豐富度及操作便捷性等功能方面有所增強和提升。

一、WiFi RTT功能——復雜地形精確導航

WiFi RTT功能是Android P新引入的一個功能，從原理上來說與蜂窩網路的定位原理一致，但這個功能極大的彌補了蜂窩網路在室內定位的短板，WiFi RTT將能夠在室內提供高精度的定位，這是蜂窩網路很難做到的。

WiFi RTT是全新的功能，在android.net.wifi包下增加了rtt包，用於存放WiFi RTT相關類和介面。

WiFi RTT的API以WifiRttManager為核心，藉助AP熱點或WiFi，利用RTT原理完成測距，通過三個以上的測距點就能夠准確地定位到設備所在位置。

WiFiRTTManager提供了測距介面，是一個非同步測距操作，根據官方文檔（https://developer.android.com/reference/android/net/wifi/rtt/WifiRttManager.html）說明，其測距介面如下：

void startRanging(RangingRequest request, RangingResultCallback callback, Handler handler);

註：SDK Platforms Android P Preview Revision 1的相關介面定義與此不同，但實際的官方鏡像中介面與此一致，開發者需要更新最新的Android P Preview Revision 2，此版本中Google已經修正該介面。

介面中，RangingRequest通過RangingRequest.Builder構建，RangingRequest.Builder構建出RangingRequest所需要的參數可以通過WiFiManager等系統服務獲取到相關的內容，如List<ScanResult> scanResults = wifiManager.getScanResults();

以下提供一個簡單的測試Demo，以供參考：

private WifiRttManager wifiRttManager;
private WifiManager wifiManager;

@Override
protected void onCreate(Bundle savedInstanceState) {
// ... ...

if(getPackageManager().hasSystemFeature(PackageManager.FEATURE_WIFI_RTT)) {
Object service = this.getApplicationContext().getSystemService(Context.WIFI_RTT_RANGING_SERVICE);
if(service instanceof WifiRttManager) {
wifiRttManager= (WifiRttManager) service;
Log.i(TAG, "Get WifiRttManager Succ.");
}

wifiManager = (WifiManager) this.getApplicationContext().getSystemService(Context.WIFI_SERVICE);

IntentFilter wifiFileter = new IntentFilter();
wifiFileter.addAction(WifiManager.NETWORK_STATE_CHANGED_ACTION);
wifiFileter.addAction(WifiManager.WIFI_STATE_CHANGED_ACTION);
wifiFileter.addAction(WifiManager.SCAN_RESULTS_AVAILABLE_ACTION);
registerReceiver(new WifiChangeReceiver(), wifiFileter);
}

// ... ...
｝

private void startScanAPs() {
wifiManager.setWifiEnabled(true);
wifiManager.startScan();
}

class WifiChangeReceiver extends BroadcastReceiver {
@RequiresApi(api = 28)
@Override
public void onReceive(Context context, Intent intent) {
if (intent.getAction().equals(WifiManager.SCAN_RESULTS_AVAILABLE_ACTION)) {
List<ScanResult> scanResults = wifiManager.getScanResults();
Log.i(TAG, "Wifi Scan size:" + scanResults.size());
for(ScanResult scanResult: scanResults) {
Log.i(TAG, scanResult.toString());
RangingRequest.Builder builder = new RangingRequest.Builder();
builder.addAccessPoint(scanResult);
wifiRttManager.startRanging(builder.build(), new RangingResultCallback() {
@SuppressLint("Override")
@Override
public void onRangingFailure(int i) {
// TODO
}
@SuppressLint("Override")
@Override
public void onRangingResults(List<RangingResult> list) {
// TODO get result from list

for(RangingResult result : list) {
Log.i(TAG, result.toString());
}
}
}, new Handler());
}
}
}
}

使用WiFi RTT時，需要在AndroidManifest.xml中增加如下聲明：

<uses-feature android:name="android.hardware.wifi.rtt" />

通過上面的簡單代碼，就能夠實現WiFi RTT的功能。

WiFi RTT功能適用於復雜地形的大型室內外場所，如商場、娛樂場所、大型休閑、游樂場等等，提供場所內的局部區域精確化導航等功能。相信在很快的時間內，就能夠在各大地圖應用內體驗到這項便利功能，對於路痴、地圖盲的夥伴們將是極大的福音。

二、顯示剪切——支持劉海屏

隨著iPhone X的推出，「劉海屏」達到了空前的高潮。Android P里提供了對異形屏幕的UI適配兼容方案，通過DisplayCutout類提供的相關介面，能夠獲取到屏幕中Cutout區域的信息。

藉助DisplayCutout，可以獲取到如下信息：

DisplayCutout displayCutout = view.getRootWindowInsets().getDisplayCutout();
if(displayCutout != null) {
Region bounds = displayCutout.getBounds();
Log.d(TAG, String.format("Bounds:%s", bounds.toString()));
int top = displayCutout.getSafeInsetTop();
int bottom = displayCutout.getSafeInsetBottom();
int left = displayCutout.getSafeInsetLeft();
int right = displayCutout.getSafeInsetRight();
Log.d(TAG, String.format("Cutout edge:[left:%d, top:%d,right:%d, bottom:%d]", left, top, right, bottom));
}

public Region getBounds()能夠獲取到Cutout區域的所有信息，Region就是Cutout區域。

public int getSafeInsetTop()
public int getSafeInsetBottom()
public int getSafeInsetLeft()
public int getSafeInsetRight()

以上四個介面，可以獲取到去除Cutout區域後的安全區域邊界值。

通過上述數據，開發者能夠精準的控制UI的繪制，避免將UI內容繪制到Cutout區域造成UI顯示異常。

Android機器里，劉海屏目前還是極為罕見的Google為了方便開發者調試，在Android P Preview鏡像中，特別提供了Cutout的支持，具體打開方式可以參考Google提供的特性說明文檔cutout小節內容。

cutout小節：https://developer.android.com/preview/features.html#cutout

如圖所示，筆者使用手頭的Pixel 2 XL體驗了Android P的Cutout設置。

三、通知優化——操作更多樣，內容更豐富

Android P在通知內容的豐富度和操作上做了優化。

最近的版本中，Android系統的通知管理方面一直優化升級，Android O提供了更細粒度的Channel功能，通知欄推送時需要指定NotificationChannel，用戶可以對通知的Channel選擇，只允許感興趣的Channel推送的通知顯示。通過通道設置、免打擾優化等方式，極大增強了消息體驗。

增強消息體驗

Android P繼續改進和增強消息通知[v1]。早在Android 7.0時，就提供了在通知中直接應答和輸入，Android P對這一功能做了更多的增強。

Android P的通知中支持圖像內容，可以通過setData()方法，給出消息的圖像內容，在通知上展示給用戶。

Android P同樣簡化了通知的配置形式。Android P中增加了Notification.Person類，用於區分同一個對話的參與者信息，如參與者的頭像、URI等。根據官方說明，Android P中，通知消息的其他一些API，也使用Person替代之前的CharSequence。

簡單的體驗下新的API的開發：

NotificationChannel channel = new NotificationChannel("WtTestChannel",
"WtTestChannel", NotificationManager.IMPORTANCE_DEFAULT);
channel.enableLights(true); // luncher icon right corner's point
channel.setLightColor(Color.RED); // read point
channel.setShowBadge(true); // whether show this channel notification on long press icon

Notification.Builder builder =
new Notification.Builder(MainActivity.this,
"WtTestChannel");
Notification.Person p = new Notification.Person();
p.setName("WeTest");
p.setUri("http://cdn.wetest.qq.com/" +
"ui/1.2.0/pc/static/image/newLogo-16042.png");
Notification.MessagingStyle messageStyle = new Notification.MessagingStyle(p);
Notification.MessagingStyle.Message message =
new Notification.MessagingStyle.Message("WeTestMessage", 2000, p);

//show image
Uri image = Uri.parse(
"http://cdn.wetest.qq.com/ui/1.2.0/pc/static/image/newLogo-16042.png");
message.setData("image/png", image);
messageStyle.addMessage(message);
builder.setStyle(messageStyle);
builder.setSmallIcon(R.mipmap.ic_launcher);
Notification notification = builder.build();

NotificationManager notifyManager =
(NotificationManager) getSystemService(
MainActivity.this.getApplicationContext().NOTIFICATION_SERVICE);


notifyManager.createNotificationChannel(channel);
notifyManager.notify("WeTest", 1, notification);

通道設置、廣播和免打擾優化

Android P中，重點做了內容豐富上的工作，同時也對Channel的設置方面做了一些簡化處理。

Android O版本里，首次推出了NotificationChannel，開發者需要配置相應的Channel，才能夠推送通知給用戶。用戶能夠更加細粒度[v1]的針對App的Channel選擇，而不是禁止App的所有通知內容。

而在Android P中，對通知的管理做了進一步的優化，包括可以屏蔽通道組、提供新的廣播類型和新的免打擾優先順序。

屏蔽通道組：用戶可以在通知設置中屏蔽App的整個通道組。開發者可以通過isBlocked()來判斷某個通道組是否被屏蔽了，並根據結果，不向已經被屏蔽的通道組發送任何通知。另外，開發者可以在App中使用新介面getNotificationChannelGroup()來查詢當前的通道組設置。

新的廣播類型：新廣播類型是針對通道和通道組的功能增加的「通道(組)屏蔽狀態變化」廣播。開發者App中可以對所擁有的通道(組)接收廣播，並根據具體廣播內容作出動作。開發者可以通過NotificationManager，查看廣播相關的具體信息。針對廣播的動作可以通過Broadcasts查看具體的方法和信息。

免打擾優先順序：NotificationManager.Policy增加了兩個新的優先順序常量，PRIORITY_CATEGORY_ALARMS(警告優先)，PRIORITY_CATEGORY_MEDIA_SYSTEM_OTHER(媒體、系統和游戲聲音優先)。

四、支持多攝像機和相機共享

近一段時間，雙攝、多攝等機型紛紛面世。雙攝及多攝提供了單攝像頭所無法完成的能力，如無縫縮放、散景和立體視覺。Android P在這方面也提供了系統級的API支持。

Android P提供了系統API，支持從兩個或者多個物理攝像頭同步獲取數據流。此前OEM廠商提供的雙攝設備多是廠商自行定製系統實現，此時Android P推出了API，從系統層面上制定了API規范。

新的API提供了在不同相機之間切換邏輯數據流或混合數據流的調用能力。在捕捉延遲方面，提供新的會話參數，降低初始捕捉延遲。同時，提供相機共享能力，以解決在多種使用相機的場景下重復停止、開啟相機流。閃光燈方面，Android P增加基於顯示的閃光燈支持。光學防抖方面，Android P向開發者提供OIS時間戳，用於圖像穩定性優化以及其他特效使用。

此外，Android P還支持外部USB/UVC相機，可以使用更強大的外置攝像頭模組。

五、支持圖像媒體後期處理

Android P引入了新的ImageDecoder，該類除了支持對各種圖片格式的解碼、縮放、裁剪之外，其強大之處在於支持對解碼後的圖像做後期處理（post-process)，使用該功能可以添加復雜的自定義特效，比如圓角，或是將圖片放在圓形像框中。編寫後期處理回調函數，你可以添加任何繪圖指令實現需要的效果。

此外，Android P原生支持GIF和WebP格式的動圖，新增了AnimatedImageDrawable類，並被新增的解碼器類ImageDecoder直接支持，用法跟矢量動畫類AnimatedVectorDrawable類似，實現方式也類似，通過新增渲染線程和工作線程，不需要在UI線程處理動圖更新，可以說是無痛使用，非常省心。

下面通過編寫代碼，顯示一張gif圖，並利用後期處理機制，在圖像中間繪制一個綠色的實心圓。

final ImageView image = (ImageView) findViewById(R.id.image);
File gifFile = new File("/data/local/tmp/test.gif");
if (!gifFile.exists()) {
Log.d(TAG, "gifFile is not exsited!");
return;
}

ImageDecoder.Source source = ImageDecoder.createSource(gifFile);
try {
d = ImageDecoder.decodeDrawable(source, new ImageDecoder.OnHeaderDecodedListener() {
@Override
public void onHeaderDecoded(ImageDecoder imageDecoder, final ImageDecoder.ImageInfo imageInfo, ImageDecoder.Source source) {
imageDecoder.setPostProcessor(new PostProcessor() {
@Override
public int onPostProcess(Canvas canvas) {
int w = imageInfo.getSize().getWidth();
int h = imageInfo.getSize().getHeight();
Paint paint = new Paint();
paint.setAntiAlias(true);
paint.setColor(Color.GREEN);
canvas.drawCircle(w/2, h/2, h/4, new Paint(paint));
return 0;
}
});
}
});
image.setVisibility(View.VISIBLE);
image.setImageDrawable(d);
} catch (IOException e){
Log.d(TAG, e.toString());
}
Button button = (Button) findViewById(R.id.buttonText);
button.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View view) {
if (d != null && d instanceof AnimatedImageDrawable) {
AnimatedImageDrawable ad = (AnimatedImageDrawable) d;
if (ad.isRunning()) {
Log.d(TAG, "stop running");
ad.stop();
} else {
Log.d(TAG, "start running");
ad.start();
}
}
}
});

六、支持HDR VP9和HEIF

Android P內置了對HDR VP9和HEIF(heic)圖像編碼的支持。HEIF是蘋果在iOS11推出的一種高效壓縮格式，目前在IphoneX、Iphone 8、IPhone 8P上已經支持。該格式的壓縮率更高，但是編碼該格式需要硬體的支持，解碼並不需要。最新的支持庫中的HeifWriter支持從YUV位元組緩沖區、Surface或是Bitmap類轉換為HEIF格式的靜態圖像。

Android P新引入了MediaPlayer2，支持DataSourceDesc創建的播放列表。

功能優化提升一覽

一、神經網路API 1.1

在前不久發布的Android 8.1 (API level 27)上，Google首次在Android平台上推出了神經網路API，這意味著我們的Android機器智能化水平又提高了一大步。而本次Android P，進一步豐富了神經網路的支持，不僅對之前的相關API進行了優化，並且提供了9個新的操作，為具體的數據操作方面提供了更深入的支持。

二、改進表單自動填充

Android 8.0（API等級26）中引入了自動填充框架，這使得在應用中填寫表單變得更加容易。 Android P引入了自動填充服務並實現了多項改進，得以在填寫表單時進一步增強用戶體驗。

三、安全增強

Android P引入了許多新的安全功能，包括統一的指紋驗證對話框和敏感交易的高確信度的用戶確認。應用程序內的指紋認證UI也將會更加一致。

統一的指紋驗證對話框

如果第三方APP想要使用指紋，Android系統框架為應用提供了指紋認證對話框，該功能可以提供統一的外觀和使用體驗，用戶使用起來更放心。如果您的程序還在使用FingerprintManager，現在改用FingerprintDialog替代吧，系統來提供對話框顯示。對了，在使用FingerprintDialog之前，別忘了調用hasSystemFeature()方法檢查手機設備是否支持指紋。

敏感交易的高確信度的用戶確認

Android P系統提供了受保護的確認API，藉助這組全新的API，應用可以使用ConfirmationDialog對話框向用戶提示，請求用戶批准一條簡短的聲明， 該聲明允許應用提醒用戶，即將完成一筆敏感交易，例如支付。

如果用戶接受聲明，應用將會收到一條key-hash的消息認證碼（HMAC)，該簽名由TEE產生，以保護用於輸入和認證對話框的顯示。該簽名表示用於已經看到了聲明並同意了。

硬體安全模塊

Android P還提供了StrongBox Keymaster（強力沙盒秘鑰大師），一個存儲在硬體安全模塊的具體實現。在這個硬體安全模塊中有自己的CPU、安全存儲空間，真隨機數生成器，以及額外的機制抵禦應用被篡改或是未授權應用的惡意載入。當檢查存儲在StrongBox Keymaster中的密鑰時，系統通過可信執行環境（TEE）確認密鑰的完整性。為了降低能耗，StrongBox支持了一組演算法和不同長度的秘鑰：

●RSA 2048

●AES 128 and 256

●ECDSA P-256

●HMAC-SHA256 (支持8位元組到64位元組任意秘鑰長度)

●Triple DES 168

需要說明的是，這個機制需要硬體支持。

安全秘鑰導入KeyStore

使用新的ASN.1編碼的秘鑰格式添加導入秘鑰到Keystore，Android P提供了額外的密碼解密安全能力。之後KeyMaster就可以解密KeyStore存儲的秘鑰，這種工作方式使得秘鑰明文永遠不會出現在設備內存中。這項特性要求設備支持Keymaster 4。

四、支持客戶端側Android備份加密

Android P支持使用客戶端密鑰對Android備份進行加密。 這項隱私措施，需要設備的PIN、圖案密碼或標准密碼才能從用戶設備備份的數據中恢復數據。

五、Accessibility優化

為了使App使用更便捷，Android在多個方面為開發者提供了易用性的優化。

1、Navigation semantics

Android P在App的場景切換和操作上為開發者提供了很多的優化點。

2、Accessibility pane titles

Android P中對Section提供了新的機制，被稱為accessibility pane titles， Accessibility services能夠接收這些標題的變化，使得能夠對一些變化提供更加細粒度的信息。

指定Section的標題，可以通過android:accessibilityPaneTitle新屬性來設置，同樣運行時可以通過setAccessibilityPaneTitle()來設置標題。

3、頂部欄導航

Android P提供了新的頂部欄導航機制，通過設置View實例的android:accessibilityHeading屬性為true,來顯示邏輯標題。通過這些標題，用戶就可以從一個標題導航到下一個標題，

4、群組導航和輸出

針對屏幕閱讀器，Android P對View提供了新的屬性android:screenReaderFocusable代替原有的android:focusable來做標記，來解決在一些場景下為了使屏幕閱讀器工作而設置View為可獲取焦點的操作。這時，屏幕閱讀器需要同時關注android:screenReaderFocusable和android:focusable設置為ture的View。

5、便捷操作

tooltips交互

Android P中，可以使用getTooltipText()去讀取tooltips的文本內容。使用新的ACTION_SHOW_TOOLTIP和ACTION_HIDE_TOOLTIP控制View顯示或者隱藏tooltips。

新全局交互

Android P在AccessibilityService類中提供了兩個全新的操作。開發者的Service可以通過GLOBAL_ACTION_LOCK_SCREEN幫助用戶鎖屏，通過GLOBAL_ACTION_TAKE_SCREENSHOT幫助用戶完成屏幕截圖。

窗體改變的一些細節

Android P優化了在App多窗體同步發生變化時的更新內容獲取。當出現TYPE_WINDOWS_CHANGED時，開發者可以通過getWindowChanges()API獲取窗體變化情況。

當多窗體發生改變時，每個窗體都會發出自己的事件，開發者可以通過getSource()獲取到事件窗體的根View。

如果你的App為View定義了accessibility pane titles，UI更新時你的Service就能夠識別到相應的改動。當出現TYPE_WINDOW_STATE_CHANGED事件時，使用新方法 getContentChangeTypes()返回的類型，就能夠獲取到當前窗體的變化情況。例如，現在就能夠通過上述的機制，檢測到一個[v1]窗格是否有了新標題，或者一個窗格的消失。

六、新的Rotation方案

旋轉屏幕，是一些游戲、視頻等場景必要的操作，但有一些場景，用戶旋轉屏幕並不是為了讓應用顯示從豎屏變成橫屏或反過來。為了避免這種誤操作，Android P提供了新的機制，開發者可以指定屏幕不隨重力感應旋轉，而是用戶通過一個單獨的按鈕自行控制屏幕顯示轉向。