2014年，移动APP的热度丝毫没有减退，怎么为您的移动端app设计良好的服务器端接口（API）呢？ 下面谈谈我个人的一些想法。
2014年，移动APP的热度丝毫没有减退，并没有像桌面软件被WEB网站那样所取代，不但如此，越来越多的传统应用、网站也都开始制作自己的移动APP，也就是我们常说的IOS客户端、Android客户端。
这仿佛又回到了多年前的CS架构，那时候我们用VB、VC、Delphi在Windows平台上快速开发各种应用程序。 不同的是，如今的移动端APP基本上都是联网从服务器端获取各种数据，客户端只是一个简单的表现层的工具。
不仅仅是移动APP，包括面向服务的SOA架构，都需要制定一套统一、规范的接口，那么，做这样的后端接口需要注意哪些问题呢？
1、跨平台性
所谓跨平台是指我们的接口要能够支持不同的终端，比如android、ios、windowsphone以及桌面软件、网站等，一套接口，支持多端，就像当年Java的口号一样&Write Once,Run Anywhere&。 当然从本质上讲，服务器端的接口跟终端是没有太大关系的，只是接口应该考虑到不同端的接入成本，采用通用的解决方案，比如通信协议就采用最常用的HTTP协议，如果是即时通信，可以采用开放的XMPP协议，做游戏的可以采用可靠的TCP协议，除非TCP不够用了，再采用定制的UDP协议。数据交换采用xml或者json格式等等。
总之，要达到的目标就是让不同的端能够很方便的使用你的接口。
2、良好的响应速度
如果要用一个指标来衡量接口的性能的话，那么我想最重要的就是响应速度了。接口应该以最快的速度将数据返回给请求者。试想，当我们打开一个页面，如果&努力加载中&之类的提示超过三五秒钟的话，我们肯定会变得不耐烦，移动app本来大部分就是用户在碎片化时间来使用的，在有限的时间内，用户恨不得获得的信息越多越好，即使你的app界面设计的再好，用户也不会买账。
提高响应速度又是个老生常谈的问题，大体上应该按照以下步骤来做：a、初期，以功能为主，要保证功能完整，满足业务需求，这阶段可以使用动态的语言，比如java、php、asp.net等，配合设计良好的数据库结构和索引，能满足一定的需求；
b、其次，随着用户的增多，可以考虑一些缓存方案，缓存是解决性能问题的万金油，通常能起到立竿见影的效果。最常用的静态文件缓存，memcached内存缓存等。 c、然后，单台机器的吞吐率不行了，通过负载均衡多加几台机器就行了。七八台机器，支持每天千万级的接口调用是可行的。或者，直接采用CDN的解决方案，将绝大多数的静态资源交给CDN去处理。
总之，要达到的目标就是快，一个页面，秒开最好，超过三秒就需要找找原因了。
3、接口要为移动客户端考虑
接口不仅仅是提供数据和功能就完事了，更应该充分考虑移动端的特性，为移动端提供更加方便、快捷的接口。比如，在移动端里，下拉刷新和上拉加载更多是很常见的功能，如果接口仍然按照传统的web思路，只提供按页读取的话，就会造成移动端的额外的数据请求和计算。这时，接口就应该针对这两种类型的操作提供额外的支持。
再比如，对于一个新闻阅读类的app来说，最新的新闻列表里的文章，特别是前几条，用户很容易点击进去看，而后面的老的文章列表，一来用户下滑加载好几页的情况较少，二来过时的新闻用户也很少点。如果，接口在返回新闻列表时，对于最新的列表，可以直接把文章的正文（或者部分正文，比如一屏的内容）信息一起传给客户端，这样，用户在打开新闻详情页的时候，就不用再从服务器端获取了，自然可以做到秒开。
比如访问第一页时，接口可以返回文章内容，如下所示 ，content=1表示加载文章内容newslist?page=1&pagesize=20&content=1；其他页时，newslist?page=5&pagesize=20&content=0 ,不用加载文章内容。
当然，客户端要跟接口做好配合，搭配好，才能最大化的提高性能。 比如，移动端都有左右滑动来看上一篇、下一篇文章或者图片的功能，如果，当用户请求某篇文章的时候，服务器端顺便也把下一篇文章的内容返回回来了，那么当用户看下一篇的时候，是不是就很快了呢。
当然这种preload的方案也不能滥用，如果预加载数据的命中率较低的话，也不行，白白浪费了很多的流量。
4、考虑移动端的网络情况和耗电量
如果让我们说出哪类app比较好，可能还不大好说，但是如果让我们说出哪些app很差，我们肯定会说出那些体积很大、占用内存多、界面很卡、费电的app不好。
对于移动APP开发者来说，网络流量和电池电量是不得不考虑的问题。对于网络情况，接口应该具备为不同的网络提供不同的内容的能力， 通常，移动端的上网方式无非是2G（GSM、GPRS、EDGE）、3G（CDMA、TDSCDMA、WCDMA）、WIFI，设想一下，如果用户在流量需要花钱的情况下，你的app给用户展示了视频、音频、大量的图片而没有通知用户的情况下，用户会怎么想，毕竟国内的流量费用还是很贵的。
还以上面的新闻列表接口为例，如果我们能够知道用户的网络情况，只有在wifi的情况下才给用户传输封面图、缩略图之类的， 是不是可以帮用户节省很多流量呢。 不过，您也许会说，这些跟接口没啥关系吧，服务器端的接口还能管得了客户端的网络流量和电量？
newslist?page=1&pagesize=20&content=1&network=wifi 对于电量，首先我们要弄清楚，app的哪些方面会消耗电量？比如app有大量的计算、有很炫的视觉画面都会消耗电量，另外，不断的移动网络链接也会消耗大量的电量，我们都知道移动网络是通过无线电波来通讯的，那么发射装置就需要消耗一定的电量来发射和接收无线信号。特别的是，频繁的链接会不断的切换网络设备与移动基站之间连接状态，这都会消耗一部分电量。
所以，对于接口而言，尽量用少的链接传输多的数据， 比如，对于关于我们、版本更新以及一些系统配置信息，完全可以通过一次链接全部返回给客户端。
5、通用的数据交换格式
目前，对于接口和客户端的数据交换格式，基本上就是两种，xml和json，而现在使用json的应该占大多数。 交换的数据包括两种，一种是客户端请求服务器端接口时传递的一些参数，一种是服务器端返回给客户端的数据。
对于客户端的请求参数，现在也越来越多的接口要求采用json的格式，而不是以往最常见的key_value对了。
比如，接口需要username和password两个参数key_value pair的方式是：username=hutuseng&password=hutusengpwd
然后通过GET或者POST方式传送。 而通过json方式交换数据的话，格式如下，直接POST到服务器端。
'username':'hutuseng',
'password':'hutusengpwd'
对于服务器端返回的json数据格式，需要注意两个问题： 一是汉字编码问题，因为json（javascript）内部支持Unicode编码，会将汉字等转换成unicode编码保存，所以在返回结果中，对于中文，可以直接输出中文，也可以输出中文的unicode编码，json解析器都会很好的解析。
比如下面两种方式都是可以的。
"code":"208",
"data":"\u53c2\ud\u5b8c\u6574"
"code": "208",
"data": "参数不完整"
二是字段的数据类型，特别是数字类型的，json中尽量转成数字格式，比如{'userid':128 } 不要写成 {'userid':'128' }
6、接口统计功能
在做PC端网站的时候，我们都会给我们的网站加上个统计功能，要么自己写统计系统，要么使用第三方的比如GA、百度等。 移动端接口API则需要我们自己实现统计功能，这时就需要我们尽可能多的收集客户端的信息，除了传统的IP、User-Agent之外，还应该收集一些移动相关的信息，比如手机操作系统，是android还是ios，都是什么版本，用户使用的网络状况，是2G、3G、4G还是WIFI 客户端APP是什么版本信息。
这样，有助于我们更好的了解我们用户的使用情况。
7、客户端与服务端的肥瘦平衡
在以前C/S、B/S架构时，我们就已多次讨论过这个问题，客户端是瘦点好还是肥点好，当然也没有固定答案，需要自己根据实际情况去做权衡。 但是，在移动开发中，由于客户端的修改会很费时费力，特别是IOS应用还要经过Apple审核，另外，当前IOS开发人员、Android开发人员的人工成本普遍较高，人才紧缺，基于这两点，能在服务器端实现的功能就不要放在客户端，毕竟服务器端程序的修改要比客户端方便、灵活、快捷的多。
8、隐式用户与显式用户
显式用户和隐式用户，我不知道这两个词用的是否确切。显式用户指的是，APP程序中有用户系统，一个username、password正确的合法用户，称之为显式的用户，通常显式用户都需要注册，登录以后能完成一些个人相关的操作。
隐式用户指的是，APP程序本身就没有用户系统，或者一个在没有登录的情况下，使用我们APP的用户。在这种情况下，可以通过客户端生成的UDID来标识一个用户。
有了用户信息，我们就能够了解不同用户的使用习惯，而不仅仅是全体用户的一个整体的统计信息，有了这些个体的信息之后，就可以做一些用户分群、个性化推荐之类的事情。
9、安全问题网络安全已经从桌面互联网转到了移动互联网，从客户端蔓延到了接口API中。
传统固若金汤的网站，很可能因为接口的一点疏忽而遭受入侵。现在，在很多白帽子或者黑客的入侵思路中，先看看移动端接口是否存在漏洞，再看网站是否有漏洞。
客户端APP与接口的通信很容易被得到，只要在中间路由上嗅探一下就行，whireshark、tcpdump这类工具使得这项工作变得简单无比。
所以，接口的安全工作不能马虎，暴力破解啊、SQL Injection啊、伪造请求和数据啊、重复提交啊也要考虑到,如果数据特别敏感，可以考虑采用SSL/TLS等加密传输，或者客户端、服务器端约定一个加密算法和密钥，对来往传输的数据进行加密、解密；如果不采用RESTful API，可以采用基于WSDL和SOAP的Web Service的安全措施。
10、良好的接口说明文档和测试程序
接口文档有时候是项目初期就定下来的，前后端开发人员按照接口规范开发，有的是接口开发完成后写的。
接口文档要清晰、明了，包含多少个接口，每个接口的地址、参数、请求方式、数据交换格式、返回值等都要写清楚。
接口测试程序，有条件的话，也可以提供，方便前后端的调试。
11、版本的维护
随着业务的变化，客户端APP和服务器端API都会发生变化，增加新的功能，修改已有的功能， 增加功能还好说， 如果是接口需要修改，那么就面临着同一个接口要同时为不同版本的客户端服务的问题。 因此，服务器端接口也要做好相应的版本维护。
阅读(...) 评论()博主最新文章
博主热门文章
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)向研发交付设计稿时，需要注意些什么 - 简书
向研发交付设计稿时，需要注意些什么
在一个产品开发的流程中，UI设计师离不开和研发打交道，UI做出来的图都需要研发这边去实现，所以我们也要站在研发的视角去考虑问题，这样可以减少不必要的沟通成本，提升工作效率。
每个研发有不同的性格。在我们团队中，有的研发需要你每个地方都标注得很清楚，不然他会不断地来找你，有的研发则不需要，这些都需要慢慢去磨合，找到彼此觉得舒服的方式。下面主要是我写我自己工作上和研发合作的一些总结，内容也比较基础，大神可以忽略我?。当一个页面做完以后，需要交付给研发的东西的离不开这两个重要的部分。
①以什么单位进行标注先来了解一下这几个单位：px 、dp 、sppx：pixel像素，电子屏幕上组成一幅图画或照片的最基本单元，设计时使用的单位。dp: dip，Density-independent pixel, 是安卓开发用的长度单位，1dp表示在屏幕像素点密度为160ppi时1px长度sp: scale-independent pixel，安卓开发用的字体大小单位。具体要使用什么单位进行标注，请和研发沟通好。目前有些设计师提供设计稿的时候依旧使用px进行标注，但如果不影响他开发以及他能换算清楚的前提下，理论上是可以的。但这不是一个最好的选择，建议使用dp或sp。那怎么换算呢：px转dp：安卓端屏幕大小各不相同，根据其像素密度，分为以下几种规格：
1dp定义为像素密度值为160ppi时的1px，即，在MDPI时（分辨率为320*480），1dp = 1px。以mdpi为标准，这些屏幕的密度比为：ldpi : mdpi : hdpi : xhdpi : xxhdpi ：xxxhdpi= 0.75 : 1 : 1.5 : 2 : 3：4
。即在HDPI的密度下，1dp=1.5px；在xHDPI情况下，1dp=1.5px。以此类推。所以当我以使用分辨率为（即xxHDPI）来做图时，假设间距是48px，那标注时应该是16dp。px转sp：dp和sp都是安卓的开发单位，sp与dp类似，但是sp可以根据用户的字体大小首选项进行缩放。就是说Android系统允许用户自定义文字尺寸大小（小、正常、大、超大等等），如下图，如果我以sp为单位时，当把文字改为“大”时，应用内部也会进行字体的相应缩放，dp则不行。一般情况下可认为1sp=1dp
进入系统的设备显示可调字体大小
当然目前也有一些工具可以帮你更好的进行标注，不需要你自己去换算。建议利用好能够提升效率的工具。②间距
需要标注的地方很多，比如图与字的间距、字/图与界面两边的间距、字与字的间距等...标注的方法也可以有不同，可以以边框、附近的元素作为标准，也可以告知具体坐标...重点讲一下字与字的间距：在实际的开发中，两个字体的间距在手机上的显示效果要比标注图的间距要大。 这是因为在一个字体中，字母的高度可能会有所不同，系统会默认给字体增加一个高度，但每个手机增加的高度也不同，你可以按你的图来进行标注，再由研发进行判断和调试，ui也需要一起跟进。间距的标注也需要考虑在不同机型上显示会出现什么问题，这个问题是否严重，这个比例大不大等。③字体大小及粗细在一个页面下，常用的字号有：12、14、16、20 和 34sp。除了标注字体大小外，还需要标注字体的粗细，你还可以根据需要设置字距，行距等。也支持打包其他字体。④颜色
按元素种类来分，需要标注的有：背景色（遮罩的颜色）、字体颜色，按钮颜色，点击色...如果是通过不同的颜色来表示不同的状态也需要标注说明。按颜色的数量来分：单色，多色（渐变色）如果是渐变色，那渐变的角度也要说明，是从左往右，从上到下还是从中间到四周等。已经是否有透明度等。。。这里强烈建议在项目开始之初能够建立基本的设计规范（包括颜色，字体大小等），建立完后不要就扔在共享就不管了，一定要让负责这个项目的每个UI、研发人员都知道。这里补充一个小点：如果你的文字是有带透明度的，那你标注的时候可以采用以下方式：因为研发采用十六进制的代码，就是说当你给研发一个80%的白色时，其实也可以给对应代码：#CCFFFFFF ，前两位是CC是表示透明度，后面六位FFFFFF是表示具体的色值，其他的透明度可以。最后提醒一句：如果不清楚你该怎么标，一定要和研发沟通！而且也不需要每一张效果图都进行标注，能保证研发工作顺利进行即可。切图
安卓尺寸众多，按每个屏幕去适配肯定不现实，所以为了解决这个问题，安卓手机屏幕有自己初始的固定密度，安卓会根据这些屏幕不同的密度自己进行适配。
这和前面提到的单位有关系，下图为在不同分辨率下对应切图的倍数关系，对于切多少套图的问题，要根据实际开发来定，这里建议大家安装切图插件，一键导出多套非常方便。网上教程也很多，我就不多讲了。
在切图之前你应该明白哪些图是可以不需要切的，那些图是一定要切的。以下图为例
截图来自Ace Cleaner
要切的地方有(红色部分)：四个主要的功能图标，侧边栏入口，右上角的商店入口以及小红点（切点九）不需要切的地方有（黑色部分）：两个色块以及上面的小动画图总的来说就是当程序实现不了的时候，就需要你切图。程序实现有个很大的好处就是能减少包体的大小。记得压缩！记得压缩！记得压缩！补充一点：对于切图以及点击区域大小的问题。Material design中规定，为了确保平衡信息密度和可用性，触发区域大小至少是 48 x 48 dp。在大多数情况下，触发区域之间应该还有8dp或更大的间距。当你的切图小于这个大小时，可标注说明。因为我遇到研发会按的UI给的图的尺寸大小来设置点击区域的大小。除了这两部分，还有交互方式说明，有动画效果的进行详细描述，这部分写起来也很多，下次讲。
分享自己的一些心得
使用sketch最重要的一点是设计好控件的规范。 为做好设计规范需要对色彩进行编号，比如:color_a”_1，color_b_2，color_c_3等8。 对色彩的归类可分为以下几种: 品牌色（即主色调） 通过纯度（S）和明明度（B）的变化，延伸出扩展色。 辅助色”8 通...
之前U妹给大家分享了《一款APP设计的从0到1之：iOS精华篇》，今天U妹给大家带来的是Android的设计规范篇。 iOS设计规范回顾： 《一款APP设计的从0到1之：iOS精华篇》 Android的设计规范不同于iOS，Android是一个开源的系统，国内外有很多的手机...
从零开始设计一款APP之Android设计规范篇 《从零开始设计一款App》系列文章共6部分，之前已经讲了前5个部分，今天把 设计规范 部分也给大家科普下。 作者：佚名来源：优设| 13:51 移动端 《从零开始...
成功的app设计案例一直是我们学习的榜样，也是我们参考和临摹的APP产品。 俗话说，成功基于前人的经验之上的。APP设计的我想要快速学习APP界面设计，必须先去网上看看那些优秀的APP设计案例。 今天由我来说说： 一. 基础概念
设计app首先来了解下基本知识： 1...
从上图可以知道，在整个过程中，设计师的工作可以分为做人和做事两大类。 学会做人 楼主将这个放在做事的前面，特意强调了一下它的重要性。人的本质是一切社会关系的总和。 同事之间会有部门、职位、年龄、婚姻状况等各种不同的情况，是除了家人之外跟自己相处时间最久的一类人。跟合作的部门...
事情的真实起因现在已经无法弄清了，似乎是上周的那一次测试大家伙的全军覆没，大老王为此特别生气，又开始训话了。 奇怪的是这是在一个露天的场子，在一个莫名其妙的地方。似乎下过雨，挺多泥巴，我偷偷的将鞋上的泥巴刮在了桌子腿上。座位刚刚调换过，我所在的位置比较安 全，离旁边的过道蛮...
每天收获数声晚安 也道出去几句好梦 斯人已入睡 留君一片星空 白天是世人的游乐场 黑夜是创客的独居地 随手托几颗星星 把梦想塞进月色 斗转星移 火辣辣的太阳光芒万丈
这是500字思考的第3篇。@绿豆侠 这次的500字思考有点澎湃，因为几乎800字了。 我最近发现自己印象笔记里面的笔记总数已超3000，倒没有吓自己一跳，因为我很清楚自己这两年在干什么。 这3000个笔记里面，除去一小部分是自己创建和撰写，一小部分零散的笔记，类似于在草稿纸...
by 王骐骥GPLP
贾跃亭终于松了一口气，挣扎在死亡边缘的他看到了救命的稻草。
1月13日，乐视网公告称，乐视网、乐视致新与乐视影业将引入战略投资者及其他投资人合计资金约168亿元，其中150.41亿元来自融创中国。
发布会上，...
诗云： 情淖中人襟常湿，泥田陷足日恨深。 悔汲山井溅罗带，春袖尽掩旧啼痕！ 此诗咏的，盖是人命中若犯劫数，“情”字约莫占得头筹无疑。看官若不信，试看晋有绿珠坠楼，唐有盼盼守节，今人看来，纵是一叶障目而至香消玉殒，无比愚暝可笑，也须知自古是旁观者清，当局者迷。再说这首诗，本是...还没有账号
邮箱/用户名登录用户名或密码错误
用第三方帐号直接登录
[设计日志] 关于APP设计规范需要注意些什么
文章来源：my.68design.ne
作者：Inpic
未经作者同意，严禁转载，或做商业使用！
推荐：2次 评论：次
为什么制定设计规范？为了后续更好的服务于用户体验，更高效，更流畅，更可控！其实主要是产品规模大了之后就需要多个产品设计师协作完成整个产品，每个设计师之间的设计理念、设计方法、设计习惯的不同，协作完成的产品往往会导致产品一致性差，质量参差不齐。这个时候一份设计规范来规范，从而保证产品设计的一致性，提升整体产品质量。什么时候制作设计规范呢？设计规范不是凭空就产生，正常都是敲定主要页面或者页面完成以后，为了后续的工作展开制定规范。开始设计页面会有比较大创意空间，也是设计比较感性的一面，但规范的制定就是设计比较理性的一面。在统一的规范框架内，有一个整体观感的视觉形像示人。也促使团队的工作流程加以梳理，使之效率更高。一个APP的设计主要颜色选取来自ICON，ICON敲定了，后续的页面会根据色调进行设计和优化搭配。设计规范的内容正常设计规范会按下面几个步骤来：颜色，字体，图标，按钮，公共控件，模块 ，有了这些规范，会让用户使用过程有一个统一的感受& 。比如弹出框的使用，用户在前面使用过一个，会希望下一个弹出框也是相同的感受，默认使用习惯的延续。反过来，不同的弹出窗效果会让用户也茫然，是否跳转到别的页面。产品界面的设计，是用户在使用产品时，最直接的感官体验，也是企业形像间接的面向用户的直观体现。规范的整理项目进行中，如果有问题出现，就需要设计规范来为你证明了，很多时候空口无凭，规范的形成，一定要用文档、图表等方式整理出来，记录在案。使团队成员使用时，可以随时查阅。规范的介绍与使用标准，文字介绍一定要简洁，便于浏览。一套规范，就算做的再好，如果没有很好的监督执行，那只是装饰作用。所以，在达成共识的情况下，做每一个项目时都能够遵循设计规范，在规范的指导下完成工作，那么统一性的目的就可以实现。设计规范部分效果图展示：我的沈阳规范设计从产品到设计到前端再到开发和测试，这中间是需要经过很多环节才能最终上线的，每一个细节，每一个banner、每一个按钮都需要整个团队用心去设计，不用担心规范会变成“紧箍咒” ，套在每个团队成员的头脑上。让最好的想法、最优的效果展示给大家，这也是我们最初制定设计规范初衷的。所以亲们加油啊！坚持！哈哈！
提示：本站所有资源仅供学习与参考，请勿用于商业用途。转载请注明来自：
本周热点日志排行榜 ······
<img src="/uploads/userup/746/-1F5.jpg" width="50" height="50" title="打破平淡的背景设计,背景设计的重要性" />
打破平淡的背景设计,背景设计的重要性设计日志 11:49:08
爱昵二微码
扫描二维码即可关注爱昵图库哦爱昵推送手机用户快捷下载图集WebApp是针对NativeApp而产生的，Webapp最直接明了的定义就是一个针对Iphone、Android优化后的移动网站，它使用的技术无非就是HTML或HTML5、CSS3、JavaScript，服务端技术JAVA、PHP、ASP等。
今天，25学堂需要跟大家浅谈WebAPP设计的五个注意点及如何去设计webAPP
1. 必须要适配所有的智能手机设备
移动设备的屏幕是各式各样的，对设计影响较大的主要是屏幕分辨率、尺寸、屏幕方向这些因素。现在的iOS设备有320×480，640×960，，，这些分辨率，3.5寸、4寸、7.9寸、9.7寸这些尺寸等，未来还有更大的尺寸。
所以，需要解决Web app在不同屏幕下的界面适配问题。
最佳解决办法有2个：
1、在写前端页面的时候，css 采用100%布局
2、采用html5技术来布局开发。
1.1 适配不同分辨率
通过响应式网页的设计方法提升页面在不同分辨率下的兼容性：
由于手机屏幕尺寸下，一般来说只能一个模块一个模块地从上到下排列。此时设计者就需要考虑模块摆放的优先级了。一般来说，用户重点关注的、最近更新、与用户相关的信息应该放在前面。
另外最好以主流分辨率480×800进行设计，对略高于和略低于该分辨率的屏幕可将界面元素进行缩放，对间距、边距进行适当调整。
所以，在设定容器、图片、文本框的宽度时最好避免使用px单位，使用%可使页面在不同分辨率屏幕下保持布局和页面结构不发生改变。
1.2 平板电脑
使用CSS3的媒体查询(media query)语句可获得浏览器的高宽和设备的像素比，并可根据开发者的需要对不同的设备应用不同的样式表。所以开发者可以控制一个页面在不同设备上的表现。
由于手机屏幕和平板电脑的屏幕尺寸和像素都相去甚远，所以为了充分利用平板电脑的大屏优势，以获得良好的用户体验，最好在两种设备上使用不同的界面布局。相信iOS用户都有这样的感觉：有的App只适配iPhone，在iPad上运行则无法布满屏幕，只能点“2X”按钮显示一个粗糙的界面。还有一种App可同时兼容iPhone和iPad，在手机和平板的屏幕上都能完美显示，用户也无需单独下载两个版本。很明显，后者使用起来更方便，更美观。
Mobile Web App使用媒体查询功能即可实现这种功能。那么在平板电脑上，有哪些需要注意的设计点呢?
因为平板电脑多在横屏下使用，所以使用分栏视图可在一个界面内显示两个层级的内容，方便用户快速切换item。
首页多以宫格视图、Tab为主，微博、QQ这种以内容为主的界面将分栏视图作为默认首页也是可以的。在手机上最常使用的list在平板上就不是很常用了，整个屏幕显示list，不仅浪费空间，也没有分栏视图的操作高效。
需要注意的是，IE9以下的浏览器不支持media query.
1.3 横竖屏切换
由于目前还不能在webkit内核里禁止设备方向的旋转，所以如果用户的设备开启了屏幕方向根据重力自动旋转，那么运行于浏览器的Web App也是会跟着旋转的。
如果能够捕捉到设备的方向，可以对横竖屏分别进行布局设计，但最好能保证界面风格和样式不会有大的变化。
反例就是iPhone的音乐App，在竖屏下会显示歌曲list，但是切换到横屏下显示专辑封面。两种界面风格跳动太大会导致部分用户不适应，以为是两个不同的页面。计算器App也只有在横屏下才显示科学计算模式，竖屏下用户根本无法切换到该模式，连引导也没有。
宫格视图是横竖屏切换最平滑的布局，看看iOS系统的主屏幕就知道了。一个个应用程序图标在横竖屏切换时，几乎只是图标旋转了一下方向。
还有一点就是切换到横屏时，可自动进入全屏模式以显示更多的内容。否则标题栏和底部栏将会占去很多空间
2.WebAPP的交互动效
受浏览器性能影响，很多Native App能实现的华丽动画在里的表现并不是很好。所以应该果断去掉非必要的动效以保证Web App能够运行流畅。
因为很多动效会对用户起到很好的引导作用，如果没有这些动画，可能会导致用户对界面逻辑关系的理解产生混乱。这就对动效的设计提出了较高的要求。
总结了一下Web App的几点动效设计原则：
●尽量不使用不必要的动效。
●优先使用简单的动画。如平移、缩放。尽量避免使用3D动画。
●避免刷新页面。因为整个页面白屏，浏览器走进度条的体验会给用户浏览网页的感觉，而不是在使用app
●框架元素优先显示。只在内容加载区域显示loading动画
●避免跳变。在不影响性能的情况下，可尽量用缩放和平移动画，保证用户视觉焦点的延续性和理解的延续性。
●同类界面/对象，同层级界面/对象的动效保持一致。可帮助用户理解产品架构和导航逻辑。
●高层级界面的动效对应高级物理位置。如果左右平移的动画是用来切换上下一层级，那么首页应该是在最左边，如iOS。如果前后切换的动画是用来切换上下一层及，那么首页应该是在最上面，如Windows Phone。
3.WebAPP的内容布局和APP的风格要保持一致
讲导航和信息内容布局的文章众多，Mobile Web App既然要实现Native App的操作体验，照传统的移动客户端的设计模式去设计即可。只需要记住你设计的Web App需要运行在iOS, Android, Windows Phone等多个平台，多种设备上即可。
由于iOS相比其他平台，没有back按键，所以在iOS上运行需要保证界面内的导航能够实现闭环。所以Android上有些操作可以通过Menu键唤出，但是在iOS上就需要直接暴露出来。
下图左侧是Zaker的Android版，右侧是iPhone版。Android版的菜单栏需要点击Menu键才出现。
4.善于使用Native App的UI相关控件
使用Native App的UI控件，可以让Mobile Web App更有Native App的操作体验。常见的如Badge，Back button，Bubble，Picker，Indicator，Title bar，Dialog，Toast，Loading，Drap down to refresh，Notification等。下图分别是Facebook的Native App和Web App，由于后者使用了客户端常见的一些UI控件，所以用户很难从视觉上识别出后者是Web App.
避免使用传统的Web UI控件，如面包屑、文字链：
另外，在控件尺寸上也应该像Native App那样提供尽量大点击区域的控件。参照经验和各平台的官方人机界面指南，可以知道适合用户手指点击的尺寸应该在7-9mm之间，不能小于7mm。相邻点击控件的行距不应小于2mm。
5. WebAPP后期需要针对浏览器进行优化
为了兼顾浏览器的性能和交互，需要注意以下几点：
●页面使用尽量少的DOM元素;
●简化动效;
●避免与浏览器的交互冲突，如左右滑动，如浏览器的tab bar, action bar, 以及浏览器全屏后的虚拟按钮;
●考虑保存用户的哪些数据：设置、个人数据、阅读锚点、跳出页面等。
●规则图形用Canvas绘制，避免向服务器请求img.
●注意离线数据存储，通过manifest定义需要被缓存的文件，以便用户离线时使用。
●减少数据请求频率。
所以，当我们在设计webAPP的时候，不管采用哪种方法，都必须要注意这5大方面。才能设计出来优秀的webAPP。再者要多练习多阅读相关。
分享一下,与TA一见钟情~~
本文标题：
本文地址：http://www.25xt.com/webapp/5802.html
除非注明，本站文章均为原创或编译，转载请注明出处和原文链接，转载同时请务必保留原网站网址。
移动APP设计入门课程
为你推荐的相关文章
Copyright@ www.25xt.com All Rights Reserved ICP备案号：桂ICP备号-2本站声明所有资源均是网上搜集或网友上传提供，如有侵犯您的版权，请及时联系我们（），我们将尽快处理。