android支持库 Support Libraries v22.1.0

翻译自：https://chris.banes.me/

 

距离上一次发帖有一段时间了。昨天你们可能已经看到支持库发布了22.1.0版本，这一次可能是我们所做的最大的一次与平台版本无关的发布版本。

在我们深入了解以前，需要先读过官方发布的博客http://android-developers.blogspot.co.uk/2015/04/android-support-library-221.html。

这篇博文为这次新发布的版本中所有的库列举了所有新特性的提纲。在本文当中我会集中说明如何一些东西的用法和为什么这么用。尤其对于我所做的这些。

AppCompat(应用兼容)

现在我们来看一下本次有大量更新的AppCompat，首先要做的就是，重构……

Refactoring(重构)

以前使用AppCompat机制只有一个入口，就是通过现在已经被抛弃的类ActionBarActivity。但是很不爽的是，这会强制性使用一个无法使用类似PreferenceActivity的Activity类层级。

而我们现在将所有内部的机制都释放出来，通过一套单独的代理API暴露出来，这就是AppCompatDelegate. AppComatDelegate可以通过任何暴露Window.Callback接口的android内置对象来创建，比如任何Activity或Dialog的子类。你可以通过他的静态方法create()来创建。

当你创建了一个代理对象，有一个约定去维护它。你必须在每一次调用代理对象暴露的方法时回调给它(比如onCreate())，不过这个很简单，并很容易抽出来方法一个基类当中。

只要在合适的时候调用它，如此一来就可以将AppCompat的兼容功能附加到任何Activity的子类中。

如果你打算使用AppCompatDelegate，我极力主张你找机会看一下AppCompatActivity 的源代码，它是一个极好地示范了如何嵌入AppCompatDelegate的例子。

尽管如此，多数人(你可能习惯了用ActionBarActivity) 不需要这个级别的定制化，而只会去使用AppCompatActivity.

Dialogs(对话框)

在重构的步骤当中我一提到Dialog的时候就应该给你灵感我们可能在加了什么。在我们完成了重构工作以后，对话框也是自然而然成为下一步要改的。从一个视图点建立布景，对于Activity和Dialog实际上差别不大(这句话意思不太明白)。

这意味着我们最终关闭了一个自从v21版本到现在最大的请求：材料样式的对话框。

我们现在有了新的AppCompatDialog类，这个类你应该使用任何引用了Theme.AppCompat.Dialog样式的对话框。

为了让这一部分更加完整，AppCompat现在也有了自己的使用了材料样式的AlertDialog，要使用它，只要改变使用来源为android.support.v7.app.AlertDialog。它已经处理好了。

一个需要注意的是，AppCompat的AlertDialog没有去做框架版本做的事。它仅仅暴露了在这个‘材料的世界’中有价值的东西。(原文就是这么写的)

android:theme

在我们开始这个部分之前，确保你已经阅读过我的 Theme vs Style  这篇博文解释了我们所探讨的东西最基础的说明。

在AppComat v21，我们披露了一种能快速搞定的方法来使用app:theme来为Toolbar设置主题的方法。

在22.1.0我们现在扩展了这个功能，使得你可以在你的布局中为视图设置主题。我们现在改用android:theme，如此以来可以在兼容包和框架间无缝切换。

最喜闻乐见的是，在运行着API v11以上的设备可以自动继承父主题。有一个快速示例：、

对于运行API v10以及以前的设备，你仍能使用android:theme，但是父主题是无效的。这就意味着你要不重新构思你的布局，或者全都设置android:theme。

对于那些被关注的，能够使用父主题继承的是 LayoutInflater.Factory2.

Widgets

如果你读过Ian的官方博文你会看到那些可以着色的小部件，现在已经开放了（尽管不多）。

这非常好，但因此会有另外的变化：我们不再改变平台主题默认的小部件样式。如果你正在使用AppCompat实现的小部件(无论是显式的或隐式的)，这意味着你只能在v21以前的设备上使用材料样式。在实践中，因为我们将appcompat自动实现到位，你不会感受到差别。

