ios开发适配问题,ios移动端适配

IOS项目新手引导页图片适配方案

基本上每个IOS APP都会有新手引导页面这个功能，常规的就是几张静态图片，可以左右滚动。既然涉及到图片，就肯定会存在适配的问题（为了达到最优的体验效果，一般都会针对不同的分辨率设计不同尺寸的图片），本文主要就是讨论如何适配的问题。

2.1 方案一

根据屏幕分辨率的不同，使用不同的图片。

2.2  方案二

熟悉IOS开发的人都知道，每一个ios项目中，都有一个Assets.xcassets文件夹，用来管理项目中所有的图片（AppIcon、LaunchImage、其他业务图片）。

从上面的截图我们可以看到，xcode提供了两个内置的类型AppIcon、LaunchImage。我们只要提供正确尺寸的图片，ios系统就能在不同分辨率的设备上使用对应的图片而无需我们自己指定；另外就是我们自己创建的（avatar），提供2x、3x这两种类型的图片即可（1x的设备现在基本上找不到了，而且当前的ios系统也不支持1x的设备）。那么问题来了，我们自己创建的图片集合，只有3个类型（1x、2x、3x），并不能按照分辨率来设定。再看一下上面的截图，有一个“show”的图片集合，形式如下：

咦！这个鬼东西是怎么搞出来的？我们先看看Assets.xcassets文件夹在硬盘上的组织形式：

从上图我们可以看到，系统内置的两种类型AppIcon、LaunchImage对于的文件夹为AppIcon.appiconset、LaunchImage.launchimage，我们自己创建的图片集合avatar对应的文件夹为avatar.imageset。讲到这里，你应该大概猜到了show这个图片集合是怎么创建出来了吧？

1、先创建一个LaunchImage类型的图片集合；

2、修改名称（LaunchImage→show）

3、修改文件夹名称(show.launchimage→show.imageset)

回到正题，在show这个图片集合里面，我们就可以轻松的根据分辨率设置2x、3x类型的图片。

现在我们可以按照下图的方式使用新手引导图片了：

亲测：不同分辨率的设备，展示对应的图片。

我们注意到，show.imageset文件夹中有一个文件Contents.json，正是这个文件，ios系统才能根据设备类型展示对应的图片资源。Contents.json文件内容如下：

系统展示图片的时候，会先解析这个文件，然后根据设备的分辨率，找到对应的图片。

相关问答

Q1: iOS 四种iPhone屏幕适配方案(借鉴)

Come on! 来看看 主流的适配方案吧

随着苹果发布两种新尺寸的大屏iPhone 6，iOS平台尺寸适配问题终于还是来了，移动设计全面进入“杂屏”时代。看看下面三款iPhone尺寸和分辨率数据就知道屏幕有多杂了。

当然除了这三种还有iPhone4 屏幕是 640*960,加起来就有四种屏幕了，你有没有感觉很复杂，发过愁吗，我们来慢慢分析下

加上Android生态中纷繁复杂的各种奇葩尺寸，现在APP设计开发必须考虑适配大、中、小三种屏幕。所以如何做到交付一套设计稿解决适配大中小三屏的问题？设计和开发之间采用什么协作模式？一个基本思路是：

1、选择一种尺寸作为设计和开发基准；

2、定义一套适配规则，自动适配剩下两种尺寸；

3、特殊适配效果给出设计效果。

来看一下手机淘宝的iPhone 6/iPhone 6 Plus采用的协作模式，再慢慢说明原委。

第一步，视觉设计阶段，设计师按宽度750px（iPhone 6）做设计稿，除图片外所有设计元素用矢量路径来做。设计定稿后在750px的设计稿上做标注，输出标注图。同时等比放大1.5倍生成宽度1125px的设计稿，在1125px的稿子里切图。

第二步，输出两个交付物给开发工程师：一个是程序用到的@3x切图资源，另一个是宽度750px的设计标注图。

第三步，开发工程师拿到750px标注图和@3x切图资源，完成iPhone 6（375pt）的界面开发。此阶段不能用固定宽度的方式开发界面，得用自动布局（auto layout），方便后续适配到其它尺寸。

