前言

之前一直听说过libffi大名，但是并没有时间去真正了解，也了解过一些热修复的软件，但是很好奇它们是如何做到函数不参与编译而无中生有注入到执行序列的。本文对两种热修复软件JSPatch和mangoFix如何执行利用脚本文件执行代码进行了分析。

前言

最近看到一个有趣的问题，我们知道方法调用的本质是msgSend，反汇编时也可以看到实际调用的是msgSend，那么为啥堆栈中显示的反而是实际调用的方法，而不是msgSend呢？

前言

今天被一位北美的同事的comment了一个memcpy使用的代码，大致如下，在解析数据时把数据段的2个字节的数据长度memcpy到NSInteger *上:

1
2
3
4

- (void)updateData:(NSInteger *)dataLength data:(uint8_t *)data {
    memcpy(dataLength, data, sizeof(uint16_t));
  	...
}

这位同事的comment如下:

大意是这样使用memcpy不安全并且性能不好，应该采用他建议的方式，那么这里到底有什么门道呢？

前言

OC对象的方法由于运行时系统的存在，不会被Strip掉，而是编译成汇编代码放入程序段，因此找到并去除未使用代码也可以有效的减少包体积。本文对2种查找未使用方法的方案进行了讲解。

前言

查找未使用的类有两种方式，一种是基于代码的静态扫描，但是非常耗时，而且逻辑复杂。而mach-O中通过classlist和classrefs差集可以快速的定位出哪些未在代码中显式被调用的类。而且速度非常快，所以优先采用这种方式实现，具体脚本见github。

前言

借助mach-o view源码对Mach-O的知识做一次系统的记录。但是这个开源库已经近5年没有更新了,不仅下下来各种无法编译，并且很多mach-o信息也无法解析，于是我对它进行一些修改，可以直接拿我fork过来的工程 ，已经修复了一些问题并兼容了苹果最新的mach-o结构。

前言

最近为了复现一个1%概率左右的跨平台层的崩溃，在MSDK的TestApp中集成了一个CrashHandler来进行压力测试。借着解决问题的机会深入学习一下Unix的信号机制。并在本文讲述了如何实现一个CrashHandlerDemo。

前言

最近工作和socket打了不少交道，对于socket也是一知半解，导致遇到不少问题，于是抽时间好好学习了一下socket相关的知识。本文主要对socket关键字进行详细分析，深入理解了不同关键字在不同情况下的行为表现，一些相关的工作原理，最后以一个简易的一对多客户端和服务端通信Demo来实地分析和学习socket工作原理。

前言

首先抛出几个个问题：

1.什么是header serach path,什么又是framework search path？答案

2.#import,#include, @class和@import的区别是什么。循环#import一定会导致编译失败吗？答案

3.可以同时通过#import <>和使用header seach path来#import ""动态库里的文件吗？答案

4.如果编译时主工程（注意不是来自外部link的库）中有个Class的.m文件没有被加入到指定的target的complie files里会导致什么问题，如果是一个Category的文件呢？答案

5.如果一个类里的方法只有声明没有定义，则编译时会出现undefined symbol吗, 为什么？答案

6.如果一个静态库里面有两个相同的类会出现duplictate symbols错误吗？如果是动态库呢，如果是可执行文件呢？答案

7.如果主项目和连接的静态库有相同的类和相同的符号时会出现什么问题？动态库也会这样吗？答案

8.动态库和静态能呈现多层的链式链接关系吗？在链式链接的关系中能否跨层级直接调用到链接链中任意库文件中的方法吗？可以从链接链后面的库文件直接调用前面的库文件中的方法吗？答案

9.什么Other Link Flag,什么是_all-load, 什么是-Objc, 什么是-force-load，什么是-dead_strip?答案

前言

在最近的版本中，MSDK要支持bitcode了。于是开始对这个2015WWDC就提出老概念进行了新的学习。很多开发者都知道开启bitcode可以在archive时生成一份中间代码以提交给苹果，让其根据不同的架构生成不同的ipa，以减少安装包体积与应对未来出现新架构不兼容问题。也几乎都碰到过引用第三方库因其不支持bitcode而编译不过。但是Bitcode到底是什么呢？

我们知道编译器前端可以把不同的高级语言转换为中间代码（IR），再由编译器后端将中间代码转换成指定平台的目标代码，再通过链接器把目标代码和依赖的库文件link到一起即可变成可执行文件。因此理论上只需要中间代码即可生成任一平台的目标代码（只要编译器后端支持），因为中间代码已经包含了源程序所所要表达的全部意思。

再看下LLVM官方文档的描述：

1

The LLVM code representation is designed to be used in three different forms: as an in-memory compiler IR, as an on-disk bitcode representation (suitable for fast loading by a Just-In-Time compiler), and as a human readable assembly language representation.This allows LLVM to provide a powerful intermediate representation for efficient compiler transformations and analysis, while providing a natural means to debug and visualize the transformations. The three different forms of LLVM are all equivalent.

重点是三种代码表现形式：编译过程中的中间代码IR；编译出的bitcode；可读的汇编代码。其实都是对源代码的一种描述，只是面向了不同的对象时的表现形态。由此可知bitcode其实只是IR的另一种表现形式。