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提供了新的机制，开发者可以指定屏幕不随重力感应旋转，而是用户通过一个单独的按钮自行控制屏幕显示转向。