[回目录]
五、分辨率与横竖屏
我花费了巨多的时间来处理DPI和分辨率的问题，说出来可能大家都不信，1/3到1/4的总开发时间，都是在处理DPI和分辨率相关的问题，这实在令人费解，因为当今的Android和IOS开发几乎不用考虑这些问题，Windows Phone 7和Windows8也不用，我怎么如此折腾？
5.1，花点篇幅讲讲“分辨率”
分辨率（Resolution）在不同时候指的可能是不同的东西，有时候指的是屏幕像素，有的时候指的是点的密度。如“1024*768”，这指的是水平像素和垂直像素，而“96DPI”，则是点的密度（Dots Per Inch），DPI越高，点的密度越大。那么Windows的DPI设置是什么意思？
（Windows控制面板中的DPI设置，通过“控制面板 - 外观和个性化 - 显示 - 设置自定义文本大小(DPI)”打开）
默认情况下，Windows认为显示器的DPI是96，一个9号的宋体字，按照这个DPI去渲染，结果是这样（放大10倍）：
这个“宋”字使用了11*12个点绘制而成，在一个普通显示器下显示这个字应该是OK的，但试想现在新出了一款显示器DPI特别高，点的密度特大，点间距特小，如果这个“宋”字还是使用11*12个点绘制出来的话，那就显得太小了，眼睛看起来费劲，所以Windows提供了这么一个调整DPI的选项，允许你放大Windows界面的元素，例如：如果你把DPI调整到192，那么，这个“宋”字将会这样显示（放大10倍）：
它变成了使用28*29个点去绘制，奇怪了，为什么不是22*24？这是因为我把margin去掉了，理论上确实应该是长宽各两倍的关系，相信大家明白。BTW：当你把自己电脑的DPI调整到192之后，你发现不光是字体变了，滚动条，菜单等很多Windows元素都变了，但有些又没变，有些则显示很怪异，这是为什么？因为并非所有的软件都考虑到了DPI，许多软件都只是按照默认的DPI去设计，所以我认为目前让Windows使用更高的DPI的显示器是没有必要的，因为软件层面的支持不足啊！那么为什么最新的视网膜屏的Macbook Pro没这个问题？——那是因为Apple的工程师和设计师在其背后做了许多工作量大得你根本无法想象的的工作，但即便如此，还是有些软件对视网膜屏支持不好，用多了你就会发现了。
所以，DPI这个选项的意图是：使得在不同的DPI的显示器中，同样逻辑尺寸的一个界面元素显示出来的物理尺寸一致。准确说基本一致，举个简单的例子：17寸标屏的液晶显示器（现在绝版了）的标准分辨率是1280*1024，而19寸的标屏液晶（也绝版了）显示器也是这个分辨率，那你认为谁的DPI更高？对Windows来说一样，默认都认为是96DPI，而物理DPI的话当然是17寸的高一点，所以显示同样逻辑尺寸的界面元素时，17寸的显示器看到的要小一点，（貌似我在讲废话）要处理这点细微的差距实在太繁琐了，所以就近似吧，都把他们认为是96DPI即可。
最后再提一下PPI（Pixels Per Inch），其实跟DPI是一回事，只不过DPI用在打印机领域上较多，而Windows一直“DPI，DPI”地叫，我也跟着DPI了，大家知道打印机的DPI是多少么？现在主流打印机基本都支持2880 DPI的打印模式，其点的密度比显示器大太多太多了……
5.2，Windows Mobile的DPI
Windows Mobile有3种DPI（其实可能还不止，但我这里说我遇到过的），分别是：96、128和192，和像素分辨率通常有以下关系：
| 屏幕分辨率 | DPI |
| 240*320 | 96 |
| 480*640 | 192 |
| 240*240 | 96 |
| 480*480 | 192 |
| 480*800 | 192 |
| 320*320 | 128 |
这是参考表，并非绝对，事实上，Windows Mobile的DPI是可以在ROM定制的时候配置的。
同样一张贴图，在96DPI的机器上正常，在192DPI的机器上就太小了；反过来，在192DPI机器上正常，在96DPI机器上就太小了——这就是我要解决的问题。
大家说怎么办？
一个解决方案是拉伸/压缩图片，但坏处有三个：
- 走样。图片的拉伸/压缩会带来走样，实际使用起来是很影响美观的。
- 资源浪费。如果96DPI的机器使用了为192DPI机器准备的贴图的话，那是极大的浪费，很可能带来资源枯竭的问题。（这个后面会提到）
- 效率低下。拉伸/压缩比常规直接贴图要耗费更多的CPU，可能带来用户界面响应的迟缓和更高的电耗。
我选择了最繁琐的解决方法：为不同的分辨率准备不同的3套图！
（不同DPI所使用的不同的贴图）
如果你是专业美工，也许你能看出来，192DPI这个图最完美，而96DPI和128DPI这两个貌似有些毛糙，原因嘛，悄悄告诉你：由于我需要三套图这个苛刻的要求，公司的美工对我意见很大……所以默认皮肤里很多图都是我自己直接用Photoshop的调整大小调出来的，从这反应出了我技术以外的相当不足的一面……
5.3，横屏与竖屏
做电脑的软件很少需要考虑横竖屏的问题，但手机就得考虑了，在开发SoSoPi的过程中，我曾经接触过一个山寨机，只有横屏的，没办法把它调整为竖屏的，这种奇葩Android估计也不会有吧，可Windows Mobile是“一切皆有可能啊”。横竖屏问题对于软件来说是一个分辨率调整的自适应问题，或者叫“重新布局”吧。480*800的分辨率变味了800*480，界面上的元素得重新调整吧，这可真不是一件容易的事情。大家看看SoSoPi的首页自适应方法：
（首页的横竖屏自适应）
从上图上看得出来，你至少需要面对的问题是背景图的“自适应”，如果你是使用了480*800的背景图，那在竖屏的时候是没问题的，但到了横屏，恐怕只能显示480*480的大小，右边的一大块区域它填充不到，解决方法我想过很多，包括拉伸图片，旋转图片等，但效果都不理想，最后的决定是：使用800*800的图片，这样无论横屏竖屏都能填充满了，而对美工来说稍微增加了一点难度，他得测试一张背景图片在横屏和竖屏下的不同的效果，用户如果需要更改图片的话，对图片的选择也有一定要求：如果屏幕长边的长度为N，那么就最好选择N*N的图片，比如480*640的屏幕，就选择640*640的图片为佳。
背景图仅仅是其中一方面，我还得考虑很多很多的东西，界面元素是完全重新布局！这意味着我要做两套布局来适应不同的屏幕状态，可能表面上看看不觉得太难，但做起来发觉工作量还真大，界面上的许多元素不能直接指定坐标了，而是得按照百分比来计算坐标，在整个界面的绘制代码里，通篇都充满着“横屏”和“竖屏”的判断。而界面元素的对齐，有些是从顶部开始，有些是从底部开始，有些是对别的元素取相对坐标，有些则是取AB两个元素之间的靠近A元素的30%的位置……
（这是日历的横竖屏对比图）
除了麻烦之外，这里面还有一个大问题。如果你看过前一篇关于贴图的文章，你会想起图片的缓存，我为了加快贴图速度，使用了一些空间换时间的算法，也就是缓存，现在回想一下，由于横竖屏的切换，我的一些缓存是不是也要跟着更新？——是的。比如之前我作了一个480*800的图片缓存区，现在变成横屏后我得调整为800*480的，怎么调整？把之前的删了，重新创建。需要特别说明一下的是，这个动作很容易导致系统崩溃，因为Windows Mobile的资源十分有限，内存管理能力也远不及Windows，重建图片缓存就是一个很耗资源的动作。对这个问题，直到最后我都没有什么好的解决方法。
5.4，现在还有这些问题吗？
无限今日并不存在这些问题，因为无限今日的皮肤总是针对某个分辨率（DPI及像素点）去设计的，用户会根据自己的手机的实际情况去选择不同的皮肤（横竖屏的问题依然存在）。而现在的iPhone的APP开发，存在这些问题吗？大体上也不存在，因为iOS的绘制使用的是设备无关的单位，其实现在的几乎所有的UI开发（包括微软体系）都是偏向于使用设备无关单位了，比如“厘米”和“英寸”这些单位，这样就能确保在不同DPI的显示设备上显示出来的物理尺寸基本一致，即便使用点，也是设备无关的点，而不是直接对应到屏幕上的像素去，所以我们还可以使用浮点数来表示点的大小，比如线条的粗细为0.7个点，绘制出来的0.7个点粗细的线条给你感觉确实比一个点粗细的线还“细”，因为底层图形库在必要的时候会把它渲染的颜色改得更浅一些，总之你不需要再操心它具体用什么颜色绘制了几个像素了；横竖屏切换呢？基本上不用考虑，仅仅在你的App需要特别地用到横屏或竖屏的时候才需要考虑，比如查看一张横向的照片的时候允许用户把手机横过来看，而其它大多数时候，你可以把你的设计固定为横屏或竖屏。
最后留个问题在这里，各位看看iPhone的“桌面”，你来弄个横屏怎么弄？（实际上不越狱的话，iPhone不允许桌面横屏，但我假设可以，嗯，考考你们的设计能力）
[回目录]