第四步，适配调试阶段，基于iPhone 6的界面效果，分别向上向下调试iPhone 6 plus（414pt）和iPhone 5S及以下（320pt）的界面效果。由此完成大中小三屏适配。

为什么选择iPhone 6作为基准尺寸？

当面对大中小三种屏幕需要适配的时候，很容易想到先做好一种屏幕，再去适配剩下两种屏幕。第一个决定是到底以哪种屏幕作为设计和开发的基准尺寸。我们选择中间尺寸的iPhone 6（750px/375pt）作为基准，基于几个原因：

1、从中间尺寸向上和向下适配的时候界面调整的幅度最小。375pt下的设计效果适配到414pt和320pt偏差不会太大。假设以414pt为基准做出很优雅的设计，到320pt可能元素之间比例就不是那么回事了，比如图片和文字之间视觉比例可能失调。

2、iPhone 6 plus有两种显示模式，标准模式分辨率为1242x2208，放大模式分辨率为1125x2001（即iPhone 6的1.5倍）。可见官方系统里iPhone 6和iPhone 6 plus分辨率之间就存在1.5倍的倍率关系。很多情况下这两种尺寸可以用1.5倍直接等比适配。

3、1242x2208这个奇葩的数值是苹果官方都不愿意公开宣传的一个分辨率，不便于记忆和计算栅格。640x1136虽然是广泛应用的一个分辨率，但是大屏时代依然以小尺寸为设计基准显然不合时宜，设计师会停留在小屏的视角做设计。

所以，iPhone6的750x1334是最适合基准尺寸。

只交付一套设计稿，默认用什么规则来适配？

前文提到适配策略是先选择iPhone 6作为基准设计尺寸，然后通过一套适配规则自动适配到另外两种尺寸。这套适配规则总结起来就一句话：文字流式，控件弹性，图片等比缩放

控件弹性指的是，navigation、cell、bar等适配过程中垂直方向上高度不变；水平方向宽度变化时，通过调整元素间距或元素右对齐的方式实现自适应。这样屏幕越大，在垂直方向上可以显示更多内容，发挥大屏幕的优势。

按照上述默认适配规则，大中小三种屏幕显示效果均相同。有时候想在大屏幕显示更多内容，需要设计出特殊适配效果。比如App store首页焦点图，从iPhone 6适配到iPhone 6 plus时焦点图尺寸和排版做了特殊处理。底下应用列表也从一排3+个变成一排4+个，真正实现了大屏幕显示更多内容的理念。这些就需要设计师给出相应设计稿。

读完你懂了吗，如果有疑问，欢饮留言跟我讨论╰(￣▽￣)╮

原文地址

Q2: iOS开发：iPhone尺寸和适配

我们通常所说的iPhone5屏幕尺寸为4英寸、iPhone6屏幕尺寸为4.7英寸,指的是显示屏对角线的长度(diagonal)

PPI(Pixel Per Inch by diagonal):表示沿着对角线,每英寸所拥有的像素(Pixel)数目。

PPI数值越高,代表显示屏能够以越高的密度显示图像,即通常所说的分辨率越高、颗粒感越弱。

根据勾股定理

计算结果稍有出入,这是因为像素的离散采样有锯齿效应。

早期的iPhone3GS的屏幕分辨率是320*480(PPI=163),iOS绘制图形(CGPoint/CGSize/CGRect)均以point为单位(measured in points):

后来在iPhone4中,同样大小(3.5 inch)的屏幕采用了Retina显示技术,横、纵向方向像素密度都被放大到2倍,像素分辨率提高到(320x2)x(480x2)= 960x640(PPI=326), 显像分辨率提升至iPhone3GS的4倍(1个Point被渲染成1个2x2的像素矩阵)。

在同样的逻辑坐标系下(320x480):

为了自动适应分辨率,系统会根据设备实际分辨率,自动给UIScreen.scale赋值,该属性对开发者只读。

在同样的逻辑分辨率下,可以通过scale参数识别是iPhone3GS还是iPhone4(s)。以下基于nativeScale参数,定义了探测机型是否为iPhone6+的宏

