注意，根据《中华人民共和国计算机信息网络国际联网管理暂行规定》，任何单位和个人不得自行建立或者使用其他信道进行国际联网，因此本文尽可能在不违反法律的情况下使用镜像站解决上述网络问题。对于依旧解决不了的，可以酌情考虑换个行业。

开源镜像站

所谓开源镜像站，就是在原站点访问太慢或者无法访问时提供一个备用的镜像功能，通常用于企业环境指向内网的私有镜像站制品仓库。当然，在国内个人开发者的使用场景更多是用于网络加速。一些常用的开源镜像站点主页如下:

• 清华大学开源软件镜像站 (TUNA)
• 北京外国语大学开源软件镜像站 (TUNA)
• USTC open source software mirror - 中科大镜像源，含部分反向代理列表
• 上海交通大学镜像站
• 南京大学镜像站
• 阿里巴巴开源镜像站
• 腾讯软件源

一般镜像站中除了镜像本身，还附带了比较整洁的文档或者说明，其中 TUNA 镜像站的文档是笔者认为写得最好的，可以参考其文档并根据自身网络环境选择合适的镜像源。

更详细的镜像站汇总，可以参考:

• Thanks-Mirror
• 校园网镜像站索引
• 国内开源镜像网站汇总 - 知乎

其中各个站点的索引的软件都不太一样，比如  山东女子学院开源软件镜像站 中还可以下载 java 的二进制文件。因此如果在某个镜像站找不到你所需的软件源，可以换几个镜像站找找，说不定能有所收获。

其他:

• 谷歌学术镜像站
• z-library 镜像站

包管理器

我们先从简单的说起。在全新安装好操作系统时，第一步要准备的自然是包管理工具。这类工具有很多，只选几个典型作为记录，即 Debian/Ubuntu Linux 系的 apt-get 以及 macOS 下的 Homebrew。

APT-GET

一般我们配置 apt 镜像的时候会上百度随便搜 “ubuntu 国内源”，然后进入到某个 CSDN 的文章，把里面的源复制一下，粘贴到系统的 /etc/apt/sources.list 中。这样确实能解决问题，不过对于新手而言可能会不小心复制错源，比如将 ubuntu 18.04 (bionic) 的源复制到了自己的 ubuntu 22.04 (jammy) 系统中，导致更新出错。因此更好的方法是直接到上面的开源镜像站中查找对应的源。

扯句题外话，apt 源的格式一般如下:

deb [ option1=value1 option2=value2 ] uri suite [component1] [component2] [...]
deb-src [ option1=value1 option2=value2 ] uri suite [component1] [component2] [...]

其中只有 uri 和 suite 是必填的，其他都是可选的，比如我们经常复制下来的形式是:

deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ jammy main restricted universe multiverse

suite 代表系统的 codename，component 则表示启用的组件，从请求来看，它们一起组合成了完整的 URL 路径 <uri>/dists/<suite>/<component>，例如:

https://mirrors.tuna.tsinghua.edu.cn/ubuntu/dists/jammy/main

那么我们怎么知道应该使用哪些 component 呢？一般来说，

• main 表示发行版官方支持开源软件版；
• restricted 表示官方支持但不是完全 License free 的软件包；
• universe 表示社区维护的软件，但非官方支持；
• multiverse 表示非自由软件，比如 NVIDIA 的驱动；

不过我们无需记住所有的源，只需要把原始 sources.list 中的 URI 替换即可。值得注意的是有的文章中使用 sed 去替换，比如替换成阿里云的源:

sed -ibak "s/archive.ubuntu.com/mirrors.aliyun.com/g" /etc/apt/sources.list

这需要注意 URI 的路径，以及针对安全更新使用的 URI 通常是其他子域名，如: http://security.ubuntu.com/ubuntu/ ，因此更为稳妥的方式还是进行手动替换。

参考:

• sources.list man(5)
• What are Repositories

HomeBrew

如果你用的是 macOS 系统，那么很可能会用到 Homebrew。该包管理工具与 apt 不同，并不是系统自带的，需要手动安装。官网的安装介绍就一句话:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

如果网络不好，很可能会收获一个 curl: (28) SSL connection timeout。此时还是参考 TUNA 中的文档，从镜像源中获取 install.sh 进行安装:

# 从镜像下载安装脚本并安装 Homebrew / Linuxbrew
git clone --depth=1 https://mirrors.tuna.tsinghua.edu.cn/git/homebrew/install.git brew-install
/bin/bash brew-install/install.sh
rm -rf brew-install

对于侥幸网络顺畅已经安装过的朋友，在 brew update/install 时可能也会遇到网络问题，因为 formula/cask 默认是从 github 下载的。此时就需要通过环境变量将其设置为镜像地址:

export HOMEBREW_API_DOMAIN="https://mirrors.tuna.tsinghua.edu.cn/homebrew-bottles/api"
export HOMEBREW_BOTTLE_DOMAIN="https://mirrors.tuna.tsinghua.edu.cn/homebrew-bottles"
export HOMEBREW_BREW_GIT_REMOTE="https://mirrors.tuna.tsinghua.edu.cn/git/homebrew/brew.git"
export HOMEBREW_CORE_GIT_REMOTE="https://mirrors.tuna.tsinghua.edu.cn/git/homebrew/homebrew-core.git"
export HOMEBREW_PIP_INDEX_URL="https://pypi.tuna.tsinghua.edu.cn/simple"

参考:

• MAC 安装 homebrew 国内镜像
• Homebrew / Linuxbrew 镜像使用帮助 - tuna

WinGet

Windows 中也有一些包管理工具，比如 chocolatey 或者 scoop。目前 Windows 官方推出了 WinGet，后续随着软件源的丰富会日渐成为主流。但是不幸 WinGet 的软件包元数据也是存放在 github 上的，因此我们也要寻找镜像。

幸运的是部分国内开源镜像也提供了 winget 的源，比如 USTC Mirrors:

winget source remove winget
winget source add winget https://mirrors.ustc.edu.cn/winget-source

但可惜这只是 manifest 的源，实际的安装包还是走的原始下载地址，很多是对应软件官网提供的。由于软件来源不一，因此很难实现统一的镜像。因此对于原始二进制文件下载不了的情况只能开启系统代理，因为 winget 的代理选项还在开发中，见 issue#190。

参考:

• WinGet 源使用帮助
• How do I install WinGet on Windows Server 2019

Python

准备好包管理器之后我们就可以开始写代码了，首选的自然是简单实用的脚本语言 Python。使用包管理器可以很简单地进行安装，不过如果没有使用包管理器，或者需要的安装最新的 Python 版本没有及时更新到包管理仓库中，那么还是需要手动下载安装的。

下载自然是要到官网下载，不过需要注意的是如果使用某搜索引擎需要仔细辨别哪个是官网，否则不小心安装完发现是个全家桶就得不偿失了。

有时候 Python 的官网 python.org 访问也是会出现网络超时的，此时也可以借助上面说到的镜像源。在 校园网联合镜像站 中可以搜索哪个镜像站支持下载 Python binary 的镜像，发现北京交通大学镜像站有，因此可以在这里加速下载:

• https://mirror.bjtu.edu.cn/python/

安装好 Python 之后还需要安装 pip 并配置好对应的 pypi 源，否则控制台可能会出现一些红红黄黄的错误。

在 TUNA PyPI 镜像使用帮助 中已经比较详细地说明了配置方法，这里简单记录一下:

python3 -m pip install --upgrade pip
python3 -m pip config set global.index-url https://mirrors.aliyun.com/pypi/simple/

这会将镜像源地址写入到 $HOME/.config/pip/pip.conf 文件中，当然自己手动修改该文件也是可以的。很多所谓教程还会额外修改 install.trusted-host，这对于 HTTPS 的源而言已经没必要了。

NodeJS

最为另一个最受欢迎的语言 JavaScript 我们当然也是要支持的，为此就需要先安装 nodejs 环境。不考虑包管理器的话根据官网应该是要到 https://nodejs.org/dist/ 中下载，不过在国内访问仿佛会受到一股无形的阻力:

From: vsping.com

因此，还是再次感谢镜像们救我狗命:

• https://mirrors.cernet.edu.cn/list/nodejs-release
• https://mirrors.bfsu.edu.cn/nodejs-release/
• https://mirror.iscas.ac.cn/nodejs-release/
• https://developer.aliyun.com/mirror/nodejs-release

安装完 nodejs 和 npm 后还需要配置 npm 仓库的镜像源，以加速 npm install 等命令:

# 刷新缓存
npm cache clear --force
# 将配置写入 ~/.npmrc
npm config set registry https://registry.npmmirror.com/

注意镜像的地址是 HTTPS 而不是 HTTP，否则可能会会遇到 npm ERR: Cannot read property ‘insert’ of undefined 之类的错误。

很多情况下需要使用 nvm 管理不同的 nodejs 版本，那么也可以直接在包管理器中先任意安装某个版本的 node 和 npm，然后再安装 nvm 去切换版本:

npm install -g n
n lts
export PATH=$HOME/.n/bin:$PATH
node --version

参考:

• https://npmmirror.com/
• https://mirrors.bfsu.edu.cn/help/nodejs-release/

Golang

Golang 也是一个常用的语言，官网地址: https://go.dev/doc/install

当然，官网速度比较感人，你可以选择国内的镜像站点来安装 go 程序，比如:

• https://golang.google.cn/dl/
• https://mirrors.aliyun.com/golang/

golang 的包管理的加速略有不同，不是使用镜像而是使用 GOPROXY 协议，细节就不考究了，简单来说配置如下:

go env -w GO111MODULE=on
go env -w GOPROXY=https://goproxy.cn,direct

其他模块加速代理的地址包括但不限于:

• https://goproxy.cn/
• https://goproxy.io/
• https://proxy.golang.org

Rust

Rust 是近期用的比较多的静态类型语言，可以作为 C++ 的一个很好补充和替代。 Rust 官网 的安装介绍就一句话:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

如果你直接复制粘贴这条命令来安装，很可能也会碰到一些网络问题。在安装阶段使用的工具其实称为 rustup，因此我们可以去查找 rustup 的镜像，其中字节的 rsproxy.cn 看起来就比较符合我们的需求:

export RUSTUP_DIST_SERVER="https://rsproxy.cn"
export RUSTUP_UPDATE_ROOT="https://rsproxy.cn/rustup"
curl --proto '=https' --tlsv1.2 -sSf https://rsproxy.cn/rustup-init.sh | sh

安装完后使用 cargo 拉取包的时候会请求 crates.io，又会出现网络问题，此时可以修改 cargo registry 地址，即修改文件 ~/.cargo/config:

[source.crates-io]
replace-with = 'rsproxy-sparse'
[source.rsproxy]
registry = "https://rsproxy.cn/crates.io-index"
[source.rsproxy-sparse]
registry = "sparse+https://rsproxy.cn/index/"
[registries.rsproxy]
index = "https://rsproxy.cn/crates.io-index"
[net]
git-fetch-with-cli = true

参考:

• rsproxy.cn: A high speed crates.io mirror

Java

Java 是笔者比较不喜欢的一门语言，但无奈国内各个大厂都喜欢用 Java，作为安服仔就只能默默接受这个现实并接受它。安装部分就不必说了，重点看一下依赖包下载过程中遇到的网络问题。

在介绍具体的项目管理工具之前，我们先了解一下 Java 基本的代理设置。Java 主要通过 system properties 来设置代理，即通过命令行指定 -D 或者在代码中调用 System.setProperty 实现。

而控制代理的系统属性有下面这些。

针对 HTTP 请求的 HTTP 代理:

• http.proxyHost
• http.proxyPort
• http.nonProxyHosts

针对 HTTPS 请求的 HTTP 代理:

• https.proxyHost
• https.proxyPort

socks5 代理:

• socksProxyHost
• socksProxyPort

值得一提的是 Java 会根据请求的协议选择不同的代理，因此如果只设置了 http.ProxyHost，那么就只有纯 HTTP 请求会走代理，HTTPS 请求则会直连。详细的介绍可以参考:

• Oracle: Java Networking and Proxies

Maven

maven 算是 Java 中最常用的项目管理工具了，但相信各位 Java 开发者一开始 mvn clean pacakge 编译别人的项目时都遇到过依赖下载缓慢甚至网络错误的问题。一个直接的方法是使用镜像，即修改 maven 默认配置文件，比如 $HOME/.m2/settings.xml，加入下述节点:

