SQUARE | a full-stack engineer

Others

从头梳理之–内存与内存管理

前言

对于大多数开发者，特别是 C, Objective-C, Swift 等相关的开发者来说，已经很了解如何避免内存泄漏，解决循环引用等问题。但如果继续深入讨论为何会需要手动管理内存，为何内存泄漏仅在特定场景下产生，如何尽可能减少内存开销等问题时，能回答很清楚的人就相对较少了。

所以还是有必要从头梳理一下关于内存的基本知识与概念了，如果我们掌握了这些知识，相信很多问题就会迎刃而解了。

基础知识

位：( bit ) 是电子计算机中最小的数据单位。每一位的状态只能是0或1。
字节：1 Byte = 8 bit ，是内存基本的计量单位，
字：”字” 由若干个字节构成，字的位数叫做字长，不同档次的机器有不同的字长。
KB ：1KB = 1024 Byte。也就是1024个字节。
MB : 1MB = 1024 KB。类似的还有GB、TB。
内存编址：计算机中的内存按字节编址，每个地址的存储单元可以存放一个字节（8个bit）的数据，CPU通过内存地址获取指令和数据，并不关心这个地址所代表的空间具体在什么位置、怎么分布，因为硬件的设计保证一个地址对应着一个固定的空间，所以说：内存地址和地址指向的空间共同构成了一个内存单元。
内存地址：内存地址通常用十六进制的数据表示，例如通常在C或者Objective-C中输出一个变量的地址可能为：0x7fff5fbff79c，这就是一个用十六进制的数表示的地址。

下图的整数100在三种进制中的表示：

什么是内存?

从硬件的角度来说，它是重要的部件之一.

也是硬盘与 CPU 之间沟通的桥梁。所有的应用程序运行时都会放入内存，然后交由 CPU 进行计算执行。CPU 能通过寻址找到内存对应的数据。

严格意义上讲，内存不仅仅是我们经常所指的内存条。寄存器(Register)、缓存(Cache) 都属于内存的一种。

所以内存一般分为 RAM(main memory), SRAM(cache), Register。

寄存器是 CPU 的组成部分，因为在CPU内，在设计上和CPU同频，所以CPU对其读写速度是最快的，不需要IO传输。

部分缓存的设计也基本保持了与 CPU 同频，所以速度相对内存也是比较快。

理论上讲，缓存和寄存器是一样快的。不过因为缓存里面的东西不一定就是需要的，如果不存在就要一级一级往下找，直到内存。因为不同的缓存或内存时钟频率不一样，所以CPU在查找时需要一定的等待时间。

CPU 寻找数据进行运算的流程是:

CPU -> Register -> L1 Cache -> L2 Cache -> 内存

RAM 内存的主频现在主流是1600左右，单位是MHz，这比CPU的速度要低的多。

32 位与 64 位是什么概念？

所谓多少位一般是指处理器(CPU)的运算能力与寻址能力。

运算能力

比如32位，一次能处理32位，也就是4个字节的数据(1字节=8位)。而64位处理器则能处理8个字节的数据。

如果我们将总长128位的指令分别按照16位、32位、64位为单位进行编辑的话：旧的16位处理器，比如Intel 80286 CPU需要8个指令，32位的处理器需要4个指令，而64位处理器则只要两个指令。

寻址能力

除了运算能力之外，与32位处理器相比，64位处理器的优势还体现在系统对内存的控制上。

相比32位的CPU来说，64位CPU最为明显的变化就是增加了8个64位的通用寄存器，内存寻址能力提高到64位。

32位的内存地址空间为2的32次方，即4GB。64位可获得更大的寻址空间，能识别4G以上的内存。

另外，要实现真正意义上的64位计算，光有64位的处理器是不行的，还必须得有64位的操作系统以及64位的应用软件才行，如果应用软件不支持，反而在64位机器上会变慢。

寄存器 (Register)

为了处理数据，暂时储存结果，或者做间接寻址等动作，每个处理器都具备一些内建的内存，这些能够在不延迟的状态下存取的内存就称为寄存器。

寄存器是数据处理的重要一环，如果经常使用汇编语言，对它应该会非常熟悉。

IA-32构架提供了16个基本寄存器，这16个基本寄存器可以归纳为如下几类:

通用寄存器
段寄存器
状态和控制寄存器
指令寄存器

通用寄存器
32位通用寄存器有八个， eax, ebx, ecx, edx, esi, edi, ebp, esp

他们主要用作逻辑运算、地址计算和内存指针，具体功能如下：

eax 累加和结果寄存器
ebx 数据指针寄存器
ecx 循环计数器
edx i/o指针
esi 源地址寄存器
edi 目的地址寄存器
esp 堆栈指针
ebp 栈指针寄存器

当然，以上功能并未限制寄存器的使用，特殊情况为了效率也可作其他用途。

在 64-bit 模式下，有16个通用寄存器，但是这16个寄存器是兼容32位模式的，

32位方式下寄存器名分别为 eax, ebx, ecx, edx, esi, edi, ebp, esp, r8d – r15d

在64位模式下，他们被扩展为 rax, rbx, rcx, rdx, rdi, rsi, rbp, rsp, r8 – r15，其中 r8 – r15 这八个寄存器是64-bit模式下新加入的寄存器。

段寄存器
段寄存器是因为对内存的分段管理而设置的。计算机需要对内存分段，以分配给不同的程序使用（类似于硬盘分页）。

把内存分为很多段，每一段有一个段基址，当然段基址也是一个20位的内存地址。不过段寄存器仍然是16位的，它的内容代表了段基址的高16位，这个16位的地址后面再加上4个0就构成20位的段基址。而原来的16位地址只是段内的偏移量。这样，一个完整的物理内存地址就由两部分组成，高16位的段基址和低16位的段内偏移量，当然它们有12位是重叠的，它们两部分相加在一起，才构成完整的物理地址。

段寄存器又分为 cs, ds, ss, es, fs, gs。

cs 代码段寄存器
ds, es, fs, gs 数据段寄存器
ss 堆栈段寄存器

在 64-bit 模式下，这6个寄存器并无变化，只是使用上略有区别。

状态和控制寄存器 EFLAGS
这个寄存器表示的意义非常丰富，程序中并不直接操作此寄存器，并由此衍生出很多操作指令。

指令寄存器 EIP
标志当前进程将要执行指令位置，在64位模式下扩展为 RIP 64位指令寄存器。

OK 以上，关于寄存器，在这里我们只需要了解这么多就够了，不用深入。

