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

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

环境配置

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

1. OS: Ubuntu 14.04.2
2. Web Server: Nginx 1.4.6
3. CGI: PHP-FPM

证书

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

官方推荐方式：
certbot –nginx

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

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

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

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

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

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

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

这里有几点需要注意

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

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

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

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

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

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

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

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

如何使用

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

pod ‘ASDebugger’

然后

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

ASDebugger 截图之一

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

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

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

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

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

简介

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

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

基本述语

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

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

先看看标准的 Gitflow 流程

当你设计APP时，很可能要动态地响应事件。例如：触摸可能来自屏幕上不同的对象，你必须理解这些对象，知道如何正确的响应这些事件。

当用户生成的事件发生时，UIKit 会创建包含所需要处理的信息在一个事件对象里。然后将它放置在当前活动APP的事件队列中。对于触摸事件，它是将一组触摸封装在 UIEvent 对象里。对于运动事件，这个事件对象取决定于你使用的框架，并在里面有一些你所感兴趣的运动类型。

一个事件延特定的路径旅行，在它被交给下一个对象前，你都可以处理它。首先,单例的 UIApplication 对象从队列顶部拿到这个事件，并调度处理它。通常，它发送该事件给 Key Window 对象，然后它根据不同的事件类型传递给不同的实例对象。

手势识别

手势识别器将抽像度低的事件操作转化为更容易理解的动作，它们是附加在视图上的对象，并允许对这些动作进行回应。手势识别器解释这些触摸事件是否是一个特定的手势，比如轻扫，缩放，旋转。如果它们能正确识别，它们会发送一个动作给目标对象。这个对象是你指定的视图控制器，如下图所示。这样的设计模式强大简单，你可以动态指定响应动作，而且你可以添加一个手势识别给一个视图，而不用子类化视图。

为什么要有手势

在我们拿起手机时，除了语音外，最重要的交互操作就是通过手指触摸了。就如游戏机的手柄，电脑的键盘一样。在iPhone设备里，因为它没有物理键盘，所以每一个手势动作，必须准确的覆盖到每一个用户想要表达的真实意图。手势的重要性也不言而喻。

苹果如何设计手势

MKNetworkKit 网上已有不少介绍它的文章了，不过对于它提供的众多特性的实现机制，还是值得研究研究的。其中 Auto caching 是其中之一。

官方文档是这样写的：

High performance background caching (based on HTTP 1.1 caching specs) built in

MKNetworkKit can automatically cache all your “GET” requests. When you make the same request again, MKNetworkKit calls your completion handler with the cached version of the response (if it’s available) almost immediately. It also makes a call to the remote server again. After the server data is fetched, your completion handler is called again with the new response data. This means, you don’t have to handle caching manually on your side. All you need to do is call one method

[[MKNetworkEngine sharedEngine] useCache];

Optionally, you can override methods in your MKNetworkEngine subclass to customize your cache directory and in-memory cache cost.

• 它是基于 HTTP1.1 协议设计的Cache模式，刚好我们请求的后端服务也是基于这个协议，Cache-Control 用的是 max-age=0, private, must-revalidate , ETag 标记缓存