RBAC（Role-Based Access Control，基于角色的访问控制），就是用户通过角色与权限进行关联。简单地说，一个用户拥有若干角色，每一个角色拥有若干权限。这样，就构造成“用户-角色-权限”的授权模型。在这种模型中，用户与角色之间，角色与权限之间，一般者是多对多的关系。（如下图）

角色是什么？可以理解为一定数量的权限的集合，权限的载体。例如：一个论坛系统，“超级管理员”、“版主”都是角色。版主可管理版内的帖子、可管理版内的用户等，这些是权限。要给某个用户授予这些权限，不需要直接将权限授予用户，可将“版主”这个角色赋予该用户。

当用户的数量非常大时，要给系统每个用户逐一授权（授角色），是件非常烦琐的事情。这时，就需要给用户分组，每个用户组内有多个用户。除了可给用户授权外，还可以给用户组授权。这样一来，用户拥有的所有权限，就是用户个人拥有的权限与该用户所在用户组拥有的权限之和。（下图为用户组、用户与角色三者的关联关系）

在应用系统中，权限表现成什么？对功能模块的操作，对上传文件的删改，菜单的访问，甚至页面上某个按钮、某个图片的可见性控制，都可属于权限的范畴。有些权限设计，会把功能操作作为一类，而把文件、菜单、页面元素等作为另一类，这样构成“用户-角色-权限-资源”的授权模型。而在做数据表建模时，可把功能操作和资源统一管理，也就是都直接与权限表进行关联，这样可能更具便捷性和易扩展性。（见下图）

请留意权限表中有一列“权限类型”，我们根据它的取值来区分是哪一类权限，如“MENU”表示菜单的访问权限、“OPERATION”表示功能模块的操作权限、“FILE”表示文件的修改权限、“ELEMENT”表示页面元素的可见性控制等。

这样设计的好处有二。其一，不需要区分哪些是权限操作，哪些是资源，（实际上，有时候也不好区分，如菜单，把它理解为资源呢还是功能模块权限呢？）。其二，方便扩展，当系统要对新的东西进行权限控制时，我只需要建立一个新的关联表“权限XX关联表”，并确定这类权限的权限类型字符串。

这里要注意的是，权限表与权限菜单关联表、权限菜单关联表与菜单表都是一对一的关系。（文件、页面权限点、功能操作等同理）。也就是每添加一个菜单，就得同时往这三个表中各插入一条记录。这样，可以不需要权限菜单关联表，让权限表与菜单表直接关联，此时，须在权限表中新增一列用来保存菜单的ID，权限表通过“权限类型”和这个ID来区分是种类型下的哪条记录。

到这里，RBAC权限模型的扩展模型的完整设计图如下：

随着系统的日益庞大，为了方便管理，可引入角色组对角色进行分类管理，跟用户组不同，角色组不参与授权。例如：某电网系统的权限管理模块中，角色就是挂在区局下，而区局在这里可当作角色组，它不参于权限分配。另外，为方便上面各主表自身的管理与查找，可采用树型结构，如菜单树、功能树等，当然这些可不需要参于权限分配。

以上，是从基本的RBAC模型进行了扩展，具体的设计要根据项目业务的需要作调整。欢迎大家提出批评意见！

在一个互联网公司的工作流程中，产品经理（主要指偏向产品设计的产品人员）和交互设计师是这个流水线上最起点的环节，也是关系最暧昧的两个环节。说其暧昧，是因为在很多互联网公司里面，这两个环节所做的事情是有重合的，这就意味着，他们或许也是整个流程中合作最紧密的两个环节。

相对比之下，产品经理更关注的是产品的内部逻辑、操作流程、策略等；而交互设计师更关注的是产品的易用性、流畅度和操作感受。总的来看，似乎可以认为，产品经理是从一个更加宏观的角度去设计产品，而交互设计师，则是从更多的细节出发，去提升用户体验。这两种不同的视角决定了只有产品经理和交互设计师密切配合，深入沟通，才能够最高效最合理的将产品策略转化为产品原型，从而为流水线的后面环节提供精确的参考资料。

下面以人人网广告平台的一些产品和交互细节为例，使用对话的形式来分享一下我个人在做交互设计过程中的一些体会和想法。入门级文章，高手请绕行。

在广告平台其中一个投放系统中，有一个产品需求，是要根据广告受众所在的地区做广告的定向投放。也就是说，可以控制广告只展示给固定地域的受众。这就意味着，需要设计一个「区域选择器」，供用户选择区域。产品经理的原始需求是这样的：