内核空间与用户空间

为了保护操作系统不会被运行的用户程序所干扰，所以分为了内核空间与用户空间，所有的应用程序会被分配在用户空间。

内核空间是持续存在的，并且在所有进程中都映射到同样的物理内存，内核代码和数据总是可寻址的，随时准备处理中断和系统调用。

现代的操作系统都处于32位模式下。每个进程一般都能寻址4G的物理空间。但是我们的物理内存不足 4G，通常我们使用一种叫做虚拟内存的技术来实现，因为可以使用硬盘中的一部分来当作内存使用。

虚拟空间中的内存布局 (Memory layout)

如果一个应用程序在运行时，会被装载到用户内存空间，并构成一个虚拟地址空间（virtual address space）。

典型的虚拟地址空间有四个部分构成

执行的代码 (Executable code)
这个空间包括了可被机器执行的代码，为只读区域
静态数据 (Static data)
这个部分包括了静态分配的变量
堆 (Heap)
这个部分包括了动态分配的变量
栈 (Stack)
这个部分包括了临时变量，返回地址，执行参数

每个部分分别占用了一块或多块连续的地址空间，他们被操作系统所管理。

如果我们想看看操作系统自己的内存分布，可以用下面的命令

cat /proc/self/maps

...
00aed000-00b0e000 rw-p 00000000 00:00 0 [heap]
…

cat /proc/self/maps

...

00aed000-00b0e000 rw-p 00000000 00:00 0 [heap]

…

第一列显示了内存地址块，第二列显示一些标记，如只读，可写等，三，四，五，六列分别表示偏移地址，设备，节点，名称

C 语言应用程序的内存布局

除了核心的内核空间外，其它的空间分为 5 种类型:

文本段 (Text segment)

通常存放执行的代码，只读段。

初始化的数据段 (Initialized data segment)

这个区域分为”只读数据段”和”可读写的数据段”

只读数据段是程序使用的一些不会被更改的数据。
可读写数据段会放入在程序中声明，具有初值的变量，以供程序运行时读写。
如全局 ( main 函数外) 字符串定义 char s[] = “hello world” 或 int debug=1 。

这样的全局声明 const char* string = “hello world” 中，“hello world” 被放入只读区，而字符串指针变量 string 会被放入读写区。
这样的声明 static int i = 10 与 int I = 10 都会被存入数据段。

未初始化的数据段 (Uninitialized data segment)

又称为 BSS (block started by symbol) 段。
这样的声明 static int I; 或全局的 int j; 都会放入这个区域。

栈 (Stack)

栈空间主要用于以下3种数据的存储：

函数内部的动态变量
函数的参数
函数的返回值

栈空间是动态开辟与回收的。在函数调用过程中，如果函数调用的层次比较多，所需的栈空间也逐渐加大，对于参数的传递和返回值，如果使用较大的结构体，在使用的栈空间也会比较大。

栈上的局部变量往往通过偏移地址去访问，如果通过 push/pop 会浪费大量时间。

栈通常都会放在高位区，它遵循 LIFO (后进先出) 机制。

#include
int main(int argc, const char * argv[]) {
int a = 100;
int b = 100;
printf("%p \n",&a); // 0x7fff5fbff79c
printf("%p \n",&b); // 0x7fff5fbff798
return 0;
}

#include

int main(int argc, const char * argv[]) {

int a = 100;

int b = 100;

printf("%p \n",&a); // 0x7fff5fbff79c

printf("%p \n",&b); // 0x7fff5fbff798

return 0;

}

变量a的地址 0x7fff5fbff79c 比变量 b 的地址 0x7fff5fbff798 要大。所以它也是从高位开始按顺序一条条出栈执行。

堆 (Heap)

堆开始于 BSS 段的未尾。然后往高地址增长。Heap 区通常由 malloc, realloc, and free 命令管理。Heap 区可以在一个进程中被多个库或动态加载的模块所共享。

我们来看看一个最简单的 C 程序，在 linux 系统上编译后它的内存部局是什么样的:

#include
int main(void)
{
return 0;
}

#include

int main(void)

{

return 0;

}

$ gcc memory-layout.c -o memory-layout
> size memory-layout
text data bss dec hex filename
1115 552 8 1675 68b memory-layout

$ gcc memory-layout.c -o memory-layout

> size memory-layout

text data bss dec hex filename

1115 552 8 1675 68b memory-layout

然后我们增加一个全局变量，看看内存有什么变化

#include
int global; /* Uninitialized variable stored in bss*/

int main(void)
{
return 0;
}

#include

int global; /* Uninitialized variable stored in bss*/

int main(void)

{

return 0;

}

重新编译

$ gcc memory-layout.c -o memory-layout
$ size memory-layout

text data bss dec hex filename
1115 552 12 1675 68f memory-layout

$ gcc memory-layout.c -o memory-layout

$ size memory-layout

text data bss dec hex filename

1115 552 12 1675 68f memory-layout

如果我们增加一个 static 变量

#include
int global; /* Uninitialized variable stored in bss*/

int main(void)
{
static int i; /* Uninitialized static variable stored in bss */
return 0;
}

#include

int global; /* Uninitialized variable stored in bss*/

int main(void)

{

static int i; /* Uninitialized static variable stored in bss */

return 0;

}

text data bss dec hex filename
1115 552 16 1683 693 memory-layout

1 2	text data bss dec hex filename 1115 552 16 1683 693 memory-layout

让我们实例化这个变量，它会被放入 Data Segment (DS)

#include
int global; /* Uninitialized variable stored in bss*/

int main(void)
{
static int i = 100; /* Initialized static variable stored in DS*/
return 0;
}

#include

int global; /* Uninitialized variable stored in bss*/

int main(void)

{

static int i = 100; /* Initialized static variable stored in DS*/

return 0;

}

text data bss dec hex filename
1115 556 12 1683 693 memory-layout

1 2	text data bss dec hex filename 1115 556 12 1683 693 memory-layout

如果我们实例化全局变量后，它也会被放入 DS

#include
int global = 10; /* Uninitialized variable stored in bss*/
...

#include

int global = 10; /* Uninitialized variable stored in bss*/

...

text data bss dec hex filename
1115 560 8 1683 693 memory-layout

1 2	text data bss dec hex filename 1115 560 8 1683 693 memory-layout

注意：如果你是在 Mac 系统上编译，查看内存布局时，会是这样的情况

__TEXT __DATA __OBJC others dec hex
4096 4096 0 4294971392 4294979584 100003000

