- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary<NSKeyValueChangeKey,id> *)change context:(void *)context {

        if (self.tabBar.height != KSTabBarHeight) {
            self.tabBar.height = KSTabBarHeight;
            self.tabBar.bottom = SCREEN_HEIGHT;
        }

Stackoverflow的类似情况

2、CoreData数据库升级时间长

问题描述：App在升级的时候会对CoreData数据库进行一次迁移，而某些用户反馈升级时间长达数分钟。

问题定位：CoreData数据库迁移使用的是系统提供的自动迁移，经过本地测试，确实存在数据库较大的情况下，升级时间较长的问题。

那么如何确定数据库是哪些表是瓶颈？

用户的数据库比较大，不可能进行整个数据库上传操作；而CoreData并不支持获取某个表的大小。

可以采取一种方案：用户上报数据库每张表的行数，本地通过工具求出每张表的平均值，用以估算每张表的大小。

找到可以导出沙盒本地沙盒的App活跃使用者（比如说运营、产品），用sqlite3_analyzer对数据库进行分析，得到每张表大小，再除以行数，得到每张表每行的平均值。

（不能通过行数直接判断数据库大小，因为表的列数不确定；也不能通过列大小*行数得到表体积，因为某些字段为空）

修复方案：

对瓶颈的表进行行数和体积双重控制；
对某些行数较多但表体积小的表建索引；

引用：

sqlite数据库分析

sqlite3_analyzer安装

Appropriate Uses For SQLite

sqlite索引

Customizing the Migration Process

3、objc_msgSend的Crash分析

问题描述：objc_msgSend是常见的一种Crash，这次的堆栈如下

objc_msgSend

这类由UIKit引起的Crash通常是在回调业务层时，对应的target已经被释放，于是在objc_msgSend的时候就会发生Crash。

寄存器和模块加载地址

问题定位：在本例中，查看上图知道，lr寄存器的地址是在第一个模块的加载区间内，以此作为线索。

用以下指定，进行手工符号化：

atos -o XXX arm64 0x000000010134d36c -l 0x1000fc000（XXX是二进制名字）

最终定位到问题，具体的代码类似：

[self.delegete remove];
self.data = ...

在这种情况下，self.delegate在remove掉之后self之后，self已经被释放，下面的self.data再进行赋值操作，就会出现异常情况。

解决方案：把 [self.delegete remove]; 放到最后一行。

后记：

该问题只出现在iOS 8。在iOS 11的机型上，通过调试我们可以获取到self.data=...这一行在执行时，关于self的内存引用情况：

autoreleasepool和thread都会持有self，保证self在本次执行过程中不释放。故此猜测该问题苹果已经发现，并且在iOS 8后续的版本已经修复。

4、内存相关问题

实际场景涉及到业务，所以抽象成代码来进行分析。

场景1

下面这段代码是否能够正常运行？

如果可以，结果是什么？

如果不可以，是为什么？

- (void)viewDidLoad {
    [super viewDidLoad];
    SInt16* buffer = NULL;
    SInt16* p = &buffer[15];
    NSLog(@"tmp %d", p);
}

场景2

下面这段代码是否能够正常运行？

如果可以，结果是什么？

如果不可以，是为什么？

- (void)viewDidLoad {
    [super viewDidLoad];
    
    char *pBuf = malloc(5);
    memcpy(pBuf, "aaabbbcccddddeeefff", 10);
   
    puts(pBuf);
}

分析：

场景1：

此处有两个trick：

1、p是否能够正常赋值，以及赋何值；

2、指针类型是SInt16*，计算地址要注意；

[] 是下标运算符，根据操作数和偏移量，获取指定地址的值；

在此题之中，buffer15等于*(buffer + 15)；

&buffer15 等于&(*(buffer + 15))；

& 是取址运算符，返回操作数的内存地址；

&buffer15 = &(*(buffer + 15)) = buffer + 15

所以p = &buffer[15] = buffer+15 = 0+15*sizeof(SInt16) = 30

故而答案是能正常运行，结果是"tmp 30"。

场景2：

申请了一块较大的内存，在memcpy的时候，偶然情况下会出现越界的情况。但是因为堆内存空间到栈内存空间的距离不固定，不一定会出现crash的情况。

上面的题目本质是堆内存访问越界。

故而上述代码大多数情况下输出aaabbbcccd，少数情况下不可预知。

总结

2018年的忙碌情况超过我想象，长时间不更新iOS开发笔记让我都忘了还有这个专题所在。

我有个习惯，开发中遇到问题，超过十分钟还没解决的时候，就会记录下来，这样是开发笔记专题的雏形。

而在加入新公司的第二个年头，我慢慢已经在iOS上的收获越来越少。

从笔记的新增情况来看，就可以发现：每天大多数是重复性劳动！

尝试看过一些iOS相关的书籍，但总感觉收获不大。

今年我选择把更多的业余学习时间分配给Metal，详见Metal入门教程总结。