RunLoop 学习笔记

RunLoop 是 iOS 开发当中一个很基础又很重要的概念。由于它是一个很底层的概念,日常开发中很少直接接触到,再加上官方文档写得很难理解,导致很多开发者(包括我自己)都对这个概念一知半解。但是,既然它是很重要的概念,又是 iOS 开发的底层基础,我们就不得不去把它啃下来。

经过这几天的学习,感觉自己对 RunLoop 的概念理解得比较清晰了,因此写篇笔记来进行下总结。

(译)使用 Swift 3 与 Xocde 8 创建条码与二维码扫描应用

本文由SwiftGG独家授权发布。

那么,什么是二维码呢?我相信读者中的大多数都知道什么是二维码(译者注:我觉得应该是全部都知道吧)。以防还有读者没有听说过二维码,可以看一下上面这张图片(译者注:原文如此,并且原文中也没有图片)——那就是二维码。

二维(QR 全称是 Quick Response 快速响应)码是一种二维的条形码,它是由 Deson 所发明的。它原本被设计用于跟踪工业生产中的零件,最近几年二维码被用于编码 URL,在消费市场上受来越来越多的欢迎。与你所熟悉的普通条形码不同的是,二维码在横向和纵向上都包含了信息。这赋予了它储存大量数字和字母信息的能力。我并不想在这里深入讨论二维码的技术细节。如果你对这些感兴趣的话,可以参考二维码的官方网站

免越狱版 iOS 抢红包插件

又到年末,微信红包又开始成为大家所关心的话题了,不管是公司年会,还是朋友聚会,似乎不发红包就没办法继续聊下去了。因此,值此新年来临之际,我对我的iOS 微信抢红包 tweak进行了一下改进。主要增加了插件开关,以及随机延迟功能,让你在新一轮红包大战中无往而不利。

但是,这毕竟是一个 tweak,只有少数有越狱机器的小伙伴才能使用这个插件,无疑门槛是太高了。到目前为止,已经有无数朋友在问到底有没有免越狱版本的插件了。

今天,我们就要讨论下如果制作免越狱版本的微信抢红包插件。

通过逆向深入理解 Block 的内存模型

自从对 iOS 的逆向初窥门径后,我也经常通过它来分析一些比较大的应用,参考一下这些应用中某些功能的实现。这个探索的过程乐趣多多,不仅能满足自己对未知的好奇心,还经常能发现一些意外的惊喜。

正常情况下,通过分析界面以及 class-dump 出来头文件就能对某个功能的实现猜个八九不离十。但是 Block 这种特殊的类型在头文件中是看不出它的声明的,一些有 Block 回调的方法名 dump 出来是类似这样的:

1
- (void)FM_GetSubscribeList:(long long)arg1 pageSize:(long long)arg2 callBack:(CDUnknownBlockType)arg3;

因为这种回调看不到它的方法签名,我们无法知道这个 Block 到底有几个参数,也不知道它函数体的具体地址,因此在使用 lldb 进行动态调试的时候也是困难重重。我也一度被这个困难所阻挡,以为调用到有 Block 的方法就是进了死胡同,没办法继续跟踪下去了。我还因此放弃过好几次对某个功能的分析,特别受挫。

好在,我们还有 Google 这个强大的武器。没有什么问题是一次 Google 不能解决的。如果有,那就两次。

这篇文章就来讲讲如何通过 Block 的内存模型来分析出它的函数体地址,以及函数签名。

MacVim 安装 vim-airline 插件

Emacs 是神的编辑器,而 Vim 是编辑器之神。

这句话由来已久,具体的出处已经不可考了。

要真讲起来,我使用编辑器之神也有小几年了,但是一直以来都只是把它当成普通的编辑器来使用了。这无异于使用屠龙刀来杀鸡,每次想起来都让我感学羞愧难当,这次痛定思痛,决定再把 Vim 系统学习一遍,务必把它当成日常使用的编辑器。

Vim 编辑器最重要的两样零件就是 .vimrc 配置文件和各种好用的插件了。

关于 .vimrc 配置文件,我决定从零开始,在重新学习的过程中一行一行添加自己需要的功能,而非直接使用网上各种大神共享的配置文件,毕竟使用别人的东西难免还是会不趁手。

而对于 Vim 插件,现在已经有很多好用的插件管理器了,安装插件也不是什么困难的事了。

但是,在我安装第一个插件 vim-airline 的时候就遇到了不少坑,这里用篇文章来记录下。

配置 Nginx 的目录浏览功能

有时候我们需要将服务器上的某些目录共享出来,让其他人可以直接通过浏览器去访问、浏览或者下载这些目录里的一些文件。

最近我就正好需要将一些静态的 HTML 页面部署到服务器上,让自己的多台设备能随时随地进行查看。

经过搜索之后找到了两个方法:一是使用 Node 的 http-server,二是使用 Nginx 自带的 ngx_http_autoindex_module 模块。由于我自己的博客就是使用 Nginx 部署的,所以我就选择了第二种方法。

本篇文章介绍如何打开 Nginx 的目录浏览功能,配置简单的密码保护,并对索引页面进行美化。

使用 JavascriptCore 与 UIWebView 进行交互

本篇文章的示例代码可以在我的Github上进行下载。

上一篇文章中我们讨论了 JavaScriptCore 的基本使用,如何在脱离 UIWebView 的情况下让 JavaScript 与原生进行交互。

但是,在混合开发过程中,我们需要的是让原生应用能与 UIWebView 进行流畅的交互。就如上一篇文章讲到的,从 iOS 2 以来,我们与 UIWebView 进行交互的唯一方式就是使用 stringByEvaluatingJavaScriptFromString:方法拦截请求,像在 Github 上很火的 WebViewJavascriptBridge 就是使用这一原理来实现的。不幸的是,这一现状在 iOS 7 以后并没有改变,虽然苹果公司在 iOS 7 之后推出了 JavaScriptCore 这个新工具,但是官方并没有提供获取 UIWebView 的 JSContext 方法。

(译)Swift 3 中的 GCD 与 Dispatch Queue

本文由SwiftGG独家授权发布。

多核处理器是中央处理器(CPU)自出现以来最大的技术进步,这意味着它可以同时运行多条线程,并且可以在任何时刻处理多于一个的任务。

串行执行以及伪多线程都已经是多年以前的历史了,如果你不是年轻到没有使用过老式的电脑,又或者你有机会去接触搭载着旧操作系统的旧电脑,你就能轻易明白我的话。但是,不管 CPU 拥有多少个核心,不管它有多么强大,开发者如果不好好利用这些优势 ,那就没有任何意义。这时就需要使用到多线程以及多任务编程了。开发者不仅可以,实际上是必需要好好利用设备上 CPU 的多线程能力,这就需要开发者将程序分解为多个部分,并让它们在多个线程中并发执行。

JavaScriptCore 基本使用

现在的移动开发已经越来越倾向于使用混合开发,而要使用混合开发就要求我们必须能让原生与 JavaScript 进行无缝的交互。

在 iOS 7 之前,我们对 JavaScript 的操作只有 UIWebView 里的一个方法 stringByEvaluatingJavaScriptFromString,而从 Javascript 里面调用原生方法只能使用拦截 URL 的方法,类似 WebViewJavascripBridge 就是基于 URL 拦截的原理来进行实现的。

而从 iOS 7 开始,苹果把 JavascriptCore 引进到了 iOS 开发当中,这个框架可以让我们脱离 UIWebView 同时用更方便同时更强大的方法来与 Javascript 进行交互。