CFSDN坚持开源创造价值，我们致力于搭建一个资源共享平台，让每一个IT人在这里找到属于你的精彩世界.

这篇CFSDN的博客文章iOS开发笔记之键盘、静态库、动画和Crash定位由作者收集整理，如果你对这篇文章有兴趣，记得点赞哟.

前言 。

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

ios11键盘问题 。

功能背景:

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

问题描述:

当快速切换键盘之后，容易出现输入框的位置没有紧贴键盘，如下：（以简书键盘为例） 。

相关实现:

输入框监听系统的uikeyboardwillshownotification和uikeyboardwillhidenotification事件，在回调的过程中用uikeyboardframeenduserinfokey获取键盘的frame，再动态调整输入框的位置.

问题定位:

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

添加log进行调试，得到以下结果:

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

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

问题修复:

输入框增高，增加上图左边红框部分的高度； 。

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

附:

ios 11还有另外的键盘表现异常：在app中呼起键盘，把app切入后台，在系统桌面下滑呼起系统搜索的键盘，会导致app内的键盘收起.

静态库相关 。

功能背景:

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

问题描述:

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

相关实现:

静态库有单独的工程，会打包出模拟器和真机两个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，实现刷新完毕自动上滑的操作.

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

问题定位:

首先看问题的表现：uitableviewcell上的视图在刷新后进行位移.

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

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

• 1.下拉刷新 ==> 2.数据请求 ==> 3.本地数据源更新 ==> 4.1调用reloaddata更新视图
• 3.本地数据源更新 ==> 4.2 下拉刷新结束didfinish ==> 4.3refreshheaderview结束动画 ==> 4.4触发didscroll
  回调 ==> 4.5回调中调用visiablecell ==> 4.6触发cellfor方法 ==> 4.7uitableviewcell初始化会改变frame

视图位移原因就在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日志的寄存器信息，我们可以拿到这三个参数的值，如下:

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

（这里memcpy的三个参数是我特意构造的，以便描述问题） 。

这里有两种crash的可能性:

1、参数1写数据非法； 。

2、参数2读数据非法； 。

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

答案是：大多数情况下正常运行，少数情况下会crash.

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

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

总结 。

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

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

原文链接：https://www.jianshu.com/p/beeabf129dec 。

最后此篇关于iOS开发笔记之键盘、静态库、动画和Crash定位的文章就讲到这里了,如果你想了解更多关于iOS开发笔记之键盘、静态库、动画和Crash定位的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。