<settings>
  ...
  <mirrors>
    <mirror>
      <id>aliyunmaven</id>
      <name>Aliyun</name>
      <url>https://maven.aliyun.com/repository/public</url>
      <mirrorOf>central,jcenter</mirrorOf>
    </mirror>
  </mirrors>
  ...
</settings>

在阿里云的文档中说还可以在 repositories 加入，但 repository 中更多是添加私有仓库地址；另外阿里云的文档还有个问题是将 mirrorOf 设置为了 * 即代理所有仓库，这会导致某些阿里云没有做镜像的仓库下载失败，因此最好还是按需添加镜像。

参考:

• Using Mirrors for Repositories
• 阿里云: maven 配置指南

Gradle

另外一个常用的 Java 项目管理工具就是 Gradle，比如笔者常用的 Android Studio 就是使用 Gradle 作为 APK 的编译工具。

更准确地说是使用 gradle 的封装脚本 gradlew，其中包含了具体的 gradle 版本，避免不同版本之间的编译脚本兼容性问题。作为国内用户，经常就死在了 gradlew 的第一步，因为其会去下载对应版本的 grandle-bin，比如 https://services.gradle.org/distributions/gradle-8.0-bin.zip 。

解决方法是修改 gradle/wrapper/gradle-wrapper.properties 文件指定 distributionUrl 为国内镜像源的具体地址，例如:

distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
distributionUrl=https\://mirror.nju.edu.cn/gradle/gradle-8.0-bin.zip
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists

其他的 gralde distribution 镜像地址可以参考:

• https://mirror.nju.edu.cn/gradle/
• https://mirror.sjtu.edu.cn/gradle/distributions/

解决完 gradle-bin 的下载问题后，还会遇到与 maven 类似的中央仓库下载网络问题，但是 gradle 没有类似 maven 的 mirror tag，而只有类似的 repositories tag，用指定私有仓库的方式将其指定到国内的 maven 仓库镜像中。

使用 Groovy DSL 的 gradle 配置文件 build.gradle 可以添加以下配置:

allprojects {
    repositories {
		maven { url 'https://maven.aliyun.com/repository/google' }
        maven { url 'https://maven.aliyun.com/repository/public' }
        mavenLocal()
        mavenCentral()
    }
}

使用 Kotlin 的 gradle 配置文件 build.gradle.kts 可以使用下述配置:

repositories {
    maven { setUrl("https://maven.aliyun.com/repository/google/") }
    maven { setUrl("https://maven.aliyun.com/repository/public/") }
    mavenLocal()
    mavenCentral()
}

Gradle 似乎没有全局的配置方案，网上的教程更多是使用 init.gradle 即初始化脚本，在项目的 gradle 脚本任务执行之前替换掉 repo 地址:

allprojects{
  repositories {
    all { ArtifactRepository repo ->
      if(repo instanceof MavenArtifactRepository){
        def url = repo.url.toString()
        if (url.startsWith('https://repo1.maven.org/maven2')) {
          project.logger.lifecycle "remove ${repo.url}"
          remove repo
        }
        if (url.startsWith('https://jcenter.bintray.com/')) {
          project.logger.lifecycle "remove ${repo.url}"
          remove repo
        }
      }
    }
    maven {
      url 'https://maven.aliyun.com/repository/public/'
    }
  }
}

这种方式着实不太优雅，但也能算是一种不修改原始代码工程文件的镜像方案。

值得一提的是，云厂商的 maven 仓库镜像也只有一部分 repository，像 jitpack.io 这类仓库可能镜像中就无法找到，此时只能另觅他法了。

说句题外话，不管是 maven 还是 gradle，其实本质上都是一个 Java 工具，因此我们可以通过给 Java 应用添加属性的方式设置代理。比如 maven/gradle 可以通过 -D 添加属性；gradle 可以通过在 gradle.properties 中添加属性 (需要添加前缀，如: systemProp.https.proxyHost)。其中 gradle.properties 除了放在项目根目录中，还可以全局使用，在 NIX 系统中路径是 $HOME/.gradle/gradle.properties，Windows 中则是 %userprofile%\.gradle\gradle.properties。

参考:

• gradle: Declaring repositories
• gradle: Initialization Scripts

总结

经过这一番折腾，这些开发工具终于能够流畅使用了，总算是和老外站在了同一起跑线上！除了上面用到的这些工具和语言，其实还有其他常用的如 Ruby、PHP(Composer)、Docker 等无一不是需要镜像才能流畅使用，不得不感慨国内开发者们顽强生长的能力。同时也非常感谢维护镜像站的厂商和高校，要是没有它们，可能很多人就只能铤而走险了。

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2024/02/13/china-mirror/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

有经验的程序员都知道源码需要进行编译、链接、封装，然后才能执行。那你知道如何为一块CPU编写并编译程序吗？知道编译后的程序如何写入MCU、并让CPU加载运行的吗？

前言

早先收到阿里云提供的Developer kit开发板，对他们的RTOS进行体验，就是下面这款：

不得不说，使用aos全家桶运行、烧写和调试代码都非常方便；而且最近看发现还支持最小化定制裁剪，根据自己的需求下载对应的代码，算是咱256G小硬盘的福音了：）

不过今天不是分析阿里的RTOS(AliOS Things)，也不是把玩这块开发板，而是借助其中的MCU来探索下裸板的开发和运行之路。

芯片分析

在开始为一块MCU编程之前，我们要做的第一件事就是先查看这个MCU的文档。例如，如果我们想写一个helloworld程序，那么就至少需要知道：

1. MCU复位之后从哪启动，这决定了我们的main程序位置。
2. MCU内存映射，这是为了查看串口的地址空间。

对于我们而言，手上的MCU型号是STM32L496VGTx，因此这些大部分都能在stm32l496ae datasheet中查看到。首先，在datasheet中我们知道STM32L496VGTx中的CPU是ARM Cortex-M4，内存SRAM为320KB，内部含有1MB的Flash。

初始化

根据ARM的文档中关于Cortex-m4 中断向量表的介绍，我们可以看到保存第一条指令地址的地址为0x0004：

其中0x0000保存的是栈的地址。也就是说，CPU复位之后，会首先将0x0000地址的内容加载到栈寄存器sp中，然后将0x0004地址的内容加载并保存到指令寄存器pc中，然后才开始执行第一条指令。

CPU执行每条指令，本质上包含5步：取指、译码、执行、访存、写回。如果不影响状态，多条指令的5步可以交错，这就称为CPU的流水线，现代CPU都包含多级流水线的设计和其他的优化来提升执行速度。……扯远了，说这个主要是强调一点：CPU实际运行的第一条指令的地址为*(addr *)0x0004。而前面两条"指令"，即加载sp和加载pc，实际上是通过CPU硬件的有限状态机实现的。

内存映射

还是在ARM的文档Memory-Model中，可以看到我们的芯片内存映射的结构大致如下：

在32位的寄存器下，有大约4GB的寻址空间。其中ARM只定义了一个大概的范围，地址空间的实际映射其实和厂商的设计有比较大的关系。比如在我们的STM32L4 MCU中，实际的映射如下：

需要注意的是flash地址空间，为0x08000000 ~ 0x08100000，大小为0x10000正好是datasheet中所说的1MB。还有就是APB的地址空间，因为APB总线通常是用来控制外设的，比如我们下面会用到的串口(UART)。

The Code

Talk is cheap，接下来就是实际的编码，我们的目标是在CPU上电启动后马上打印“HelloWorld”，没有其他多余的操作。

程序骨架

在打印HelloWorld之前，我们先确保MCU能够正常启动并运行我们的代码。为此，需要正确编译和链接我们的程序。根据上面ARM初始化向量表的定义，我们先写个汇编文件startup_m4.s：

.syntax unified
.cpu cortex-m4
.fpu softvfp
.thumb

.global g_pfnVectors
.global Default_Handler
.global Reset_Handler

.section .text
Default_Handler:
Infinite_Loop:
    b   Infinite_Loop

Reset_Handler:
    ldr sp, =stack_top
    mov r0, #0
    mov r1, #1
    mov r2, #2
    ror r3, r0, #2
_loop:
    add r3, #1
    B _loop

// ISR vecotor data
.section .isr_vector, "a"
g_pfnVectors:
    .word stack_top
    .word Reset_Handler
    .word Default_Handler // NMI
    .word Default_Handler // HardFault
    .word Default_Handler // MemManage
    .word Default_Handler // BusFault
    .word Default_Handler // UsageFault
    .word 0
    .word 0
    .word 0
    .word 0
	.word Default_Handler // SVC
    // and a lot more ...

Reset_Handler是我们实际运行的第一条指令地址，其地址写在中断向量表的0x04偏移处。对于其他的中断处理程序，我们先简单放一部分到Default_Handler中。

编译和链接

有了代码，还需要链接到对应的地址中，执行这项任务的就是linker脚本。通常我们使用ld时也会调用默认的linker脚本，可以通过ld --verbose命令查看，不过默认的链接脚本无法满足我们的需求，所以根据上面的文档，我们写一个简单的链接脚本m4.ld如下：

ENTRY(Reset_Handler)

MEMORY {
    FLASH (RX) : ORIGIN = 0x08000000, LENGTH = 1024K
    SRAM (RWX) : ORIGIN = 0x20000000, LENGTH = 320K
}

stack_top = 0x20050000;

SECTIONS {
    .isr_vector : {
        . = ALIGN(8);
        KEEP(*(.isr_vector))
        . = ALIGN(8);
    } > FLASH

    .text : {
        . = ALIGN(8);
        *(.text)
        . = ALIGN(8);
        text_end = .;
    } > FLASH

    .data : { *(.data) } >SRAM AT>FLASH
    .bss : { *(.bss COMMON) } > SRAM
    . = ALIGN(8);
}

编译并链接我们的程序：

arm-none-eabi-as startup_m4.s -g -o startup_m4.o
arm-none-eabi-ld -T m4.ld startup_m4.o -o startup.elf

最后生成的是ELF程序，为了在裸板上运行，需要将无用的信息去掉，只保留纯粹的代码和数据：

arm-none-eabi-objcopy -O binary startup.elf startup.bin

如果想要了解更多链接脚本的语法和含义，可以参考官方的文档——Linker Scripts。

烧写和调试

有了starup.bin之后，就可以使用对应的接口写入Flash，对于我们这块开发板引出的接口是ST-LINK，所以可以直接使用stlink程序来写，前面说了Flash地址为0x08000000：

st-flash --reset write startup.bin 0x08000000

当然，你也可以使用其他工具，比如我最喜欢的OpenOCD。使用openocd需要自己对接口进行适配，其中包含了很多预置的配置，例如对于我们手上的开发板，可以使用以下配置：

source [find interface/stlink.cfg]

transport select hla_swd

source [find target/stm32l4x.cfg]

reset_config srst_only

值得一提的是，openocd的配置使用的是裁剪过的TCL语言，使用前可以花一两个小时先了解下。

OpenOCD中内置了gdbserver，不过如果你用openOCD+gef进行调试的话，很可能会遇到错误。经过查看代码和相关的资料，我发现openocd的gdbserver会将程序状态字寄存器命名为xPSR而不是传统的cpsr，所以我写了个gdb脚本解决这个问题：

set remote hardware-breakpoint-limit 6
set remote hardware-watchpoint-limit 4

# openOCD-gdbserver name $cpsr as $xPSR, make gef known about it
pi current_arch.all_registers = ['$r0', '$r1', '$r2', '$r3', '$r4', '$r5', '$r6', '$r7', '$r8', '$r9', '$r10', '$r11', '$r12', '$sp', '$lr', '$pc', '$xPSR']
pi current_arch.flag_register = '$xPSR'
reset-cache

# ignore stack
gef config context.layout "legend regs code args source memory threads trace extra"

target extend :3333

烧写成功后复位使用JTAG接口进行调试，可以看到进入了我们的程序中：

PS：由于我们的大部分中断都没有处理，所以单步调试触发中断后程序很可能跑飞：）

固件逆向

说句题外话，生成的starup.bin就是我们常说的固件，实际上在逆向分析时从flash读出来的数据也就是这个格式，从0x00地址开始。比如，分析这个固件的时候通常使用的方法是：

r2 -n -a arm -b 16 -m 0x08000000 startup.bin

其他工具也可以用类似的方法将首地址rebase进行分析，但关键是要知道对应芯片的中断向量表定义，这样才能找到真正的入口函数。

HelloWorld

现在有了骨架，可以实现真正的功能了。在操作系统中，我们printf("hello world")本质上是经过系统调用让内核把数据写到标准输出，但是在裸板上可没那么方便，一切都要自己操作。

