能同时用于 Android 和 iOS的APP UI设计怎么做

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了能同时用于 Android 和 iOS的APP UI设计怎么做相关的知识,希望对你有一定的参考价值。

参考技术A  遵循这些步骤,你的 App 就能同时在 iosandroid 保持完美!
  1. 总体的样式
  从 iOS7 以后,Apple 就一直在采用扁平化的设计模式,去除了所有不必要的纹理和阴影等效果——和早些年间的版本完全不同。Google 的新 MD 设计规范有了一些更加细节的规定,通过一种叫逗纸片地的方法来创造更多的层级关系。
  2. 实体按钮
  Android 有一个返回按钮,点击它可以返回上一个屏幕。
  iPhone 上则没有这样一个按钮,所以需要有一种方式能够让用户回到先前的屏幕。通常的解决方案是在屏幕的左上角放置一个返回键。
  3. 通用元素
  两种平台之间的确存在着一些通用的元素,比如说状态栏和标题栏,它们会出现在每一屏的顶部。你不应当改变导航栏的高度,如果你想让 App 看起来更加原生的话。所以,我推荐你在设计的第一页就定义好标题栏的样式,然后在其他的屏幕上使用一个占位的方框来替代,这样能省下不少时间,但是你应当向程序员说明标题栏在不同的屏幕上都是一样的样式。
  不同平台上的导航栏有一定的差别。在 Android 上文本是左对齐的,然而 iOS 上是居中对齐的。在 iOS 上,很多企业都用它们的 logo 来替换首页标题栏中的文字,但是在 Android 设备上这不是一个好的主意。状态栏(显示你的网络、电量和时间信息)是系统组件,你不需要考虑设计它,只要确保它们不会对他人造成误解就好了。
  4. 导航
  或许iOS 和 Android 平台之间最大的区别就在于他们的导航样式了。Android 上最主要的导航方式是抽屉菜单,Android 用户们通常在这个菜单内进行跳转。而且在整个 App 中,这种体验是一贯的。Apple 的导航样式更倾向于 tab bar,它位于屏幕的底部,并且以一种很简单的方式实现上部内容的切换。当你设计 App 的结构的时候,你可以为不同的平台设计不同的导航样式。
  5. 要不要用卡片式
  在 UI 设计中,卡片正逐渐成为一种主要的 UI 设计样式,它们可以应付多种情况,而且给用户提供了一种能够呈现有效内容的便捷方式。视觉上,卡片非常适应于 Android 的 Material Design(它事实上源自于纸张的灵感)。使用阴影和卡片之间的合理间距能够创建一种自然的外观。
  在 iOS 上,使用卡片设计需要更加的小心谨慎,尽管一些大型的 App,诸如 Facebook 和 pinterest 的确使用了一种略微偏离 iOS 视觉规范的设计风格。Instagram 使用了一种完全扁平化的设计风格,尽管从结构的观点上看,用户的每一条推送都能被视为是一张卡片,instagram 的设计很值得你去花时间揣摩,它是如何遵循 iOS 视觉规范的。如果你要在 iOS 平台上应用阴影,你最好小心谨慎,尽量使得这些阴影不是那么的明显。
  6. 排版
  iOS 系统上的默认字体是 Helvetica Neue,在 Android 上则是 Roboto。尽管这两种字体在外观上有显著的差异,但是这两个字体的尺寸却是近乎相同的。如果你想要在设计的时候节省时间,那么用一款字体就可以,但是要和开发人员沟通在不同的平台上使用对应的字体。而在设计重要的布局结构和使用大号字体时,我建议你还是同时用这两种字体测试效果。
  如果你想要精益求精,那么你就要对不同平台上的设计规范更加注意。比如如下几条:
  Android 的 MD 设计需要用到更多的空格来进行布局
  在 MD 中字体大小的变化会更加多样
  在 iOS 上,字体没那么多大小差异,但是在字体重量上(Font weight)有更多的变化,同样允许你创建主次结构
  两个平台都使用比较细的字体来现实正文内容,然而,在下面的例子中,Android 使用了轻(Lighr)和常规(Regular)字体,而 iOS 使用了粗体(Bold)和常规字体
  这是一个非常简单的例子,向你展示了排版方面的一些细微的不同可以导致印象上的巨大差异——你能很快分辨你是在用 Android 手机还是在用 iPhone!
  7. 网格和触摸元件
  iOS(@1x 下 44px)和 Android(1:1 比率下 48p)都有对可触摸元件的设计规范。MD 规范同样建议对所有元素使用 8dp 网格对齐。
  在最近的项目上,我发现遵守 Android 的这些设计规范会更加安全,因为大一些的 48px 的按钮在两个平台上都表现良好,而且 MD 的规范更加全面,还经常更新。不管怎么说,你都应该在设计中使用网格,但是我们发现定义更加明确的 Android 网格会更好用一些。

