交互设计android

⑴ 浅谈iOS与Android设计规范：6类交互设计规范对比

iOS和Android两个不同的平台，肯定是有很多区别的，下面就从交互的角度，谈谈区别。

以前就读过IOS和Android的规范，但是觉得没啥大用处，因为现在APP为了保持一致性，通常在IOS和Android上的设计是一样的，而且一些小公司只设计IOS的交互原型，因为只要IOS上能用，安卓上肯定没问题，前段时间，和一个人聊，问我它俩的区别，当时一脸懵逼，不知从何说起。毕竟是两个不同的平台，肯定是有很多区别的，下面就从交互的角度，谈谈区别。
一、全局导航
IOS：通常放在底部，方便用户点击
Android：通常放在上面，下面有物理按键，防止误操作。

解析：因为Android比IOS多了物理按键，为了防止误操作，所以只能将全局导航放在上面，但是随着屏幕越来越大，上面是手指无法触及的区域，所以切换起来相对成本较高。
二、二级导航
IOS：通常放返回、上一级标题、标题（居中），操作通常只有一个
Android：通常返回控件、logo、下拉菜单、重要操作、更多操作

解析：IOS显示了上一级的名称，让用户点击返回后，心里有预期，Android放了APP的logo，增加了品牌性，但是就使用来讲，用户不知道点击会回到哪，下拉菜单和更多操作都需要点击才能显示，增加了操作步骤。
三、工具栏
IOS：通常放在最下面，方便操作
Android：放在导航栏里，将重要操作放在外面，其他放在更多里。

解析：IOS将操作都放在底部，区域更大，操作更方便。Android将操作放在了顶部，显得很拥挤，并且还收起了一部分，需要用户查找，但是却节省了空间，让内容显示区更大。
四、提示框
IOS：出现在屏幕中间，可以带图标，可以不带，可以是静态的，也可以是动态的。
Android：不可以带图标，不能是动态的，最多只可以带一个操作按钮，最多只能出现一个提示，不能和低端的悬浮按钮重合。

解析：IOS的设计理念是尽量不打扰用户，只要用户能看见变化，轻易不会出现提示，只有一些用户无法感知时，才会出现提示框，所以可以是动态的，像调节音量。Android的提示要比IOS重一些，因为它可以带一个按钮。
五、警示框
IOS：标题和按钮是必须的，可以有内容和输入

Android：主要有四种：用途、内容、事件、表现。
1、用途包含了标题，内容和事件。

六、手势定义
IOS的手势规定有8种，如下：

解析：IOS只有8种手势，Android有14种，但是很多都不常用，个人感觉IOS的8种已经完全够用了，定义那么多种，用户的学习成本就会提高，而且Android的有些手势并没有定义可以做什么，所以给出这么多手势也没有用。
结语
本文对IOS和Android的规范进行了对比，Android的规范那是相当详细，但是IOS的只给出了设计原则，所以，一些是我自己总结的，可能对比的还不够全面，欢迎大家一起讨论。

⑵ 设计开发一个完整的android系统，需要掌握哪些知识

看你想要做什么类型的app了，还有就是一个app的难易程度，不同的app使用功能的差异也导致不同的技术实现或者算法模型。对于一个app开发者
来说一个app从设计到最终实现需要懂得以下几个必要方面：
1、前期需求规划与信息、交互设计——你需要制定出一个完整的需求文档，流程图，功能文档，时序图。
2、交互设计、UI设计——设计出基本且完善的原型图和app基础的交互设计效果，以后再根据这些设计出完整的UI界面并学会切图，一些需要做自
适应的素材图片需要做点9patch。这里还需要你懂得px，pt和dp之间的换算，屏幕密度的换算和相互之间的系数，以便你的app能完美适应不同分
辨率设备。其中交互设计需要你懂得很多人机操作的技巧经验，掌握Axure等交互工具的运用，UI设计需要你掌握Photoshop和Illustrator等操作
。
3、使用ADT之类的开发环境进行app开发，你最基本的也得掌握java语言，熟悉android环境和机制，这里面涉及面广，请根据项目自行学习相关知
识。
4、如果不是单机版的app，需要用到服务器，那你还得掌握WebService相关知识和开发语言，PHP，常用的有ASP.Net，JSP等。
5、熟悉并能开发数据库。
6、某些功能需要做算法，这还需要一定得专业知识，尤其是数学基础。
7、熟悉API接口开发，这里包括你自行开发API的能力以及调用第三方API的经验。
8、熟悉TCP/IP，socket等网络协议和相关知识。
9、熟练掌握App发布的流程，打包，真机调试技巧，证书，上架。
App开发其实不一定适合一个人搞，太费劲，如果可以还是找团队或者公司比较好，毕竟每个人都有各自擅长的领域技术嘛。