打印数据到串口的功能通过UART实现，而UART是连接在CPU的APB总线上的。在软件上向UART发送数据实际上是通过向APB总线发送数据到UART硬件对应的接口，发送数据的操作通过将APB总线的读写映射为MMIO实现，简单来说就是通过CPU向内存读写数据实现总线上的读写操作。

在前面的图片中我们能看到APB总线的MMIO映射地址为0x40000000，那么UART在哪个地址呢？可以通过STM32的应用文档中查看；或者更简单地，直接查看STM32的驱动文件stm32l496xx.h：

#define PERIPH_BASE           (0x40000000UL) /*!< Peripheral base address */
...
/*!< Peripheral memory map */
#define APB1PERIPH_BASE        PERIPH_BASE
#define APB2PERIPH_BASE       (PERIPH_BASE + 0x00010000UL)
...
/*!< APB1 peripherals */
#define USART2_BASE           (APB1PERIPH_BASE + 0x4400UL)
#define USART3_BASE           (APB1PERIPH_BASE + 0x4800UL)
#define LPUART1_BASE          (APB1PERIPH_BASE + 0x8000U)
..
/*!< APB2 peripherals */
#define USART1_BASE           (APB2PERIPH_BASE + 0x3800UL)
  
#define USART2              ((USART_TypeDef *) USART2_BASE)
#define USART3              ((USART_TypeDef *) USART3_BASE)
#define UART4               ((USART_TypeDef *) UART4_BASE)
#define UART5               ((USART_TypeDef *) UART5_BASE)
#define LPUART1             ((USART_TypeDef *) LPUART1_BASE)
#define USART1              ((USART_TypeDef *) USART1_BASE)

在stm32l496xx中，APB总线连接了6个串口，起始地址分别是：

• USART1, 0x40013800
• USART2, 0x40004400
• USART3, 0x40004800
• ….

UART地址空间的定义是：

/**
  * @brief Universal Synchronous Asynchronous Receiver Transmitter
  */

typedef struct
{
  __IO uint32_t CR1;         /*!< USART Control register 1,                 Address offset: 0x00 */
  __IO uint32_t CR2;         /*!< USART Control register 2,                 Address offset: 0x04 */
  __IO uint32_t CR3;         /*!< USART Control register 3,                 Address offset: 0x08 */
  __IO uint32_t BRR;         /*!< USART Baud rate register,                 Address offset: 0x0C */
  __IO uint16_t GTPR;        /*!< USART Guard time and prescaler register,  Address offset: 0x10 */
  uint16_t  RESERVED2;       /*!< Reserved, 0x12                                                 */
  __IO uint32_t RTOR;        /*!< USART Receiver Time Out register,         Address offset: 0x14 */
  __IO uint16_t RQR;         /*!< USART Request register,                   Address offset: 0x18 */
  uint16_t  RESERVED3;       /*!< Reserved, 0x1A                                                 */
  __IO uint32_t ISR;         /*!< USART Interrupt and status register,      Address offset: 0x1C */
  __IO uint32_t ICR;         /*!< USART Interrupt flag Clear register,      Address offset: 0x20 */
  __IO uint16_t RDR;         /*!< USART Receive Data register,              Address offset: 0x24 */
  uint16_t  RESERVED4;       /*!< Reserved, 0x26                                                 */
  __IO uint16_t TDR;         /*!< USART Transmit Data register,             Address offset: 0x28 */
  uint16_t  RESERVED5;       /*!< Reserved, 0x2A                                                 */
} USART_TypeDef;

对应硬件接口：

软件中对UART的读写主要通过对UART本身的寄存器操作实现，例如向串口写一个字节就是：USART->TDR = 0x41，具体的写入内容根据型号有所差异，在STM32F4XX的驱动中相关代码如下：

  /**
    * @brief  Transmits single data through the USARTx peripheral.
    * @param  USARTx: where x can be 1, 2, 3, 4, 5, 6, 7 or 8 to select the USART or
    *         UART peripheral.
    * @param  Data: the data to transmit.
    * @retval None
    */
  void USART_SendData(USART_TypeDef* USARTx, uint16_t Data)
  {
    /* Check the parameters */
    assert_param(IS_USART_ALL_PERIPH(USARTx));
    assert_param(IS_USART_DATA(Data));

    /* Transmit Data */
    USARTx->DR = (Data & (uint16_t)0x01FF);
  }

对于我们STM32L4XX的MCU，在官方的cube中代码实现为stm32l4xx_cube/Drivers/STM32L4xx_HAL_Driver/Src/stm32l4xx_hal_uart.c的HAL_UART_Transmit函数，虽然相对复杂，但本质上也大同小异。

实际上在MCU中printf和puts等函数的实现都是通过逐字节写入UART寄存器实现的。所以我们新建一个c文件并定义最简单的print函数如下：

// hello_m4.c
volatile unsigned int * const UART_TDR = (unsigned int *)0x40008028; // LPUART1->TDR
void my_print(const char *data) {
    while(*data != '\0') {
        *UART_TDR = (unsigned int)(*data);
        data++;
    }
}

void my_entry() {
    my_print("hello world!\n");
    for(;;);
}

然后在之前的Reset_Handler稍加修改，令其跳转到我们的主程序执行：

Reset_Handler:
    ldr sp, =stack_top
    bl my_entry

最后编译并重新链接：

arm-none-eabi-gcc -c -O0 -mcpu=cortex-m4 -g hello_m4.c -o hello_m4.o
arm-none-eabi-ld -T m4.ld hello_m4.o startup_m4.o -o hello_m4.elf

监听串口的数据并重新烧写，一个硬核的HelloWorld就完成了！

$ miniterm /dev/ttyACM0 115200
--- Miniterm on /dev/ttyACM0  115200,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
hello world!

如果串口是USART而不是UART，那么可能需要经过一些额外的配置，具体可以参考USART vs UART: Know the difference。

在实际工程中，真正进入用户程序之前需要初始化好各个硬件外设，配置好基本的中断处理程序。这部分代码一般是由MCU vendor提供的，作为Bootloader(Boot ROM)固化。当然我们这里是绕过MCU直接针对CPU编写程序，以展示软硬件之间的微妙联系。

后记

本文主要介绍了CPU上电从硬件到软件的启动过程，其中一个关键概念就是中断向量表，这是所有First Stage Bootloader都需要理解和实现的地方。此外还介绍了如何通过控制串口在裸机上实现了一简单的HelloWorld应用，这实际上是一个简化的外设驱动，即通过总线读写外设寄存器来封装外部硬件的调用，这部分代码在内核中也是相当常见的。

参考资料

• ARM datasheet
• STM32L4XX datasheet
• GNU linker script
• OpenOCD – Open On Chip Debugger
• bare metal program for ARM926ej
• NOMMU Linux

Xcode

iOS的应用必须要用Xcode来创建，步骤很简单：

1. 下载并打开Xcode
2. 选择ios -> Single View Application
3. 填写项目名、开发组、包名（Identifier）

项目创建成功后，目录结构如下：

$ tree HelloWorld/
HelloWorld/
├── HelloWorld
│   ├── AppDelegate.h
│   ├── AppDelegate.m
│   ├── Assets.xcassets
│   │   ├── AppIcon.appiconset
│   │   │   └── Contents.json
│   │   └── Contents.json
│   ├── Base.lproj
│   │   ├── LaunchScreen.storyboard
│   │   └── Main.storyboard
│   ├── Info.plist
│   ├── ViewController.h
│   ├── ViewController.m
│   └── main.m
└── HelloWorld.xcodeproj
    ├── project.pbxproj
    ├── project.xcworkspace
    │   ├── contents.xcworkspacedata
    │   ├── xcshareddata
    │   │   └── IDEWorkspaceChecks.plist
    │   └── xcuserdata
    │       └── pan.xcuserdatad
    │           └── UserInterfaceState.xcuserstate
    └── xcuserdata
        └── pan.xcuserdatad
            ├── xcdebugger
            │   └── Breakpoints_v2.xcbkptlist
            └── xcschemes
                └── xcschememanagement.plist

可以看到项目下有两个文夹，分别是源代码文件HelloWorld，以及工程文件HelloWorld.xcodeproj。 作为示例，我们可以修改ViewController.m文件，如下：

#import "ViewController.h"

@interface ViewController ()

@end

@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    // Do any additional setup after loading the view, typically from a nib.
    
    // 创建控件
    UILabel* label = [[UILabel alloc]init];
    label.text = @"Hello World";
    // 自适应大小
    [label sizeToFit];
    // 居中
    label.center = self.view.center;
    // 添加控件
    [self.view addSubview :label];
}


@end

这样，一个Hello World小程序就完成了，左上角运行按钮，即可编译并在模拟器中运行，如下：

在源代码框下方Products区域也能看到编译出的HelloWorld.app。 是不是很简单？好我们今天的文章就这样结束了，… 才怪！

命令行编译

为了更好地了解编译过程，我们可以脱离Xcode IDE，在命令行编译该项目：

首先，在项目目录中查看Schemes：

$ xcodebuild -list -project HelloWorld.xcodeproj
Information about project "HelloWorld":
    Targets:
        HelloWorld

    Build Configurations:
        Debug
        Release

    If no build configuration is specified and -scheme is not passed then "Release" is used.

    Schemes:
        HelloWorld

然后，选择一个scheme进行编译，这里是HelloWorld：

$ xcodebuild -scheme HelloWorld build
note: Using new build system
note: Planning build
note: Using build description from disk
Build system information
error: Signing for "HelloWorld" requires a development team. Select a development team in the project editor. (in target 'HelloWorld')

** BUILD FAILED **

凹，编译失败了，签名出错，因为万恶的资本主义坏苹果要求必须要每年99$或者299$去购买 Apple Developer Program 会员资格才能对应用进行合法签名，从而发布并运行我们创建的app。

但是这里写的这个简单APP只需要在我自己的手机上运行，所以并不需要这一步，禁用签名进行编译即可：

$ xcodebuild -scheme HelloWorld build CODE_SIGN_IDENTITY="" CODE_SIGNING_REQUIRED=NO
Build settings from command line:
    CODE_SIGN_IDENTITY =
    CODE_SIGNING_REQUIRED = NO

note: Using new build system
note: Planning build
note: Constructing build description
Build system information
warning: HelloWorld isn't code signed but requires entitlements. It is not possible to add entitlements to a binary without signing it. (in target 'HelloWorld')
...
Validate /Users/pan/Library/Developer/Xcode/DerivedData/HelloWorld-dnyjqrgxcjjobvfzytzhtzpmjlmx/Build/Products/Debug-iphoneos/HelloWorld.app (in target: HelloWorld)
...
Touch /Users/pan/Library/Developer/Xcode/DerivedData/HelloWorld-dnyjqrgxcjjobvfzytzhtzpmjlmx/Build/Products/Debug-iphoneos/HelloWorld.app (in target: HelloWorld)
...
** BUILD SUCCEEDED **

编译成功了！中间省略了很多输出信息，这里就不贴了。值得一提的是，生成的app并不是在当前项目目录下， 而是在$HOME/Library/Developer/Xcode/DerivedData/$PROJECT-xxxx/{...}/HelloWorld.app中， xxxx看起来是一段随机数。HelloWorld.app就是一个传统的苹果应用，其目录结构如下：

$ tree HelloWorld.app
HelloWorld.app
├── Base.lproj
│   ├── LaunchScreen.storyboardc
│   │   ├── 01J-lp-oVM-view-Ze5-6b-2t3.nib
│   │   ├── Info.plist
│   │   └── UIViewController-01J-lp-oVM.nib
│   └── Main.storyboardc
│       ├── BYZ-38-t0r-view-8bC-Xf-vdC.nib
│       ├── Info.plist
│       └── UIViewController-BYZ-38-t0r.nib
├── HelloWorld
├── Info.plist
└── PkgInfo

其中HelloWorld就是ARM64的Mach-O文件：

$ file HelloWorld.app/HelloWorld
HelloWorld.app/HelloWorld: Mach-O 64-bit executable arm64

模拟器

iOS模拟器除了可以在Xcode启动，也可以通过命令行进行管理，如：

xcrun simctl help

查看具体帮助：

$ xcrun simctl help install
Install an app on a device.
Usage: simctl install <device> <path>

例如，我们要想在模拟器中启动上节编译好的HelloWorld.app，可以用以下命令：

# 查看当前设备列表，选择一个设备UDID
xcrun simctl list devices
# 打开并启动设备
open -a Simulator --args -CurrentDeviceUDID $UDID
# 在启动的设备中安装我们的应用，注意需要app支持x86架构
xcrun simctl install booted /path/to/HelloWorld.app