产品经理：“我们这次的投放系统需要设计一个区域选择器，就是让用户选择广告定向投放的区域的。可以精确到城市，可以多选。另外，‘区域’作为一个投放广告的限制条件，如果用户没有选择任何选项，那就代表用户忽略该条件，则该广告会面向全国投放。”

交互设计师：“哦。”

产品经理：“嗯，我能够想到的这个东西的原型，可以提供两个下拉框，让用户分别选择省和城市。当用户在第一个下拉框里面选定了省以后，第二个下拉框中会显示该省下面的地级市。我做了一个简单的框图，大家看一下。”

产品经理：“大概就是这个样子。每选定一个城市，点击后面的添加按钮，可以将该城市添加到下面的列表中。同时，如果点击已经添加的城市名称后面的「删除」链接，则会将该城市从已选列表抹去。”

交互设计师：“等一下，我有一个问题。按照产品的策略，如果用户一个城市都不选，那么就会默认投放全国。但是这个概念很难表达给用户，比如说，如果在「区域选择器」旁边放提示，估计没有多少人会注意到。”

产品经理：“一个都没选，就是等于忽略条件啊。因为这些都是限制条件。”

交互设计师：“问题是用户很难意识到是这样。在中国人的观念中，大家都是觉得，选上的，是我要的。但是大家没有「不选就等于全要」这种思维习惯。”

交互设计师：“我觉得可以这样。我们在现在的「区域选择器」上面放两个单选按钮。一个叫「全国」，另一个叫做「指定」。打开页面时，默认选中「全国」项，并隐藏「区域选择器」。只有用户选择「指定」项时，区域选择器才会出现。这样表达就很明确了，你不是「全国」就是「指定」。”

产品经理：“哦~听起来不错。试试。”

于是得到了下面这个版本的原型图：

交互设计师：“嗯，我想，现在这个版本已经基本上从界面的层面解决了全国投放的选项问题，我想，用户应该不会因为不知道怎么选而卡在这里了。”

交互设计师：“我看下一步，需要对一些关键的元素做一定的视觉设计，以便于引导用户操作。比如「添加」按钮，应该更明显些。我觉得可以请UI设计师出一个简单版本的UI了。”

产品经理：“稍等一下，我看咱们还是把细节再讨论清楚一些再去找UI吧。比如，字的颜色啊什么的都没定呢。而且，我觉得选中的区域中，每个城市名称后面都跟着一个删除链接，很奇怪。”

交互设计师：“嗯。的确。我的想法是这样，字的颜色，就用黑色吧，或者是深一些的灰色也行。虽然从视觉设计的角度来看，视觉设计师觉得稍浅一些的灰色比较养眼，可能黑色太‘抢’。但是咱们的系统毕竟是给人用的，灰色的话，可能会让人误认为这些选项是不可操作的。你看如何？”

产品经理：“同意。”

交互设计师：“关于已经选中的区域列表。我看可以把「删除」链接换成×，事实上，用户对于×这种符号比汉字更敏感。你看，大家不论是用Windows还是Mac，关闭窗口的时候都是×，早就习惯了。另外，为了让所选定的城市名称看起来是一个整体，并且跟其他城市名称区分开。我看，可以给每一个城市加上背景色，每个城市一个色块，这样也一目了然。”

产品经理：“颜色呢？”

交互设计师：“蓝色吧，人人网都是蓝色的风格。”

产品经理：“ok”

于是，配合UI设计师，得到了下面的界面：

产品经理：“我看现在这个地方已经基本上成型了。咱们也已经讨论很很久了。该问问别人的意见。”

———-时间分割线———-

产品经理：“Hi~ 各位。我收集了一些内部测试的意见。有用户提出，搞不太清楚两个下拉菜单和「添加」按钮之间的关系。”

交互设计师：“什么意思？”

产品经理：“就是说，有人意识不到选完了省，选完了城市以后，还得点「添加」。他们觉得，选完了就完事了。”

交互设计师：“晕。”

交互设计师：“可能是已选列表框在空着的时候长得太秀气了，大家没意识到它是用来装东西的。”

交互设计师：“好吧，我有两个方案。1、把「添加」按钮上面加一个向下的箭头。指向已选列表框。2、在已选列表空着的时候，添加一条提示语，来提示用户他并没有完成区域选择操作。”

产品经理：“提示语那个，你的意思是说，当用户添加了城市以后，会自动消失是吧？”

交互设计师：“是的。”

产品经理：“我觉得加提示吧。感觉放箭头有点儿傻。”

交互设计师：“嗯，而且，可能放了箭头以后，用户依然不知所云。”

