Android屏幕适配全攻略2-我想跟美工谈谈

[TOC]

前言

俗话说完事开头难

对一个Android开发而言，项目正式开发的第一步就是拿到图（高清图和具体切图）。第一步至关重要，UI图做得好、标准高，后面的开发更倾向于按照高的标准去要求自己，开了个好头。UI本身就做得很烂，很多不合理的设计交互，切图大小不一，格式紊乱，粗制劣造，做出来的app质量可想而知。

给美工的建议

基本原则： 符合规范

所谓规范主要是，符合美工的美学常识规范，和Google官方设计规范，我在项目中遇到的问题，概括起来包括以下几个方面：

单位规范

android屏幕有自己的基本单位。使用dp为单位切图，android开发做起来会得心应手。当然使用px为单位已经是行业惯例了，如果实在改不了，并且你还不清楚他们之间的换算关系，可以参考我的上一篇博文-Android屏幕适配全攻略1-从dp sp px说起。这里要说的是，让设计和美工清楚的知道为什么要使用dp这个单位，是为了去解决Android屏幕格式的多样化问题。清楚了这个概念和具体计算以后，切图和设计的时候才会更加注意，更早的去处理屏幕适配的问题，而不是到开发甚至测试和预发布的时候才想起来处理这个问题，项目经验告诉我们，尽早的发现问题，可以减少项目风险。

字体规范

主要指字体样式和大小的规范性，一般字体样式我们都采用默认字体，如果实在有特殊需求，需要在app里面导入

字体包。大小规范是指： 1.使用sp为单位标出。2.使用常用单位，并且为偶数（奇数除以2会产生小数，强制转型会产生误差）。在dimens文件中这样定义字体引用：

<dimen name="font_size_tiny">10sp</dimen>

<dimen name="font_size_small">12sp</dimen>

<dimen name="font_size_normal">14sp</dimen>

<dimen name="font_size_normal_high">16sp</dimen>

<dimen name="font_size_large">18sp</dimen>

<dimen name="font_size_large_high">20sp</dimen>

<dimen name="font_size_xlarge_high">22sp</dimen>

分别对应超小号、小号、正常号、偏大号、大号、超大号、特大号，一般app开发而言这7号字体基本够用了，然后叫美工定义字体的时候按照标准定义，就像写word文档的时候选择小四，四号，小五这样。这样有个好处就是以后修改起来特别方便，比如你觉得整个app字体偏小，不需要你去挨个挨个的控件去改，直接修改下dimens文件中引用的字体就好了。交流起来也更方便，不用说14sp，15sp这种抽象数值，而是告诉他这是一个普通字体类型，诸多好处项目开发的时候慢慢体会。

我近期的项目美工还是按照px切图，自己按照他切图的手机列出一张对应表，按照表的标注找到对应的具体字体大小值。

如：切图的手机为442ppi，那么列出对应关系 ，找到他的px值，直接按照查表法，找到对应的数值填进去。

SP	FONT	PX
10	tiny	26
12	small	32
14	normal	37
16	normal high	42
18	large	48
20	large high	53
22	xlarge	58

颜色规范

一般美工标注颜色就是把设计发过来的图，用取色器吸一下，然后写到切图上。这个工作没技术含量，也突出不了工作的重要性。而且更可能会造成问题：取色器在不同电脑和图片位置取到的定义同一颜色色值不一致，虽然这种不一致不容易被肉眼所发现（例如定义一个亮蓝色，取值为：#ff239ff2，有的地方取值误差变成：#ff239ff8,你很难发现他们的差别，但是他们总让人心里觉得不舒服），号称拥有像素眼的设计师犯这种错误不应该。

一个app设计师为了风格统一，不会定义稀奇古怪的颜色，主色调，次色调，字体色调，导航色调就那么几种，为什么不把他们统一列出来在手机上对比下UI效果后，取一个确定的值。所有页面的颜色取值不要用取色器吸，对一下取色表，直接指定是哪一种色值就行了，规范统一。

这样开发直接在color.xml文件中定义这些值：