关于simctl的更多使用示例可以参考这篇文章。

签名与ipa

上节说到我们可以不签名来编译APP，但对于真机而言，要想运行应用，签名是必须的。 在Xcode7以后，开发者可以只用自己的Apple ID来在自己的设备上运行iOS应用，设置如下：

这样就可以通过USB在物理机上运行iOS应用了，不过要注意的是第一次启动时会提示不可信的开发者， 需要到设置-通用中进行信任。

什么是ipa

iOS应用与Android应用类似的一点是，最后安装到系统中的都是一个zip压缩包，对于Android而言后缀是apk， 而对于iOS而言则是ipa（iPhone Application Archive）。通常ipa会通过苹果加密（使用FairPlay DRM技术）。 所以一般我们想从手机上已经安装的应用还原出ipa需要先解密，也通常称为砸壳。

常见的解密方法有如下几种：

• Clutch- Fast iOS executable dumper
• dumpdecrypted - Dumps decrypted mach-o files from encrypted iPhone applications from memory to disk
• frida-ios-dump

当然这些都是需要越狱的，在非越狱的机器上可以通过iMazing提取，热门应用可以直接在第三方应用商店下载， 比如AppCake。

ipa打包

对于有源码的应用，我们可以使用Xcode进行打包，打包流程可以参考stackoverflow中的一个回答。 不过这需要有开发者账号。由于我们是自己使用，因此要找一种无需开发者账号的方法。

无需开发者账号的打包方式有很多，比如：

• How to create ipa in xcode 6 without Apple Developer account?
• Export an IPA From Xcode Without an Apple Developer Account

这里使用命令行方式进行打包（archive&export）：

# archive
xcodebuild archive -project HelloWorld/HelloWorld.xcodeproj -scheme HelloWorld -configuration Debug  -archivePath ./build/HelloWorld

# export
xcodebuild -exportArchive -archivePath ./build/HelloWorld.xcarchive -exportOptionsPlist exportOptions.plist -exportPath ./build

这样就在./build目录下生成HelloWorld.ipa包了。其中exportOptions.plist如下：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>method</key>
    <string>development</string>
</dict>
</plist>

详细exportOptions的key/value值可以通过xcodebuild -help查看。

ipa安装

无需AppStore的ipa的安装方法有下面几种（欢迎补充）：

• 使用Apple Configurator 2 工具（只支持MacOS）
• 使用Xcode安装
• 使用OTA部署方式安装
• 其他

使用Apple Configurator 2

Apple Configurator 2是苹果公司提供的一个部署和配置工具，可以直接从AppStore下载。 USB连接苹果手机后打开工具，图形界面操作，依次选择：

Add -> Apps -> Choose from my Mac

然后点击生成的ipa文件即可。不是很推荐这个工具，如果一定要用图形界面，还不如用下面的Xcode。

使用Xcode

同样是图形界面操作，USB连接手机后依次选择：

Window -> Devices and Simulators -> Devices

选择自己的手机后，点击+添加或者直接把ipa文件拖拽进来即可。

OTA部署

OTA部署支持使用HTTPS的方式部署和分发你的ipa包，一个示例OTA链接地址如下：

itms-services://?action=download-manifest&url=https://example.com/ota.plist

itms-services是苹果上的自定义协议，会根据action下载并处理目标plist文件， ota.plist内容如下：

<plist version="1.0">
  <dict>
    <key>items</key>
    <array>
      <dict>
        <key>assets</key>
        <array>
          <dict>
            <key>kind</key>
            <string>software-package</string>
            <key>url</key>
            <string>
              https://example.com/app.ipa
            </string>
          </dict>
        </array>
        <key>metadata</key>
        <dict>
          <key>bundle-identifier</key>
          <string>com.evilpan.helloworld</string>
          <key>bundle-version</key>
          <string>1</string>
          <key>kind</key>
          <string>software</string>
          <key>title</key>
          <string>一个有趣的APP</string>
        </dict>
      </dict>
    </array>
  </dict>
</plist>

解析后会从https://example.com/app.ipa下载应用，用户点击确定即可安装。 这里注意不论是ota.plist还是app.ipa的地址都是强制要求为HTTPS的， 因此若想以这种形式安装，还必须要去注册一个合法的SSL证书，也可以用免费的。

由于AppStore审核很严格，很多私人用的或者不合规的iOS软件都是通过OTA部署的形式分发的， 并且在会在安装说明中指引用户去设置->通用->描述文件与设备管理中手动点击信任该个人/企业开发者。

其他

除了上述方式，还有一些开源脚本可以帮助我们安装部署自己的应用，如ios-deploy， 只要连接USB输入以下命令即可安装：

$ ios-deploy -b HelloWorld.ipa
[....] Waiting for iOS device to be connected
------ Install phase ------
...
[ 65%] InstallingEmbeddedProfile
[ 70%] VerifyingApplication
[ 75%] CreatingContainer
[ 80%] InstallingApplication
[ 85%] PostflightingApplication
[ 90%] SandboxingApplication
[ 95%] GeneratingApplicationMap
[100%] Installed package HelloWorld.ipa

有点类似于Android的adb install，相当方便。个人建议直接使用源码编译而不是npm安装。

后记

本文从开发者的角度，介绍了iOS应用创建、编译、打包、测试、部署等方面， 从零开始构建并运行我们的第一个iOS程序。 既介绍了模拟器的安装测试方式， 也介绍了物理机上的打包和部署过程。其中很多地方尽可能的使用命令行去运行， 这有利于后续自动化的操作，也有利于我们理解各个选项所使用到的参数作用。

为了降低工作量，我们特地在没有越狱以及没有开发者账号的情况下完成上述操作。 下一篇，我们将尝试从攻击者的角度，实际“破解”一个iOS应用，Stay Tuned！

参考链接

• iOS builds / ipa creation from the command line
• Setting up Frida Without Jailbreak on devices running iOS 12.1.4
• AppCake - Third party ipa download
• dumpdecrypted - Dumps decrypted mach-o files from encrypted iPhone applications from memory to disk
• Clutch- Fast iOS executable dumper
• frida-ios-dump
• insert_dylib
• Non-market App Distribution - Monaca Docs

什么是Objective-C

Objective-C，简称OC，是一种通用、高级、面向对象的编程语言。它扩展了标准的ANSI C编程语言， 将Smalltalk式的消息传递机制加入到ANSI C中。当前主要支持的编译器有GCC和Clang（采用LLVM作为后端）。 Objective-C的商标权属于苹果公司，苹果公司也是这个编程语言的主要开发者。 苹果在开发NeXTSTEP操作系统时使用了Objective-C，之后被OS X和iOS继承下来。 现在Objective-C与Swift是OS X和iOS操作系统、及与其相关的API、Cocoa和Cocoa Touch的主要编程语言。

Objective-C是C语言的严格超集。这意味着任何C语言程序不经修改就可以直接通过Objective-C编译器， 在Objective-C中使用C语言代码也是完全合法的。Objective-C被描述为盖在C语言上的薄薄一层， 因为Objective-C的原意就是在C语言主体上加入面向对象的特性。OC项目中常用的拓展名如下：

Hello, World!

学习任何一门语言之前，基本都需要做的就是编写并运行一个HelloWorld程序，对于OC而言则是如下：

#import <Foundation/Foundation.h>

int main (int argc, const char * argv[])
{
    @autoreleasepool {
        NSLog (@"Hello, World!");
    }
    return 0;
}

使用clang进行编译：

clang -framework Foundation hello.m -o hello

运行：

$ ./hello
2019-04-05 09:33:22.579 hello[75742:3312942] Hello, World!

So easy！我们学习Objective-C时记住要重点关注概念而不是具体的语言细节，避免陷入学而无用的境地。

关键概念

消息传递

Objective-C最大的特色是承自Smalltalk的消息传递模型（message passing）， 此机制与今日C++式之主流风格差异甚大。 Objective-C里，与其说对象互相调用方法， 不如说对象之间互相传递消息更为精确。此二种风格的主要差异在于调用方法/消息传递这个动作。 C++里类别与方法的关系严格清楚，一个方法必定属于一个类别，而且在编译时（compile time） 就已经紧密绑定，不可能调用一个不存在类别里的方法。但在Objective-C，类别与消息的关系比较松散， 调用方法视为对对象发送消息，所有方法都被视为对消息的回应。所有消息处理直到运行时（runtime） 才会动态决定，并交由类别自行决定如何处理收到的消息。也就是说，一个类别不保证一定会回应收到的消息， 如果类别收到了一个无法处理的消息，程序只会抛出异常，不会出错或崩溃。

C++里，送一个消息给对象（或者说调用一个方法）的语法如下：

obj.method(argument);

Objective-C则写成：

[obj method: argument];

此二种风格各有优劣。C++强制要求所有的方法都必须有对应的动作，且编译期绑定使得函数调用非常快速。 缺点是仅能借由virtual关键字提供有限的动态绑定能力。Objective-C天生即具备鸭子类型之动态绑定能力， 因为运行期才处理消息，允许发送未知消息给对象。可以送消息给整个对象集合而不需要一一检查每个对象的类型， 也具备消息转送机制。同时空对象nil接受消息后默认为不做事，所以送消息给nil也不用担心程序崩溃。

举例来说，定义下面的程序：

@interface MyClass: NSObject
// instance method
- (int) add: (int) num1 secondNumber:(int) num2;
// static method
+ (int) mul: (int) num1 secondNumber:(int) num2;
@end

@implementation MyClass
- (int) add: (int) num1 secondNumber:(int) num2 {
    return num1 + num2;
}
+ (int) mul: (int) num1 secondNumber:(int) num2 {
    return num1 * num2;
}
@end

其中add方法是实例函数，mul是类函数，调用过程如下：

int main() {

    int a = 3, b = 4;
    MyClass *myClass = [[MyClass alloc]init];
    int c = [myClass add:a secondNumber:b];
    int d = [MyClass mul:a secondNumber:b];
}

编译后在调试器中查看汇编可以看到，add方法的汇编是：

    0x100000ea2: mov    rsi, qword ptr [rbp - 0x18]
    0x100000ea6: mov    edx, dword ptr [rbp - 0x8]
    0x100000ea9: mov    ecx, dword ptr [rbp - 0xc]
    0x100000eac: mov    rdi, qword ptr [rip + 0x122d] ; "add:secondNumber:"
    0x100000eb3: mov    qword ptr [rbp - 0x28], rdi
    0x100000eb7: mov    rdi, rsi
    0x100000eba: mov    rsi, qword ptr [rbp - 0x28]
    0x100000ebe: call   qword ptr [rip + 0x13c]   ; (void *)0x00007fff6344e000: objc_msgSend

其实就是转换为：

objc_msgSend(myClass, "add:secondNumber:", 3, 4)

所有的Objective-C方法调用都通过objc_msgSend进行调用，且实例和方法名称分别为前两个参数。 这也是为什么OC方法调用称之为消息传递的原因。

字符串

作为C语言的超集，Objective-C 支持 C 语言字符串方面的约定。也就是说，单个字符被单引号包括， 字符串被双引号包括。然而，大多数Objective-C通常不使用C语言风格的字符串。 反之，大多数框架把字符串传递给NSString对象。NSString类提供了字符串的类包装， 包含了所有你期望的优点，包括对保存任意长度字符串的内建内存管理机制，支持Unicode，printf风格的格式化工具， 等等。因为这种字符串使用的非常频繁，Objective-C提供了一个助记符@可以方便地从常量值创建NSString对象。 如下面的例子所示：

// 从一个C语言字符串创建Objective-C字符串
NSString*  fromCString = [NSString stringWithCString:"A C string" 
encoding:NSASCIIStringEncoding];
// 使用助记符@
NSString* name = @"PANN";
NSString* line = [NSString stringWithFormat:@"Hello, %s\n", @"String"];

类(class)

类是面向对象语言中最重要的一个概念，Objective-C同样支持类。下图是一个名为MyClass的类声明介绍：

声明

遵循C语言的规范，类声明一般定义在.h头文件中。类声明以关键字@interface作为开始，@end作为结束。 其中类方法前的+号表示类方法，-号表示实例方法。一个对应的C++类定义如下：

public MyClass : NSObject {
  protected:
  int count;
  id data;
  NSString *name;
  public:
  id intWithString(NSString *aName);
  static MyClass *createMyClassWithString(NSString *aName);
};

实现