1 2	__TEXT __DATA __OBJC others dec hex 4096 4096 0 4294971392 4294979584 100003000

同样也是分为 Text 区，Data 区。

代码段、只读数据段、读写数据段、未初始化数据段属于静态区域，而堆和栈属于动态区域。代码段、只读数据段和读写数据段将在链接之后产生，未初始化数据段将在程序初始化的时候开辟，而堆和栈将在程序的运行中分配和释放。

设想一下，如果系统将程序初始化阶段把所有变量全部分配好，那得要多少内存。所以有这样段设计，将动态的部分根据需要再去分配，这才有了运行时的概念。

基本数据类型的内存空间

变量在内存中以二进制形式存储，一个变量占用的存储空间，不仅和变量类型有关，还和编译环境有关，同一种类型的变量在不同编译环境下占用的存储空间不一样。比如开发中常用的基本数据类型char、int等在不同编译环境下就会占用不同大小的空间。

在 64 位机器下的许多程序设计环境，int 变量仍然是 32 位宽，不过 long 是 64 位宽。这就是为什么 Objective-C 中会有 NSInteger 的定义，它会根据操作系统位数自由选择不同的数据类型。

我们通过一个例子来验证 int 的内存空间。

int main(int argc, const char * argv[]) {
int a = 1;
int b = 2;
printf("%p\n",&a); //0x7fff5fbff79b
printf("%p\n",&b); //0x7fff5fbff797
return 0;
}

int main(int argc, const char * argv[]) {

int a = 1;

int b = 2;

printf("%p\n",&a); //0x7fff5fbff79b

printf("%p\n",&b); //0x7fff5fbff797

return 0;

}

我们可以看到 b 与 a 刚好是 4 个字节。

C语言中数组的存储和普通的变量不太一样，数值中存储的元素，是从所占用的低地址开始存储的。例如

int main(int argc, const char * argv[]) {
char chars[4] = {'l','o','v','e'};
printf("chars[0] = %p\n",&chars[0]); //0x7fff5fbff79c
printf("chars[1] = %p\n",&chars[1]); //0x7fff5fbff79d
printf("chars[2] = %p\n",&chars[2]); //0x7fff5fbff79e
printf("chars[3] = %p\n",&chars[3]); //0x7fff5fbff79f
return 0;
}

int main(int argc, const char * argv[]) {

char chars[4] = {'l','o','v','e'};

printf("chars[0] = %p\n",&chars[0]); //0x7fff5fbff79c

printf("chars[1] = %p\n",&chars[1]); //0x7fff5fbff79d

printf("chars[2] = %p\n",&chars[2]); //0x7fff5fbff79e

printf("chars[3] = %p\n",&chars[3]); //0x7fff5fbff79f

return 0;

}

仅仅通过上面的字符数组例子还不能完全说明数组在内存中关于其元素存储和元素中值的存储关系。如果换用一个整型数组就能看出一些差别。

int main(int argc, const char * argv[]) {
int nums[2] = {5, 6};
printf("nums[0] = %p\n",&nums[0]); // 0x7fff5fbff7a0
printf("nums[1] = %p\n",&nums[1]); // 0x7fff5fbff7a4
return 0;
}

int main(int argc, const char * argv[]) {

int nums[2] = {5, 6};

printf("nums[0] = %p\n",&nums[0]); // 0x7fff5fbff7a0

printf("nums[1] = %p\n",&nums[1]); // 0x7fff5fbff7a4

return 0;

}

数组在使用过程中遇到的最多的问题可能就是下标越界，下面的代码就是越界访问数组示例：

int main(int argc, const char * argv[]) {
char charsOne[2] = {'a', 'b'};
char charsTwo[3] = {'c', 'd', 'e'};
charsTwo[3] = 'f';
printf("charsOne[0] = %p\n",&charsOne[0]); // 0x7fff5fbff79e
printf("charsTwo[0] = %p\n",&charsTwo[0]); // 0x7fff5fbff79b
printf("charsOne[0] = %c\n",charsOne[0]); // f
return 0;
}

int main(int argc, const char * argv[]) {

char charsOne[2] = {'a', 'b'};

char charsTwo[3] = {'c', 'd', 'e'};

charsTwo[3] = 'f';

printf("charsOne[0] = %p\n",&charsOne[0]); // 0x7fff5fbff79e

printf("charsTwo[0] = %p\n",&charsTwo[0]); // 0x7fff5fbff79b

printf("charsOne[0] = %c\n",charsOne[0]); // f

return 0;

}

结构体变量占用的内存空间是其成员占用最大内存空间的整数倍

struct Person {
int age;
int hegiht;
int weight;
};
int main(int argc, const char * argv[]) {
struct Person p1 = {1, 2, 3};
int size = sizeof(p1);
printf("%i\n",size); // 4 * 3 = 12
printf("变量的地址：%p\n",&p1); //0x7fff5fbff750
printf("%p\n",&p1.age); //0x7fff5fbff750
printf("%p\n",&p1.hegiht); //0x7fff5fbff754
printf("%p\n",&p1.weight); //0x7fff5fbff758
return 0;
}

struct Person {

int age;

int hegiht;

int weight;

};

int main(int argc, const char * argv[]) {

struct Person p1 = {1, 2, 3};

int size = sizeof(p1);

printf("%i\n",size); // 4 * 3 = 12

printf("变量的地址：%p\n",&p1); //0x7fff5fbff750

printf("%p\n",&p1.age); //0x7fff5fbff750

printf("%p\n",&p1.hegiht); //0x7fff5fbff754

printf("%p\n",&p1.weight); //0x7fff5fbff758

return 0;

}

内存对齐

对于结构体来说，会有内存对齐的规范。
首先结构体从首个成员分配空间；如果空间不够则重新分配，如果空间剩余则会把下一个成员的数据存储到剩余的空间中

struct Student {
char id;
double score;
int age;
}
int main(int argc, const char * argv[]) {
struct Student s1 = {'A', 10.0, 15};
int size = sizeof(s1);
printf("%i\n",size); //24
printf("%p\n",&s1.id); //0x7fff5fbff788
printf("%p\n",&s1.score); //0x7fff5fbff790
printf("%p\n",&s1.age); //0x7fff5fbff798
return 0;
}

struct Student {

char id;

double score;

int age;

}

int main(int argc, const char * argv[]) {

struct Student s1 = {'A', 10.0, 15};

int size = sizeof(s1);

printf("%i\n",size); //24

printf("%p\n",&s1.id); //0x7fff5fbff788

printf("%p\n",&s1.score); //0x7fff5fbff790

printf("%p\n",&s1.age); //0x7fff5fbff798

return 0;

}

