Android支持多屏幕机制即用为当前设备屏幕提供一种合适的方式来共同管理并解析应用资源。本文就介绍了4中Android屏幕自适应解决方案。

目前最为推荐的Android多屏幕自适应解决方案。

该属性的作用是决定控件在其父布局中的显示权重，一般用于线性布局中。其值越小，则对应的layout_width或layout_height的优先级就越高，一般横向布局中，决定的是layout_width的优先级；纵向布局中，决定的是layout_height的优先级。

传统的layout_weight使用方法是将当前控件的layout_width和layout_height都设置成fill_parent,这样就可以把控件的显示比例完全交给layout_weight；这样使用的话，就出现了layout_weight越小，显示比例越大的情况。不过对于2个控件还好，如果控件过多，且显示比例也不相同的时候，控制起来就比较麻烦了，毕竟反比不是那么好确定的。

于是就有了现在最为流行的0px设值法。看似让人难以理解的layout_height=0px的写法，结合layout_weight，却可以使控件成正比例显示，轻松解决了当前Android开发最为头疼的碎片化问题之一。

根据实际布局情况，选用当中的一种，不需要自己设置，看过我前一个ActivityGroup的Demo的同学应该非常熟悉了

这个是我自己想出来的方法，可能是个比较笨的方法，所以没有多少人提过用这种方法解决自适应的问题。虽然这个方法缺点也很多，但有时候也是个不错的方法。

可以看到我定义了两套尺寸文件，我们可以看下其中一个文件

这个是values-480x320文件夹下dimens_height.xml文件中的代码，我把整个高度分成了80等分，这是因为大部分屏幕的宽度或高度都是80的整数倍(个别特殊的除外)，不同的等分在不同的分辨率中设定不同的尺寸值。

由于每一套界面都要写一套，所以有些同学可能觉着不太好，不过这个写起来比较简单，而且以后也不用改，所以有时候也可以考虑用一下！

以上是我写的统一的布局代码，大家注意我的代码中有margin这样的值也用到了自定义尺寸，如果这个margin使用layout_weight来控制的话，无疑要多嵌套一层线性布局，所以说没有一个方法是十全十美的，这第2个方法有时候用起来反而还要方便一些。。

三、在java代码中设置宽高度

也许很多人会反对这种方法，因为即使是官方也是推荐使用xml的方式写布局。不过我们在这不会像Swing那样写那么多麻烦的布局代码，因为我们只是在代码中重新设定控件的宽高度而已，其他属性依然是交给xml布局文件的。这个方法其实是我跟同事偷学来的，虽然我不赞成这样的方法，但他确确实实也是解决屏幕自适应问题的方案之一，而且它没我想象的那么复杂，其实很简单。

首先我们要做的是获取当前屏幕的宽高度，因为这个在后面要用到

我们可以写两个静态变量用来保存当前屏幕的宽高度：

然后在第一个Activity启动的时候，获取这两个值

布局代码我们可以全都统一写成wrap-content，其实写成什么都无所谓，因为这个值只是暂时的

// 第一个按钮，宽度100%，高度10%

// 第二个按钮，宽度100%，高度30%

// 第三个按钮，宽度50%，高度20%

// 第三个按钮，宽度70%，高度填满剩下的空间

做为最后的方法，也是最后一个才会考虑的方法，那就是为不同的尺寸界面单独写布局。不到万不得已不要用这个方法，相信不少人和我一样都被逼着用过这个方法吧。需要说明的是，横竖屏切换使用不同布局也是用这个方法解决的；代码我就不上.

补充一下，写多个布局的时候，配置文件一定要加上这段配置代码，不然有时可能会出问题

以上说的都是多个屏幕显示相同内容需要考虑的问题，还有一种是在不同的屏幕上显示内容不同的情况，其实这个问题我们往往是用滚动视图来解决的，也就是ScrowView；需要注意的是ScrowView中使用layout_weight是无效的，既然使用ScrowView了，就把它里面的控件的大小都设成固定的吧。