遵循C语言的规范，类实现一般定义在对应的.m文件中。类实现包含了公开方法的实现， 以及定义私有（private） 变量及方法。 以关键字@implementation作为区块起头，@end结尾。 上述类的一个实现如下：

@implementation MyClass {
  NSString *secret;
  -(id) initWithString: (NSString*)aName {
    self.name = aName;
    return 0;
  }
  +(MyClass)createMyClassWithString:(NSString*)aName {
    MyClass * my = [[MyClass alloc] init];
    my.name = aName;
    return my;
  }
}

头文件（类声明）中定义的属性默认为protected，方法为public。而类实现中定义的属性为private。 当然也可以使用@public、@private等助记符来覆盖默认行为。

实例化

实例化即创建对象。Objective-C创建对象需通过alloc以及init两个消息。alloc的作用是分配内存， init则是初始化对象。 init与alloc都是定义在NSObject里的方法，父对象收到这两个信息并做出正确回应后， 新对象才创建完毕。如上述类中：

MyClass * my = [[MyClass alloc] init];

在Objective-C 2.0里，若创建对象不需要参数，则可直接使用new：

MyClass * my = [MyClass new];

仅仅是语法上的精简，效果完全相同。

若要自己定义初始化的过程，可以重写init方法，来添加额外的工作。（用途类似C++ 的构造函数constructor）， 如下：

- (id) init {
    if ( self=[super init] ) {   // 必须调用父类的init
        // do something here ...
    }
    return self;
}

方法(method)

在上节介绍类的时候已经见过了一些方法的定义和使用，第一次接触Objective-C的人肯定会觉得很奇怪（比如我就觉得这语法比Golang还奇葩）， 但是只要接收了这种设定，还是可以慢慢习惯的。

声明

下图为Objective-C内置数组类型的insertObject方法声明：

方法实际的名字(insertObject:atIndex:)是所有方法标识关键的级联，包含了冒号。冒号表明了参数的出现。 如果方法没有参数，你可以省略第一个(也是唯一的)方法标识关键字后面的冒号。本例中，这个方法有两个参数。 该函数转换成类似的C++表示如下：

void insertObject:atIndex:(id anObject, NSUInteger index);

调用

调用一个方法实际上就是传递消息到对应的对象。这里消息就是方法标识符以及传递给方法的参数信息。 发送给对象的所有消息都会动态分发，这样有利于实现Objective-C类的多态行为。 也就是说，如果子类定义了跟父类的具有相同标识符的方法，那么子类首先收到消息， 然后可以有选择的把消息转发（也可以不转发）给他的父类。

消息被中括号( [ 和 ] )包括。括号中接收消息的对象在左边，消息及其参数在右边。 例如，给myArray变量传递消息insertObject:atIndex:消息，可以使用如下的语法：

[myArray insertObject:anObj atIndex:0];

消息允许嵌套。也就是说，假如你有一个myAppObject对象，该对象有getArray方法获取数组， 有getObjectToInsert方法获取元素，那么嵌套的消息可以写成：

[[myAppObject getArray] insertObject:[myAppObject getObjectToInsert] atIndex:0];

属性(attribute)

属性没什么好说的，和C++的类属性类似。不过在Objective-C 2.0引入了新的语法以声明变量为属性， 并包含一可选定义以配置访问方法的生成。属性总是为公共的，其目的为提供外部类访问（也可能为只读） 类的内部变量的方法。属性可以被声明为“readonly”，即只读的，也可以提供储存方法包括“assign”， “copy”或“retain”（简单的赋值、复制或增加1引用计数）。默认的属性是原子的， 即在访问时会加锁以避免多线程同时访问同一对象，也可以将属性声明为“nonatomic”（非原子的）， 避免产生锁。

定义属性的例子如下：

@interface Person : NSObject {
    @public
        NSString *name;
    @private
        int age;
}

@property(copy) NSString *name;
@property(readonly) int age;

-(id)initWithAge:(int)age;
@end

synthesize

属性的访问方法由@synthesize关键字来实现，它由属性的声明自动的产生一对访问方法。 另外，也可以选择使用@dynamic关键字表明访问方法为手动提供。

@implementation Person
@synthesize name;
@dynamic age;

-(id)initWithAge:(int)initAge
{
    age = initAge; // 注意：直接赋给成员变量，而非属性
    return self;
}

-(int)age
{
    return 18; // 注意：并非返回真正的年龄
}
@end

访问

属性可以利用传统的消息表达式、点表达式或"valueForKey:"/“setValue:forKey:“方法对来访问。如下：

Person *aPerson = [[Person alloc] initWithAge: 53];
// 修改属性
aPerson.name = @"Steve";
[aPerson setName: @"Steve"];
// 读取属性
NSString *tmp;
tmp = [aPerson name]; // 消息表达式
tmp = aPerson.name;	  // 点表达式
tmp = aPerson->name;  // 直接访问成员变量
tmp = [aPerson valueForKey:@"name"]; // property访问

协议(Protocol)

协议是一组没有实现的方法列表，任何的类均可采纳协议并具体实现这组方法。简而言之就是接口， 可以类比Java的interface，或者C++的纯虚函数，表述一种is-a的概念。

协议以关键字@protocol作为区块起始，@end结束，中间为方法列表。如下：

@protocol Mutex
- (void)lock;
- (void)unlock;
@end

若要声明实现该协议，可以使用尖括号<>，如下：

@interface SomeClass : SomeSuperClass <Mutex>
@end

一旦SomeClass表明他采纳了Mutex协议，SomeClass就有义务实现Mutex协议中的两个方法：

@implementation SomeClass
- (void)lock {
  // 实现lock方法
}
- (void)unlock {
  // 实现unlock方法
}
@end

动态类型

类似于Smalltalk，Objective-C具备动态类型：即消息可以发送给任何对象实体，无论该对象实体的公开接口中有没有对应的方法。 虽然Objective-C具备动态类型的能力， 但编译期的静态类型检查依旧可以应用到变量上。 以下三种声明在运行时效力是完全相同的， 但是三种声明提供了一个比一个更明显的类型信息， 附加的类型信息让编译器在编译时可以检查变量类型，并对类型不符的变量提出警告。

下面三个方法，差异仅在于参数的形态：

- setMyValue1:(id) foo;
- setMyValue2:(id <aProtocol>) foo;
- setMyValue3:(NSNumber*) foo;

Objective-C中的id类型类似于void指针，但是被严格限制只能使用在对象上。

消息转发

一个对象收到消息之后，他有三种处理消息的可能手段，第一是回应该消息并运行方法，若无法回应， 则可以转发消息给其他对象，若以上两者均无，就要处理无法回应而抛出的例外。只要进行三者之其一， 该消息就算完成任务而被丢弃。若对"nil”（空对象指针）发送消息，该消息通常会被忽略， 只不过对于某些编译器选项可能会抛出异常。

Objective-C运行时在Object中定义了一对方法：

转发方法：

- (retval_t) forward:(SEL) sel :(arglist_t) args; // with GCC
- (id) forward:(SEL) sel :(marg_list) args; // with NeXT/Apple systems

响应方法：

- (retval_t) performv:(SEL) sel :(arglist_t) args;  // with GCC
- (id) performv:(SEL) sel :(marg_list) args; // with NeXT/Apple systems

GCC和NeXT/Apple编译器的区别是返回值和参数类型不同。

希望实现转发的对象只需用新的方法覆盖以上方法来定义其转发行为而无需重写响应方法performv::， 因为后者只是单纯的对响应对象发送消息并传递参数。其中，SEL类型是Objective-C中消息的类型。

类别(Category)

Objective-C借用并扩展了Smalltalk实现中的"分类"概念，用以帮助达到分解代码的目的。

一个分类可以将方法的实现分解进一系列分离的文件。程序员可以将一组相关的方法放进一个分类， 使程序更具可读性。举例来讲，可以在字符串类中增加一个名为"拼写检查"的分类， 并将拼写检查的相关代码放进这个分类中。

分类中的方法是在运行时被加入类中的，这一特性允许程序员向现存的类中增加方法， 而无需持有原有的代码， 或是重新编译原有的类。 例如若系统提供的字符串类的实现中不包含拼写检查的功能，可以增加这样的功能而无需更改原有的字符串类的代码。

在运行时，分类中的方法与类原有的方法并无区别，其代码可以访问包括私有类成员变量在内的所有成员变量。 若分类声明了与类中原有方法同名的函数，则分类中的方法会被调用。因此分类不仅可以增加类的方法， 也可以代替原有的方法。这个特性可以用于修正原有代码中的错误，更可以从根本上改变程序中原有类的行为。 若两个分类中的方法同名，则被调用的方法是不可预测的。

分类的声明如下：

@interface ClassName (CategoryName)

@end

下面是一个具体的例子，通过MyAdditions分类，动态的给NSString类中添加getCopyRightString方法：

#import <Foundation/Foundation.h>

@interface NSString(MyAdditions)
+(NSString *)getCopyRightString;
@end

@implementation NSString(MyAdditions)

+(NSString *)getCopyRightString {
   return @"Copyright evilpan.com 2019";
}

@end

int main(int argc, const char * argv[]) {
   NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
   NSString *copyrightString = [NSString getCopyRightString];
   NSLog(@"Accessing Category: %@", copyrightString);
   
   [pool drain];
   return 0;
}

小结

现在，我们已经了解了Objective-C语言的基本语法和关键概念，可以开始自己编写简单的程序了。 一门语言只是一个工具，常用常新，如果不使用，学得再深也很容易遗忘。 当然，本文介绍的Objective-C特性只是一小部分，但我们仍然可以先用起来， 等遇到具体语法或者API时候再查阅文档（如spec、tutorialspoint等）即可。 使用得越多，需要查阅文档但频率也会越少，学习没有捷径可言。

前言

最近把Jekyll搭建的博客翻新了一遍，主要是规范化了文章的永久连接（permlink）和分类标签。 好处是用起来更加规范，坏处就是在野的文章链接指过来的时候就404了。所以说重构最难的还是保持前向兼容， 不过还好我的访问量不高，可以不用顾忌太多甩开历史包袱。由于Jekyll都是是静态页面，所以对于很多访问的细节难以了解， 可以说在此之前我都是对其不管不顾的状态，也没太多时间维护。

由于全部是静态资源，所以一开始也部署了Nginx作为HTTP服务器。日志采用默认的格式产生，一直也没太关注， 这次正好藉着博客改版，尝试分析下近期的日志，以对网站状态有个全局的了解。

Nginx

Nginx是个开源的，高性能的HTTP服务器，反向HTTP代理服务器，以及IMAP/POP3代理服务器，功能强大， 因为我也只用过其部分子集，所以本文不对其做详细。这里要交待一下的是配置文件/etc/nginx/nginx.conf 的相关配置，因为后面会有相关：

user www-data;
pid /var/run/nginx.pid;
...

http {
    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log error;
    server {
        listen 80;
        server_name www.pppan.net;
        location / {
            root /path/to/jekyll/_site;
        }
    }
}

可以看到这里没有指明日志的格式，因此采用默认设置，根据nginx-log-module 文档得知对于access_log， 其默认的格式是combined，如下所示：

log_format combined '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent"';

对于错误日志error_log，一共有6个等级，分别是info, notice, warn, error, crit, alert(emerg)， 默认的输出等级是error，所以上面配置里error_log xxx.log error中的error不写也是可以的。详情参考nginx core functionality。

总而言之，Nginx的日志分为访问日志access_log和错误日志error_log两大块，前者主要记录用户每次访问的情况， 后者则侧重于服务器的具体错误，比如返回403的具体原因是文件不可读还是权限不足之类的。

准备工作

现在有了日志，便可以着手开始处理了，但在此之前还是要先选择好工具。网上有许多日志分析采用的是简单粗暴的bash脚本(awk)来进行处理， 好处是分析速度快，但坏处是拓展性不强，如果未来想要做图表或者在网页前端展示就比较麻烦了。

因此我就挑了比较顺手的Python来做这个工作，因为其还能用matplotlib做些可视化的工作，看起来直观一点。 不过还是那句老话，语言只是工具，你也可以用php或者易语言，挑最顺手的来就行了。

访问日志

存储

从上面的配置文件可以看到我的访问日志保存在/var/log/nginx/access.log里，日志到了一定大小就会被压缩改名， 所以/var/log/nginx里的文件看起来是这样的：

用Python可以很容易将其全部提取出来合并，我将其取出然后存到数据库里，这样可以方便做些查询和聚合的操作， 这里为了简单起见因此选用sqlite3作为数据库，省去安装和配置MySQL的麻烦。表access的格式如下：

