IOS

关注公众号 jb51net

关闭
首页 > 软件编程 > IOS > iOS开发之键盘、静态库、动画和Crash定位

iOS开发笔记之键盘、静态库、动画和Crash定位

作者:落影loyinglin

最近在学习iOS开发,进行了一些实战,所以下面这篇文章主要给大家介绍了关于iOS开发笔记之键盘、静态库、动画和Crash定位的相关资料,文中通过示例代码介绍的非常详细,需要的朋友可以参考下

前言

本文主要分享了开发中遇到的问题,和相关的一些思考。分享出来给有需要的朋友们参考学习,下面话不多说了,来一起看看详细的介绍吧。

iOS11键盘问题

功能背景:

弹出键盘时,如果有输入框的话,需要输入框的位置跟随键盘大小而变动。

问题描述:

当快速切换键盘之后,容易出现输入框的位置没有紧贴键盘,如下:(以简书键盘为例)


相关实现:

输入框监听系统的UIKeyboardWillShowNotification和UIKeyboardWillHideNotification事件,在回调的过程中用UIKeyboardFrameEndUserInfoKey获取键盘的frame,再动态调整输入框的位置。

问题定位:

此问题可以复现,呼起键盘之后频繁切换键盘。

添加Log进行调试,得到以下结果:

/*
226是系统英文键盘的高度;
292是搜狗输入法键盘的高度;
271是emoji键盘的高度;
*/
UIKeyboardWillShowNotification : {{0, 510}, {414, 226}}
UIKeyboardWillShowNotification : {{0, 444}, {414, 292}}
UIKeyboardWillShowNotification : {{0, 510}, {414, 226}}
UIKeyboardWillShowNotification : {{0, 444}, {414, 292}}
UIKeyboardWillShowNotification : {{0, 465}, {414, 271}}
UIKeyboardWillShowNotification : {{0, 510}, {414, 226}}
UIKeyboardWillShowNotification : {{0, 444}, {414, 292}}

实际操作中,当键盘从292高度的搜狗键盘切换成271的emoji键盘的时候,有时会无法触发回调,造成实际上键盘高度产生292-271的误差(21pt)。

正常苹果应该每次切换键盘都回调,但在切换emoji表情键盘的时候,偶现不触发回调。

问题修复:

输入框增高,增加上图左边红框部分的高度;

和键盘对齐的时候,往下计算红框的高度。

附:

iOS 11还有另外的键盘表现异常:在APP中呼起键盘,把APP切入后台,在系统桌面下滑呼起系统搜索的键盘,会导致APP内的键盘收起。

静态库相关

功能背景:

项目中存在某些功能,需要用静态库集成的方式接入。

问题描述:

在线上运行过程中发现某些Crash出自静态库,但是Crash日志里面无法定位到静态库出现Crash的具体代码行数。
如下,testNull的Thread 0发生Crash,但是没有函数相关信息。

Exception Type: EXC_BAD_ACCESS (SIGSEGV)

Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 testNull       0x000000010494aacc 0x104944000 + 27340
1 testNull       0x000000010494aac8 0x104944000 + 27336
2 testNull       0x000000010494a6b0 0x104944000 + 26288
3 UIKit        0x000000018cec4efc -[UIViewController loadViewIfRequired] + 1040
4 UIKit        0x000000018cec4ad4 -[UIViewController view] + 28
5 UIKit        0x000000018cecb6a0 -[UIWindow addRootViewControllerViewIfPossible] + 136
6 UIKit        0x000000018cec890c -[UIWindow _setHidden:forced:] + 272
7 UIKit        0x000000018cf379ec -[UIWindow makeKeyAndVisible] + 48

相关实现:

静态库有单独的工程,会打包出模拟器和真机两个framework,然后合并成一个framework,再放入项目的工程。

问题定位:

Crash日志里面的信息无法符号化,原因就是还原Crash信息的符号表里没有静态库的信息。

我们知道,静态库是只有编译,没有链接的过程。

在实际打到二进制包的时候,才会进行链接操作。

符号表里没有静态库的信息,是静态库的framework里没有代码行数的相关信息!

通过查询官方文档知道,Generate Debug Symbols的属性描述如下

Enables or disables generation of debug symbols. When debug symbols are enabled, the level of detail can be controlled by the Debug Information Format (DEBUG_INFORMATION_FORMAT) setting.

静态库的工程如果设置该属性为NO,那么打包出来的framework是不包括Debug用的信息。

问题修复:

修改Generate Debug Symbols设置。

正确设置

附:

Xcode相关设置的文档,直接点击这里的链接。如果失效,可以按照下面的步骤查找:

Xcode设置

UITableView下拉刷新导致的动画异常

功能背景:

UITableView用于展示内容,scrollView上会添加一个RefreshHeadrView,用于实现下拉刷新。

问题描述:

现在在下拉刷新之后,Cell内部的视图会有移动,类似的效果如下(为了方便展示,用按钮点击取代下拉刷新的操作):

相关实现:

RefreshHeadrView(下拉刷新view)通过监听scrollView的didScroll回调,触发下拉刷新;在结束的时候通过修改scrollView.contentInset,实现刷新完毕自动上滑的操作。