这让我们能够解决一个问题，在我们的使用了材料样式，不会再无法着色。这种情况发生在平台实现的小部件使用了我们的样式，显示却是不同的地方。取而代之的是，你会看到平台默认的样式，例如Holo。这会看起来有点怪异，但是总比一个黑漆漆的未着色的视觉绘制区域要好。

Theme window features(窗口主题特性)

AppCompat现在对Window对象的flag比较严格，会更加匹配你从框架层中得到的效果。

一个最主要的原因是为了支持我们之前提到的对话框。他们会重度使用windowNoTitle这个标识，在这之前AppCompat并没有把注意力放在这方面上。

当你升级到v22.1.0你会发现如下异常。

IllegalArgumentException: AppCompat does not support the current theme features

这种情况就参考一下我在StackOverflow上的回答关于如何修复你的主题：

http://stackoverflow.com/q/29790070/474997

v4

作为祖父级支持库，v4支持包会继续成长，并且会有新的特性加入。

ColorUtils

ColorUtils 已经移出Palette 调色板工具，转移进入v4包内，作为公共类使用。它包括一些很好的特性来对色彩进行一些操作。

举个栗子，你可以用它来计算在背景颜色之上的文本使用的最小alpha透明度值：

int backgroundColor = ...;
int textColor = Color.WHITE;
float minContrastRatio = 4.5f; //我们想要一个最小的对比度比值 1:4.5

int minAlpha = ColorUtils.calculateMinimumAlpha(
        textColor, backgroundColor, minContrastRatio);

if (minAlpha != -1) {
    // 如果已经有了一个alpha值拥有足够的对比度，那就直接用!
    return ColorUtils.setAlphaComponent(textColor, minAlpha);
}

还有很多其他的干货，像颜色组合器还有亮度计算器等。去看一下Javadoc发掘发掘。

Drawable tinting

在Lollipop中绘制对象的上色方法在动态给资源上色显得非常有用。AppCompat已经在v21版支持库中酝酿了这些实现，

现今我们把这些抽出来放到v4支持库的DrawableCompat中，让每个人都可以使用。知道如何让它起作用很重要。

Drawable drawable = ...;

// 包装一下drawable对象，后面可以在v21以下的设备上使用上色方法的调用，
//需要使用返回的drawable对象
drawable = DrawableCompat.wrap(drawable);

// 我们可以指定一种色彩进行上色
DrawableCompat.setTint(drawable, Color.RED);
// ...或者一个色彩状态列表
DrawableCompat.setTintList(drawable, myColorStateList);
// ...或者一种不同的上色模式
DrawableCompat.setTintMode(drawable, PorterDuff.Mode.SRC_OVER);

有一件事要记住，在你调用了 DrawableCompat.wrap()之后 ，你不能指望结果是和你给它相同的类型。所以你应该

使用DrawableCompat.unwrap()方法来还原为原来的Drawable类型。

我们在内部会封装你的Drawable成为一种“可上色的绘制对象”，这会从特定的上色彩为你的Drawable颜色过滤器进行更新上色。

这可以允许我们处理ColorStateList 实例。

Palette

调色板Palette也在这次发布中也很有爱。第一个就是我们加入了一个新的Builder类来辅助初始化。之前我们发现我们加入越来

越多的“小旋钮” ，然后把Palette的API变的拐弯抹角令人费解。Builder则让人们使用这些API更加舒适。

第二方面的（也是更加重要的）改变，是生成调色板时对性能的大幅度优化。调色板最耗时的操作是色彩量化步骤。这实际上

是获取了一个图片的所有像素以后，降低色彩深度到一个更少的色彩数上(通常是是16色)。

在这一次的发布版中，我们回退了一些老式的色彩量化的优化方式。比如更少的对象空间分配，更加合适的数据结构，简化算法

复杂度等。这些最终提供了在速度上拥有了更好的表现。

我做了一些快速测试。你能看出来使用了ART的设备有5~6倍的速度提升，但是在传统的Dalvik设备上，速度提升更明显。

Device	22.0	22.1.0	Speedup
Nexus 6	47ms	8ms	~6x
Nexus 5	55ms	11ms	~5x
Nexus One	1200ms	120ms	~10x

数据可能不是很科学，仅仅是给出一个大体的估计，仅仅是作为一个参考。