此外关于图片的自适应问题，主要是2点，一个是9patch图，这个东西大家都要学会去做，不难；不过有些编译器在识别9patch图时会出这样那样的bug，像我的Eclipse就不认这个，而同一个9patch图在别的电脑上却是没问题的，

第二个要说的是我曾经被困扰的一个问题，对于480x800 和 480x854这两个尺寸，他们显示同一个图片时，总有一个会拉伸(如果9patch可以解决的还好)。其实当初困扰我的是，这两个尺寸都是hdpi的，以为无法给这两个屏幕做不同的图片。后来无意中发现，图片可以和布局一样分多个尺寸的，而不仅仅是根据密度分，也就是说你可以写这样的文件夹drawable-hdpi-800x480和drawable-hdpi-854x480，在它们里面放不同的图片，这样图片也能自适应了。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持脚本之家。

换肤分为动态换肤和静态换肤

这种换肤的方式,也就是我们所说的内置换肤,就是在APP内部放置多套相同的资源。进行资源的切换。
这种换肤的方式有很多缺点，比如， 灵活性差，只能更换内置的资源、apk体积太大,在我们的应用Apk中等一般图片文件能占到apk大小的一半左右。
当然了,这种方式也并不是一无是处, 比如我们的应用内，只是普通的 日夜间模式 的切换，并不需要图片等的更换，只是更换颜色,那这样的方式就很实用。

适用于大量皮肤，用户选择下载，像QQ、网易云音乐这种。它是将皮肤包下载到本地，皮肤包其实是个APK。

换肤包括替换图片资源、布局颜色、字体、文字颜色、状态栏和导航栏颜色。

可以看到inflate会返回具体的View对象出去，那么我们的关注焦点就放在createViewFromTag中了

inflate最终调用了createViewFromTag方法来创建View,在这之中用到了factory，如果factory存在就用factory创建对象，如果不存在就由系统自己去创建。我们只需要实现我们的Factory然后设置给mFactory2就可以采集到所有的View了，这里是一个Hook点。

当我们采集完了需要换肤的view，下一步就是加载皮肤包资源。当我们拿到当前View的资源名称时就会先去皮肤插件中的资源文件里找

Android加载资源的流程图：

所以我们复写了Factory的onCreateView之后，就可以不通过系统层而是自己截获从xml映射的View进行相关View创建的操作，包括对View的属性进行设置（比如背景色，字体大小，颜色等）以实现换肤的效果。如果onCreateView返回null的话，会将创建View的操作交给Activity默认实现的Factory的onCreateView处理。

将属性符合的view保存起来

加载皮肤包需要我们动态获取网络下载的皮肤包资源，问题是我们如何加载皮肤包中的资源

Android访问资源使用的是Resources这个类，但是程序里面通过getContext获取到的Resources实例实际上是对应程序本来的资源的实例，也就是说这个实例只能加载app里面的资源，想要加载皮肤包里面的就不行了

自己构造一个Resources（这个Resources指向的资源就是我们的皮肤包）

构造一个指向皮肤包的AssetManager，但是这个AssetManager是不能直接new出来的，这里就使用反射来实例化了

AssetManager有一个addAssetPath方法可以指定资源的位置，可惜这个也只能用反射来调用

换肤的核心操作就是替换资源，这里采用观察者模式，被观察者是我们的换肤管理类SkinManager，观察者是我们之前缓存的每个页面的LayoutInflater.Factory2

applySkin()在去遍历每个factory缓存的需要换肤的view，调用他们的换肤方法

这里能看到换肤的实现方式就是根据原始资源Id来获取皮肤包的资源Id，从而加载资源。因此我们要保证app和皮肤包的资源名称一致

其实很简单，就是我们重新建立一个项目（这个项目里面的资源名字和需要换肤的项目的资源名字是对应的就可以），记住我们是通过名字去获取资源，不是id

1. 将换肤的资源文件添加到res文件下，无java文件