⑶ ios和android设计规范区别

Android 整体视觉设计规范

App 界面的整体视觉组成大致可以分为四个部分：

StatusBar（状态栏）、TopBar（头部栏）、Body Content（内容区域）、FootBar（底部栏）。

StatusBar 的样式由系统 UI 决定，除背景配色外，不需要做其他的设计。

TopBar 两个系统平台规范上的显示高度与内容布局有明显的差异，按各自的规范进行设计。

Body Content 除控件外，采用相同的布局与视觉设计。

FootBar 除控件外，采用相同的布局与视觉设计。

 

二、Android差异化设计案例解读

 

1. StatusBar/TopBar 差异化设计

 

2. 常用的三个系统图标/控件差异化

 

3. 搜索/输入控件差异化

4. 弹窗样式差异化

 

 

三、Android系统交互与iOS系统交互的差异化设计

1. 交互方式：

除了上面提到了弹窗样式与交互差异化之外，对于一些系统交互行为，推荐尽量使用 iOS 与 Android 各自平台的系统控件与交互方式，降低开发与用户学习成本。系统交互行为主要包含以：返回上级/关闭当前页面的方式、通知开启或者关闭设置、发送/提交内容（键盘自带或者新增按钮点击）、Item 列表排序/删除、提示窗显隐、时间选择控件、手势操作等等。

2. 交互动效：

交互动效也推荐尽量使用 iOS 与 Android 各自平台的系统提供的动效。比如 iOS 的镜头切近与高斯模糊，Android 的纸墨磁吸等等。

单条 item 的交互差异示例

 

总体来说，就是以 iOS 版为参照，底部栏与中间内容区域尽量保持相同的设计，通过对状态栏、头部样式、控件（开关、选框、搜索、输入）、系统图标（返回、分享、更多）、弹窗样式、系统交互进行 Android 规范化差异，以保证该 App 的设计在两个不同的系统平台即能符合中国用户的使用习惯，又能适当体现系统的不同风格与特性。

⑷ android 和 ios 人机交互设计指南中最重要的几点是什么

android 和 ios 人机交互设计指南中最重要的几点告诉你，希望你能理解：
这是针对于处于开发中的API或技术的初步文档。虽然该文档在技术精确度上经过了严格的审核，但并非最终版本，仅供苹果开发者计划的注册会员使用。苹果提供这份机要文档的目的，是帮助你按照文中描述的方式对技术的选择及界面的设计开发进行规划。这些信息有可能发生变化，届时，你的设计开发方式需要基于最终版本的操作系统及文档进行相应的调整和测试。该文档或许会随着未来API或相关技术在的发展而进行更新。

审美的完整性
对app而言，审美的完整性并不是用来衡量app漂亮与否，或者塑造它的风格。而是通过app的外观、交互行为和功能共同传递一致的，清晰明了的信息。

用户关注app能否兑现此前承诺的功能，但是app的外观和交互行为也潜在地影响着用户。比如，一款帮用户处理严肃任务的app，可通过使用标准控件或可预见的交互方式让装饰性元素更为精妙和无打扰，从而让用户把注意力集中在对任务的处理上。

