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的只给出了设计原则，所以，一些是我自己总结的，可能对比的还不够全面，欢迎大家一起讨论。
[img]一、android篇
1、android分辨率
Android的多分辨率，一向是设计师和开发者非常头疼的事儿。尽管如此，对于多分辨造成的复杂问题，也是大家要优先解决的。Android支持多种不同的dpi模式：ldpi 、mdpi 、hdpi 、xhdpi 、xxhdpi 、xxxhdpi
注意，ppi、dpi 是密度单位，不是度量单位 ：
dpi主要应用于输出，重点是打印设备上；ppi对于设计师应该比较熟悉，photoshop画布的分辨率常设置为72像素/英寸，这个单位其实就是ppi 。尽管概念不同，但是对于移动设备的显示屏，可以看作ppi=dpi 。
ppi的运算方式是：PPI = √（长度像素数² + 宽度像素数²） / 屏幕对角线英寸数。即：长、宽各自平方之和的开方，再除以屏幕对角线的英寸数。
以iphone5为例，其ppi=√（1136px² + 640px²）/4 in=326ppi（视网膜Retina屏）
对于android手机，一个不确切的分法是，720 x 1280 的手机很可能接近 320 dpi （xhdpi模式），480 x 800 的手机很可能接近 240 dpi （hdpi模式），而320 x 480 的手机则很接近 160 dpi（mdpi模式）。
2、单位换算方法
android开发中，文字大小的单位是sp，非文字的尺寸单位用dp，但是我们在设计稿用的单位是px。这些单位如何换算，是设计师、开发者需要了解的关键。
简单理解的话，px（像素）是我们UI设计师在PS里使用的，同时也是手机屏幕上所显示的，dp是开发写layout的时候使用的尺寸单位。
为什么要把sp和dp代替px？ 原因是他们不会因为ppi的变化而变化，在相同物理尺寸和不同ppi下，他们呈现的高度大小是相同。也就是说更接近物理呈现，而px则不行。
根据单位换算方法，可总结出：
当运行在mdpi下时，1dp=1px ：也就是说设计师在PS里定义一个item高48px，开发就会定义该item高48dp ；
当运行在hdpi模式下时，1dp=1.5px ：也就是说设计师在PS里定义一个item高72px，开发就会定义该item高48dp ；
当运行在xhdpi模式下时，1dp=2px ：也就是说设计师在PS里定义一个item高96px，开发就会定义该item高48dp ；
当你的app需要适配多个dpi模式的时候，请参考图1的比例进行换算 。
3、设计稿基本元素的尺寸设置
为了适应多分辨率的手机，理想的方式是为每种分辨率做一套设计稿，包括所用到的icon、设计稿标注等。但在实际开发中，这种方法耗时耗力。所以通常会选择折中的方法。
方法一 ：在标准基础上（比如xhdpi）开始，然后放大或缩小，以适应到其他尺寸。不足之处是，对于更高分辨率的手机，图标被放大后会导致质量不高。
方法二： 以最高分辨率为基准设计，然后缩小适应到所需的小分辨率上。缺点是，图标等若都最大尺寸，加载时速度慢且耗费流量较多，对于小分辨率的用户也不够好。
结合友盟的分辨率占比数据、也为了方便换算到android开发中的尺寸单位， 推荐设计稿的画布尺寸选用 720X1280 ，分辨率仍旧为72ppi（像素/英寸）。
在android规范中对于导航栏、工具栏等的尺寸没有明确的规定。但根据48dp原则，以及一些主流的android应用的截图分析，总结一下尺寸要求：
状态栏高度 ：50 px
导航栏、操作栏高度 ：96 px=48dp x 2
主菜单栏高度 ：96 px
内容区域高度 ：1038 px （1280-50-96-96=1038）
Android最近出的手机都几乎去掉了实体键，把功能键移到了屏幕中，高度也和菜单栏一样为：96 px
4、图标和字体大小（来自官方规范文档）
a、启动图标（home页或app列表页）
整体大小为48 x 48 dp
b、操作栏图标，代表用户在app中可以使用到的最重要的图标
整体大小为32 x 32 dp ，图形实际区域为 24 x 24 dp
c、小图标/场景图标，提供操作或特定项目的状态。
比如gmail app的星型标记、一些内容展开收起用到的向下向上的图标等。整体大小为16 x 16 dp ，图形实际区域为 12 x 12 dp 。
d、通知图标
如果app有通知，要提供一个有新通知时显示在状态栏的通知图标。整体大小为24 x 24 dp ，图形实际区域为 22 x 22 dp 。
注：android规范提供的尺寸单位是dp，若设计稿尺寸设为720 x 1280 ，图标大小需在规范要求的尺寸数字上乘以2。比如操作栏图标32 x 32 dp ，则设计稿上应该是64 x 64 px 。
e、字体大小
Android规范中的要求如下：
前面提到Android开发中的字号单位是sp，而换算关系是 sp*ppi/160 = px 。所以720 x 1280尺寸的设计稿上，字体大小可选择为 24px 、28px 、32px 、36px ，主要根据文字的重要程度来选择，特殊情况下也可能选择更大或更小的字体。
f、其他尺寸要求
通常把48dp作为可触摸的UI元件的标准。
为什么要用48dp呢？一般来说，48dp转化为一个物理尺寸约9毫米。通常建议目标大小为7-10毫米，以方便用户手指能准确并且舒适触摸目标区域 。
如果你设计的元素高和宽至少48dp，你就可以保证：
（1）触摸目标绝不会比建议的最低目标（7mm）小，无论在什么屏幕上显示。
（2）在整体信息密度和触摸目标大小之间取得了一个很好的平衡。
另外，每个UI元素之间的空白通常是8dp 。
二、iOS篇
1、分辨率
iPhone 界面尺寸：
iPad 界面尺寸：1024×768、2048×1536
（以上单位都是像素，至于分辨率一般网页UI和移动UI基本上都只要 72 ppi）
2、单位换算px、pt
这里需要先区分pt、px，pt(磅值)是物理长度单位，指的是72分之一英寸。手机上看来同一大小的字磅值是一样的，但是换算成不同分辨率手机的字号px值不一样。（px=pt*ppi/72）
iPhone在出retina屏(也就是4S)之前的屏幕像素是320x480px，屏幕密度是163ppi，4S的屏幕像素是640x960px，屏幕密度是326ppi，翻了一倍。iPhone5的ppi没有变化，兼容性方面要增加类似首屏画面等程序上的判断。
在iPhone界面上元素的定位、尺寸是通过一个单位point，而非px，屏幕上固定有320x480pt，retina屏两倍的分辨率改变的只是pt和px之间的比例而已，这样就能实现不改变程序，只上传两套图片就兼容两个分辨率。
****在设计的时候并不是每个尺寸都要做一套，尺寸按自己的手机尺寸来设计，比较方便预览效果，一般用 640×960 或者 640×1136 的尺寸设计。其中设计稿的画布分辨率设为默认的72ppi（此时1px=1pt ），所以设计师可以统一采用px为单位。
开发拿到设计稿时，将上面标注的以px为单位的字号大小、图像尺寸除以2，就是非retina屏上的pt值，这样在retina屏上也可以根据此pt值换算对应的px大小，以确保不同的分辨率下有合适的效果。****
3、基本元素的尺寸设置
iPhone的APP界面一般由四个元素组成，分别是：状态栏、导航栏、主菜单栏以及中间的内容区域。
这里取用 640×960 的尺寸设计，那我们就说说在这个尺寸下这些元素的尺寸：
状态栏：就是我们经常说的信号、运营商、电量等显示手机状态的区域，其高度为：40 px
导航栏：显示当前界面的名称，包含相应的功能或者页面间跳转的按钮，其高度为：88 px
主菜单栏：类似于页面的主菜单，提供整个应用的分类内容的快速跳转，其高度为：98 px
内容区域：展示应用提供的相应内容，整个应用中布局变更最为频繁的，其高度为：734 px=960-40-88-98
以上尺寸适用于 iPhone 4、4S，iPhone5/5s 的 640×11136 的尺寸，其实就是中间的内容区域高度增加到：910 px，其他尺寸也同上。
4、常用图像、图标大小（来自官方规范文档）
单位：像素
5、字体大小
iOS交互设计规范文档上，对字体大小没有做严格的数值规定，只提供了一些指导原则：
单位：点pt
– 即便用户选择了最小文字大小，文字也不应小于 22 点。作为对照，正文样式在大字号下使用 34 点字体大小作为默认文字大小设置。
– 通常来说，每一档文字大小设置的字体大小和行间距的差异是 2 点。例外情况是两个标题样式，在最小、小和中等设置时都使用相同字体大小、行间距和字间距。
– 在最小的三种文字大小中，字间距相对宽阔；在最大的三种文字大小中，字间距相对紧密。
– 标题和正文样式使用一样的字体大小。为了将其和正文样式区分，标题样式使用加粗效果。
– 导航控制器中的文字使用和大号的正文样式文字大小（明确来说，是 34 点）。
– 文本通常使用常规体和中等大小，而不是用细体和粗体。
百度用户体验做过的一个小调查：
单位：像素px
还有个方法就是找你觉得好的APP应用，手机截图后放进PS自己对比调节字体大小。
UI设计师在根据原型进行设计稿设计的时候，Android和IOS UI规范都是不同的，最好的条件下就会制作两个版本的设计稿来进行开发，下面我们一起来了解一下Android和IOS UI规范的区别。
01
先从设计稿尺寸开始说，Android的设计稿尺寸我们选择的是360*640，而IOS的设计稿尺寸为375*667。
02
从上到下开始了解，最上方的是状态栏，Android状态栏的高度为25px，IOS状态栏的高度为20px。
03
接下来就是导航栏，Android导航栏的高度为45px，IOS导航栏的高度为49px，两个版本中导航文字都是18px。
04
IOS导航栏有一点不同，那就是下方会多1px的分界，一般我们可用描边，或者是用Y=1的阴影来表示。
05
最下边就是标签栏了，Android标签栏的高度为50px，IOS标签栏的高度为49px。
06
IOS的标签也不同，也有向上的1px分界，用Y=-1的阴影或者是描边来表示。
07
在标签栏中肯定就是ICON图标了，Android和IOS的图标点击范围最小都是24px，IOS±4px调整，Android±8px调整。
08
关于设计的时候排版间距的问题，我的习惯是按照8px的倍数来排版，当然你也可以用10px，看个人习惯了。
特别提示
本文尺寸均为1x。
硬件抽象层模块编写规范
硬件抽象层最终都会生成.so文件，放到系统对应的目录中。在系统使用的时候，系统会去对应目录下加载so文件，实现硬件抽象层的功能。因此硬件抽象层的加载过程就是我们使用so的一个接口。先了解加载过程从源头了解抽象层模块儿的编写规范。
1、硬件抽象层加载过程
系统在加载so的过程中，会去两个目录下查找对应id的so文件。这两个目录分别是/system/lib/hw和/vendor/lib/hw。
so文件的名字分为两个部分例如id.prop.so，第一部分是模块id。第二部分是系统prop的值，获取顺序为“ro.hardware”、“ro.producat.board”、“ro.board.platform”、“ro.arch”，如果prop都找不到的话，就用default。（不是找不到prop的值，是找不到prop值对应的so文件）。
负责加载硬件抽象层模块的函数是hw_get_module，所在的文件是/hardware/libhardware/hardware.c如下：
/** Base path of the hal modules */
#if defined(__LP64__)
#define HAL_LIBRARY_PATH1 "/system/lib64/hw"
#define HAL_LIBRARY_PATH2 "/vendor/lib64/hw"
#else
#define HAL_LIBRARY_PATH1 "/system/lib/hw"
#define HAL_LIBRARY_PATH2 "/vendor/lib/hw"
#endif
/**
* There are a set of variant filename for modules. The form of the filename
* is ".variant.so" so for the led module the Dream variants
* of base "ro.product.board", "ro.board.platform" and "ro.arch" would be:
*
* led.trout.so
* led.msm7k.so
* led.ARMV6.so
* led.default.so
*/
static const char *variant_keys[] = {
"ro.hardware", /* This goes first so that it can pick up a different
file on the emulator. */
"ro.product.board",
"ro.board.platform",
"ro.arch"
};
static const int HAL_VARIANT_KEYS_COUNT =
(sizeof(variant_keys)/sizeof(variant_keys[0]));
/**
* Load the file defined by the variant and if successful
* return the dlopen handle and the hmi.
* @return 0 = success, !0 = failure.
*/
static int load(const char *id,
const char *path,
const struct hw_module_t **pHmi)
{
int status;
void *handle;
struct hw_module_t *hmi;
/*
* load the symbols resolving undefined symbols before
* dlopen returns. Since RTLD_GLOBAL is not or'd in with
* RTLD_NOW the external symbols will not be global
*/
handle = dlopen(path, RTLD_NOW);
if (handle == NULL) {
char const *err_str = dlerror();
ALOGE("load: module=%s\n%s", path, err_str?err_str:"unknown");
status = -EINVAL;
goto done;
}
/* Get the address of the struct hal_module_info. */
const char *sym = HAL_MODULE_INFO_SYM_AS_STR;
hmi = (struct hw_module_t *)dlsym(handle, sym);
if (hmi == NULL) {
ALOGE("load: couldn't find symbol %s", sym);
status = -EINVAL;
goto done;
}
/* Check that the id matches */
if (strcmp(id, hmi-id) != 0) {
ALOGE("load: id=%s != hmi-id=%s", id, hmi-id);
status = -EINVAL;
goto done;
}
hmi-dso = handle;
/* success */
status = 0;
done:
if (status != 0) {
hmi = NULL;
if (handle != NULL) {
dlclose(handle);
handle = NULL;
}
} else {
ALOGV("loaded HAL id=%s path=%s hmi=%p handle=%p",
id, path, *pHmi, handle);
}
*pHmi = hmi;
return status;
}
/*
* Check if a HAL with given name and subname exists, if so return 0, otherwise
* otherwise return negative. On success path will contain the path to the HAL.
*/
static int hw_module_exists(char *path, size_t path_len, const char *name,
const char *subname)
{
snprintf(path, path_len, "%s/%s.%s.so",
HAL_LIBRARY_PATH2, name, subname);
if (access(path, R_OK) == 0)
return 0;
snprintf(path, path_len, "%s/%s.%s.so",
HAL_LIBRARY_PATH1, name, subname);
if (access(path, R_OK) == 0)
return 0;
return -ENOENT;
}
int hw_get_module_by_class(const char *class_id, const char *inst,
const struct hw_module_t **module)
{
int i;
char prop[PATH_MAX];
char path[PATH_MAX];
char name[PATH_MAX];
char prop_name[PATH_MAX];
if (inst)
snprintf(name, PATH_MAX, "%s.%s", class_id, inst);
else
strlcpy(name, class_id, PATH_MAX);
/*
* Here we rely on the fact that calling dlopen multiple times on
* the same .so will simply increment a refcount (and not load
* a new copy of the library).
* We also assume that dlopen() is thread-safe.
*/
/* First try a property specific to the class and possibly instance */
snprintf(prop_name, sizeof(prop_name), "ro.hardware.%s", name);
if (property_get(prop_name, prop, NULL) 0) {
if (hw_module_exists(path, sizeof(path), name, prop) == 0) {
goto found;
}
}
/* Loop through the configuration variants looking for a module */
for (i=0 ; iHAL_VARIANT_KEYS_COUNT; i++) {
if (property_get(variant_keys[i], prop, NULL) == 0) {
continue;
}
if (hw_module_exists(path, sizeof(path), name, prop) == 0) {
goto found;
}
}
/* Nothing found, try the default */
if (hw_module_exists(path, sizeof(path), name, "default") == 0) {
goto found;
}
return -ENOENT;
found:
/* load the module, if this fails, we're doomed, and we should not try
* to load a different variant. */
return load(class_id, path, module);
}
int hw_get_module(const char *id, const struct hw_module_t **module)
{
return hw_get_module_by_class(id, NULL, module);
}
找到so文件之后，调用方法load方法去加载对应的so文件，并返回hw_module_t结构体。load方法源码在上面程序中。
load方法首先调用dlopen加载对应的so文件到内存中。然后用dlsym方法找到变量HAL_MODULE_INFO_SYM_AS_STR符号对应的地址，这个地址也就是一个hw_module_t结构体，然后从这个结构体中拿出id比对load方法出入的id是否一致，如果是的话表示打开成功。加载过程完成。
HAL_MODULE_INFO_SYM_AS_STR这个符号值为HMI，也就是必须要保证这个符号之后是一个hw_module_t。接下来的规范中有这个要求。
到此，模块加载完成
2、硬件抽象层模块编写规范
硬件抽象层有两个结构体，一个是hw_module_t和hw_device_t，定义在hardware.h中。
首先说一下hw_module_t的编写规范。
1、必须要有一个“自定义硬件抽象层结构体”，且结构体第一个变量类型要为hw_module_t。
2、必须存在一个HARDWARE_MODULE_INFO_TAG的符号，且指向“自定义硬件抽象层结构体”。在加载的时候根据这个符号找到地址，并把地址的转变为hw_module_t，这也是为什么第一条中hw_module_t必须要在第一个的原因。
3、hw_module_t的tag必须为HARDWARE_MODULE_TAG
4、结构体中要有一个方法列表，其中要有一个open方法。用open方法获得hw_device_t
接下来说一下hw_device_t的编写规范
1、必须要有一个“自定义硬件设备结构体”，且结构体第一个变量类型要为hw_device_t。
2、hw_device_t的tag必须为HARDWARE_DEVICE_TAG
3、要有一个close函数指针，来关闭设备
按照上面规范编写的硬件抽象层就可以由系统加载并正确获取到device。具体的应用层逻辑在device中实现。
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 的设计在两个不同的系统平台即能符合中国用户的使用习惯，又能适当体现系统的不同风格与特性。