DROP TABLE IF EXISTS `access`;
CREATE TABLE `access` (
        `ip` VARCHAR(64),
        `user` VARCHAR(64),
        `date` TIMESTAMP,
        `request` VARCHAR(200),
        `refer` VARCHAR(200),
        `ua`    VARCHAR(200),
        `response_code` INTEGER,
        `response_size` INTEGER);

用Python读取每个文件每一行，并用正则表达式取出我们想要的内容，代码片段如下：

from dateutil.parser import parse
from dateutil import tz

TZ_LOCAL = tz.tzlocal()
pattern = re.compile(r'(?P<ip>.*) - (?P<user>.*) \[(?P<date>.*)\] "(?P<req>.*)" (?P<rcode>\d+) (?P<rsize>\d+) "(?P<ref>.*)" "(?P<ua>.*)".*')
for line in file:
    match = pattern.match(line)
    if match:
        fmt_date = match.group('date').replace(':', ' ', 1)
        foreign_date = parse(fmt_date)
        local_date = foreign_date.astimezone(TZ_LOCAL)
        cursor.execute("INSERT INTO `access` VALUES (?,?,?,?,?,?,?,?)",
                (   
                    match.group('ip'),
                    match.group('user'),
                    local_date,
                    match.group('req'),
                    match.group('ref'),
                    match.group('ua'),
                    match.group('rcode'),
                    match.group('rsize'),
                )
            )

这里先将时间部分格式化成Python的dateutil可以读取的格式，然后由于我的服务器在美国且用的系统默认时区， 因此这里还将时区转换为本地时区。最后将记录插入到刚刚创建的数据库里。

分析

虽然日志清理了很多，只保留几个月的访问情况，但不妨碍我根据现有的字段，提取出一些我所关心的内容。 首先用下列命令分别获取总的访问数以及总的访问ip数：

SELECT COUNT(*) FROM `access`;
SELECT COUNT(DISTINCT `ip`) FROM `access`;

结果一共有15325条访问记录，分别来自2101个不同的IP地址。

Top10

可以根据每个所关心的字段读取频率最高的前十看看是否有什么出乎意料的情况，这里以客户端IP，客户端User-Agent， 以及返回状态为例。

请求IP

首先获取访问频率最高的10个IP地址：

SELECT COUNT(*),`ip` FROM `access` GROUP BY `ip` ORDER BY COUNT(*) DESC LIMIT 10;

获得数据后画成表格如下：

其中排名第一第二的都是我常用的出口IP，但不要被这个饼图误导了，因为前十加起来的访问量也不过三千左右， 占总量（15235）也才20%而已。事实上访问的IP来源是挺分散的，这里仅仅关注访问频率而已。可以看到除了我自己， 其他几乎都是爬虫，嗯，挺合理的。

User-Agent

获取访问频率最高的前10个User-Agent:

select COUNT(`ua`),`ua` FROM `access` GROUP BY `ua` ORDER BY COUNT(*) DESC LIMIT 10;

结果如下：

2758|-
1465|Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
770|Mozilla/5.0 (Ubuntu; X11; Linux x86_64; rv:8.0) Gecko/20100101 Firefox/8.0
503|Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36; 360Spider
479|Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)
302|Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
290|Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
286|Mozilla/5.0 (Linux; U; Android 5.0.2; zh-CN; Redmi Note 3 Build/LRX22G) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 OPR/11.2.3.102637 Mobile Safari/537.36
279|Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
257|Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)

其中排名第一的是不带User-Agent的请求，紧随其后的是google的爬虫以及其他搜索引擎的爬虫，中间有几条来自浏览器的UA基本都是我自己乱入了。

状态码

HTTP请求的返回码也是一个值得关注的信息：

SELECT COUNT(*),`response_code` FROM `access` GROUP BY `response_code` ORDER BY COUNT(*) DESC;

结果如下：

200|6676
301|3271
400|2487
502|1270
404|1147
304|435
206|15
499|10
403|8
504|6

除了200和301重定向以外，还有不少异常的请求，以502状态为例，随手拿几条出来看看：

149.202.98.160|-|2017-05-31 18:57:57+08:00|HEAD / HTTP/1.1|-|scan/0.01|502|0
91.230.47.3|-|2017-05-31 19:41:01+08:00|GET / HTTP/1.0|-|-|502|172
31.210.102.114|-|2017-05-31 19:52:39+08:00|GET / HTTP/1.0|-|masscan/1.0 (https://github.com/robertdavidgraham/masscan)|502|172
91.230.47.3|-|2017-05-31 20:45:07+08:00|GET / HTTP/1.0|-|-|502|172
91.247.38.53|-|2017-05-31 22:42:19+08:00|HEAD /categories.html HTTP/1.1|-|Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 OPR/42.0.2393.94|502|0
91.247.38.53|-|2017-05-31 22:42:28+08:00|GET /categories.html HTTP/1.1|-|Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.2) Gecko/20100316 AskTbSPC2/3.9.1.14019 Firefox/3.6.2|502|172
91.247.38.53|-|2017-05-31 22:42:31+08:00|GET /categories.html?geVG%3D8598%20AND%201%3D1%20UNION%20ALL%20SELECT%201%2CNULL%2C%27%3Cscript%3Ealert%28%22XSS%22%29%3C%2Fscript%3E%27%2Ctable_name%20FROM%20information_schema.tables%20WHERE%202%3E1--%2F%2A%2A%2F%3B%20EXEC%20xp_cmdshell%28%27cat%20..%2F..%2F..%2Fetc%2Fpasswd%27%29%23 HTTP/1.1|-|Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.2) Gecko/20100316 AskTbSPC2/3.9.1.14019 Firefox/3.6.2|502|172

可以看到大多数都是出于扫描器，估计是带了错误的HOST头导致Nginx无法正确代理，具体还要配合error_log查看。 上面的输出里最后一个请求有点奇怪，url decode如下：

/categories.html?geVG=8598 AND 1=1 UNION ALL SELECT 1,NULL,'<script>alert("XSS")</script>', table_name FROM information_schema.tables WHERE 2>1--/**/; EXEC xp_cmdshell('cat ../../../etc/passwd')#

查了下IP是来自乌克兰，其实不算很惊讶，因为前面IP访问频率里排第三的就是来自俄罗斯的爬虫。这里根据最后三条记录来看， 应该是什么测试XSS和SQL注入的脚本，因为间隔比较短。不过能自动选择/categories.html这种可能带搜索的路径也是挺厉害的。 扯得有点远了，还是继续分析日志吧。

流量观察

对于一般网站来说流量监控也是比较重要的，所以根据访问时间，可以统计出每天的访问量和一天中平均各个时间段的访问量：

可惜这里只有几个月的访问日志，不过从左图能看到每天的访问量高低起伏很大，其中最高那里是5月31号端午节我在博客园发新博客的时候。 右图是24小时中各个时间段的访问频率，可以看到凌晨四点最低，下午三点最高，这里我都已经转换为北京时间了。

错误日志分析

错误日志也叫应用程序日志，主要用于方便开发者或者运维在出问题的时候排查原因。

存储

同样地，我们可以先把日志保存在数据库里：

DROP TABLE IF EXISTS `error`;
CREATE TABLE `error` (
        `date` TIMESTAMP,
        `level` VARCHAR(20),
        `pid`   VARCHAR(20),
        `message` TEXT
        );

具体过程和访问日志的保存类似，就不再赘述了。

分析

错误日志相对于访问日志要少（废话），但从中也能找到对我们有价值的信息。

错误类型

首先看看都有哪些等级的错误：

select level,count(level) from error group by level;

输出为：

error|2335 notice|9

很好，没有严重的错误，notice里的信息基本上就是Nginx重启的记录，error里则记录了许多异常的访问， 这也是要重点分析的。

路径错误

前一段时间改版了博客，因此导致文章路径和以前不兼容了

SELECT COUNT(*) FROM `error` WHERE `message` LIKE '%2: No such file or directory%';

发现有1051个日志都是404错误，几乎占了所有错误日志的一半，下面是随便挑的一些日志详情：

4|connect() failed (111: Connection refused) while connecting to upstream, client: 109.169.29.30, server: bbs.pppan.net, request: "GET /robots.txt HTTP/1.1", upstream: "http://127.0.0.1:5000/robots.txt", host: "www.pppan.net"
3|open() "/home/pnz/html/pppan.net/_site/tech/2015/11/01/mitm-detail-1.html" failed (2: No such file or directory), client: 125.38.58.212, server: www.pppan.net, request: "GET /tech/2015/11/01/mitm-detail-1.html HTTP/1.1", host: "www.pppan.net", referrer: "http://www.cnblogs.com/pannengzhi/p/4989406.html"
3|open() "/home/pnz/html/pppan.net/_site/tech/p2p/2015/12/12/p2p-standard-protocol-stun.html" failed (2: No such file or directory), client: 121.35.211.124, server: www.pppan.net, request: "GET /tech/p2p/2015/12/12/p2p-standard-protocol-stun.html HTTP/1.1", host: "www.pppan.net", referrer: "http://www.cnblogs.com/pannengzhi/p/5048965.html"
3|open() "/home/pnz/html/pppan.net/_site/tech/2015/11/01/mitm-detail-1.html" failed (2: No such file or directory), client: 220.178.225.121, server: www.pppan.net, request: "GET /tech/2015/11/01/mitm-detail-1.html HTTP/1.1", host: "www.pppan.net"
2|open() "/home/pnz/html/pppan.net/_site/favicon.ico" failed (2: No such file or directory), client: 175.9.149.46, server: www.pppan.net, request: "GET /favicon.ico HTTP/1.1", host: "www.pppan.net"
2|open() "/home/pnz/html/pppan.net/_site/tech/2015/11/01/mitm-detail-1.html" failed (2: No such file or directory), client: 218.29.102.120, server: www.pppan.net, request: "GET /tech/2015/11/01/mitm-detail-1.html HTTP/1.1", host: "www.pppan.net", referrer: "http://www.cnblogs.com/pannengzhi/p/4989406.html"
2|open() "/home/pnz/html/pppan.net/_site/tech/p2p/2015/12/12/p2p-standard-protocol-stun.html" failed (2: No such file or directory), client: 123.157.208.18, server: www.pppan.net, request: "GET /tech/p2p/2015/12/12/p2p-standard-protocol-stun.html HTTP/1.1", host: "www.pppan.net", referrer: "http://www.cnblogs.com/pannengzhi/p/5048965.html"