产品经理：“那提示语怎么说呢？您尚未添加任何区域，请选定城市后，点击上面的「添加」按钮，该城市会被添加到…”

交互设计师：“停！太长了，大部分人不会认真看完的。”

产品经理：“的确…”

交互设计师：“我看就一句话就可以。写‘您尚未添加任何区域。’”

交互设计师：“你看。下拉列表后面的按钮叫「添加」。提示中又明确的传达出了尚未「添加」的状态。这样既说明了这个框框是用来放东西的，又可以告诉用户，这个东西是可以选多个的。因为「添加」的概念就是一个一个往里面放。如果只能放一个，那应该叫「选择」。”

产品经理：“顶。”

交互设计师：“而且，我觉得这个控件最初的原型你设计的不错。嗯，用户只要成功的进行一次操作，以后就可以非常高效的进行操作了。这个东西的学习成本和认知成本都比较低。”

产品经理：“oh,yeah~”

那么，现在的UI是这样的：

产品经理：“哎，对了。话说，我最开始的策略是，用户如果不选，相当于全选，要全国投放的。你说如果用户选了「指定」，但是并没有添加具体的城市，直接提交表单，怎么办？系统是应该直接把用户的广告设置成全国投放，还是报错，阻止用户继续？”

交互设计师：“我看啊，报错吧。因为现在「全国」和「指定」这两项，已经明确的把整体和局部给分开了。我觉得你那个策略没必要再应用了，因为现在这种已经达到了你最初的目的，而且还好理解。再有就是，咱们的平台是涉及到钱的，是要让用户花钱的，如果让用户不明不白花了冤枉钱，本来想投北京的投了全国，那我们会被用户骂死的。虽然感觉上报错会让用户有挫败感，但是在这种细节上，还是用户利益应该放在第一位，用户体验，可以稍微往后放一放了。”

产品经理：“好吧。”

交互设计师：“呵呵，你看，这个故事告诉我们，不能每件事情都听产品的。产品提的只是需求，但是如何实现需求，还是得从多个角度来讨论。”

产品经理：“好吧。那么，技术兄弟们，下面的工作就拜托你们了。”

个人观点：

1、产品经理和交互设计师需要时刻密切配合，深入沟通。

2、有时候，产品策略和用户体验会发生冲突，这时应该从多种角度去考虑和探讨最终解决方案，不应该有谁一定比谁重要的说法。

3、优秀的产品经理，相当于半个交互。同样，优秀的交互设计师，相当于半个产品。二者虽然职位不同，但是应该在一定程度上考虑对方的工作内容。

4、产品提出的只是策略和需求，并不是一定要按照产品人员所描述的细节去设计具体的产品细节。交互设计师以及团队中其他所有成员，有义务有权利对产品需求提出自己的见解和更好的设计方案。有不同意见可以讨论，但是最终决定权，应该依然属于产品经理。

5、产品经理之所以叫经理，是因为，他们除了设计产品，还需要时刻把握整个流程。比如，当细节没讨论清楚的时候，不要去找UI做设计。

注：本文中对话部分并非真实情节，只是为了说明主题而已。

THE END

简摘：本文从手机平台、机型（触屏和键盘）及屏幕大小三个方面简单的讨论了一下手机客户端的交互及适配特性及一些原则。

手机客户端软件虽只是手机中一个功能，但它却要比设计单款手机更为复杂。在设计单款、单系列手机时，需要考虑这款手机的软、硬件优势及不足，考虑其特性、其UI Style Guideline ，确定这些内容后，整个平台的UI也找到基础了。说起来，这至多是考虑某个系统、某个屏幕的特性而已，而不同功能的所有设计基础都是一致的。

但是对于客户端，咋一看，好像很简单，就是设计一个应用。实则不然，客户端重在适配，客户端不仅仅会用在一个型号的手机中。这样问题随之而来，如何能适配不同的手机呢，手机千变万化，我总不能只针对一款手机，一个平台吧？当然也有些客户端确实是这样的，只能使用Windows Mobile、Symbian、iOS、Android、Java(非系统)等的某个平台。但是即使对同一个平台，问题还是很多，是要在触摸屏中来用，还是在键盘机中使用？是在大屏幕中，还是小屏幕中等等。 如何处理？？？有待大家讨论，这里只是抛砖引玉…

                        客户端在不同的平台中，界面展示和特性各不相同

所以，本文中，我想简单的总结一下手机客户端的交互适配方法，希望能更好地来指导当前移动应用的设计需求。

一、 手机客户端的适配分析 