下拉刷新结束的代码如下:

  [UIView beginAnimations:nil context:NULL];
  [UIView setAnimationDuration:0.2];
  [UIView setAnimationCurve:UIViewAnimationCurveEaseOut];
  scrollView.contentInset = UIEdgeInsetsMake(-REFRESH_TRIGGER_HEIGHT + _initTopContentInset, 0.0f, 0.0f, 0.0f);
  [UIView commitAnimations];

问题定位:

首先看问题的表现:UITableViewCell上的视图在刷新后进行位移。

位移的原因有多种可能,同事奥斯丁提供了一种解决方案:下拉刷新之后,把reloadData放到下个runloop再执行。
在尝试之后,果然修复了此问题!

奥斯丁的解决方案让我确定到问题一定是出现在当前runloop做的一些操作,导致了UITableViewCell上的视图位移。
经过一番调试,把问题的整个原路径给回溯出来:

视图位移原因就在4.3的结束动画是在UIView的动画事务操作,而4.7的改变frame的操作会被认为也在动画事务内,所以会触发视图的动画效果。

问题修复:

修复方案,可以是dispatch到下一个runloop再执行reloadData,这样在4.5回调中调用visiableCell的时候visiableCell拿到上一次的cell,这样链路会断开,不会导致视图位移。但是,这样会把Bug隐藏:数据源和UI显示不一致!!

最佳解决方案:不调用visiableCell去获取当前显示的cell,改为监听UITableView的willDisplay和didEndDisplayingCell方法,再用一个双端队列维护一个业务侧的当前可见cell。

通过这个问题,我们可以确定-reloadData方法是把UITableView的可见cell清空;
visiableCell是一个getter,调用的时候如果visiableCell是空,会触发cellfor的方法进行初始化。

Crash定位

源于实际开发中遇到的一个Crash问题,类似堆栈如下:


crash问题在各个iOS版本均有出现,每天的crash率(crash次数/用户数)在万分之1.5左右。

通过crash的描述platform_memmove,还有堆栈信息我们可以定位到代码异常是出现在memcpy的函数。

通过错误类型,我们知道是访问非法内存地址。

memcpy一共有三个参数,在执行函数的时候会把三个参数push进x0、x1、x2三个寄存器。再通过crash日志的寄存器信息,我们可以拿到这三个参数的值,如下:

Thread 0 crashed with ARM Thread State (64-bit):
 x0: 0x00000000000000aa x1: 0x00000000000000bb x2: 0x00000000000000cc x3: 0x00000000000000c0
 x4: 0x0000000000000010 x5: 0x0000000000000002 x6: 0x0000000000000064 x7: 0x0000000000000000
 x8: 0x00000000000000aa x9: 0x0000ddf9664f0000 x10: 0x0000000000004887 x11: 0x00000001b8741211
 x12: 0x00000001b8741211 x13: 0x000000000000001d x14: 0x0000000000000001 x15: 0x0000000000000881
 x16: 0x00000001855b1ab0 x17: 0x0000000000000000 x18: 0x0000000000000000 x19: 0x00000000000000aa
 x20: 0x0000000119d064f0 x21: 0x0000000000000018 x22: 0x000000018fb4dd6a x23: 0x0000000000000000
 x24: 0x0000000000000010 x25: 0x0000000119e01b40 x26: 0x0000000000000280 x27: 0x0000000119d06c50
 x28: 0x0000000000000001 fp: 0x000000016bce95f0 lr: 0x000000018542ce58
 sp: 0x000000016bce95f0 pc: 0x00000001855b1b60 cpsr: 0x80000000

从上面的寄存器信息,我们可以拿到x0、x1、x2的寄存器值为0xAA、0xBB、0xCC,从而还原出导致crash的函数为memcpy(0xaa, 0xbb, 0xcc);。

(这里memcpy的三个参数是我特意构造的,以便描述问题)

这里有两种crash的可能性:

1、参数1写数据非法;

2、参数2读数据非法;

先看一个类似的问题,下面的代码有什么问题?

int *p1=malloc(1024);
int *p2=malloc(1024);
memcpy(p1, p2, 1025);

答案是:大多数情况下正常运行,少数情况下会Crash。

Crash本质是堆内存访问越界,但堆内存空间到栈内存空间的距离不固定,如果p1+1025仍有写权限,p2+1025仍有读权限,则不会出现crash的情况。

附:
实际开发中,寄存器x2+寄存器x5的值,才是真正的memcpy的第三个参数。
x2: 0x00000000000003e0 + x5: 0x0000000000000020 = 0x0000000000000400 = 1024
怀疑是苹果对memcpy的方法做了修改:
当 第二个参数是堆内存地址的时候,会进行截断;
当 第二个参数是非法地址时(比如0x00000000000000bb),就不会进行截断;

总结

遇到问题是常态,如果能从解决问题中学到知识,以及用问题去验证知识,那么问题也可以成为学习进步的一部分。

好了,以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,如果有疑问大家可以留言交流,谢谢大家对脚本之家的支持。

您可能感兴趣的文章:
阅读全文