--------------------------------------------------------------------------------那么,同样的分辨率和scale,如何区分机型iPhone4与4s、iPhone5与5s呢?通过[[UIDevice currentDevice] model]只能判别iPhone、iPad、iPod大类,要判断iPhone具体机型型号,则需要通过sysctlbyname("hw.machine")获取详细的设备参数信息予以甄别。

iPhone3GS时代,我们为一个应用提供图标(或按钮提供贴图),只需要icon.png。针对现在的iPhone4~6 Retina显示屏,需要制作额外的@2x高分辨率版本。

Phone6+在实际渲染时,downsampling/1.15(1242x2208-1080x1920),准确的讲,应该是@2.46x。苹果为方便开发者用的是@3x的素材,然后再缩放到@2.46x上。

参考： 一张图帮你看懂 iPhone 6 Plus 屏幕分辨率

1

该方法使用系统缓存,适合表视图重复加载图像的情形。同时该API根据UIScreen的scale,自动查找包含对应高倍图后缀名(@2x)的文件,如果找到二倍图,则image.scale=2.0,对应逻辑size大小以point度量(pixel度量的一半);如果没找到设置默认image.scale=1.0,对应逻辑size大小同像素尺寸。因此,

2

这组方法创建的UIImage对象 没有使用系统缓存 ,并且指定文件名必须包含明确的高倍图后缀。

3

//考虑  转屏  的影响,按照实际屏幕方向(UIDevice  Orientation)的宽高

//不考虑转屏的影响,只取竖屏(UIDevice OrientationPortrait)的宽高

待续

Q3: ios和android 浏览器适配问题总结

移动端、 适配（兼容）、 ios点击事件300ms延迟、 点击穿透、 定位失效......

关于Web移动端Fixed布局的解决方案，这篇文章也不错

详细介绍见这里：

一篇文章有详细介绍，地址：

//问题一解决，我目前用的是js。如下

//问题二，是因为form提交默认做了表单验证，step默认是1,要设置step属性，假如保留2位小数，写法如下：

input type="number"step="0.01"/

关于step，我在这里做简单的介绍，input 中type=number，一般会自动生成一个上下箭头，点击上箭头默认增加一个step，点击下箭头默认会减少一个step。number中默认step是1。也就是step=0.01,可以允许输入2位小数，并且点击上下箭头分别增加0.01和减少0.01。

假如step和min一起使用，那么数值必须在min和max之间。

看下面的例子：

input type="number"step="3.1"min="1"/

输入框可以输入哪些数字？

首先，最小值是1，那么可以输入1.0，第二个是可以输入（1+3.1）那就是4.1,以此类推，每次点击上下箭头都会增加或者减少3.1，输入其他数字无效。这就是step的简单介绍。

//问题三，去除input默认样式

解决方式如下：

设置如下：

可以设置如下：

iOS 浏览器横屏时会重置字体大小，设置 text-size-adjust 为 none 可以解决 iOS 上的问题，

但桌面版 Safari 的字体缩放功能会失效，因此最佳方案是将 text-size-adjust 为 100% 。

这个不是 BUG，由于自动播放网页中的音频或视频，会给用户带来一些困扰或者不必要的流量消耗，所以苹果系统和安卓系统通常都会禁止自动播放和使用 JS 的触发播放，必须由用户来触发才可以播放。

解决方法思路：先通过用户 touchstart 触碰，触发播放并暂停（音频开始加载，后面用 JS 再操作就没问题了）。

这个我感觉没有什么好的解决方案，用如下方法

有些机型的搜索input控件会自带close按钮（一个伪元素），而通常为了兼容所有浏览器，我们会自己实现一个，此时去掉原生close按钮的方法为:

如果想使用原生close按钮，又想使其符合设计风格，可以对这个伪元素的样式进行修改。

//zepto方式:

Q4: iOS开发 - iOS15导航栏适配（Object-C、Swift）

Swift版导航栏适配参考

在iOS 13中给导航的 UINavigationBar 增加了 scrollEdgeAppearance 属性应用在iOS 14及更早版本的大标题导航栏上，在iOS 15中 scrollEdgeAppearance 属性适用于所有的导航栏

官方解释：描述当关联的UIScrollView到达与导航条相邻的边缘(导航条的上边缘)时要使用的导航条的外观属性。如果没有设置，将使用修改后的standardAppearance