对于手机客户端的适配，我想首先需要做的就是如何适配，我要在什么样的手机上使用？在设计上，我会从平台、键盘机与触屏机、屏幕大小三个维度进行分析：

1. 平台：

不同的平台手机的设计风格、操作方式、硬件配置都存在很大的差异。当前的主流平台主要包括 iOS、Android、Symbian、Blackberry、Win Phone7、Web OS等。

每个平台都有各自的设计指南（UI Style），其对应的手机的硬件也有各自的特点，如iPhone的home键，Android 的back键，blackberry的滚轮等等。特别提一下Palm，Palm的web OS真的值得手机交互设计师研究一下（手机 Palm pre）。因此，在设计上，不仅要了解平台的设计指南，同时需要考虑平台的硬件特征，使自己设计的应用不仅符合平台的交互特性，并能兼容平台上硬件使用习惯，提高应用的可用性。

Win phone 7 系统的几个特点 

iOS系统的几个特点

Android 系统的几个特点

由上图可知，几个最新的平台也存在较大的不同。对于手机的平台特性，会在未来的博文中再详细赘述。

2. 触屏机和键盘机

键盘机和触屏机在操作方式上很不同。

下面简单总结一下键盘机和触屏机的特点。

•  键盘机： 

1）键盘机的操作方式采用Soft Key 与屏幕软键标签一一映射（左右软键、对话框的按钮等都需要与键盘的标签一一对应），对所有的屏幕元素，都需要用五向键（滚轮）导航；需要用光标来操控屏幕上的所有元素。

2）一般左右软键上有一个【返回】键。用户可以通过软键快速的返回。

3）由于用键盘操作时，每次选择项目都需要从上到下依次浏览项目，因此重要性高、使用频率高的元素应放在屏幕的最前面。

4）按键可以根据数字键来设置一些快捷的操作；通过长按来设置快速翻页。

5）除了网页的形式，绝大多数的操作都是在菜单里完成。

6）文字输入的方式，通过键盘来输入，全键盘和数字键又有不同。

•  触屏机（屏幕尺寸会略大）： 

触摸屏手机最主要的特点是直接操作屏幕对象。对用户来说，不需要进行映射的转换，因此易学性更强。但是由于手机的使用场景很特殊，或站着，或在行走，或只能腾出一只手等等，在这些时候要精确指点操作也有一定的难度。

触屏手机也有两种操作形式，用手指直接操作或者用笔操作。但是当前的屏幕发展及推出的机型来看，主要会针对用手指直接来操作。如果用户操作后，有屏幕的力反馈，则效果会更好。

1）操作对象的大小符合手指的操作，按键的大小设置规范：

• 食指点击的间距 约为7*7 mm， 1mm间距，
• 拇指点击8*8 mm，2mm间距。当前推荐的值为9mm 大小，最小应不小于7mm。
• 当然一些重要操作，或者频繁点击的区域可以设置的略微更大一些。

2）由于单手操作时，只能使用拇指操作，因此，使用最频繁的按钮大小必须根据拇指的大小来设置；拇指辐射的范围主要在屏幕的底部，因此需要把这些操作放在稍微靠下面的位置更好。

3）信息显示：大屏幕可以显示更多的内容，但是避免信息显示过于拥挤。

4）手势的定义：当前手机上我们可以看到一些基本的手势操作，如拨动、拖拽、双指放大/缩小、双击等最常用的操作。其实还有很多其他的手势形式，如画圈，打勾，打叉，双指点击，双指滑动等等，这些需要根据手机本身的配置来使用，不建议随便使用特殊的手势来定义常见的操作行为。

5）输入的方式：输入时会起一个虚拟键盘，键盘的显示与隐藏都需要考虑，同时，可以根据当前输入的目的，直接做操作的按钮。

3．屏幕的大小

在考虑手机屏幕大小时，一定要区分物理尺寸与分辨率的关系。物理尺寸的大小和分辨率并非一一对应，例如对于HTC的S1 2.8 英寸，分辨率为320*240；Nokia n81 2.4 英寸，但是分辨率也是320*240。因此，对于相同分辨率大小的图标，在 S1 中看起来就要更大些，但是图标可能就没有那么细腻了。

在视觉设计时，需要首先考虑这个问题，在首次设计时，应该更勤于导入设计视觉图片到目标屏幕中去检验，看看设计是否合适，别到都完成了视觉设计，才发现设计的图标太小或者不够精致。

对于2.8 英寸 及320 * 240 （含）以下的屏幕，在现在来说都是小屏幕界面，在这个档次上，应该是键盘机占主导地位。在键盘机的设计上应该更多地去参考Nokia的规范（对于可用性，Nokia的设计还是无可挑剔的）。