<color name="gray">#FFA9A9A9</color>
<color name="gray_deep">#cc6977d2</color>
<color name="gray_little">#999999</color>
<color name="gray_green">#d4d4d4</color>
<color name="hint">#B3B8E5</color>
<color name="white">#ffffff</color>
<color name="white_little">#f4f4f4</color>
<color name="black">#000000</color>
<color name="brown">#A67D3D</color>
<color name="black_input_bg">#4C4F53</color>
<color name="blue_little">#1dabf0</color>
<color name="blue_tony">#01a0f3</color>
<color name="red_text_state">#cd3013</color>
<color name="red_remind">#e90000</color>
<color name="green_little">#73D152</color>
<color name="dlg_lite_blue">#ff359ff2</color>

使用的时候直接引用这些值

android:text="@string/common_company_name"
android:textColor="@android:color/white"
android:textSize="@dimen/font_size_xlarge"

而不是这样：

android:text="公司名称"
android:textColor="#ffffff"
android:textSize="22sp"

这样，开发在实际使用的时候有个明确的颜色概念，而不是具体的、抽线的一个色值，方便交流和记忆。如果后面发生意外，比如：反映字体色彩偏暗，你直接修改引用的色值就可以实现全局修改，更不会出现取色器不准造成的不良后果，优点多多。

对了，说到颜色，美工记住所有纯色系的图片，不用切图，程序可以自己实现，减少图片数量和大小，可以极大的减少apk的体积。

切图的规范

经历过就会明白切图是个细致活儿，图标大小一定要统一。同一类图如果是居中显示，那么这一类的图标，都要居中显示，形状是规则正方形，不要留下白边。如下面这种不规则切图，会让开发的过程变得异常的恼火。



另外就是创建多套图的适配，这个美工一般都知道，需要为Android创造多套图，但是现在资料更新不及时以前主流包扩mdpi，hdpi，xhpi，xxhpi。现在出现了1080p的xxxhpi屏幕没人切图适配，我们知道高分屏的图片放倒低分屏，系统会自动对他进行压缩，从而达到一个较满意的效果（但是系统压缩会消耗系统资源，如果不考虑卡顿和大图片内存溢出的情况，一般创造一套超高清图就可以适配其他低分屏的手机）。但是如果低分屏的图片拉伸到高分大屏上面，效果就实在惨不忍睹，所以如果实在是忙不过来，可以先切一套高分辨率的图用着。

还有就是尽量图标和背景分离，复杂场景分离成简单icon，不要切图一整块的切出来，这样在一些偏窄或者偏宽的屏幕上，图标容易被挤压变形，把图标分离，让程序员自己手动填充进去。

使用.9.PNG

使用draw9patch神器下载地址，具体怎么使用可以借助搜索引擎搜索关键词9png，有很多教程。 9png的目的是为了解决Android应用在不同屏幕上，很多控件的切图文件在被放大拉伸后，边角会模糊失真的情况。这时候我们可以通过定义图片可拉伸区域，来保证边角不被拉伸；定义图片可填充区域，来指定文字的显示区域，保证文字显示框按规范拉伸。使用口诀：上下左右，由少到多（拉伸区域往往是点两个点，因为拉伸10个像素和1个像素区别不大。但是填充区域是必须是一段距离，直观的理解就是从点变成了线，也就是从少变多）。需要注意的一点是，有时候文字的填充区域不应该是绝对的居中，而是相对图片显示区域的居中。如：




。

另外要注意的一点是，app被打包为apk发布的时候，图片的9png样式会被去掉，你看到的是没有点出9png的图片原型的样子。通过把apk重命名为zip，然后解压缩后找到对应文件，可以验证这一点。

出图格式

1.使用PNG24+jpg保存，jpg主要用来保存app启动图，引导图片这种比较大的图片。其他图标，背景色使用PNG24保存，不要用PNG8保存，会造成色差。

2.尽可能在保证图片质量的基础上压缩图片体积，这里介绍一个好用的第三方工具智图



原图大小1128KB，压缩后的WebP质量为原图的75%，左边为原图右边为webp图片，通过比较，几乎看不出来两张图的差别，同时压缩后的webp图片大小为123KB。这样过后，可以极大的压缩我们app的体积，而且iOS也支持webp这种图片格式。webp在Android代码中使用，需要借助jni层实现，具体实现请参考我的Blog。

当然美工拿到的图，也是从设计师和产品经理哪儿给出来的高清，有些设计和体验上的东西他们也无能为力。我们还得往上追，下一篇我想和产品经理谈谈。