按照前面的说明，系统为 s1 分配内存时以 sizeof(double) 8个字节为单位，所以为 s1.id 分配了8个字节的空间，但是由于id定义为char类型，所以只占了8个字节中数值最小的一个内存空间；由于前面剩下的 8 – 1 = 7个字节不足以存放double类型的值，所以接着为s1.score分配8个字节并占满8个字节空间；最后为s1.age分配8个字节并占用了前4个字节空间。故s1变量在内存中占用的内存大小为 8 X 3 = 24个字节。

如果调换结构体Student成员之间的顺序如下，情况又会发生变化。

struct Student {
double score;
char id;
int age;
};
int main(int argc, const char * argv[]) {
struct Student s1 = {'A', 10.0, 15};
int size = sizeof(s1);
printf("%i\n",size); //16
printf("%p\n",&s1.score) //0x7fff5fbff790
printf("%p\n",&s1.id); //0x7fff5fbff790
printf("%p\n",&s1.age); //0x7fff5fbff79c
return 0;
}

struct Student {

double score;

char id;

int age;

};

int main(int argc, const char * argv[]) {

struct Student s1 = {'A', 10.0, 15};

int size = sizeof(s1);

printf("%i\n",size); //16

printf("%p\n",&s1.score) //0x7fff5fbff790

printf("%p\n",&s1.id); //0x7fff5fbff790

printf("%p\n",&s1.age); //0x7fff5fbff79c

return 0;

}

这是由于第二次为 s1.id 分配内存时没有完全占满8个字节的空间，而且第三次为s1.age分配时其需要的4个字节空间也没有超出剩余的8-1 = 7个字节空间，所以s1.age的值按照内存对齐的原则就存放在了第二次分配的8个字节的后4位空间中。

总结：结构体变量所占存储空间受其不同类型的成员排列顺序及编译器内存对齐影响，开发中尽量将相同类型的成员依次定义，有助于节省内存空间。

内存管理

根据以上知识点，我们知道内存管理分为系统和手动管理两个部分。
BSS, Data, Text, Stack 区都是系统自动管理的。Heap 区是手动创建，所以需要手动释放。否则内存会不断的增大，直到进程被强制退出。

不过对于栈区 (Stack )，虽然是由系统管理的，但它也是动态分配的。所以如果栈特别大，比如递归函数，会不断的压栈，也会造成内存耗尽。另外，如果在函数里定义的变量，也会分配在栈区，假设有一个无限循环，局部变量不停的生成，如果不及时释放，也会造成内存溢出。

所以无论是何种内存管理方式，垃圾回收机制，无外乎要注意以上几点。比如 iOS 开发中的 ARC 机制，就是采用了引用计数，来帮我们管理 Heap 区的内容，防止我们遗忘释放对象。 Autorelease Pool 也是一种管理栈区变量的一种机制。

内存泄漏

内存泄漏是指分配的内存未能及时释放，导致这部分的内存长期占用，产生了浪费，甚至还会导致系统资源不足引起崩溃。

根据上述提到的点，这种场景确实是会发生的。

场景一

int *pOld = (int*) malloc( sizeof(int) );
int *pNew = (int*) malloc( sizeof(int) );

1 2	int pOld = (int) malloc( sizeof(int) ); int pNew = (int) malloc( sizeof(int) );

这两段代码分别创建了一块内存，并且将内存的地址传给了指针 pOld 和 pNew。此时指针 pOld 和 pNew 分别指向两块内存。

如果接下来进行这样的操作：

pOld = pNew;

pOld 指针就指向了 pNew 指向的内存地址，这时候再进行释放内存操作：

free(pOld);

此时释放的 pOld 所指向的内存空间就是原来 pNew 指向的，于是这块空间被释放掉了。但是 pOld 原来指向的那块内存空间还没有被释放，不过因为没有指针指向这块内存，所以这块内存就造成了丢失。

场景二

另外，不应该进行类似下面这样的操作：

malloc( sizeof(int) );

这样的操作没有意义，因为没有指针指向分配的内存，无法使用，而且无法通过 free() 释放掉，造成了内存泄露。

泄漏检测

我们可以用 leaks 命令 (Mac 系统下);

首先在命令行下用 MallocStackLogging=1 ./test.out & 打开 Malloc 调试日志。
当你运行上面的命令后，会出现一个线程 id。然后运行命令：leaks 线程 ID，即可看到是否有泄漏。
注意: 进程需要保持运行状态，否则退出后，所有的内存都会被销毁，就没办法跟踪了。可以用 sleep(100) 能让它一直运行

比如

#include
#include
void f()
{
char *c = malloc(24); // 泄漏在此，没有对应的 free 操作
}

int main()
{
f();
sleep(100);
return 0;
}

#include

void f()

{

char *c = malloc(24); // 泄漏在此，没有对应的 free 操作

}

int main()

{

f();

sleep(100);

return 0;

}

四月 8, 2018 by square

Foundation

剖析几种流行的 iOS 设计模式–MVC;MVVM;VIPER

— 原文首发在简书，现移值过来。

在这篇文章里，我们争取用最精简的语言，解释清楚这几种设计模式到底给我带来了什么便利。

以看图说话的方式逐一解释，最后总结

这是我们最早接触，也最熟悉的设计模式了

但要记住 Controller 不是我们通常理解的 ViewController ！Controller 你可以认为是 Helper 方法。他不掌管 View 的生命周期。也就是说和 UIKit 无关！ViewController 你可以把他理解为 Scene 或装配中心。

感谢有人做了一个精辟的总结。看图理解吧:

这才是真正的 MVC 使用姿势。

MVP

从对比可以看到 MVC 的 Controller 变成了 Presenter , UIView 或 UIViewController 为 View 层。View 持有 Presenter，Presenter 持有 Model。View 与 Model 完全隔离。

当事件发生，交由 Presenter 进行业务逻辑处理，Presenter 从 Model 拿数据，拿到数据后然后将数据返回给Presenter，Presenter 再返回给 View 。可以理解 Presenter 是一个中间人。

同样 Presenter 应完全不依赖 UIKit 。如果需要与 View 交互，可以采用 Protocol 协议进行约定，调用。保证逻辑清楚，可测试。

最简样列代码：

MVP Example

注意中文标注的地方。

