今天清理旧电脑文件时，眼睛不经意间扫到了尘封已久的博客文件夹，一种回归写作的冲动油然而生…

于是赶忙尝试运行一下，enm…果然运行不起来：

GitLab作为目前最主流的分布式代码托管工具，不仅免费还支持私有化部署，同时又具备高度可定制化工作流特性，因此被业界大部分公司企业所采用。

本文章主要记录基于Mac+Docker方案的Gitlab部署过程，如果你是个人，可以用来搭建自己的gitlab服务器作为私人代码仓库，如果你就职于小型或初创公司，在资源有限的情况下也可以尝试部署成团队代码仓库作为过渡。

iBeacon调研记录(一)主要介绍了iBeacon(Bluetooth Low Energy)是什么,使用场景,API介绍及注意事项。如果看过了上篇文章,相信你对iBeacon已经有了初步了解,这篇文章主要是利用上一篇所记录的内容写一个方便监视iBeacon设备信号动态变化和修改监视区域参数的工具。

简单描述一下需求:

• 实时监测到iBeacon信号变化
• 可以方便添加/删除/修改监视的iBeacon
• 从边界进入到监视区域会通知用户 (在前台:弹出提示框 在后台:本地推送消息)
• 刚开始就在监视区域通知用户 (在前台:弹出提示框 在后台:本地推送消息)
• 同一区域不重复性提示用户

看了上面的需求,首先我们要有一个列表用来展示所有iBeacon信号变化,当进行添加/修改操作的时候,需要跳转到一个新的页面去编辑,编辑完成之后再跳回到iBeacon列表页面,页面的简单操作描述就是这样。

最终在真机下的效果:

最近公司机场的广告机项目要实现用户只要走近机器就在手机上推送广告消息的功能,基于这一点让我想到了苹果公司iOS7推出的iBeacon定位技术,之前也没有实际使用过,趁着项目需要,边研究边记录。

iBeacon

iBeacon的底层技术是采用的低功耗蓝牙技术(Bluetooth Low Energy),它与传统的蓝牙概括有这几点区别:

• 耗电量:持续运作的时间更长,estimote声称可以运作24个月,具体的运作时间还是和iBeacon设备的广播频率周期有关。
• 低成本:iBeacon设备的成本相当于传统蓝牙设备的60%-80%。
• 应用:iBeacon设备适用于只要求少量定期传输数据的简单应用,传统的蓝牙适用于需要持续通信和大量数据传输的复杂应用。

我们在日常使用移动应用产品时经常会遇到正在使用的这款APP在操作中经常会跳转到另一款APP中去操作,比如支付宝支付,微信支付,微博分享等。这不禁让我们联想到苹果的沙盒机制,受苹果的这一机制影响,我们不能应用之间资源共享,也就是说我们的应用都是独立的块,应用内所需要的资源都是自给自足不受外界的”救济”,那么应用之间通信的行为就是通过URL Schemes来实现的。

URL Schemes

我们通过对比网页链接来理解iOS上的 URL Schemes。

URL Schemes有两个单词:

• URL:链接地址或网址,https://www.baidu.com 就是一个URL。
• Schemes:表示的是URL中的最初位置,即://之前的那段字符,比如 https://www.baidu.com 这个URL的Schemes就是https。

根据上面对URL Schemes的理解,我们在iOS中如果想定位到某个APP,只需要知道 Schemes 部分就可以做到了,比如我们要打开微信这个APP,我们只需要知道微信的 Schemes 是 wexin ,在后面拼接上 :// 即: wexin://
然后在 safari 浏览器输入网址的地方输入 wexin:// 确认后就会在屏幕中弹出 在"微信"中打开链接吗? 的提示框,当你选择打开操作后就会自动跳转到微信界面了。

目前我们仅仅是定位到了某个APP,如果想跳转到这个APP并让它做一些我们想要的操作的话,我们需要在://后面跟一些路径参数让它定位到具体的功能或页面:

我们在xcode工程Build Settings中的Architectures一栏可以看到诸如armv7,arm64字样的配置信息,这类配置信息在我们日常开发过程中究竟起到什么作用,查阅了相关资料后在此整理一下。

指令集

指令集是存储在CPU内部，对CPU运算进行指导和优化的硬程序。拥有这些指令集，CPU就可以更高效地运行。Intel主要有x86，EM64T，MMX，SSE，SSE2，SSE3，SSSE3 (Super SSE3)，SSE4A，SSE4.1，SSE4.2，AVX，AVX2，AVX-512，VMX等指令集。AMD主要是x86，x86-64，3D-Now!指令集。

简单粗暴地理解下来就是指令集可以帮助CPU更高效地运行。

在项目开工之前,为了保证代码质量,通常我们会和团队中的成员讨论并制定一份代码规范文档,虽然文档已经形成了,但是在实际开发的过程中为了赶项目亦或者某个成员习惯于自己以前的代码风格忽略了规范文档中的细节要求,导致了部分代码风格不统一,这时候再通过审视写过的代码来排查是一件枯燥又乏味的过程,相信大多数紧张进行中的团队也没有足够的时间来做这样一件事情,如果我们能够像xcode编译工程代码一样Command + B就能提示哪里没有符合代码规范就省去了我们大量的Code Review时间,既然本篇文章讲的是自动化Code Review,接下来我们实现这一自动化过程。

OCLint

OCLint 是一个开源的，基于 Clang 用 C++ 编写而成的，可以用于 C、C++ 和 Objective-C 的静态代码分析器。它可以在扫描的过程中动态加载规则文件（Rules），因此可以实现非常灵活的，高度可自定义的代码分析方案。它几乎可以和大多数系统无缝集成，例如 Cmake、Bear、xcodebuild、xctool、Xcode、xcpretty、Jenkins CI、Travis CI 等。

当项目不断扩大,团队中不断有新的成员加入,这时候就需要我们的项目有可查看的技术文档,方便新加入的成员查阅,快速地了解项目。但是这种文档如果从团队中专门调配出人去整理的话,既低效成本又高,还好iOS也有类似于java语言中的javadoc可以根据源码中的注释来生成技术文档的工具。

目前iOS比较常用的自动生成文档工具有doxygen, headdoc 和 appledoc三个,下面来看一下这三个工具的对比情况。

Doxygen

Doxygen原本是为C++开发的文档生成工具，当然它是开源的，通过一票扩展也能支持各种主流非主流语言。除了能生成HTML外，还能生成pdf和LATEXLATEX格式。在appledoc出现之前，很多人就喜欢用这个来生成ObjC代码的文档。相比HeaderDoc来说，有很多可以调教的地方。苹果官方也曾为这个工具写过文档。一切看上去都很棒，不足的地方就是，它生成的文档风格和官方文档的风格差了很多（虽然说不算太难看，但是放到Xcode里看格格不入），配置复杂等。。