王中周的技术博客

Stay hungry,stay foolish.

变长参数学习笔记

1、简介

在定义接口时,经常会遇到参数个数甚至类型都不确定的情况。这时,在类 C 语言中我们可以使用省略号指定参数表,具体形式如下:

1
void fun(parm1,parm2,...);

这种传参形式被称为 变长参数。C 语言中的:

1
int printf(const char * format, ...)

便是两个最经典的例子。对于固定参数列表的函数,每个参数的名称、类型是直接可见的,他们的地址和值也可以直接得到。但是对于变长参数的函数,该如何获取这些信息呢?

Try Catch 原理剖析

一、非局部跳转

1、简介

大部分语言的运行控制模型,都是基于栈的。在这种模型中,调用一个函数时,就会将这个函数的参数、返回地址、局部变量等信息入栈;这个函数返回时,对应信息再出栈。正常情况下,函数调用的进栈和出栈都是成对出现的,比如函数的调用顺序是:func1 —> func2 — > func3,那么一定是 func1 先进栈,然后是 func2,最后是 func3;而 func3 调用结束后一定是先返回到 func2 ,然后从 func2 返回到func3,而不能直接从 func3 返回到 func1。

我们都知道,C 语言中的 goto 语句,可以实现在一个函数内部跳转;与此同时,C 语言还提供了一种能够在函数间跳转、被称为 非局部跳转 (no-local goto) 的机制,这种机制可以允许从一个多层嵌套的函数调用中直接返回。我们先通过下面的栗子来见证它的神奇之处:

iOS内存探秘

iOS 内存机制特点

  • 有限的可用内存

iPhone 设备的 RAM 一直非常紧缺,iPhone 一代只有 128MB,直到 iPhone5 时达到了 1GB,并且在 iPhone7 plus 达到了 3GB。StackOverFlow 上提供了部分 iPhone 机型的可用内存数目。

  • 低内存通知

在可用物理内存较少时,iOS 会给各应用发出低内存广播通知,如果此后可用内存仍然低于特定值,则会杀死优先级较低的进程。

  • 没有内存交换机制

桌面操作系统可以在物理内存紧张的时候把暂时不用的物理内存置换到磁盘上,并在需要的时候再次加载到内存中。而 iOS 没有这种机制,原因是移动设备的闪存没有 PC 机那么大的硬盘,而且频繁的读写闪存会降低其寿命。目前 iOS 在内存不足时采用的方案是杀死优先级较低的进程。

  • 使用虚拟内存机制

和大多数桌面操作系统一样,iOS 也使用虚拟内存机制。

为什么 Objective-C 对象存储在堆上而不是栈上

为什么 Objective-C 对象存储在堆上而不是栈上

一、什么是栈对象和堆对象

在 Objective-C 中,对象通常是指一块有特定布局的连续内存区域。我们通常这样创建一个对象:

1
NSObject *obj = [[NSObject alloc] init];

这行代码创建了一个 NSObject 类型的指针 obj 和一个 NSObject 类型的对象,obj 指针存储在栈上,而其指向的对象则存储在堆上(简称为堆对象)。

目前 Objective-C 并不支持直接在栈上创建对象(简称为堆对象),但可以通过如下方式间接地创建:

1
2
3
4
5
6
7
struct {
Class isa;
} fakeNSObject;
fakeNSObject.isa = [NSObject class];

NSObject *obj = (NSObject *)&fakeNSObject;
NSLog(@"%@", [obj description]);

栈对象 obj 也能正常工作,由此可见栈对象和堆对象都是可行的,但为什么 Objective-C 不默认使用栈对象呢?

CocoaPods 详解之—-更新篇

CocoaPods 大概是 2011 年出现的开源组件管理工具(目前已支持 Objective-C 和 Swift),近年来普及率越来越高,几乎已是所有 Cocoa 开源项目的标配。另外,很多大点的团队会用 CocoaPods 拆分工程,实现项目插件化。

博主曾在 2014 年写过 CocoaPods 详解 系列文章:CocoaPods详解之——使用篇CocoaPods详解之——进阶篇CocoaPods详解之——制作篇,简单介绍了从使用到亲手制作 CocoaPods 开源组件的过程。

然而随着时间的推移,CocoaPods 有些使用方式也发生了变化,比如组件提交方式等。本文将从 Trunk 和私有仓库两个方面介绍自己对 CocoaPods 的新认识。

手动解析CrashLog之—-原理篇