另外还有一个 Supervising Presenter MVP 的升级版本，将 View 与 Model 进行绑定。View 会受到 Model 的变更影响，同时 Presenter 依旧可以控制 View 状态。这种模糊的职责关系，还是少用为好。

MVVM

和 MVP 一样，View Model 承担了类似 Presenter 中间层的角色。区别在于”数据与用户行为”的绑定是在 View 与 View Model 层上发生的。这个时候不影响这个设计架构中 View Model 应该承担的角色属性：更新 View 状态。

关于绑定我们可以用 KVO 模式及函数式编程来实现我们的所需。如果你想更高效的完成这个动作，可以参考现有的解决方案:
1. KVO: RZDataBinding or the SwiftBond
2. Functional programming: ReactiveCocoa, RxSwift or PromiseKit

不过，对于 ReactiveCocoa 我只能说慎用，设计起来会非常麻烦。

这里，我们还列举最简单的例子，没有用到 KVO 或 RX 之类的设计，使用最为传统的 Protocol 来实现彼此的交互过程

MVVM Example

我们可以看重点中文标注的地方，这里通过协议里的定义，第一步 View 层发起数据请求 showGreeting 交由 ViewModel 进行数据处理，处理完成后，因 greeting 发生变化，触发 greetingDidChange 事件发生。

在这个实例里 ViewController 有设定 greetingDidChange 回调，所以实现了类似了上面所说的数据与行为绑定。

VIPER

从结构上来看，在 Presenter 中间多了一层 Interactor ，它主要起到了数据维护访问的职责。你可以封装更多的 Service 或 Managers 做为依赖调用。

对于页面间的跳转，这里增加了 Router 层，专门用于跳转逻辑，实际上现在不少架构已经加了各自的 Router 逻辑。这一点可能是从 Rails 框架继承而来。

下面的例子不包含 Router 层

VIPER Example

从以上最简的示例代码来看，View 层 (ViewController) 同样还是通过 Presenter 层 (GreetingViewEventHandler) 触发事件逻辑，只不过 Presenter 拿数据是从 Interactor 层（GreetingProvider）去拿。层与层之间还是通过协议通导，不依赖实体。

从这个架构来看，它的耦合性是最小的，不过也带了设计上的复杂性。所以使用时，要因地制宜。

总结

最后附上一位专家 Bohdan Orlov 的总结，它们的横向对比图，寻找自己最适合的模式使用。

iOS Arch comparison

耦合度 (Distribution)
可测性 (Testability)
易用性 (Ease of use)

PS：这里也提到了 Redux 模式，想了解 Redux 相关的内容话，看这个链接吧。研究不深，大致是和 FP (函数式编程) 与 State 流相关。

总而言之

没有杀手锏
no Silver Bullet
分层治理
分久必合，合久并分，看具体业务场景
低耦合，高内聚
基本要素
遵从流行的框架与概念，有利于团队间的沟通成本
如果一定要发明，请多推广你的概念
从简到繁，再化繁为简
前一个繁是业务的属性，后一个繁是框架本身

三月 8, 2018 by square

Others

重头梳理网络协议栈

从 1989 年 HTTP 0.9 发布开始，互联网的发展已经近三十年，各种网络概念也是层出不穷。如 Https, WebSocket, Http 2.0, spdy 等等。

相信大家或多或少能从各种途径，获取到详细的资料。这里我想通过另一个维度，来看看它们是如何演化而来，为什么这么设计，解决了什么业务场景，以及一些基本的入门实践等。

我们试图从以下几个问题出发，解释这篇文章的初衷。

当我们打开浏览器访问一个网页时，它是如何将数据安全的发送给我们的？
Http 2.0 为何时隔10年才出现，它解决了什么问题？
Socket 和 Http 什么关系？
Web socket 又是什么？它是工作在哪一层的？
想要更轻量，更有效率的数据传输如何做？

为了解释以上问题，我们先从网络基础知识开始，这对解释以上问题很重要。

1. 网络协议

1.1 七层协议

OSI model: The Open Systems Interconnection model
一种概念模型，由国际标准化组织（ISO）提出，一个试图使各种计算机在世界范围内互连为网络的标准框架。
通俗的说，为了全世界的计算机之间相互通信，而设计的一种协议框架，所有需要联网的设备或软件都需要遵循它的规则。另外，也为了尽可能避免所有功能混杂在一起，让不同公司或组织更聚焦在一个领域上，才有了现在的分层模型。

我们可以看到在每一层，根据实际应用场景，都有对应的协议被设计出来。

从上面的模型我们可以知道，大的结构上，分为面向上层应用与面向网络媒介两个部分。应用层上主要是面向数据与数据的传输，网络媒介主要是面向网络通信与硬件。

1.2 TCP/IP

基于 OSI 协议模型衍生而来，现今使用最多的就是 TCP/IP 协议栈了。注意这里的 TCP/IP 协议栈并不只是指 TCP 与 IP 协议的合集，它是一种更简化的 OSI 模型。

通过下图可以看到它与 OSI 模型区别:

从 tcp/ip 协议规范来看，应用层，表示层与传输层被合并在一起。主要原因是这三层，在当今的实际使用中有相当多耦合关系，也很难将它们刻意的分离。

实际上现在的 TCP/IP 模型更加简单明了，更适应现在的应用场景。

除了以上的协议栈外，还有当今两个重要的协议：TLS 与 SPDY 。

1.3 TLS/SSL

TLS/SSL 是当今一个比较重要的安全传输协议，它不在上面所列的协议栈中。但它被设计位于应用层与传输层之间。以确保数据在传输之前是安全的，但又不破坏原有的数据协议。应用层协议（例如：HTTP、FTP、Telnet等等）能透明的创建于TLS 协议之上。

我们经常听到的 HTTPS, 这个 S 指的就是 secure (安全)，同时分为 SSL 和 TLS 协议。它被 Netscape 公司在 1994 年推出。

SSL: (Secure Socket Layer，1994 年推出, 第一版作者: 塔希尔·盖莫尔)。
SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。

TLS: (Transport Layer Security, 1999 年推出)
它建立在SSL 3.0协议规范之上，作用同于 SSL, 与 SSL 3.0 差别极小，可以理解为SSL 3.1。

无论是 SSL 还是 TLS 都分为两层: 握手协议与记录协议

SSL 因为被报有各种安全问题，所以基本上现在所使用的都是 TLS。

以下是建立连接的过程：

它必须建立在可靠的数据传输基础上，所以一般是在TCP之上。

同时，如果一但使用了 SSL/TLS 做安全验证，建立连接的时间实际上是会变长的，如图：