APP接口版本兼容的问题

现在基本每个公司都做APP,所以大家都面临 APP接口版本兼容的问题。

iOS和android 要不断开发新版本,很多服务端开发都是在以前接口的逻辑上进行修改。新的APP和接口开发后,接口如何兼容老的APP?

有的公司 每次发布完APP,就强制用户更新到最新版本。不推荐这样,因为用户体验太差。

就算是用 强制更新,在苹果审核期间,新的APP接口和 老的接口 也必须能同时使用。

下面我们说下如何做,我们用的是最后一种方式,大家有不同意见可以 留言讨论。

一、客户端 做兼容,接口不用做兼容

1、APP强制更新(不建议)

接口URL:api.xxx.com/v1.0/xxxx.java

接口的URL中加入版本号,如上:v1.0。

每次发布新APP版本就强制更新。

灰度服务器 部署正在审核中的 接口版本(如:v1.1)。等审核通过后,将老版本的APP设置强制更新,这样老的接口就不用了。

然后把线上服务器重新部署上最新的代码,再去掉灰度服务器。

这样APP接口全部访问正式的线上服务器。

2、热更新

紧急的小需求可以用热更新,大的需求建议还是用原生的代码,因为你用热更新修改完(用JS或Lua),最后还要在原生代码里修改。

网游用热更新的比较多,因为网游的APP太大,不可能加个小关卡 就要求用户重新下载,并且游戏更新比企业级APP更频繁,用热更新可以不断新加关卡、场景、活动推广。

3、React Native 和Weex

Weex比React Native好用,建议大家可以尝试下。个人建议先不要 大范围用它们来做,毕竟它们只是第三方的东西,有的东西也不太完善。

 

二、服务端 做 版本兼容

全部接口版本是否统一:

  • 所有的接口都用 相同的版本号:这样要发一个APP新版本就统一修改版本号,好修改,但是如果想修改其中一个接口的版本号就不行了。

  • 每个接口的版本号可以不一样:这样比较灵活,建议这样做。

因为已经好多年没有做过服务端了。下面的见解如果有错误,希望指正。

1、每个接口逻辑里 加if 判断(不建议)

接口URL:api.xxx.com/api?version=v1&..

if (version == ‘1.5.0’) {
  do_something
} else if (version ==‘1.4.0) {
  do_something
}

 

优点:实现简单

缺点:不同版本的逻辑都在一个方法里,在于容易造成代码混乱,不利于维护。

2、不同的文件夹

相当于每个接口版本都是一个独立的项目。放到服务器的独立文件夹里。

例如:

接口URL:api.xxx.com/v1.0/xxxx.php

文件夹位置:Controller/V1.0/

-----------------/xxxx.php

文件夹位置:Controller/V2.1/

-----------------/xxxx.php

优点:版本逻辑分开维护。看url就能知道哪个版本。删除多余版本 不用修改代码。

缺点:同个接口不同版本 文件是重复的。并且 如果有个接口前几版就有问题,一直遗留到现在,就需要改好几套一样的代码。

3、不同版本 用不同的方法 :

类似:

接口URL:api.xxx.com/v1.0/xxxx.php

class XXXX{

    public functionV1_0() { }

    public functionV2_0() { }

}

 

java或者C# 都有路由配置,可以用路由配置不同版本的URL跳转到不同的方法里。

 

三、结尾

自己 已经有好几年没做 服务端了。如果大家有什么好办法,可以留言,谢。

接口兼容其实主要是服务端的任务。APP的工作量相对简单。

大家都是怎么做的?

 

以上是关于能同时用于 Android 和 iOS的APP UI设计怎么做的主要内容,如果未能解决你的问题,请参考以下文章

Flutter objectbox:我可以用于生产 APP(仅限移动设备 Android 和 iOS)

使用Flutter 编写一个同时运行在Android和iOS上的股票APP

使用Flutter 编写一个同时运行在Android和iOS上的股票APP

//判断安卓 和ios

Hybrid App 开发实践总结

Android自定义URL,用于在iOS中打开App