对于3.0 英寸 及 480*320 以上的屏幕，可以认为是大屏幕，并且是以触屏机为主的。【随着屏幕技术的发展，屏幕的密度已经越来越大，这样的值也只是一个参考值。】

1）屏幕信息布局

小屏幕和大屏幕在客户端信息内容的布局上会存在较大的差异。屏幕大时，除了考虑信息架构外，需要考虑在界面上放哪些信息和操作；屏幕小时，更需要考虑信息架构，对信息更好地分屏，信息之间的联系等。

2）不同屏幕设计特点

a) 大屏幕的设计特点：

•  在界面中，展示更多的信息；包括界面内容、导航和操作按钮；
• 大屏幕以触摸屏为主，更多地以手指来直接操作；
• 在屏幕上，显示的信息不宜过多；信息密码过高，不利于信息的搜索。

b) 小屏幕的设计特点：

• 在界面上先展示客户端的功能及结构；
• 以键盘机为主，操作方式；
• 先导航，后显示内容，内容的分屏合理，符合用户的期望。

对于手机的屏幕大小适配，会在未来的博文中再详细赘述。

二、手机客户端的设计原则及适配步骤

1. 客户端的设计原则

1） 手机本身的物理特性受限引起的指南：

a)   客户端的文字输入，必须要降到最低：由于手机在输入上的低效性，在设计的过程中，应尽量减少用户的输入，如果有可能可以设置默认值，或者让用户选择目标值。

b)   客户端的信息结构好，屏与屏之间的逻辑关系清晰：由于手机屏幕都普遍较小，即使有4吋屏，那也只能展示较少的信息量，因此，在手机设计上，更需要有清晰的信息架构，用户知道当前在哪儿，并能返回到哪儿。

c)   客户端的操作、功能不要隐藏太深，重要功能都需要在界面中有适当的提示：由于手机屏幕较小，不能展示所有的信息。因此，对重要的、使用频率高的功能或信息放在最重要的位置，并在首页上展示或指示。

2） 手机的移动特性引起的指南：

a)   客户端的最主要的功能操作，用单手可以完成：手机的使用情景多样性，在很多情景下，用户都只能单手来操作手机，因此，在客户端的设计过程中，需要考虑最重要的核心功能，能否单手操作完成。

b)   客户端的界面必须简洁、操作简单，操作步骤少：由于用户操作情景复杂，在使用客户端的过程可能有额外的认知负荷，因此，在设计客户端的过程中，逻辑必须简单，操作步骤也要减少。

c)   客户端的界面层次不要太深，最好不要超过3级：

d)   客户端的提示包括界面、声音、振动多种形式：用户在操作手机时，往往不会一直盯着手机屏幕看，因此，很多手机状态页面的切换，脱离了用户的视线，这时，必须要提供视觉之外的其他感觉通道的信息（如听觉、触觉等），来对用户做提示。

3）其他原则

a)   客户端UI的适配不必恪守所有的平台都保持一致，只要一些品牌的关键元素能体现即可：

b)   客户端的主要操作方式（框架、导航、按键功能及软键对应方式等）应与所承载的手机操作系统保持一致：客户端都承载在某款具体的手机平台中，而用户会对当前的手机平台很熟悉，因此，在设计的过程中，需要更好地理解当前的手机平台，并使客户端的设计与手机系统的设计逻辑保持一致。

2. 手机客户端设计适配的步骤：

个人认为，客户端的适配要以一个平台为起始，但是要着眼于多个平台。

1)  根据公司的战略，选择一个最先切入的平台；

2) 了解该平台的UI 设计规范，可用的UI 控件及交互原则；

3) 确定切入的屏幕大小，以此来设计第一个客户端，但是要考虑适配其他屏幕的可能性，是自适应来扩展或者缩小；

4) 根据平台及屏幕大小，来选择一款最典型的手机，开始客户端的交互设计。

5) 确定客户端的核心目的。如为娱乐为主的，应在设计方式更娱乐性；功能性完成目的为主的，以更易用性为主；

6) 根据客户端的功能和内容，来设计客户端的信息架构；

7) 根据UCD的原则，来完成客户端的交互原型；

在交互原型的过程中，需要考虑手机适配的三因素（平台、屏幕、触摸/非触摸），以便将来的适配。