1.4 SPDY

SPDY（发音如英语：speedy），2010 年 9 月一种开放的网络传输协议，由 Google 开发，用来发送网页内容的协议诞生，用以最小化网络延迟，提升网络速度，优化用户的网络使用体验。它基于 TCP 的应用层协议，也是 HTTP/2 的前身。它最早被应用在 Chrome 6 。

设计 SPDY 的目的在于降低网页加载时间。通过优先级和多路复用，SPDY使得只需要创建一个TCP连接即可传送网页内容及图片等资源。SPDY 中广泛应用了 TLS 加密，传输内容也均以 gzip 或 DEFLATE 格式压缩（与 HTTP 不同，HTTP的头部并不会被压缩）。另外，除了像 HTTP 的网页服务器被动的等待浏览器发起请求外，SPDY 的网页服务器还可以主动推送内容。

SPDY 并不用于取代 HTTP，它只是修改了 HTTP 的请求与应答在网络上传输的方式；这意味着只需增加一个 SPDY 传输层，现有的所有服务端应用均不用做任何修改。当使用 SPDY 的方式传输，HTTP 请求会被处理、标记简化和压缩。比如，每一个 SPDY 端点会持续跟踪每一个在之前的请求中已经发送的 HTTP 报文头部，从而避免重复发送还未改变的头部。而还未发送的报文的数据部分将在被压缩后被发送。

Google 之所以改动 HTTP 协议而不是 TCP/IP，是因为改 HTTP 只需更新 Browser 和 web server 就行了，而改动 TCP/IP 牵扯面太广，需要更新所有的路由器，服务器和客户端的操作系统。

1.3 TCP

无论应用层的协议如何定义、使用，都要基于一条已经连接的通路去发送与接收数据，我们可以试着从我们最熟悉的数据传输层开始，来了解连接的建立与传输。

这一层有两个重要的协议，TCP 与 UDP。

TCP 协议的运行可分为三个阶段：连接创建(connection establishment)、数据传送（data transfer）和连接终止（connection termination）

连接创建

TCP 用三次握手（three-way handshake）过程创建一个连接。在连接创建过程中，很多参数要被初始化，例如序号被初始化以保证按序传输和连接的强壮性。

一对终端同时初始化一个它们之间的连接是可能的。但通常是由一端打开一个套接字（socket）然后监听来自另一方的连接，这就是通常所指的被动打开（passive open）。服务器端被被动打开以后，用户端就能开始创建主动打开（active open）。

客户端通过向服务器端发送一个 SYN 来创建一个主动打开，作为三路握手的一部分。客户端把这段连接的序号设定为随机数A。

服务器端应当为一个合法的 SYN 回送一个 SYN/ACK。ACK 的确认码应为 A+1，SYN/ACK 包本身又有一个随机产生的序号B。

最后，客户端再发送一个 ACK。当服务端受到这个 ACK 的时候，就完成了三路握手，并进入了连接创建状态。此时包的序号被设定为收到的确认号 A+1，而响应号则为 B+1。

TCP 的三次握手

连接重试

如果服务器端接到了客户端发的SYN后回了SYN-ACK后客户端掉线了，服务器端没有收到客户端回来的ACK，那么，这个连接处于一个中间状态，即没成功，也没失败。于是，服务器端如果在一定时间内没有收到的TCP会重发SYN-ACK。在Linux下，默认重试次数为5次，重试的间隔时间从1s开始每次都翻倍，5次的重试时间间隔为1s, 2s, 4s, 8s, 16s，总共31s，第5次发出后还要等32s才知道第5次也超时了，所以，总共需要 1s + 2s + 4s+ 8s+ 16s + 32s = 63s，TCP才会断开这个连接。

数据传输

主机收到一个 TCP 包时，用两端的IP地址与端口号来标识这个 TCP 包属于哪个session。

TCP 或 UDP 使用了端口号（Port number）的概念来标识发送方和接收方的应用层，通常也称为 Internet sockets。对每个 TCP 连接的一端都有一个相关的16位的无符号端口号分配给它们。端口被分为三类：众所周知的、注册的和动态/私有的。众所周知的端口号是由因特网赋号管理局（IANA）来分配的，并且通常被用于系统一级或根进程。众所周知的应用程序作为服务器程序来运行，并被动地侦听经常使用这些端口的连接。例如：FTP (20 and 21), SSH (22), TELNET (23), SMTP (25), HTTP over SSL/TLS (443), and HTTP (80)等。注册的端口号通常被用来作为终端用户连接服务器时短暂地使用的源端口号，但它们也可以用来标识已被第三方注册了的、被命名的服务。动态/私有的端口号在任何特定的TCP连接外不具有任何意义。可能的、被正式承认的端口号有65535个。

超时重传

另外，对于 TCP 数据传输，有一个重要的概念提到的就是 超时重传。这个机制是进一步来证明为何 TCP 是一种可靠的传输。

发送方使用一个保守估计的时间作为收到数据包的确认的超时上限。如果超过这个上限仍未收到确认包，发送方将重传这个数据包。每当发送方收到确认包后，会重置这个重传定时器。

这个超时定义就是 RTT (来回通讯延迟（Round-trip delay time）) 在的定义。

连接终止

使用了四次握手 (four-way handshake) ，终止一个 TCP 连接

TCP 四次握手终止连接

更详细的资料可以参考 Wikipedia

1.4 UDP

除了可靠的 TCP 连接，还有一种称为不可靠的连接机制: 用户数据包协议（User Datagram Protocol，缩写为UDP），是一个简单的面向数据报的传输层协议。此协议由 David P. Reed 在 1980 年设计出来，并纳入 RFC 768 成为正式的规范。

两者各有利弊，UDP 无需建立连接，不保证传输的可靠性，也没有重试机制，所以它的效率更高，当然数据传输的质量也不保证。

在TCP/IP模型中，UDP为网络层以上和应用层以下提供了一个简单的接口。UDP只提供数据的不可靠传递，它一旦把应用程序发给网络层的数据发送出去，就不保留数据备份（所以UDP有时候也被认为是不可靠的数据报协议）。UDP在IP数据报的头部仅仅加入了复用和数据校验（字段）。

网络上的众多使用UDP协议的关键应用一定程度上是相似的。这些应用包括域名系统（DNS）、简单网络管理协议（SNMP）、动态主机配置协议（DHCP）、路由信息协议（RIP）和某些影音流服务等等。

1.5 Socket