scrollEdgeAppearance 与 standardAppearance 一样同属于 UINavigationBarAppearance 类型 父类是 UIBarAppearance

其中影响导航栏颜色、阴影涉及到以下属性

因为 scrollEdgeAppearance = nil ，当前控制器如果使用有 ScrollView 类的控件，当 ScrollView 向上滚动时 scrollEdgeAppearance 会默认使用 standardAppearance 的属性效果。所以 backgroundEffect 和 shadowColor 属性需要显式设置为nil，以防止 backgroundEffect、shadowColor 有颜色值影响导航栏透明效果。

下一篇：Swift版导航栏适配

PERFECT！

Q5: iOS中APP适配（RTL阿拉伯适配）

最近项目适配阿拉伯，记录一下最近的工作内容。在此之前，我是没有了解过这方面的知识。

首先说说为什么要适配阿拉伯呢，是因为我们中文和英文这些是从左往右显示的语言，但是阿拉伯的语言是从右往左显示(RTL)，恰好与我们的习惯相反，刚开始的时候实在很别扭，

首先在适配的项目的开始，我查找了一下网上的资料

感谢这几位大佬的博客：

我的项目是OC开发，布局用的masonry。

先来捋一下阿拉伯适配需要做哪些事情呢。

1阿拉伯从右往左显示，我们所有的约束需要更换。

2所有的UIView的处理

3带方向的图片处理

4手势的处理

5文字显示方向TextAlignment（大部分是UILabel）

6UIEdgeInsets（UIButton）

7富文本AttributeString

8Unicode文字的处理

9UICollectionView的处理（水平方向的）

10UIScrollView的处理（水平方向）

我们先来看一组效果图：

这是在中文下的效果

这是阿拉伯下的效果

列了一下需要处理的问题列表，接下来就是解决问题的具体方案了：

我写了一个公共的宏定义判断是不是阿拉伯语言，这个地方可以根据不同的需求做判断

1将所有的left更换成leading，right更换成trailing，这至少解决了50%的问题。是不是非常简单NO NO NO ~~

全部UIView处理

iOS9之后，苹果出了API适配RTL

UIView有一个semanticContentAttribute的属性，当我们将其设置成UISemanticContentAttributeForceRightToLeft之后，UIView将强制变为RTL布局。当然在非RTL语言下，我们需要设置它为UISemanticContentAttributeForceLeftToRight，来适配系统是阿拉伯语，App是其他语言不需要RTL布局的情况。

项目中有无数个UIView，是不是需要我们一个一个去设置呢，当然不是，这时候大家想到的是不是hook一下UIView的方法，来达到效果呢，好像是不行的呢，原因可以看我前面提到的三位的博客，我在appdelegate里面统一设置的，当我们设置UIView的semanticContentAttribute以后，发现UISearchBar还没有改变，那我们再设置一下UISearchBar

处理带方向的图片，这个部分有两种方式可以处理，要么让UI切两套图，分别展示，或者是把图片翻转一下，当然，图片不能带文字，这里得多说一句，经过这一次的教训，我发誓以后再也不要用带文字的图片了，如果只是带方向的图片，翻转就行了，但是图片带文字那就玩不转了，只能用几套图，还有国际化的时候，图片带文字，也不好处理，很不幸，我项目中很多带文字的图片，我只能一个一个去修改，言归正传，先来看一下处理带方向图片处理：

给UIImage写了一个分类，添加了一个方法，在方法里面判断是不是阿拉伯语，如果是翻转了图片，翻转图片的方法用的系统自带的。

这样子在带方向的地方使用这个方法，就可以了

手势的处理

滑动返回

RTL下，除了布局需要调整，手势的方向也是需要调整的

正常的滑动返回手势是右滑，在RTL下，是需要变成左滑返回的。为了让滑动返回也适配RTL，我们需要修改navigationBar和UINavigationController.view的semanticContentAttribute。使用[UIView appearance]修改semanticContentAttribute并不能使手势随之改变，我们需要手动修改。为了让所有的UINavigationController都生效。我们hook了UINavigationController的initWithNibName:bundle:

其他手势

跟方向有关的手势有2个：UISwipeGestureRecognizer和UIPanGestureRecognizer