在上篇文章《手动解析CrashLog之——方法篇》里介绍了手动解析CrashLog的方法,接下来再说说dwarfdumpatos等解析工具是如何从符号表文件中获取到崩溃位置信息的。一切还得从.dSYM符号表文件开始说起。

一、.dSYM文件的生成

符号表文件.dSYM实际上是从Mach-O文件中抽取调试信息而得到的文件目录,实际用于保存调试信息的问价是DWARF,其出身可以从苹果员工的文章《Apple’s “Lazy” DWARF Scheme》了解一二。

1、Xcode自动生成

Xcode会在编译工程或者归档时自动为我们生成.dSYM文件,当然我们也可以通过更改Xcode的若干项Build Settings来阻止它那么干。

2、手动生成

另一种方式是通过命令行从Mach-O文件中手工提取,比如:

1
$ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/dsymutil /Users/wangzz/Library/Developer/Xcode/DerivedData/YourApp-cqvijavqbptjyhbwewgpdmzbmwzk/Build/Products/Debug-iphonesimulator/YourApp.app/YourApp -o YourApp.dSYM

该方式通过Xcode提供的工具dsymutil,从项目编译结果.app目录下的Mach-O文件中提取出调试符号表文件。实际上Xcode也是通过这种方式来生成符号表文件。

手动解析CrashLog之—-方法篇

解决崩溃问题是移动应用开发者最日常的工作之一。如果是开发过程中遇到的崩溃,可以根据重现步骤调试,但线上版本就无能为力了。好在目前已经有很多不错的第三方CrashLog搜集平台(如友盟、Crashlytics等)为我们做好了解析工作,甚至在Xcode7里苹果也跟进了解析线上版本崩溃日志的功能,为开发者减轻了不少负担。尽管通常已经不需要我们手工处理CrashLog,了解CrashLog的还原原理和方法还是有必要的。

一、.dSYM

.dSYM(debugging SYMbols)又称为调试符号表,是苹果为了方便调试和定位问题而使用的一种调试方案,本质上使用的是起源于贝尔实验室的DWARF(Debugging With Attributed Record Formats),其在.xcarchive目录中的层次结构为:

1
2
3
4
5
6
.xcarchive
--dSYMs
  |--Your.app.dSYM
    |--Contents
      |--Resources
        |--DWARF

关于DWARF的具体内容以后有机会再说。我们能解析CrashLog全靠.dSYM文件,解析方式见后文。

二、确定符号表和崩溃日志的一致性

有了符号表文件,有了崩溃日志文件,在解析之前一定要确保二者的对应关系,否则就算按照下述步骤解析出内容也肯定是不准确的。二者的对应关系可以通过UUID来确定。

离屏渲染学习笔记

一、概念理解

OpenGL中,GPU屏幕渲染有以下两种方式:

  • On-Screen Rendering

意为当前屏幕渲染,指的是GPU的渲染操作是在当前用于显示的屏幕缓冲区中进行。

  • Off-Screen Rendering

意为离屏渲染,指的是GPU在当前屏幕缓冲区以外新开辟一个缓冲区进行渲染操作。

iOS Code Signing 学习笔记

最近看了objc.io上第17期中的文章《Inside Code Signing》对应的中文翻译版《代码签名探析》,收益颇深,对iOS代码签名机制有了进一步的认识。想了解详细内容建议大家还是去看原文好了。

下面是对此文章的理解再结合自己之前对该部分的认识写出的学习笔记。本文的前提是已经对非对称加密有了一定的了解。

一、数字签名(digital signature)

对指定信息使用哈希算法,得到一个固定长度的信息摘要,然后再使用私钥(注意必须是私钥)对该摘要加密,就得到了数字签名。所谓的代码签名就是这个意思。

手动内存管理转ARC项目实战

在ARC之前,iOS内存管理无论对资深级还是菜鸟级开发者来说都是一件很头疼的事。我参加过几个使用手动内存管理的项目,印象最深刻的是一个地图类应用,由于应用本身就非常耗内存,当时为了解决内存泄露问题,每周都安排有人值班用Instruments挨个跑功能,关键是每次都总能检查出来不少。其实不管是菜鸟级还是资深级开发者都避免不了写出内存泄露的代码,规则大家都懂,可是天知道什么时候手一抖就少写了个release?

好在项目决定转成ARC了,下面将自己转换的过程和中间遇到的问题写出来和大家共享,希望能减少大家解决同类问题的时间。