上面我们提到了 Socket ？按字面的意思是插座的意思，也就是建立一个通道，进行通信或连接。

Socket 工作流

根据 OSI 模型，它是基于传输层 (TCP/UDP) 上的一种具体实现。有了 TCP/UDP 协议，双方可以按照协议的规定，搭建起连接，一但连接搭建起来，我们就称它为 Socket 连接已建立，相当于插到插座上了。

在计算机科学中

它通常代表网络套接字（Network socket），又译网络插槽，是电脑网络中进程间互相通信的一种机制。使用互联网协议（Internet Protocol）为通信基础的网络套接字，称为 Internet socket。因为互联网协议的流行，现代绝大多数的网络套接字，都是属于 Internet socket。

在操作系统中

它是一种提供进程间通信的机制。通常会为应用程序提供一组应用程序接口（API），称为套接字接口（socket API）。应用程序可以通过套接字接口，来使用网络套接字，以进行数据交换。最早的套接字接口来自于4.2 BSD，因此现代常见的套接字接口大多源自Berkeley套接字（Berkeley sockets）标准。在套接字接口中，以IP地址及通信端口组成套接字地址（socket address）。远程的套接字地址，以及本地的套接字地址完成连接后，再加上使用的协议（protocol），这个五元组（five-element tuple)，作为套接字对（socket pairs），之后就可以彼此交换数据。

例如，再同一台计算机上，TCP 协议与 UDP 协议可以同时使用相同的port而互不干扰。操作系统根据套接字地址，可以决定应该将数据送达特定的进程或线程。这就像是电话系统中，以电话号码加上分机号码，来决定通话对象一般。

所以也可以理解为 socket = IP + Port

这里有 C 写的 Socket Demo 大家可以参考。其中 accept 函数也就是实现了三次了握手的过程。

2. 应用层

2.1 HTTP

应用层里最常用的协议之一，Hypertext Transfer Protocol (HTTP) 超文本传输协议。

HTTP 历史

– 1965 年，一个叫 Ted Nelson 的 26 岁年轻人，提出了超文本与超媒体的概念。（真是英雄出少年）

– 1989 年，时隔多年，一个叫 Tim Berners-Lee 和他的团队在 CERN（欧洲核子研究组织）基于超文本概念，开始了 WorldWideWeb 项目。也就是我们现在耳熟能详的 WWW (万维网)，将超文本系统与互联网结合在一起，将超文本数据发送出去。第一个版本只有一个方法，叫 GET ，它可以从服务器请求一个页面到客户端，这个页面就是 HTML 页。

– 1991 年，第一个 HTTP 的文档 HTTP 0.9 定义出来。世界上第一个网站在 CERN 搭建。

十二月 6, 2017 by square

Others

10 分钟将你的网站升级到 HTTPS

随着 HTTPS 的普及，现在不用 HTTPS 都不好意思把网站发给别人了，所以索性也把个人博客升级到 HTTPS 。

HTTPS 带来的好处不用多说了，直入正题。

环境配置

先说一下服务器环境配置，根据运行环境不同，可能会有少许配置差异。

OS: Ubuntu 14.04.2
Web Server: Nginx 1.4.6
CGI: PHP-FPM

证书

现在提供免费证书的公益组织非常多了，Let’s encrypt 就是其中一家。为了减少配置工作，推荐使用他们的 Shell 工具 certbot 在服务端自动配置。官网上列有不同 OS 的下载与安装方法。

官方推荐方式：
certbot –nginx

我们这里用的是指定参数安装
certbot certonly -w /var/www/blog -d doruby.com

-w 是你站点存放的位置，目的是在对应的目录下，创建 well-known/acme-challenge/ 这样的目录，并放入认证文件，它会让官网根据这个文件是否可访问，来判断这个域名是不是你所拥有的。所以要保证这个目录是可以被外部所访问到的。
所以在执行这个命令前，先确认你的 nginx 配置了它可被访问：


server{

....

location ~ /.well-known {

allow all;

}

}

-d 是对应的域名，多个域名可以在后面继续用 -d 添加

如果命令顺利执行完成，会收到 Congratulations 的提示，并提示证书所在位置，比如 /etc/letsencrypt/live/doruby.com/fullchain.pem 记录下来。

在 Nginx 配置文件中，添加 SSL 相关配置


server {

listen 443; # 原先应该是 80
......
ssl on

ssl_certificate /etc/letsencrypt/live/doruby.com/fullchain.pem;

ssl_certificate_key /etc/letsencrypt/live/doruby.com/privkey.pem;
......
}

如果相让原先访问 Http 的入口自动跳转到 Https ，可以再增加一些配置


server {

listen 80;

server_name doruby.com;

return 301 https://$host$request_uri;

}

OK. 重启 Nginx ,顺利的话你现在应该可以看到你的网站跳到 Https 了，并且前面会有绿色小锁。

这里有几点需要注意

如果创建证书遇到问题，第一时间检查提示的日志文件
如果配置完成后，网站打不开，establish 不成功，先检查一下服务器有没有打开 443 端口的访问权限

八月 3, 2017 by square

Others

URLCache 设置不当影起的 App 故障

关于数据请求是几乎每个 App 会经常遇到的事，关于数据的 Request 与 Response 及 Cache 其实我们需要了解更多细节才能运用自如，排查问题更快。

很久之前，我时常遇到一部分用户能打开页面，一部用户却不能的情况。在排除网络，地域，机型，服务器状态完全正常的情况，一直无法解释其原因。客户也说不上来有什么区别，操作路径也是一样，只是过一段时间就自然恢复了，或重装等等解决。

直到最近的一次故障让我彻底将此类问题的原头分析了一遍，才有所顿悟。

故障
1. 现象
  服务端因某种原因使所有 API 请求返回错误的，类似源代码的片段内容。几个小时后服务器恢复。不过部分用户使用时看到的仍然是出错页面，而其他用户又是正常。
2. 影响范围
  后来仔细分析发现，在服务器宕机的那段时间内，用户如果打开过 App ，则一直会看到出错页面。即使完全退出 App 再进入错误仍旧发生。如果这段时间内没有打开过 App 的用户，在之后打开的话，就会看到正常的页面。所以影响面是所有服务器出错这段时间内，打开过 App 的用户。
故障分析
1. 表象分析
  最初怀疑是不是服务器未完全恢复，这部分用户仍受到影响。或服务器给出了错误的缓存页面。后来通过查询网络请求日志，发现服务器未收到任何请求，包括网关服务器。之后尝试让有此故障现象的设备重装 App ，结果发现一切又恢复正常。初步判断有可能是客户端缓存了页面，并将错误返回导致。但是这种错误页面或错误理伦上是不该有的，所以从源头开始排查。