App清楚明了地把使用目的传达给了用户，这可以让用户更加信任它。不过，如果开发者通过入侵性的，轻佻的或者武断的UI向用户传递了混乱的信息，则用户可能会质疑app的可靠性和可信赖度。

另一方面，对一款鼓励沉浸式任务的的app，比如游戏，用户期待一个迷人的外观，和有趣、刺激以及鼓舞人心的发现。用户并不期望在游戏中完成一系列严肃性的或者生产性的任务，但他们期望游戏的外观和交互方式可以与游戏目的很好地融合在一起。

App需保持一致性
这样方便用户积累的知识和技巧在app各部分UI之间，在app之间进行迁移。一致性并不是盲目模仿其他app，也不是停滞不前，而是更关注用户熟悉的标准和范例。

决定你的iOS app是否要遵守一致性的原则，考虑下边几个问题：
1.你的app是否符合iOS的标准？App 正确使用系统提供的控件、视图以及图标了吗？App以可靠方式整合设备的功能了吗？
2.App自身是否一致？文本有没有使用统一的术语和风格？相同图标代表的意义是否一致？用户在不同地方执行了相同的操作，用户能否预测到将会发生什么样的结果？贯穿App的自定义UI元素的外观和交互方式是否一致？
3.App现在的版本与此前的版本是否一致？条款和意义是否一致？App的基本概念和主要功能本质上有没有发生变化？

直接操作
直接在屏幕上操作对象，而不使用单独的控件来操作，这样用户会更专注于当前的任务，他们也更容易理解操作产生的结果。

使用Multi-Touch 界面，用户可通过双指张开或者闭合来放大或者缩小图片和内容区域。在游戏中，玩家可以直接移动屏幕上的对象或者与对象进行直接的交互。 在一款iOS app中，以下动作可为用户提供直接操作的体验：
1.旋转或者移动设备以影响屏幕上的效果
2.使用手势直接操控屏幕上的对象
3.可看到动作产生的直接结果或可视化结果

反馈
反馈是对用户动作的承认，向他们展示操作的结果，更新他们任务的进程。内置iOS app为每位用户的动作提供了可觉察的反馈。在用户执行点击操作的过程中，列表项目和控件会持续几秒钟高亮状态，通过控件所处状态短暂的改变来显示进程的变化。

精巧的动画可以给用户有意义的反馈，可帮助用户清楚地知晓动作产生的结果。比如，列表可以动态地展示新增一行的操作，从而帮助用户跟踪视觉上的变化。

声音也可以给用户有用的反馈，但不应该是仅有的反馈机制，因为用户不能时刻倾听他们的设备发出了什么样的声音来反馈执行的动作。

隐喻
如果app中虚拟的对象和动作象征着熟悉的用户体验，那么不管这些体验是深植于真实世界还是数字世界，用户都可以快速掌握app的使用方法。在隐喻不涉及对象或动作局限性的情况下，App使用隐喻来暗示用法或者体验再好不过。

由于用户真实地与屏幕进行交互，因此iOS app的隐喻空间非常广阔。iOS 中的隐喻包括：
1.移动分层的视图来展现其下面的内容
2.在游戏中拖动、滑动或者轻扫对象
3.点击开关，滑动滑块以及旋转选择器
4.在杂志或书上进行翻页

用户控制
用户应该发起和控制动作，而不是app。一款app可以启发用户的动作行为方法，或者提醒用户危险后果，但是app撇开用户做决策是错误的。app能给用户他们想要的能力，也能帮他们规避不想要的结果，最好的app应该能在这两者之间正确地平衡。

当交互行为和控件是熟悉的，可预见的时候，用户对app会更有控制感。当交互动作简单直接的时候，用户对app的动作也更容易理解和记忆。用户期望在操作产生结果前有足够多的机会来取消它们，并且他们期望有机会确认自己的目的，从而执行一个具有潜在破坏性的动作。最后，用户期望能优雅地停止正在进行的操作。