可见"重构"这地雷是多么有破坏力啊。其中很多refer都来自博客园，所以我也赶紧把博客园里对应的文章连接都修改了一遍:(

SEO（搜索引擎优化）

我对SEO完全是门外汉，但即便是我也知道，如果每次搜索引擎的爬虫每次来你的网站都吃一鼻子灰，那你在搜索引擎里的结果肯定不怎么好看。 当然每个搜索引擎的优化策略也不尽相同，说起来和杀毒软件的查杀策略一样，需要有心人不断去摸索，去exploit。

鉴于google的爬虫访问我的频率最高，那我就尝试着对其友好一点。先在错误日志里找找有没有google相关的日志：

SELECT COUNT(*) FROM `error` WHERE `message` LIKE '%google%';
SELECT `message` FROM `error` WHERE `message` LIKE '%google%';

说多也不多，说少也不少，一共有56条错误日志，其中大多数都是404错误，主要访问了以下内容：

• GET /post_google_news.xml
• GET /LocalNews.xml
• GET /googlenews.xml
• GET /googlesitemap.xml
• GET /newssitemap.xml
• GET /sitemap/news.xml
• GET /tncms/sitemap/news.xml
• …

这些东西我怎么会有嘛？！经过google得知这是sitemap即网站地图，爬虫根据地图可以更高效地遍历网站而省去许多无谓的跳转。 一般来说网站的sitemap存放于根目录/sitemap.xml，和/robots.txt一样，都是作用于爬虫。而上面的一些路径则主要针对google， 有的博客系统如wordpress，都提供了生成google news sitemap的插件，与RSS方式一样，Jekyll也可以很容易生成类似的XML， 只不过我现在志并不在此，所以就让它继续404吧～

查错示例

刚刚在分析access_log的时候发现一个乌克兰的IP(91.247.38.53)访问返回502错误网关的信息，但具体错误原因还不清楚， 通过对比error_log就能看出了：

SELECT * FROM `error` WHERE `message` LIKE '%91.247.38.53%';

2017-05-31 10:42:19|error|14829#0|*6247 connect() failed (111: Connection refused) while connecting to upstream, client: 91.247.38.53, server: bbs.pppan.net, request: "HEAD /categories.html HTTP/1.1", upstream: "http://127.0.0.1:5000/categories.html", host: "23.95.112.93"
2017-05-31 10:42:28|error|14829#0|*6249 connect() failed (111: Connection refused) while connecting to upstream, client: 91.247.38.53, server: bbs.pppan.net, request: "GET /categories.html HTTP/1.1", upstream: "http://127.0.0.1:5000/categories.html", host: "23.95.112.93"

可见是访问了bbs.pppan.net这个我曾经开过的测试域名，当时用完忘记把DNS的A记录删掉了，而且nginx里对应的反向代理还开着， 所以就报了网关错误，和我当初预计的原因一样。

总结

通过分析一遍Nginx的日志，也学习了许多新知识，比如数据的可视化，搜索引擎的习惯以及一些XSS和SQL注入的方法等， 算是温故而知新吧。

但是当时对于数据库的选择，却走了一点弯路。因为平时对于数据库接触不多，所以一开始选择了MongoDB 作为数据库。这在初期是没啥问题的，但后来随着项目推进，产品经理不断地增加需求（我要…我要…我还要…）， 数据库中各个collection的耦合度也越来越高，甚至同一个collection也有大量的冗余数据。虽然也有办法进行优化， 但是我经过查阅资料和进度考量，最后还是决定趁着项目尚未release，将NoSQL替换为关系型的数据库。

关系数据库简介

关系数据库由由埃德加·科德（IBM）在1969年左右提出。自推出后就成为商业应用的主要数据库模型（与其他数据库模型， 如分级，网络或对象模型相比）。如今已有许多商业关系数据库管理系统（RDBMS），如Oracle，IBM DB2和Microsoft SQL Server等。 也有许多免费的开源关系数据库，如MySQL，mSQL（mini-SQL）和嵌入式JavaDB（Apache Derby）等。

关系数据库将数据存储在表（table）中。一个表由行和列组成。行称为记录(record)或元组(tuple)，列称为字段(field)或属性(attribute)。 数据库的表类似于电子表格。不过关系数据库可以在这些表格中产生关联，使得可以有效地存储大量的数据，以及高效地检索数据。

SQL（结构化查询语言）通常用来对关系数据库进行操作。

关系数据库设计步骤

数据库的设计对经验的要求比理论要高，因为你必须作出许多选择。数据库通常是为了某种应用的需求而高度定制的，因此， 通常在数据库设计的指导里，通常都是指出不要做什么而不是要做什么，但最后的决定权还是在设计者的手中。

一、需求分析

尽可能地收集需求，以及定义你的数据库的最终目的。 比如要开发书店查询应用，就要先知道应用有什么需求， 如如何添加书籍，如何查询现有书籍，如何查询订单，生成的报告格式如何，等等。 在这个阶段的分析中，在纸上画出输入表单，以及查询和报告的草图，通常会有不少帮助。

二、收集数据，组织表并设定主键

一旦需求明确，接下来就要确定有哪些数据需要存储到数据库中。通常我们都是将数据基于分类存储到不同的表中。 比如设计一个书店的数据库，就需要对书本，作者，出版社，顾客，订单等分类进行分表;而对每个表， 则要定义好需要哪些列（记录），以书本为例，需要有标题，作者，出版社，出版日期，ISBN，价格等信息。 对于每一个表，我们需要选择一列（或者多列）作为主键（primary key）。

关于主键

在关系模型中，表不可以含有重复的行，否则会导致检索出现歧义。为保证唯一性，每个表都有某一列（或者多列）作为主键， 其目的是可以唯一区分每一行。如果主键只由某列构成，则被成为简单键（simple key），若由多列组成则成为组合键（composite key）。 大多数商业数据库都基于主键来生成索引以提高查询的速度。另外，主键还被用来被其他表用作关系引用（详见下文）。

主键的选择由库的设计者来决定，要遵循以下原则：

• 主键的值必须是唯一的（即不可重复）
• 主键不能为空

除此之外，对于主键的选取还有一些best practice:

• 主键的值不可修改。因为主键可能会在其他表中用来引用，如果改了主键的值，就需要把其他表的引用都更新。
• 主键可以是任何类型，但最好是整数（效率原因）
• 主键最好用简单键，如果一定要用组合键，要尽量用最少的列

目前的数据库大都可以不主动指定主键，而是由于数据库自己添加额外的一列类型为自增整数（AutoNumber）并指定为主键。

三、建立关系

在关系数据库中包含独立且不相关的表格通常没有太大意义，如果真是这种情况你可以考虑使用NoSQL或者电子表格来存储这些内容。 关系数据库的魅力所在就是“关系”二字，甚至可以说设计关系数据库的成败所在就是明确各个表之间的关系。表间关系的类型有如下三种：

• 一对多(one-to-many)
• 多对多(many-to-many)
• 一对一(one-to-one)

一对多

考虑一个族谱关系的例子，一个母亲可能会有0个或多个小孩，但是任意一个小孩都有且只有一个母亲。这样的关系便称为一对多。 一对多的关系不能只用一个表来保存。为什么？以前面的例子来说，我们一开始可能会考虑建立一个名为Mothers的表， 其中保存了母亲的信息如年龄，姓名，血型等，对于其下的小孩，可以创建不同的列，如老大，老二，老三… 但这样我们会面临一个问题，即列的数量是不确定的。换个方向来说，我们可以建立名为Children的表，其中存储小孩的基本信息， 以及其母亲的信息。这样看似能满足要求，但是由于不同的小孩可能会有相同的母亲，因此表中的重复数据是很多的。

因此，考虑支持一对多的数据库关系，我们应该建立两个表，分别为Mothers和Children，只保存各自的属性，并且设置分别的主键为 MotherID和ChildrenID。然后我们可以通过在Children新建一列包含MotherID建立一对多的关系，如下图所示：

其中Children表里的MotherID列又被称为约束或外键（Foreign Key），用SQL来描述如下：

CREATE TABLE `Mothers` ( 
`MotherID` INTEGER NOT NULL AUTO_INCREMENT,
`Name` VARCHAR(100) NOT NULL,
`Age`  SMALLINT NOT NULL,
`BloodType` VARCHAR(2) NOT NULL,
PRIMARY KEY (`MotherID`)
);
CREATE TABLE `Children` ( 
`ChildrenID` INTEGER NOT NULL AUTO_INCREMENT,
`MotherID` INTEGER NOT NULL,
`Name` VARCHAR(100) NOT NULL,
`Age`  SMALLINT NOT NULL,
`Sex` VARCHAR(50) NOT NULL,
`BloodType` VARCHAR(2) NOT NULL,
PRIMARY KEY (`ChildrenID`),
FOREIGN KEY (`MotherID`) REFERENCES `Mothers` (`MotherID`)
);

多对多

考虑一个“产品销售”数据库的例子，某个客户的订单包含一个或者多个产品，而某个产品又可能出现在多个订单之中， 这样的关系便称为是多对多的。为了构建这样的关系，我们先从两个表订单Orders和产品Products开始看。 表Products含有关于产品的信息（如名称，介绍，库存）以及一个主键ProductID;表Orders则包含订单信息 （如客户ID，订单日期，订单状态）以及主键OrderID。同样地，我们没法简单地将所有购买的产品保存在订单表里， ，因为订单所包含的产品记录是不固定的;同理，也没法将所有关联订单保存在产品表里。

因此，为了支持这种多对多的关系，我们需要第三个表。在本例子中，姑且将其命名为OrderDetails， 其中每一行都包含了特定的订单信息，对于这个表，主键应为组合键，包含两列信息， 分别为OrderID和ProductID， 而这两列也是对应Orders和Products表的Foreign Key，如下图所示：

SQL描述如下：

CREATE TABLE `Orders` (
`OrderID` INTEGER NOT NULL AUTO_INCREMENT,
`OrderDate` DATETIME DEFAULT CURRENT_TIMESTAMP,
`CustomerID` INTEGER NOT NULL,
PRIMARY KEY (`OrderID`)
);

CREATE TABLE `Products` (
`ProductID` INTEGER NOT NULL AUTO_INCREMENT, 
`Name` VARCHAR(100) NOT NULL,
`Stock` INTEGER DEFAULT 0,
PRIMARY KEY (`ProductID`)
);

CREATE TABLE `OrderDetails` (
`OrderID` INTEGER NOT NULL,
`ProductID` INTEGER NOT NULL, 
FOREIGN KEY (`OrderID`) REFERENCES `Orders` (`OrderID`),
FOREIGN KEY (`ProductID`) REFERENCES `Products` (`ProductID`),
PRIMARY KEY (`OrderID`,`ProductID`)
);

事实上，多对多的关系是以两组一对多的关系来实现的，额外引入的表被称为junction table即连接表。 从上面的例子可以看到，每个产品（product）都会在OrderDetails表里出现多次，但OrderDetails 里的每一行都只包含一个产品，若每个订单有多个产品则用多行来表示。相应地对订单（Order）也是类似。

一对一

考虑一个“产品信息”数据库，其中除了产品名称，产品数量等基本信息外，还需要保存产品图片，产品详细等富文本详情信息， 一个产品只有0个或者一个详情，一个详情有且只对应一个产品，因此这类关系就可以归类为一对一关系。 有些数据库限制了列的数量，或者我们需要将部分敏感信息用另外的表保存，这些情况都可以引进一对一的关系。

回到前面的例子，我们需要分裂出一个称为ProductDetails的表，与Products构成一对一的关系。图我就不画了， 用SQL描述如下：

CREATE TABLE `Products` (
`ProductID` INTEGER NOT NULL AUTO_INCREMENT,
`Name` VARCHAR(50) NOT NULL,
PRIMARY KEY (`ProductID`)
);
CREATE TABLE `ProductDetails` (
`ProductID` INTEGER NOT NULL AUTO_INCREMENT,
`DetailInfo` VARCHAR(65535),
FOREIGN KEY (`ProductID`) REFERENCES `Products` (`ProductID`),
PRIMARY KEY (`ProductID`)
);

可以看到在ProductDetails表中，主键和外键都为同一列, 这保证了一对一的正确性。值得一提的是，这里保证了Products 可以对应0个或1个ProductDetails，但ProductDetails必须对应一个Products，如果后者对前者不是强关联，如“丈夫-妻子” 的关系，那么后者可以不以主键作为外键，而是以另外一列声明为UNIQUE的属性作为外键即可。

精炼及规格化

当设计好一个数据库或者拿到已有的数据库时，我们可能会想要：

• 增加更多的列
• 为某个表中的可选数据创建一个新表并建立一对一关系
• 将一个大表分裂为两个小表
• …

在进行这些操作时，下列的规则就可以作为参考。

规范规则(Normalization)

范式（Normal Form），指的是符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度， 可以在某种程度上认为是一张数据表的表结构所符合的某种设计标准的级别。常见的范式有第一范式、第二范式、…第六范式， 其严格程度依次上升，一般设计上满足第三范式即可满足日常使用。

第一范式(1NF)

第一范式又称为1NF（First Normal Form），是对关系模式的基本要求，不满足第一范式的数据库就不是关系数据库。 数据库表中的字段都是单一属性的，不可再分。这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。 同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。 如果出现重复的属性， 就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。

简而言之，第一范式就是没有重复的列。

第二范式(2NF)

第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式必须先满足第一范式（1NF）。 第二范式要求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。 例如员工信息表中加上了员工编号（EmployeeID）列，因为每个员工的员工编号是惟一的，因此每个员工可以被惟一区分。 这个唯一属性列也就是我们之前提到过的主键。

第二范式也要求实体的属性完全依赖于主键。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性， 例如含有多列的主键，如前文提到的OrderDetails，主键为ProductID和OrderID，若含有一列为产品单价ProductPrice, 则不符合2NF，因为ProductPrice只依赖于ProductID而不依赖于OrderID，因此此属性应该保存在Products表中。

简而言之，第二范式就是属性应完全依赖于其主键。

第三范式(3NF)

满足第三范式（3NF）必须先满足第二范式（2NF）。第三范式要求数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖。 所谓传递函数依赖，指的是如果存在"A → B → C"的决定关系，则C传递函数依赖于A。 例如，存在一个部门信息表，其中每个部门有部门编号（DepartmentID）、部门名称(DepartmentName)、部门简介等信息。 这样一个表就不是3NF的，因为存在传递依赖（EmplyeeID->DepartmentID->DepartmentName),因此在员工信息表中列出部门编号后就不应再将部门名称、 部门简介等与部门有关的信息再加入员工信息表中，而是将这部分数据保存在部门信息表中，如果不存在部门信息表， 则根据第三范式也应该构建它，否则就会有数据冗余，并且容易产生更新、插入的异常。

