近来出了很多关于Android适配的文章和第三方库，可以说已经是一波潮流了，甚至上了Github Trending；它们的原理都是一样的，即来自于今日头条的技术分享： 一种极低成本的Android屏幕适配方式。更深入一点，其本质就是缩放，也有人叫做百分比适配，更早也有库实现这个AutoLayout。关于这些库，我隐隐觉得有问题，但要说为什么又说不清楚。理了一个礼拜的思路，大概整理出以下几个点。
首先，这种缩放式的适配替代了DP方式，但没有解决DP要解决的问题。我们知道实际显示大小和效果是看像素px和ppi的，那为什么要弄出一个dp和dpi呢？这起初就是为了可以让同样的控件在不同的设备上物理尺寸看起来一样，不会被“缩放；实际上这里已经进行了缩放了（以mdpi为准，xhdpi就是mdpi的1.5倍）；所以我们用dp就不需要进行缩放了。在中文的Android guide页面，我们还可以看到这个提示（支持多种屏幕，英文版已经修改，中文版还是旧的）：
虽然系统为使您的应用适用于不同的屏幕，会进行缩放和大小调整，但您应针对不同的屏幕尺寸和密度优化应用。这样可以最大程度优化所有设备上的用户体验，用户会 认为您的应用实际上是专为他们的设备而设计，而不是简单地拉伸以适应其设备屏幕。
值得一说的是，dp这种缩放为了兼容不同屏幕，是倍数的缩放，而不是简单的拉伸。我的理解上效果比今日头条的拉伸适配更通用的。通过DP缩放，市面上的手机现在宽的dp值一般介于320dp到411dp中间。前面提到的文章和库效果看起来都不错，我理解是现在测试的例子是取了中间值360dp或375dp进行缩放，缩放比例不大的缘故。
其次，这种适配只是粗暴的缩放了，并没有考虑图片资源的问题。使用DP做适配的时候，我们可以通过各种drawable-xxxdpi指定图片资源，这些图片和指定好的控件大小也是刚好适配的，举个例子，一个用户头像大小是40dp*40dp，设计一般会给一个默认图，这个默认图的不同尺寸我们可以放在drawable-mdpi(40px*40px),drawable-xhdpi(60px*60px),drawable-xxhdpi(80px*80px)几个文件夹，这些尺寸和控件在不同dpi设备上展示实际像素大小是相同的。我并没有看到现在这种缩放怎么解决这个问题。
再说设计，合格的设计本身就处理了不同设备的兼容问题，这种适配方式容易走入误区。现在设计一般出图的时候是以720px或750px或1080px作为原型大小宽的大小，这里已经默认用了Android的DP概念了（720px是750px是作为xhdpi，1080px是xxhdpi）。一个设计图或者原型图，展示的是页面的显示逻辑；这种逻辑不会是从1080p切换到720p或768p就不行。包括设计内在的margin或者padding，不会因为这种变化就需要进行调整。控件大小也是如此。如下面图片所示，一个微信头像在1080px设计图上展示的是80px（40dp）, 同一个设计师就算用720px作图导出来的也回事40dp。因为这个40dp不是设计师凭空而来的。适配时如果安装设计的思路还原逻辑（头像在左侧，标题和时间在头像右侧，距离头像15dp，具体金额和总值在右侧）；这样做出来的布局是可以同时适配320dp到411dp任意宽度的屏幕的。
理解了设计的逻辑，适配起来并不麻烦，使用DP就够了。同样是上面的图片，我们看底部的tab切换（红包明细/其他明细）。如果我们认为一整个tab控件的宽是308dp，就这样写上去了，会出现什么问题？原设计图的宽是360dp的，两边各留出了26dp。直接写308dp在360dp上表现是没有问题的，但是在320dp的设备上两边就只会各自留出6dp，同样地在411dp的设备上两边就会留出51.5dp。这样的适配效果和设计图对比一定看出来一个太窄，一个太宽。但如果两边各自留出26dp，然后控件本身match_parent呢？从视觉上看应该和设计图是差不多的这两种适配相比没有哪种更麻烦，适配效果好坏只看有没有清楚的认识到设计的逻辑，是不是按照设计的思路做。
Android手机屏幕的大小基本介于320dp到411dp之间（平板不在此列）；设计图也就那几种规格，换算过来720p和1080p的是360dp，750*1334是375dp。按照设计的内在逻辑去适配，使用DP也并不复杂，效果也是最佳的。虽然这里只说手机，但如果按照这样适配，就算是在平板上，显示效果也是可以的，而不是一个拉伸的界面。