2. 数据请求 Request
  数据请求，App 底层用的系统原生 URLRequest + URLSession 做的网络请求处理，所以排除第三库的问题。在 URLRequest 实例话的过程中，也没有设置特定的 cachePolicy ，所以也是默认的缓存策略。那关于系统的缓存策略有哪些，默认的缓存策略又是什么样的呢？
3. 缓存策略 Cache
  通过查询 API 我们发现有以下几种:
  useProtocolCachePolicy 协议缓存（后面会详细介绍）。这是默认的
  reloadIgnoringLocalCacheData 忽略本地缓存，也就是说不实用缓存，直接从原始资源加载。
  reloadIgnoringLocalAndRemoteCacheData // Unimplemented 在写这篇文章时 API 定义是”未实现”，所以这个忽略
  returnCacheDataElseLoad 无论缓存是否过期，都使用缓存，如果缓存不存在则请求原始资源地址
  returnCacheDataDontLoad 只用缓存，不请求网络资源。可用于类似”离线状态”
  reloadRevalidatingCacheData 从原始地址确认缓存数据的合法性后，缓存数据就可以使用，否则从原始资源请求从本例来看，我们使用了默认的协议缓存策略。下面来看看这个策略是如何工作的。
4. 协议缓存 NSURLRequestUseProtocolCachePolicy我们引用了官方给出的一张流程图来详细解释这个过程从上至下我们可以看一下整个过程
  
  Continue reading

三月 9, 2017 by square

Debug

ASDebugger — 超简单的 App 网络监控调试工具

不知道大家有没有这样的经历，我们的 App 经常需要和服务端打交道，访问各种 API。往往也不知道客户端到底发送了哪些请求，它们的返回值是什么，效率如何，有没有经为 API 异常导致的问题，等等。

所以以往我们都是用各种抓包工具比如 Charles，或打印 log 来调试，这样有时会被很多无用的信息掩盖，信息也不直观。所以才有了想做一个专门针对 API 调试的工具。

不过这还不够，因为有时因进度问题，客户端必须先 Mock 一些数据过 APP 使用，或者为了测试接口的强壮性，我们必须刻意的去修改 API 返回值，来进行异常数据的测试，所以我就加上了简单的 Mock 功能，主要还是为了方便实用。

如何使用

用 CocoaPods 的同学只需引入这个库

pod ‘ASDebugger’

然后

[ASDebugger startWithAppKey:@”AppKey”]; # Appkey 为你在 AppScaffold 网站上申请到的 AppKey

ASDebugger 截图之一

也许我们还有很多需求去实现，不过在目前的工作中，是够用了，效率也得到了提升。再也不会为数据问题纠结来纠结去，最常做的事情就是打开网站，把截图丢过去，哈。。。

点击这里开始体验吧 AppScaffold.net

因为人手问题，平台的前后端都是一人完成，所以难免遗漏不少地方。欢迎大家多提建议和意见，我将非常感谢，也欢迎加入开源的队伍中来，一起提高工作效率。

二月 21, 2017 by square

Performance

App 启动优化之一：main.m 方法之前的优化

说到APP的启动优化，网上应该也有不少经验总结，不过就我所之相对有些零散，缺乏一些系统性的梳理。为了让我们有一个完整的认识，也为了能和大家一起学习提高，这里我先抛砖引玉，引入第一篇文章从头梳理APP启动的各个环节，希望对大家有所帮助。

Launch Seq

我们首先要谈的是在开启一个 APP 的生命周期前，也就是进入 main.m() 方法之前，系统要经历怎样的一个加载过程呢？

四月 11, 2016 by square

Third Library

FlexBox 使用向导

简介

Flexbox 布局模块提供一个容器，使其中的元素，可以采用更便捷的方法实现布局、对齐、分布间距等方式。甚至当大小不定时，可以自动伸缩（它们称为”flex”）

它的思想主要是基于 flex layout，调整容器里的元素宽/高，填充合适空格（更多用于不同设备的屏幕的适配）。

基本述语

在了解 Flexbox 述语前，有必要先看看 CSS 中关于 inline-block 的介绍

十月 19, 2015 by square

Worflow

Gitflow 在客户端开发中的实践

为了规范开发流程，当存在多次预发布情况时，不至于因代码不同步，遗漏Bug修复。并让流程更清晰，避免出现多个混淆分支。所以将实践方案提出供大家一起讨论。

先看看标准的 Gitflow 流程

gitflow practices

八月 14, 2015 by square

Page 1 of 312 3 »

类	Category函数	系统Category仓库
NSObject	safeValueForKey	AccessibilityUtilities
NSDictionary	boolForKey	HMFoundation
NSDictionary	stringForKey	HMFoundation
NSDictionary	arrayForKey	HMFoundation
NSDictionary	dictionaryForKey	HMFoundation
NSDictionary	dataForKey	HMFoundation
NSDictionary	numberForKey	HMFoundation
NSDictionary	mutableDictionaryForKey	HMFoundation
NSDictionary	mutableArrayForKey	HMFoundation
NSString	unsignedLongLongValue	HearingUtilities
NSString	unsignedLongLongValue	HearingUtilities
NSString	stdStringForString	libwebrtc
NSString	stringForStdString	libwebrtc
NSString	unsignedIntValue	IMFoundation
NSString	stdString	GeoServices
NSString	containsString	Foundation
NSString	unsignedIntValue	IMFoundation
NSString	hexValue	IMFoundation
NSString	hasPrefixCaseInsensitive	CalendarFoundation
NSString	urlEncodedString	Social
NSMutableArray	nonRetainingArray	IMFoundation

可能出现问题的关键字

Category 私有函数

前言

基础知识

什么是内存?

32 位与 64 位是什么概念？

寄存器 (Register)

内核空间与用户空间

虚拟空间中的内存布局 (Memory layout)

C 语言应用程序的内存布局

基本数据类型的内存空间

内存对齐

内存管理

内存泄漏

MVP

MVVM

VIPER

总结

总而言之

1. 网络协议

1.1 七层协议

1.2 TCP/IP

1.3 TLS/SSL

1.4 SPDY

1.3 TCP

1.4 UDP

1.5 Socket

2. 应用层

2.1 HTTP

......

......

如何使用

简介

基本述语

先看看标准的 Gitflow 流程

近期文章

近期评论

文章归档

分类目录