随着各个手机操作系统的应用平台的上线，几乎所有的互联网应用都在往手机上迁移。然而手机与PC 不一样，PC经过了多年的发展，在设计上形成了很多不成文的规则，如网页的宽度都在960px左右【当然，由于整体的电脑屏幕往大尺寸及高分辨发展，除了背景宽屏自适应外，不少网页也正朝着更宽的方向上发展】。当前的手机种类繁多，手机屏幕的大小、比例各异，并且手机的屏幕本身就小，因此既要考虑应用在不同屏幕大小上的适配，又要保持其一致性，同时还要提高每个手机屏幕的使用效率，这就存在着很多的矛盾点。

在客户端的设计过程中，针对不同的屏幕大小，应该如何来设计？是否每个大小的屏幕尺寸都需要一个新的界面布局，还是所有的屏幕尺寸都使用相同的界面布局？我们将在下面的内容中来探讨这些内容。

一、当前热门手机的屏幕大小 

下图中，我抽取了国内某个网络电器城某周的10大畅销手机排名：

虽然只是2010年中的某一周的手机销售量排名，由此可以看出，当前使用中的手机屏幕差异很大，各种屏幕大小和分辨率都有。如果为了适配更多的用户群体，则需要考虑的手机屏幕大小和分辨率更多。【不过，根据当前的手机发展趋势，及手机客户端的使用行为可以看出，最主要需要用户关注的手机屏幕是2.4吋以上，240*320以上的手机屏幕，因为这样的手机使用客户端的频率和用户量都会更多。个人建议更多地是考虑320*480及以上的屏幕。】

二、屏幕大小正确理解

说起屏幕大小的时候，会有两种表达方式，1） “我的屏幕2.4吋，你的屏幕3.5吋。” 2）“这个屏幕分辨率 240*320，那个屏幕分辨率为320*480。”但在设计过程中，屏幕的分辨率和屏幕的实际尺寸必须同时考虑。

这里首先有几个概念需要再澄清一下：

• 屏幕物理尺寸：屏幕对角线长的实际尺寸，如2.4吋，3.5吋等等
• 屏幕分辨率：屏幕所能显示像素的多少。如，240*320等。
• 屏幕密度（pixel per inch）：以每英寸的像素数。每英寸的分辨率数，如160ppi。

物理尺寸决定了屏幕的实际尺寸，而分辨率可以表示屏幕上可以呈现的像素点数，屏幕密度决定了屏幕的精细程度。相同的屏幕大小，如果分辨率高，则屏幕元素更精细。一个界面元素在屏幕里的实际尺寸却是与屏幕密度相关，屏幕密度较小的屏上，界面元素的实际尺寸就会大些，反之亦然。

在进行手机界面布局中，除了元素的像素值外，考虑元素的实际尺寸也非常重要，甚至更为重要（人眼是要靠物体成像在视网膜上的视角大小来进行识别感知，视角是与物体实际大小和距离有关）。

在不同屏幕中，不同的图标点阵或者不同的字体及大小的汉字，在人的主观感知上，会有一个最优的结果值。在设计的过程中，我们需要根据这个最优值来进行界面的布局及设计。

也可以看出，这个用户感知最优的取值也与使用手机的人群有关（如年龄大的用户需要物理尺寸更大的界面元素）。

在不同屏幕中，不同的图标点阵或者不同的字体及大小的汉字，在人的主观感知上，会有一个最优的结果值。在设计的过程中，我们需要根据这个最优值来进行界面的布局及设计。

也可以看出，这个用户感知最优的取值也与使用手机的人群有关（如年龄大的用户需要物理尺寸更大的界面元素）。

三、设计过程与屏幕适配思路

1．确定目标的屏幕大小

屏幕大小由宽度和高度两个因素决定，但是在布局手机客户端的过程中，最关心的是宽度值。宽度确定后，高度可以由滚动或者翻页来显示所有内容；文字可以在适当的位置折行；标题栏可以伸缩适配屏幕宽度等等。但并不是不考虑高度，图标、文字、特殊的组件不仅需要考虑宽度，也需要考虑整个屏幕的布局是否与之适配。

由于不可能对所有的客户端进行单独的开发，因此，需要对手机屏幕的大小的归类。同时，在设计中也不会真的只考虑屏幕大小一个因素，屏幕大小和操作系统、手机类型等还是存在很大的相关性的。

首先，我们先来定义一下手机的屏幕大小的归类档次：

A. 小屏幕：宽度240 px 以下屏幕或者2.4 以下屏幕

• 一般以非智能机为主，归在这个分类中的手机屏幕，一般是以java版本的客户端为主。

B. 中等屏幕：宽度240~320 px，或者2.4~3.0吋屏幕