UIPanGestureRecognizer是无法直接设置有效方向的。为了设置只对某个方向有效，一般都是通过实现它的delegate中的gestureRecognizerShouldBegin:方法，来指定是否生效。对于这种情况，我们只能手动修gestureRecognizerShouldBegin:中的逻辑，来适配RTL

UISwipeGestureRecognizer有一个direction的属性，可以设置有效方向。为了适配RTL，我们可以hook它的setter方法，达到自动适配的目的：

UIButton的RTL适配

UIButton的imageEdgeInsets和titleEdgeInsets。正常的时候，我们设置一个titleEdgeInsets的left。但是当RTL的情况下，因为所有的东西都左右镜像了，应该设置titleEdgeInsets的right布局才会正常。然而系统却不会自动帮我们将left和right调换。我们需要手动去适配它。

TextAlignment

RTL下textAlignment也是需要调整的，官方文档中默认textAlignment是NSTextAlignmentNatural，并且NSTextAlignmentNatural可用自动适配RTL

然而，情况并没有文档描述的那么好，当我们在系统内切换语言的时候，系统经常会错误的设置textAlignment。没有办法，我们只有自己去适配textAlignment.

以UILabel为例，我们hook它的setter的方法，根据当前是否是RTL，来设置正确的textAlignment，如果UILabel从未调用setTextAlignment:，我们还需要给它一个正确的默认值。

富文本AttributeString和Unicode字符串

以UILabel为例，对于AttributeString，UILabel的textAlignment是不生效的，因为AttributeString自带attributes。为了让attributeString也能自动适配RTL。我们需要在RTL下，将Alignment的left和right互换。

attributeString的alignment一般使用NSMutableParagraphStyle设置，所以我们首先hook NSMutableParagraphStyle，在setAlignment的时候设上正确的alignment：

由于阅读习惯的差异（阿拉伯语从右往左阅读，其他语言从左往右阅读），所以字符的排序是不一样的，普通语言左边是第一个字符，阿拉伯语右边是第一个字符。

如果是单纯某种文字，不管是阿拉伯语还是英文，系统都是已经帮助我们做好适配了的。然而混排的情况下，系统的适配是有问题的。对于一个string，系统会用第一个字符来决定当前是LTR还是RTL。

那么坑来了，假设有一个这样的字符串@"小明بدأ في متابعتك"（翻译过来为：小明关注了你），在阿拉伯语的情况下，由于阅读顺序是从右往左，我们希望他显示为@"بدأ في متابعتك小明"。然而按照系统的适配方案，是永远无法达到我们期望的。

如果"小明"放前面，第一个字符是中文，系统识别为LTR，从左往右排序，显示为@"小明بدأ في متابعتك"。

如果"小明"放后面，第一个字符是阿拉伯语，系统识别为RTL，从右往左排序，依然显示为@"小明بدأ في متابعتك"。

为了适配这种情况，可以在字符串前面加一些不会显示的字符，强制将字符串变为LTR或者RTL。

在字符串前面添加"\u202B"表示RTL，加"\u202A"LTR。为了统一适配刚刚的情况，我们hook了UILabel的setText:方法。当然这种方法没法适配所有的情况，项目中具体的场景还得具体处理。

以上是常见的适配了，接下来说两个特殊的

UICollectionView在RTL下的适配

继承UICollectionViewFlowLayout 重写两个方法

最后UIScrollView在RTL适配

普通的UIScrollView可以通过把UIScrollView的transform和scrollView的subviews翻转一下

我项目中太多的地方用到了UIScrollView,因为我们的UI设计，有非常多的分页控制器，所以我们项目中使用JXCategory搭配UIScrollView。

在使用的过程中遇到一个小问题，例如ScrollView加载三个不同的view，每个view的宽度都是屏幕的宽，这在RTL下有个问题，就是有view不显示，我从左往右适配的时候，右边的不显示，从右往左适配，左边的不显示，后来我使用了一种比较愚蠢的方法。最左的view从左适配，最右的View从右适配

我的RTL适配之路暂时就到这里了，希望未来有更好的方案出现。不安的2020即将完毕，祝愿2021是温暖的一年。