赞
踩
前段时间群里有伙伴问到了关于Android开发中Theme与Style的问题,当然,这类东西在网上随便一搜一大把模板,所以关于怎么用的问题我想这里也就不做太多的说明了,我们这里把重点放在理解整个Android中Theme、Style的关系及结构,这样我们就能游刃有余的面对实际开发中遇到的很多问题了,也就免得在自定义时遇到各种坑,譬如不清楚该继承哪个parent、不清楚为何背景会有一个黑边等。
本文主要分两部分来进行简单粗略的浅析,首先会围绕Theme与Style的定义及在App开发中的使用来进行简单回顾,接着第二部分会介绍Android系统关于Theme与Style的规则及源码,然后简单总结下我们开发中如何处理自定义Theme与Style的一些方法。
【工匠若水 http://blog.csdn.net/yanbober 未经允许严禁转载,请尊重作者劳动成果。私信联系我】
对于Android开发者来说Theme主要是针对窗体及Activity级别的,通常改变的是窗体的样式;而Style主要是针对窗体及Activity中具体成员元素级别的,通常改变的是控件的样式。简单粗暴理解就是Theme作用于所有支持属性的子成员,Style作用于指定的成员。所以关于Theme与Style的基础概述这里就不做过多赘述了,具体可以移步到Android官方文档进行查阅,这里我们主要针对比较常用的一些基础点进行粗略的回顾,具体如下。
Theme的实质也是Style,所以Theme的定义格式与Style的基本一致,具体格式如下(都定义在res目录下,自己随意起名的xml中):
<?xml version="1.0" encoding="utf-8"?>
<resources>
<style name="CodeFont" parent="@android:style/TextAppearance.Medium">
<item name="android:layout_width">fill_parent</item>
<item name="android:layout_height">wrap_content</item>
<item name="android:textColor">#00FF00</item>
<item name="android:typeface">monospace</item>
</style>
</resources>
可以看见,一个style在定义时至少需要一个name的属性用来被使用者识别,其中的item就是各种不同的属性与指定的属性值,而style除过有name属性以外还可以有parent属性,在这里你先理解为类似java的继承重写关系即可,后面会详细介绍。
不过这里要特别注意,一般在style中使用parent字段的继承适用于继承系统平台现有定义的style,而我们想要继承自己实现的style一般不会通过parent字段来实现,而是通过指定格式的name字段来实现,如下:
<style name="CodeFont.Red">
<item name="android:textColor">#FF0000</item>
</style>
看见name字段了吗?证明这个style继承自我们上面自定义的CodeFont style,可见我们自定义的继承是通过“.”来实现的,在使用时只需要@style/CodeFont.Red即可使用该继承重写的style啦,如果你还想继续在这基础上继承,那写法还是一样的,具体如下:
<style name="CodeFont.Red.Big">
<item name="android:textSize">30sp</item>
</style>
整明白Theme与Style的这个约定了么!就是这么简单而已,不过要注意这两种的严格区别,别乱用,譬如将系统预定义的通过name来使用时错误的。
接着我们来看看style中item属性是怎么搞来的,这玩意如果我们定义控件的style则可以直接在对应控件或者Window的API文档中或者R.attr
文档中找到支持哪些属性,依次选择合适的进行使用即可(特别提醒,这个技能很重要,譬如有时候你会说我自定义的Dialog为何背景周边多一个黑框啥玩意的问题,然后上网一顿复制别人的style,也不明白别人为啥这么写,其实一个很重要的技巧就是遇到这种问题自己去API查下相关的属性就搞定了。)。使用系统已存在属性时切记不要忘记<item name="android:inputType">
前面的android:前缀,还有就是item中存在的属性不见得对所有View都有效,譬如Theme中需要的以windowXXX开头的属性就不适用于View,但是不会报错,只是View会忽略这些不适合自己的属性,应用适合自己的属性。
有了上面的知识我们已经能够定义出Theme与Style了,下来就是怎么将定义的这些样式应用到UI中啦。将style设置到UI主要分两类,如下:
在Android中有许多预定义的style供我们使用,所以在使用主题时我们可以如下使用:
<!-- 使用系统预制style -->
<activity android:theme="@android:style/Theme.Dialog">
<!-- 使用系统预制但局部修改的style -->
<activity android:theme="@style/CustomTheme">
<color name="custom_theme_color">#b0b0ff</color>
<style name="CustomTheme" parent="android:Theme.Light">
<item name="android:windowBackground">@color/custom_theme_color</item>
<item name="android:colorBackground">@color/custom_theme_color</item>
</style>
在新版本的Android中添加了很多新的Theme,而老版本又不兼容这些Theme,所以很多时候我们可能需要处理一下这种兼容性问题,譬如我们在res/values/styles.xml文件中定义如下Theme:
<style name="LightThemeSelector" parent="android:Theme.Light">
...
</style>
当我们想在Android3.0(API 11)以上使用新的Theme则可以res/values-v11目录下定义如下Theme:
<style name="LightThemeSelector" parent="android:Theme.Holo.Light">
...
</style>
这样当我们编译的APK在不同的设备上运行时就能自己切换选择适合自己平台的Theme了。
话说Android应用层开发之所以简单的原因就在于系统已经帮我们实现了很多自由选择的功能,关于Style与Theme也不例外(应用层开发难就难在知识面很广),具体使用可以记住如下秘诀:
上面提到的都是Theme与Style相关的东西,其实这两个东西实质都属于res资源的处理,关于Android的res资源使用规则和不同平台软硬件系统匹配的策略不属于本文范围,不过也很简单,感兴趣的同学可以移步到API Guide的App Resources进行研读。这里我们主要简单说下资源的引用语法,因为Theme与Style中也会经常使用到,免得带来不必要的疑惑。
Android中资源在Java文件中引用的语法定义如下:
[<package_name>.]R.<resource_type>.<resource_name>
//注意:当资源在当前APP中则package_name可以省略,当为系统的资源则可换位譬如android.
Android中资源在XML文件中引用的语法定义如下:
@[<package_name>:]<resource_type>/<resource_name>
//注意:package_name的规则同上java中,不过在XML中引入不是本包资源时要注意格式,譬如引用系统的资源格式为android:textColor="@android:color/secondary_text_dark"
Android系统预制资源在XML文件中引用的特殊语法定义如下:
//可以引用系统所有资源,public & private
@*android:type/name
//只能引用系统public的资源
@android:type/name
//注意:没在frameworks/base/core/res/res/values/public.xml(也就是<sdk_path>\platforms\android-X\data\res\values\public.xml)中申明的资源App时不推荐使用的。
Android在XML文件中引用当前主题属性的语法定义如下:
?[<package_name>:][<resource_type>/]<resource_name>
//资源值允许引用当前主题中的属性的值,这个属性值只能在style资源和XML中使用,随着当前主题的切换该值也在变换,该resource_name不需要自己定义,系统会自己在当前主题下寻找,常见的譬如动画中等。
Android在XML文件中创建或者引用资源语法定义如下:
//在R.java的type内部类中添加一条静态常量id资源标识符,如果标示符(包括系统资源)已经存在则表示引用该标示符。
@+type/name
//在R.java中寻找已经定义的标识符,如果找不到则提示失败错误,一般在xml中定义有先后关系。
@type/name
//所以一般推荐直接使用+号避免不必要的意外。
Android在XML文件中xmlns语法定义如下:
//xmlns(XML Namespaces)是XML的命名空间
//通用XML命名空间格式规则
xmlns:namespace-prefix="namespaceURI"
在Android的XML中命名空间规则如下:
xmlns:namespace-prefix=http://schemas.android.com/apk/res/应用程序包路径
在使用时规则如下:
namespace-prefix:属性
切记,xmlns的定义必须放在最外层开始的的标记中,譬如我们Activity的xml文件的根布局中的android前缀、tools前缀、自定义View的前缀等。常见的例子如下:
//android即为frameworks/base/core/res/res/values/attrs.xml中的属性
xmlns:android="http://schemas.android.com/apk/res/android"
//开发调试利器,不再过多说明
xmlns:tools="http://schemas.android.com/tools"
//Email App中res/values/attrs.xml等自定义属性
xmlns:settings="http://schemas.android.com/apk/res/com.android.email"
到此关于Android应用中如何定义Theme、Style及使用和继承重写相信大家已经明白了,再出现诡异的现象就可以通过查询相关API及google结合就能完全理会其中的原因了,而不是停留在能搜到复制;下面一节我们将针对上面的这些使用进行粗略的源码分析说明。
【工匠若水 http://blog.csdn.net/yanbober 未经允许严禁转载,请尊重作者劳动成果。私信联系我】
有了上面的应用使用基础,下面的源码简单浅析可能存在跳跃性和经验性,不会像之前博客那样系统性的从头到尾进行分析,而是分点点到为止,感兴趣的同学可以自行深入研读。
在我们App开发中通常我们会在新建工程后的AndroidManifest.xml文件中看见工程默认引用了应用包下自定义的主题@style/AppTheme(用法完全符合上一大节的规则)。该主题在当前应用包的style.xml中定义如下:
<resources>
<!-- Base application theme. -->
<style name="AppTheme" parent="Theme.AppCompat.Light.DarkActionBar">
<!-- Customize your theme here. -->
<item name="colorPrimary">@color/colorPrimary</item>
<item name="colorPrimaryDark">@color/colorPrimaryDark</item>
<item name="colorAccent">@color/colorAccent</item>
</style>
</resources>
看着木有,它活生生的继承了Theme.AppCompat.Light.DarkActionBar这个style,这玩意又在framework的support v7包下res的themes.xml文件中,具体如下:
<!-- Platform-independent theme providing an action bar in a dark-themed activity. -->
<style name="Theme.AppCompat.Light.DarkActionBar" parent="Base.Theme.AppCompat.Light.DarkActionBar" />
这个继承关系一直追踪下去到了该包下的themes_base.xml中的如下代码:
<style name="Platform.AppCompat.Light" parent="android:Theme.Light">
<item name="android:windowNoTitle">true</item>
......
</style>
哈哈,原来如此,这里的Theme.Light你应该十分熟悉了吧(这就是以前我们App用的不是Support包,而是默认的时候,theme默认就是这玩意哈),这玩意就在framework的base下的themes.xml中定义着呢(所以通过了android:进行引用,留意细节吧),具体如下:
<!-- Theme for a light background with dark text on top. Set your activity
to this theme if you would like such an appearance. As with the
default theme, you should try to assume little more than that the
background will be a light color.
<p>This is designed for API level 10 and lower.</p>-->
<style name="Theme.Light">
<item name="isLightTheme">true</item>
<item name="windowBackground">@drawable/screen_background_selector_light</item>
......
</style>
到这里我们就很容易明白啦,Theme.Light的父类原来是Theme哇,也在这个文件中,如下:
<!-- The default theme for apps on API level 10 and lower. This is the theme used for
activities that have not explicitly set their own theme.
<p>You can count on this being a dark
background with light text on top, but should try to make no
other assumptions about its appearance. In particular, the text
inside of widgets using this theme may be completely different,
with the widget container being a light color and the text on top
of it a dark color.
<p>If you're developing for API level 11 and higher, you should instead use {@link
#Theme_Holo} or {@link #Theme_DeviceDefault}.</p>
-->
<style name="Theme">
......
<!-- Text styles -->
......
<!-- Button styles -->
......
<!-- List attributes -->
......
<!-- @hide -->
......
<!-- Gallery attributes -->
......
<!-- Window attributes -->
......
<!-- Define these here; ContextThemeWrappers around themes that define them should
always clear these values. -->
......
<!-- Dialog attributes -->
......
<!-- AlertDialog attributes -->
......
<!-- Presentation attributes (introduced after API level 10 so does not
have a special old-style theme. -->
......
<!-- Toast attributes -->
......
<!-- Panel attributes -->
......
<!-- These three attributes do not seems to be used by the framework. Declared public though -->
......
<!-- Scrollbar attributes -->
......
<!-- Text selection handle attributes -->
......
<!-- Widget styles -->
......
<!-- Preference styles -->
......
<!-- Search widget styles -->
......
<!-- Action bar styles -->
......
<!-- Floating toolbar styles -->
......
<!-- SearchView attributes -->
......
<!-- PreferenceFrameLayout attributes -->
......
<!-- NumberPicker style-->
......
<!-- CalendarView style-->
......
<!-- TimePicker style -->
......
<!-- TimePicker dialog theme -->
......
<!-- DatePicker style -->
......
<!-- DatePicker dialog theme -->
......
<!-- Pointer style -->
......
<!-- Accessibility focused drawable -->
......
<!-- Lighting and shadow properties -->
......
</style>
看注释吧,这货有接近400多个item属性,这也就是我们Android关于Theme的开山鼻祖了,在我们自定义时其实来这看比去API查还方便呢(其实需要两个互相配合,一个查,一个看解释,哈哈),因为它里面定义了关于我们整个应用中文字样式、按钮样式、列表样式、窗体样式、对话框样式等,这些样式都是默认样式,它还有很多我们常用的扩展样式,譬如Theme.Light、Theme.NoTitleBar、Theme.NoTitleBar.Fullscreen等等,反正你要有需求来这里搞就行。当我们继承使用时只用在前加上android:即可,有些属性可能是找不到的。同理,我们所谓的style、attr等等也都是这么个框架,大致位置也类似主题Theme的,所以这里不再过多说明,自行脑补即可。
对于纯App开发来说这一个知识点可以忽略,因为本小节需要大致了解Android源码的结构和编译框架,对于固件等开发来说这个还是比较重要的,记得以前做TV盒子开发时很多系统资源需要替换及添加,也就是说会稍微涉及到修改System UI及FW的res,那时候好坑爹,虽然修改的地方不多,只是换几个图标和加几个资源,但是那时候自己还是蒙圈了一段时间才搞明白,所以说有必要啰嗦几句。
首先我们先要明白设备里系统目录下的这些常见jar与apk的来源,如下:
名字 | 解释 |
---|---|
am.jar | 执行am命令所需的java lib,对应FW的base/cmds/am目录,具体可以参考下面的Android.mk定义。 |
framework-res.apk | Android系统资源库集合,对应FW的core/res目录,具体同理参见Android.mk定义。 |
framework.jar | Android SDK核心代码,对应FW的base目录,具体可以参考目录下的Android.mk的MOUDLE定义。 |
SystemUI.apk | 从Android2.2开始状态栏和下拉通知栏被分割出一个单独的SystemUI.apk,一般在system的app或者priv-app下(还有很多其他模块呢,譬如SettingProvider等,具体可以在设备下看看),对应的源码在FW的packages下的SystemUI中。 |
Others | 其他的jar比较多,不做一一介绍,不同厂商可能还会不同定制,具体可在厂商设备的system下看看有哪些包,对应回去通过Android.mk文件寻找即可。 |
android.jar | 切记这个特例,这货是make sdk生成的,多方整合,别以为也可以找到对应目录,木有的!还有就是这个jar很实用的,很多时候我们想用AS直接调运系统的hide API等,自己编译一个就能派上用场啦! |
有了上边这几个和我们本文相关的核心常识后我们简单说下怎么修改编译:
不过这里有些坑大家要明白,我们在mm前最好每次都去清除对应out/obj目录下的中间文件,特别是资源文件更新时,否则容易被坑。还有就是切记添加系统API或者修改@hide的API或者添加资源(包含添加修改public.xml等)后,需要执行make update-api命令来同步base/api下的current.txt的修改,完事再make就行啦,这些编译文档都有介绍。
有了上面这些相信大家对于客户化资源也就有了一些认识啦,想想如果我们需要用到framework.jar的hide资源或者framework-res.apk中新加的资源时又不想用反射和源码下编译怎么办?当然是编译一个no hide的jar引入我们工程即可哇,要注意我们引入以后一定是Providered的模式,也就是该jar只编译不打包入该apk,还有就是依赖的先后优先级顺序,否则又用的是sdk默认的。还有就是万能的android.jar也是一种曲线救国的办法。当然啦,如果是SDK开发则完全可以复制一份自己搞,完事编译进系统即可,同时提供给App开发。
前面我们介绍了Android的Theme、Style的定义及使用及Theme、Style等res的由来,这里我们来看看这些被使用的Theme的最终是何时、怎样被加载生效的。我们都知道对于Theme有两种方式来使用,具体如下(Style等attr在View的使用也比较同类,这里只分析Theme、其他的请在View等地自行分析脑补):
<application>
或者<activity>
节点设置android:theme属性;可以看见,这两种方式我们都比较常用,甚至有时候还会设置Window的一些属性标记,这些标记方法都在Window类中。我们平时在设置这些Theme时总是有很多疑惑,譬如为毛只能在setContentView()前设置等等,那么下面我们就来庖丁解牛一把。故事在开始之前可能还需要你自行脑补下《Android应用setContentView与LayoutInflater加载解析机制源码分析》与《Android应用Activity、Dialog、PopWindow、Toast窗口添加机制及源码分析》两篇文章,完事再来继续下面的内容。
关于Activity通过setContentView方法设置View的来源这里就不多说了,参考前面两篇即可,我们直接跳到PhoneWindow的setContentView方法来看下,如下:
public void setContentView(int layoutResID) {
if (mContentParent == null) {
installDecor();//每个Activity第一次进来必走
} else if (!hasFeature(FEATURE_CONTENT_TRANSITIONS)) {
mContentParent.removeAllViews();
}
......
}
我们接着来看下installDecor()方法,如下:
private void installDecor() {
if (mDecor == null) {
//仅仅new DecorView(getContext(), -1)而已,也就是FrameLayout
mDecor = generateDecor();
......
}
if (mContentParent == null) {
//生成我们布局的父布局
mContentParent = generateLayout(mDecor);
// Set up decor part of UI to ignore fitsSystemWindows if appropriate.
mDecor.makeOptionalFitsSystemWindows();
final DecorContentParent decorContentParent = (DecorContentParent) mDecor.findViewById(
R.id.decor_content_parent);
......
}
}
接着我们继续看看generateLayout(mDecor);这个方法,如下:
protected ViewGroup generateLayout(DecorView decor) {
// Apply data from current theme.
//获取当前主题,重点!!!!!!!
TypedArray a = getWindowStyle();
......
//解析一堆主题属性,譬如下面的是否浮动window(dialog)等
mIsFloating = a.getBoolean(R.styleable.Window_windowIsFloating, false);
......
// Inflate the window decor.
//依据属性获取不同的布局添加到Decor
int layoutResource;
int features = getLocalFeatures();
// System.out.println("Features: 0x" + Integer.toHexString(features));
if ((features & (1 << FEATURE_SWIPE_TO_DISMISS)) != 0) {
layoutResource = R.layout.screen_swipe_dismiss;
}
......
View in = mLayoutInflater.inflate(layoutResource, null);
decor.addView(in, new ViewGroup.LayoutParams(MATCH_PARENT, MATCH_PARENT));
mContentRoot = (ViewGroup) in;
ViewGroup contentParent = (ViewGroup)findViewById(ID_ANDROID_CONTENT);
......
return contentParent;
}
一样喽,继续先看下getWindowStyle()方法是神马鬼,这个方法在其基类Window中,如下:
/**
* Return the {@link android.R.styleable#Window} attributes from this
* window's theme.
*/
public final TypedArray getWindowStyle() {
synchronized (this) {
if (mWindowStyle == null) {
mWindowStyle = mContext.obtainStyledAttributes(
com.android.internal.R.styleable.Window);
}
return mWindowStyle;
}
}
哎,没啥好看的,没有逻辑,就是流程,继续跟吧,去Context类看看obtainStyledAttributes(com.android.internal.R.styleable.Window)方法吧,如下:
/**
* Return the Theme object associated with this Context.
*/
@ViewDebug.ExportedProperty(deepExport = true)
public abstract Resources.Theme getTheme();
/**
* Retrieve styled attribute information in this Context's theme. See
* {@link android.content.res.Resources.Theme#obtainStyledAttributes(int[])}
* for more information.
*
* @see android.content.res.Resources.Theme#obtainStyledAttributes(int[])
*/
public final TypedArray obtainStyledAttributes(@StyleableRes int[] attrs) {
//获取当前Theme对应的TypedArray对象
return getTheme().obtainStyledAttributes(attrs);
}
哎呦我去,憋大招呢,急死人了!可以看见Context的getTheme()方法时一个抽象方法,那他的实现在哪呢,看过《Android应用Context详解及源码解析》一文的同学一定知道对于Activity来说他的实现类就是ContextThemeWapprer,那我们赶紧进去看看它到底搞了啥玩意,如下:
@Override
public Resources.Theme getTheme() {
//一旦设置有Theme则不再走后面逻辑,直接返回以前设置的Theme
if (mTheme != null) {
return mTheme;
}
//没有设置Theme则获取默认的selectDefaultTheme
mThemeResource = Resources.selectDefaultTheme(mThemeResource,
getApplicationInfo().targetSdkVersion);
//初始化选择的主题,mTheme就不为null了
initializeTheme();
return mTheme;
}
@Override
public void setTheme(int resid) {
//通过外部设置以后mTheme和mThemeResource就不为null了
if (mThemeResource != resid) {
mThemeResource = resid;
//初始化选择的主题,mTheme就不为null了
initializeTheme();
}
}
我勒个去,憋大招总算憋出来翔了,ContextThemeWapprer才是重头戏啊,总算看见了光明了。这里的getTheme方法有一个判断,没有设置过Theme(mTheme为空)则通过Resources.selectDefaultTheme获取默认主题,否则用setTheme设置的主题。那么我们就来先看下假设没有设置主题,使用默认主题的方法,Resources.selectDefaultTheme如下:
/**
* Returns the most appropriate default theme for the specified target SDK version.
* <ul>
* <li>Below API 11: Gingerbread
* <li>APIs 11 thru 14: Holo
* <li>APIs 14 thru XX: Device default dark
* <li>API XX and above: Device default light with dark action bar
* </ul>
*
* @param curTheme The current theme, or 0 if not specified.
* @param targetSdkVersion The target SDK version.
* @return A theme resource identifier
* @hide
*/
public static int selectDefaultTheme(int curTheme, int targetSdkVersion) {
return selectSystemTheme(curTheme, targetSdkVersion,
com.android.internal.R.style.Theme,
com.android.internal.R.style.Theme_Holo,
com.android.internal.R.style.Theme_DeviceDefault,
com.android.internal.R.style.Theme_DeviceDefault_Light_DarkActionBar);
}
/** @hide */
public static int selectSystemTheme(int curTheme, int targetSdkVersion, int orig, int holo,
int dark, int deviceDefault) {
if (curTheme != 0) {
return curTheme;
}
if (targetSdkVersion < Build.VERSION_CODES.HONEYCOMB) {
return orig;
}
if (targetSdkVersion < Build.VERSION_CODES.ICE_CREAM_SANDWICH) {
return holo;
}
if (targetSdkVersion < Build.VERSION_CODES.CUR_DEVELOPMENT) {
return dark;
}
return deviceDefault;
}
哎呀妈呀,这不就解释了我们创建不同版本的App时默认主题不一样的原因么,哈哈,原来如果我们没有设置主题Theme,系统会依据版本给我们选择一个默认的主题,也就是上面这段代码实现了该功能。
我们回过头继续回到ContextThemeWapprer的getTheme方法,当我们已经设置了Theme该方法就直接返回了,恰巧设置Theme的方法也在ContextThemeWapprer中。那这个方法啥时候被调运的呢?这一小节一开始我们就说了Activity的Theme设置有两种方法,主动通过Java调运setTheme()和在AndroidManifest文件配置,AndroidManifest文件配置的Theme又是啥时候调运的呢?有了前面几篇博客的铺垫,我想你也一定能找到的,就在ActivityThread的performLaunchActivity()方法中,也就是我们通过startActivity()方法启动Activity时就调运了Activity的setTheme方法,这个就不多说了,感兴趣的自己进去看下就行了,也是流程憋大招,最终调用了activity.setTheme()完成了AndroidManifest文件的Theme获取。
我们现在把目光回到ContextThemeWapprer的setTheme或者getTheme中调运的initializeTheme()方法中来看看,如下:
protected void onApplyThemeResource(Resources.Theme theme, int resid, boolean first) {
theme.applyStyle(resid, true);
}
//大招!!!!!!!
private void initializeTheme() {
//这就解释了为何setTheme必须在setContentView前调运,不多解释了,很明白了吧!!!!!!!!
final boolean first = mTheme == null;
if (first) {
mTheme = getResources().newTheme();
Resources.Theme theme = getBaseContext().getTheme();
if (theme != null) {
mTheme.setTo(theme);
}
}
onApplyThemeResource(mTheme, mThemeResource, first);
}
这个方法就解释了为何setTheme必须在setContentView前调运。最终通过onApplyThemeResource调运Resources.Theme的方法进行了设置,如下:
/**
* Place new attribute values into the theme. The style resource
* specified by <var>resid</var> will be retrieved from this Theme's
* resources, its values placed into the Theme object.
*
* <p>The semantics of this function depends on the <var>force</var>
* argument: If false, only values that are not already defined in
* the theme will be copied from the system resource; otherwise, if
* any of the style's attributes are already defined in the theme, the
* current values in the theme will be overwritten.
*
* @param resId The resource ID of a style resource from which to
* obtain attribute values.
* @param force If true, values in the style resource will always be
* used in the theme; otherwise, they will only be used
* if not already defined in the theme.
*/
public void applyStyle(int resId, boolean force) {
AssetManager.applyThemeStyle(mTheme, resId, force);
mThemeResId = resId;
mKey.append(resId, force);
}
到此注释也说明了一些概念,关于AssetManager的应用又是另一个大话题了,这里先不展开讨论,我们只用知道到此一个Theme就选择完成了,还有就是一个Theme的是怎么被选择出来的,当然对于Dialog等Window的Theme也是一个样子,这里不多说明,感兴趣的自行脑补即可。
到现在为止我们已经找到了Theme是怎么来的了,下来我们需要回到我们这一小节开头部分的源码分析,也就是Resources的obtainStyledAttributes()方法,还记得我们最终传递了com.android.internal.R.styleable.Window进行获取该style么。这货不就是FW中res的attr.xml中自定义的属性么,如下:
<!-- The set of attributes that describe a Windows's theme. -->
<declare-styleable name="Window">
<attr name="windowBackground" />
<attr name="windowBackgroundFallback" />
......
<attr name="windowLightStatusBar" format="boolean" />
</declare-styleable>
可以看见,Style、Theme其实就是一组自定义的内置在Android系统资源中的属性集合,而这里唯一比较特殊的就是这些定义的属性没有声明format字段。其实在Android中如果某个自定义属性没有声明format属性则意味着该属性已经定义过,这里只是别名而已。在哪定义的呢?当然还是attr中哇,属性么,自然只能在这了,找找看发下如下:
<!-- These are the standard attributes that make up a complete theme. -->
<declare-styleable name="Theme">
......
<attr name="windowBackground" format="reference" />
<!-- Drawable to draw selectively within the inset areas when the windowBackground
has been set to null. This protects against seeing visual garbage in the
surface when the app has not drawn any content into this area. -->
<attr name="windowBackgroundFallback" format="reference" />
......
</declare-styleable>
原来Theme属性集才是这货的正身哇,哈哈。有了这些属性集在themes.xml中的Theme style就是对上面这些属性的设置值了,如下样例:
<style name="Theme">
<item name="isLightTheme">false</item>
<item name="colorForeground">@color/bright_foreground_dark</item>
<item name="colorForegroundInverse">@color/bright_foreground_dark_inverse</item>
......
</style>
哈哈,有没有觉得和App层开发自定义attr和style一样呢,原来系统也是这么干的,哈哈!
到此我们已经知道Theme是怎么来的,其中的attr是怎么定义及设置的,下面我们就回到PhoneWindow的generateLayout(DecorView decor) 方法来看下万事俱备以后的应用大杂烩即可,如下:
protected ViewGroup generateLayout(DecorView decor) {
//上面已经分析过了,获取Theme及Theme中Style定义的attr的属性,这里获取Window的属性
TypedArray a = getWindowStyle();
//获取是否floating的窗口,也就是是否Dialog
mIsFloating = a.getBoolean(R.styleable.Window_windowIsFloating, false);
......
//各种属性获取及feature、flag设置
if (a.getBoolean(R.styleable.Window_windowNoTitle, false)) {
requestFeature(FEATURE_NO_TITLE);
} else if (a.getBoolean(R.styleable.Window_windowActionBar, false)) {
// Don't allow an action bar if there is no title.
requestFeature(FEATURE_ACTION_BAR);
}
......
if (a.getBoolean(R.styleable.Window_windowFullscreen, false)) {
setFlags(FLAG_FULLSCREEN, FLAG_FULLSCREEN & (~getForcedWindowFlags()));
}
// Inflate the window decor.
//依据Theme及feature、flag获取一个匹配的layoutResourceId资源布局
int layoutResource;
int features = getLocalFeatures();
// System.out.println("Features: 0x" + Integer.toHexString(features));
if ((features & (1 << FEATURE_SWIPE_TO_DISMISS)) != 0) {
layoutResource = R.layout.screen_swipe_dismiss;
} else if ((features & ((1 << FEATURE_LEFT_ICON) | (1 << FEATURE_RIGHT_ICON))) != 0) {
if (mIsFloating) {
TypedValue res = new TypedValue();
getContext().getTheme().resolveAttribute(
R.attr.dialogTitleIconsDecorLayout, res, true);
layoutResource = res.resourceId;
} else {
layoutResource = R.layout.screen_title_icons;
}
// XXX Remove this once action bar supports these features.
removeFeature(FEATURE_ACTION_BAR);
// System.out.println("Title Icons!");
}
......
//将获取到的资源id布局文件inflate成View添加到DectorView中,同时将mContentRoot赋值为当前resourceId View
View in = mLayoutInflater.inflate(layoutResource, null);
decor.addView(in, new ViewGroup.LayoutParams(MATCH_PARENT, MATCH_PARENT));
mContentRoot = (ViewGroup) in;
//找到contentParent返回使用,至此关于Window的属性基本应用完毕
ViewGroup contentParent = (ViewGroup)findViewById(ID_ANDROID_CONTENT);
......
return contentParent;
}
哈哈,整明白了吧,到此就是整个Android关于Theme、Style的核心由来、流程、实现、使用的过程,相信有了上面这些知识后在使用Theme、Style时你该不会继续蒙圈了吧,加油。
【工匠若水 http://blog.csdn.net/yanbober 未经允许严禁转载,请尊重作者劳动成果。私信联系我】
基础也整理了,源码也简单分析了,虽然上面主要是围绕Android的Theme与Style来叙述解释的,但是对于整个Android的res资源都是适用的,所以关于其他资源文中也给出了相关链接,感兴趣的自行脑补即可。
由此可见,Theme实质是style,style实质是系统已经帮忙我们预定义很多attr,我们只用按照规则使用即可,不懂时翻看API和源码即可,其他加载流程是通过Context与Window框架及Resource进行组合交互判断处理应用。
PPPS:有段时间没有写博客了,这段时间的感触很多,在毫无准备的情况下聊过几家公司,因为自己暂时不想去别的城市,在整个过程中感悟到了创业公司产品的规划思想及所处的技术尴尬,也体会到了大公司对技术人才的定位角度,同时在过去的这一年也收获了很多感慨,年轻单纯、整天没有太多的事情、即便有也是没有太多的技术含量,这样的日子持续让自己发怵、恐慌,所以最终选择了离去。有很多人问我XX公司不好吗,你为什么会选择走啊,是不是脑袋进水了,这样的质疑我只选择了沉默,因为涉及的问题很多,我不想再这么无聊的继续待下去,调整心情准备去新公司上班吧,今年7月就整整毕业满三年了,感慨万千,只能化作内心的咆哮来激励自己。
【工匠若水 http://blog.csdn.net/yanbober 未经允许严禁转载,请尊重作者劳动成果。私信联系我】
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。