• 智能手机以Symbian或S60 v1,2,3，Windows mobile为主流；或者是非智能手机的客户端以java版本为主。
• 同时包括240*320的宽屏手机。

C. 大屏幕：宽度320 px以上屏幕或者 3.0吋以上的屏幕

•  iPhone 手机只有两个版本的适配，屏幕物理尺寸保持一致；
• Android 系统手机及衍生平台手机
• Win phone 7 系统手机
• Nokia S60 v5，symbian 3等

D. 平板屏幕：7吋及以上的屏幕【可以不包含在手机中，^_^】

• 由于当前的平板电脑上的应用的开发都是基于手机应用的功能，但是，平板的屏幕物理尺寸大增，使用情景也和手机不一致，在设计上有很多的特殊性，可发挥空间也更大，因此个人建议单独的设计。

其次，根据我们的产品战略，来确定待开发产品的用户群体来确定一款目标手机屏幕。由于对于某个业务的手机客户端都不会只推出其中的某一款（除非是战略上的用户群确定为使用某种手机的特殊业务），而是会对不同的手机平台分别进行适配。因此，确定的目标手机屏幕，应该是在该档次中最主流的手机屏幕大小，在以此为基准向上或向下来适配其他的同档手机。

2．适配原则

1）  客户端的logo，在各个手机上都应该清晰地显示

2）  标题或者底部栏必须100%的与手机宽度适配

3）  文字内容如果显示不下的话，可以自动适配宽度进行折行

4）  图片可以根据宽度进行自动缩放，屏幕宽度超过图片本身时，显示图片本身的大小

5）  适配过程中，界面的元素的宽高最小值应该符合用户的主观舒适范围值。

6）  不能完全使用分辨率的绝对比例来对界面布局进行缩放；

3. 适配思路分析

根据我们前面的分析，

C类大屏幕大小主要以Android、iPhone、win phone 7 和Nokia V5等手机为主，它们都是触屏手机，在适配上可以划为一个档次。

B类中等屏幕大小智能机主要以Symbian 和Windows mobile为主，因此在适配这两个平台时，主要集中在B类屏幕间的适配。

B类中等屏幕大小还有一块是非智能手机，使用Java客户端，同时，A类小屏幕大小主要使用Java客户端，因此，Java类客户端需要适配的范围更广，至少应包括B类和A类的屏幕大小。

（1）Android 与iPhone手机的适配

iPhone 本身就只有两个分辨率及一个屏幕大小尺寸，可以很好的来适配（最多出两套图片即可，系统会自动读取）。

对于android，由于其开放性，导致了各种屏幕的大小及分辨率都有。但Android系统有一个很好的特性，系统会根据屏幕的分辨率密度来进行自适应。但是，当密度差异较大时，自适应后，图标会由于拉伸变得模糊影响效果。这时，必须要通过重新设计新的图标或者加大间距来保持最佳的视觉效果及更便利于用户操作。

Android 手机屏根据屏幕的分辨率密度和物理尺寸，可以分为以下几类：

注：图中的【】内的值为手机所占的百分比值。Android 开发平台数据，不一定准

Android 提供了如下的机制来对不同大小和密度的屏幕进行适配：

1）  图片资源的缩放

基于当前屏幕的密度，平台自动加载任何未经缩放的限定尺寸和密度的图片。如果图片不匹配，平台会加载默认资源并且在放大或者缩小之后可以满足当前界面的显示要求。如果没有多套资源，平台会认为默认的资源是中密度的屏幕资源（160dpi）。例如，当前为高密度屏幕，平台会加载高密度资源（如图片），如果没有，平台会将中密度资源缩放至高密度。

2）  根据分辨率和坐标自动缩放（密度不同的屏幕适配）

如果程序不支持多种密度屏幕，平台会自动缩放绝对像素坐标值和尺寸值等，这样就能保证屏幕元素能和密度160的屏幕上一样能显示出同样物理尺寸的效果。平台会根据密度的比例来缩放实际尺寸的大小。

3）  兼容更大的屏幕大小（屏幕不同的适配）

当前屏幕超过程序所支持屏幕的上限时，定义supports-screens元素，这样超出显示的基准线时，平台会以屏幕大小的比例来缩放整个屏幕。

由上表格也可知，当前的Android手机主要集中在标准屏的中密度和高密度两个型号上。因此在设计中，主要是设计其中的一种为主，再去适配另一个型号即可。对于在一个档次上的手机，都会根据上述的三个原则，系统自动去适配。个人认为，在进行Android手机设计时，如果只准备一套资源时，应该以高密度的版本为主，这样去适配中密度时，效果更好。