简而言之，第三范式就是任一非主键属性不应依赖于其它任何非主键属性。

鲍依斯-科得范式(BCNF)

BCNF(Boyce Codd Normal Form)又称为3.5NF，其出现的目的是为了弥补3NF的缺陷。在满足3NF的前提下， 如果数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则称为符合BCNF。 只有少部分情况下满足3NF而不满足BCNF，这里以今日会议室预订表为例。考虑有以下表格：

其中会议类型的定义如下：

• A1, 在会议室1里的一般会议
• A2，在会议室1里的管理层会议
• B1，在会议室2里的一般会议
• B2，在会议室2里的管理层会议

这个表里所有字段都是候选关键字段，因此显然是满足3NF的，但同时存在以下决定关系：

• （会议室编号）-> （会议类型）
• （会议类型） -> （会议室编号）

即关键字段影响关键字段的情况，因此不满足BCNF。

简而言之，BCNF就是任一属性不应依赖于其它非主键属性。

其他更严格的范式超出了本文的范围，因此不再赘述。

完整规则(Integrity)

除了设计范式，我们也可以通过完整性规则（Integrity rules）来检查自己的设计。常见的完整性规则如下：

实体完整性（Entity Integrity Rule）

实体完整性指表中行的完整性。主要用于保证操作的数据（记录）非空、唯一且不重复。即实体完整性要求每个关系（表） 有且仅有一个主键，每一个主键值必须唯一，而且不允许为“空”（NULL）或重复。

参照完整性（Referential Integrity Rule）

参照完整性属于表间规则。对于永久关系的相关表，在更新、插入或删除记录时，如果只改其一，就会影响数据的完整性。 如删除父表的某记录后，子表的相应记录未删除，致使这些记录称为孤立记录。对于更新、插入或删除表间数据的完整性， 统称为参照完整性。通常，在客观现实中的实体之间存在一定联系，在关系模型中实体及实体间的联系都是以关系进行描述， 因此，操作时就可能存在着关系与关系间的关联和引用。

域完整性（Domain Integrity）

域完整性是指数据库表中的列必须满足某种特定的数据类型或约束。其中约束又包括取值范围、精度等规定。表中的CHECK、 FOREIGN KEY 约束和DEFAULT、 NOT NULL定义都属于域完整性的范畴。

用户定义完整性（User-defined Integrity）

又叫业务逻辑完整性（Business logic Integrity），是对数据表中字段属性的约束，用户定义完整性规则（User-defined integrity） 也称域完整性规则。包括字段的值域、字段的类型和字段的有效规则（如小数位数）等约束，是由确定关系结构时所定义的字段的属性决定的。 如百分制的考试成绩取值范围在0-100之间，订单数量应该小于等于库存量等。

其他

通常我们可以通过对指定的列创建索引来加快数据库的读取和查询速度。在实现上，索引通常是一个结构化文件，可以提高SELECT的速度， 却会对INSERT, UPDATE和DELETE的速度有一定负面影响。如果没有索引，进行一次条件查询（比如SELECT * FROM Customers WHERE name="Sam"） 就需要对整个数据库进行一次线性查找和比较。而在带索引的结构中（如B树），查询的时间就能减少到对数级别。当然在这种情况下， 插入和删除的时间也从常数上升到对数级别，不过在实践中由于查找的频率远远大于插入和删除，因此索引带来的好处也是很明显的。

对于特定的表来说，索引可以是1列，多列组合（称为组合索引，Concatenated Index）或者是某列的部分内容（称为部分索引，Partial Index）。 在一个表里我们也可以建立多个索引，例如需要经常通过电话号码或者名字来查询某个客户，就可以在这两列建立对应的索引。 索引最终还是根据实际需要自行选择，值得一提的是大多数RDBMS都会自动基于主键建立索引。

后记

总结一下，在关系数据库设计中，我们首先要明确设计的最终目标，再根据目标决定哪些数据要持久化存储; 对于这些数据， 要按照功能和逻辑来进行拆分，并且存放在不同的表中，并且明确之间的关系; 对于设计好的表，要进行重构， 根据设计范式对大表进行拆分和优化; 对于每个表要增加对应的完整性检查，关键是实体完整性和参照完整性; 最后在实际使用中，对于高频查询的记录构建索引提升效率，以及其他因地制宜的优化。

三部曲

软件开发,无论是用什么语言,在什么操作系统,都有其本身不变的东西,称之为编程思想. 对我而言,我所遵循的开发思想其实很简单,却都是血泪的经验所汇结而成. 我将其总结为三点:

1. Make it work, 2) Make it clean, 3) Make it fast. 排序分先后,而且缺一不可.

Make it work (使其可用)

这个规则似乎是显而易见的, 软件开发的目的就是为了解决实际问题. 但是,忘记这个规则的 程序员,也不在少数. 君不见,每次上技术论坛,都有人在问:“我是新手,应该学哪门语言?”, 或者讨论"XXX语言怎么臃肿复杂难用",“XXX语言怎么语法奇异古怪”,等等.

说真的,这些事情重要吗? 我学的第一门编程语言是Verilog,之后转到SystemC做系统仿真, 后来顺其自然地学习了C++,之后才完全转到软件行业. 说这个想说明, 对于新手而言, 第一门学习的语言并不重要, 它的作用是让你了解人与机器的交互接口, 也就是条件, 循环,函数等基本概念. 再者,学习某一门编程语言,最好的办法就是那句至理名言:JUST DO IT, 纠结于语言,平台,难度这些东西反而是本末倒置, 编程首先要明确的事情是你想做什么. 比如想做嵌入式,硬件相关,那C/C++是首选; 想做手机app, 当然是Java(Android)或Objective C; 想做些数据处理,或者小工具简化日常工作,那我会推荐Python;想做网页,除了JavaScript还有其他选择吗? 因此, 忘记网上那些讨论吧. 语言圣战,也许只有新手才会热衷于此. 听闻使用不同开发语言的人会互相鄙视, 比如C++鄙视JAVA, JAVA鄙视Python, Python鄙视JS, 等等, 这让我深感无聊且幼稚.

对于有经验的软件开发人员,太执着于开发语言更是不必要. 既然是有经验,那至少是对各种类型的语言都有所了解, 比如强类型的C/JAVA, 动态类型的Python以及某种函数式语言如Scala或Haskell等. 多种语言之间虽然语法稍微有所不同, 但大体上都能在上述类型中找到很多相似的地方,也就是说,只要稍微花一两周学习语法,应该要能很快投入到团队项目中. 当然对于特别复杂的语言(如C++),多花点时间了解语言特性也是必要的.

总而言之,好的软件工程师,应该要有举一反三,快速学习的能力. 最为重要的,不要忘记自己出手的目的, 那就是Make it work, 客户端应用也好, 服务端组建也罢, 都是为了实现其功能, 对其他服务或者人进行有效而正确的交付. 在这个阶段, 除了功能无需考虑太多其他事情, 不忘初心, 才能免于掉入效率的陷进之中.

Make it clean (使其整洁)

代码整洁,是每个软件工程师都或多或少听说过的概念. 但是这个概念又不像第一点那样显而易见. 因为我们即使不管代码整洁与否,程序都能实现最初的功能,交付给老板他也很是高兴. 相反, 如果多花时间在代码的整洁性上,那必然会延时交付,从而会使得老板不高兴.因此, 这一条也是 三部曲中分歧最大的.

当然了,对于软件工程师而言,在时间足够的情况下,几乎不会有人反对代码整洁. 但现实是项目的时间 往往紧迫,而且改善代码质量在短期内也看不出有什么收获. 可是如果不注重,等到项目规模扩大之后, 开发者就会陷入代码耦合,结构混乱,难以拓展和难以维护的屎坑之中.

关于代码整洁,细说起来也是内容庞杂. 在这里可以推荐三本书:

• «代码整洁之道»
• «重构:改善既有代码的设计»
• «设计模式:可复用面向对象软件的基础»

在软件功能开发结束之后,我们可以优化现有的代码,将其中的模块和逻辑重新整理,使得整体结构清晰明朗, 一些有用的模块,可以独立出来,可以复用到以后的项目之中,以减少重复造轮子的时间.

值得一提的是, 代码整洁往往离不开重构, 而重构又离不开单元测试. 因为只有单元测试有足够的覆盖率, 你才能在改善代码的时候保证不影响现有的功能. 不论是对现有代码的重构, 还是保证新代码的一致性(coding style), 都需要额外花费时间, 但最后你会发现所付出的小部分时间, 会在将来以10x的效率提升而返还.

Make it fast (使其高效)

没人喜欢慢吞吞的代码. 对于面向用户的服务更是如此. 如果每次打开一个APP或者渲染一个页面,都需要5,6秒的时间, 那很可能这个用户就流失掉了. 除去I/O的原因, 程序运行的效率也是一个重要的考量因素.

影响程序运行速度的原因有很多,比如算法的复杂度,内存分配/拷贝的频率,以及系统上下文切换等. 很多时候我们也不能想当然地就进行优化. 正确的做法是通过profiler来进行分析. 现代的集成开发环境(IDE), 应该都会提供对应的profiler. 以Linux的c/c++程序为例, 我们就可以用gprof对应用程序进行分析. 其提供了每个函数的运行时间(百分比)/累计运行时间,调用次数等有用的信息,帮助我们查找程序热点, 从而改善程序的执行效率. 毕竟,根据二八定律,程序运行所消耗80%的时间,大都产生于20%的代码之中.

改善效率,有可能是减少某个具体算法函数的时间复杂度(比如替换random函数),有可能是用引用取代复制减少内存拷贝, 也有可能是增加缓存减少网络/磁盘的IO频率. 具体的方法取决与程序的热点所在. 一些看起来似乎有用的做法, 比如循环展开,函数inline以期减少堆栈开销等, 简直是大腿上把脉——瞎搞.

乱序陷阱

上面讲了软件开发过程中的三部曲,但是有一点非常重要,即三部曲的顺序是严格从上倒下的. 而其中一些乱序错误, 也成为了如今常见的开发阻碍:

提前优化

如果开发时第一步考虑的不是使其可用,而是使其高效,那么很有可能就掉进了提前优化的陷阱. 相信大家对 “提前优化是万恶之源"这句话也不会陌生. 如果开发者在八字还没一瞥的时候就说, 我要弄三级缓存减少数据库访问, 或者我要整合xxx-kqueue支持C1000K的高并发, 那么这个项目可能就危险了. 且不说优化是否能成功地work around, 即便这个针对性的优化达到其性能要求,也未必是最终应用的热点所在. 花了大把时间, 最后可能缓存命中率极低, 或实际最高并发数还不到500, 那这些功夫就有点得不偿失了. 再者,提前的优化为初期开发套上了枷锁, 从某种程度上说,也降低了项目的开发效率.

滥用"设计模式”

上面第二点代码整洁中提到了,软件开发,特别是面向对象的软件开发,其好处在于可以切分模块边界,使得代码可以复用. 但是我却不提倡对此过于执着. 首先想代码能够重用, 就必须给模块提供对应的灵活性, 也就是说单一模块的功能应该尽量 简单且通用. 事实上功能越具体的模块就越难以重用, 只有一些抽象的功能才值得花功夫去提炼.

设计模式, 通常指的是GoF的23中面向对象的设计模式. 有的程序员看过此书后,就急着上手应用,每次项目刚开始,就考虑 要用哪几个模式,这来个Factory,那来个Delegate. 这其实有点本末倒置,无异于拿着锤子找钉子. 设计模式的初衷是 改善代码结构,减少耦合提高扩展性. 这只在项目到了一定规模才会有实际好处, 如果只是中小型项目, 增加的这些间接层, 很有可能反而提高了复杂性,纯属画蛇添足.当然, 如果你是个非常有经验的程序员, 对于这些模式的best practice了然于胸, 在某些情况下一开始就采用某种结构也无不可, 但我还是建议对其采用保守态度, 毕竟’Simple is better than complex’. 设计模式最好还是在重构的阶段再按情况决定是否采用为好.

除了重构,代码整洁的一个重要方面是编码规范,这倒是要在项目开始前制定好的,比如变量命名,大括号换不换行,用空格还是TAB缩进, 每个公司或者小组都应该有固定的规章,这样可以免去为这些细枝末节的事情操心,从而专心投入功能开发之中.