Android适配的一点心得

        做Android屏幕适配和UI布局这种东西，其实很烦人，并且很多时候都是在做不同的参数调试，对自身代码技术的增长并没有太多的用处，但是任何一件完整的事情都是有次要、重要之分，一款app产品更是如此，我们都不想一个技术经验机械重复使用多次，我们都想能够快速地成长，那么就需要多想，多思考，多动手。

        最近在做项目上的pad版的适配，提前已经看过凯子哥有关于屏幕适配的视频教程，讲得真的是非常棒，面面俱到，把所有情况都涉猎了，并且凯子哥有一篇适配博客，写得也是非常棒，地址如下：

http://blog.csdn.net/zhaokaiqiang1992/article/details/45419023 ，在此基础之上，总结自己的一点点心得：   

        个人感觉，Android 适配集中在以下四大部分：

一 分辨率的适配

     mdpi   hdpi    xhdpi   xxhdip              

     为了适配不同分辨率，会在相应的drawble文件夹下放入适当的图片，但是这里就有一个问题，这样就会使app的大小很大，而且有时候可能你一个人开发没有专业的UI出图，这个时候是可以在drawable 下放一套资源，无论什么dpi都会默认使用这个文件夹下的图片，如果xxhdpi的屏幕没有在xxhdip的drawable中找到适合自己屏幕的图片，根据谷歌文档上介绍，安卓系统根据自己的一套适配算法，会去找比它小一级的分辨率的图片资源，也就是xhdpi，去进行相应的计算转换来显示在屏幕上，一直找到 drawble默认的图片文件夹，在凯子哥的视频教程中我们会看到这样的转换是有代价的，也就是相差越大，消耗内存就会越大，那么你加载图的时候就要注意OOM了。

      下面是谷歌文档的原文，大家随意感受一下：

        When selecting resources based on the screen size qualifiers, the system will use resources designed for a screen smaller than the current screen if there are no resources that better match (for example, a large-size screen will use normal-size screen resources if necessary). However, if the only available resources are  larger than the current screen, the system will  not  use them and your application will crash if no other resources match the device configuration (for example, if all layout resources are tagged with the  xlarge  qualifier, but the device is a normal-size screen)

     说到图片的加载，就不得不说OOM，就不得不说图片缓存框架，Universal-image-loader, Fresco,Picasso , 其实只是很简单的用过第一个框架，并自己实现了一下lruCache 和disLrucache结合的图片缓存，以后如果有机会可以读读相关框架源码，了解它们的使用场景，好像跑题了。。

 二 尺寸大小的适配

       大屏手机用得爽，可是从小手机到大手机，就意味长宽尺寸的变化，就意味着需要不同的尺度大小，就算你不用大手机，那么手机横竖屏的转换总是会有的吧，这个时候整个界面也会变得哦，当然你跟我说将方向设死了，只能竖屏，那我没话说，其实为了省事，应该很多app都是这么做的。但是为了适配Pad, 那是必须要重新设计界面的。凯子哥里面有介绍对于pad使用fragment的一些适配方法。

        对于尺寸的适配，只需要在 layout-swXXXdp的文件中对相应宽度的屏幕重写layout布局即可，系统可以根据当前屏幕去加载对应的尺寸布局，那么问题又来了，这样 320dp, 360dp,  410dp ,600dp  720dp 可能都要写布局了，好麻烦。。有一个能够稍微缓解一下的方法，就是用 values-swXXXdp,这就是为什么你在布局定义大小的时候，一般如果你明晃晃地写一个数字上面，比如56dp,一般会黄线提示你用资源来引用，@dimens/values ,  如果在不同的尺寸下，布局没有什么大变化，只是间隔等变大等，就可以直接用values来定义相同名字，在不同尺寸下系统去取不同的值，这样你就不用重写layout了，因为尺寸的等比例原因，都可以像凯子哥那样用代码生成一系列的dimens文件。自动化就是省事，当然如果是布局变了，那还老老实实重写吧。

           .9图片的使用，太省心了，点几个点，这个图片就能在任何场合下用，不过就是注意在新版的AS中，.9图片要符合一定的规则，它的宽和高都必须定义才行，否则会报错。

三 自定义view的时候的适配

     因为是自定义的view，所以布局上的元素需要自己进行绘制，而没有layout帮你在不同的分辨率和尺寸上去确定比例，你要将一张图片画在屏幕上，你需要它呈现100dp*100dp ,图片本身有自己的大小，你要将其进行压缩，还有其他一系列的图片，都需要进行压缩，那么你要计算一个比例值：

            int density = getRecources().getDisplayMetrics().denstiyDpi;  // 当前屏幕的密度

            int scale =   getRecources().getDisplayMetrics().denstiy; //   1dp = scale * px

           那么你要压缩图片的时候，需要 的宽和高是   100 / scale  ，这样画出的图片在任何屏幕下都是 100 dp * 100 dp 了  。 来个详细版的，可以进行传值的“

           将步骤分解， 其具体如下：          

             scale  =   wantWidth / ( bmp.getWidth *  dm.density * 1.0f) 

             width = bmp.getWidth() * scale  ;        

             height = bmp.getHeight() * scale;

             Bitmap result =  Bitmap.createScaledBitmap(bmp, width, height, true)       

       如果你是要在一个不同的位置上进行绘制图形，那么你可以使用values-swXXXdp中去取值的方法来进行设定。

四 版本的适配

       Android 系统本身也在迭代，从1.0 到 6.0， 大大小小的版本，也有了新的特效，新的api, 在这种情况下，就需要我们在每次新的版本发布时，第一时间去了解新版本的特效，看是否在我们的app上有一些冲突，比如  Android 6 有关于 permission方面的 问题，需要一定程度上修改代码，否则一些权限获得不到会使app崩溃，当然 谷歌也充分考虑了这些问题，如果你sdk 版本依然是在 22以下，权限依然会按照以前版本的来管理，但是要尽量升级，去适应新的版本。