当然，如果屏幕的密度差异较大时，自动适配的效果肯定不会，如果要取得更好的适配效果，必须针对几个不同的屏幕密度进行单独设计屏幕元素，提高视觉满意度。

（2）非Android、iphone的手机适配

对于其他的非Android、iphone手机，则需要更多地考虑其适配规则，这些手机系统不提供自适应的适配。

简单整理规则如下：

1）  向上适配（标准屏向更大【分辨率高，物理尺寸大】的屏幕适配）

在向更大的屏幕适配时，根据设备分辨率的不同，会分为两种状态。

A．如果两者的屏幕分辨率密度（dip）差不多，物理尺寸更大的屏幕。那可以直接在当前尺寸上拉长、拉宽即可，图标、行距都可以保持不变。

B. 如果屏幕密度要大很多，物理尺寸差不多的。则适配点包括：

• 设计多套图标，需要有更大分辨率的图标
• 使用不同的字体，需要更大的字体来适配大设备分辨率的屏幕
• 增加行间距
• 自适应放大内容中的图片
• Tab页签 需要根据屏幕的大小来确认每屏最多显示的数目。
•  考虑一些复杂界面，增大界面中的一些元素的分辨率，会导致许多东西需要重新设计。这种情况需要重新设计该界面。

2）  向下适配

在向更小的屏幕适配，这种情况较少，那会集中在如下几点：

• 考虑一些极限点的改进，需要适配到小屏幕的手机中，如标题的最大字数等。
• title、bottom栏与小屏幕宽度适配。
• 考虑到行高（行信息展示）的设计是否适合更小的屏幕高度。
• 在结构上，需要考虑在小屏幕中，显示是否合适。
• 根据屏幕密度的比例来设计屏幕元素，需要更小分辨率的屏幕元素
• 使用小的字体，具体的大小需要根据屏幕的大小来设定。

（3）竖屏横屏适配

横竖屏的适配，在本文中，不过多讨论，这里只是简单的整理一下，我自己的理解。

对于不同功能的应用，都有其特定的页面展现形式，个人并不赞同蛮目对任何应用不加选择的都去适配横屏。

个人观点如下：

1）  不同的应用，在设计的过程中，对于选择不同的屏幕有不同的选择，如普通list多的应用，竖屏更合适；显示图片更多的界面，或者想更好的展示全景的应用，横屏更合适。

2）  不必遵循，对任何的应用都可以自动进行横屏竖屏的切换。如果觉得没有必要横屏或者竖屏的应用，就可以不切换。

3）  由于用户在使用手机的过程中，经常会无意中调整位置，从而导致手机误认为是要进行横竖屏的转化，从而更容易导致操作上的失误，引起用户的反感。

4）  横竖屏的切换时，允许用户对于同一个界面有不同的展示方式。例如不一定在竖屏时时list方式显示，在横屏时也和竖屏保持一致，这时横屏可以有更好的适应横屏的展示方式，使用户更好的操作。

由于手机系统各异，手机的屏幕尺寸五花八门，屏幕的性能也呈现多样性，还有触摸屏和非触屏的区分，这四个变量结合起来，会有无数种不同的情况，如何能使你的应用完美地展现给用户，适配固然很重要。但是，更重要的是你要在适配之前，确定应用的目标群体。如果你的应用主要是针对高端手机用户的，那你何必去考虑低端的手机呢？毕竟为了很少的用户，使你花了很大的力气，可能会有不值得，这一点绝对值得每一个设计师思考。

===========

       题外话

一般来说，我们在设计一个产品时，首先需要确定产品的用户群体，然后基于用户群体来设计针对该用户群特点和使用行为的界面。但是对于手机客户端，感觉这个过程不能完全适用：

原因是因为，我的客户端设计主要是针对不同的手机平台（Android、ios，Win Phone 7，Palm Pre，Symbian…）来开发的，因此，开发出来的客户端适用于所有的持有该手机的用户。但是这些手机持有者是否都有相同的特质，是否都喜爱使用该客户端，是个很大的未知数。另一方面，如果我在建立用户群时，完全根据用户的需求、使用行为又或者人种学特征来分类，那每一群人中持有的手机各不相同，那又该如何定义每个不同平台下的客户端的功能呢？

当然，有人也会说那就先了解不同的手机平台的用户群特征，然后再研究这群人对本客户端应用的需求和使用行为，以此再来设计客户端，目前来说这是更好的研究思路。

总之，这样深入的讨论，会发现客户端会越想越复杂，有人说手机客户端的设计是最复杂的，是很有道理的，值得大家更多地探讨…