对，已经是1月9号了，早在8天前2016年便成为了过去，总觉得必须要写点什么。恰逢今天来了兴致，便随便叨叨几句。

在新的一年里，我们总会兴冲冲的立下我们的小目标（先挣它一个亿~），但是一年里，有多少是你付出的呢？这个世界从来就不存在免费的午餐。

注意看图中的时间。是的，2015年！2015年立下的几个小目标在2016年过完却是一个都没有实现，这可真是个悲伤的故事。但是我们仍然要相信，美好的事情总会发生。

接触iOS也有一阵子了，也参与到项目做了有些事情，主要是从改bug入手，边学边做，下面记录一下自己在学习中遇到一些点。

Category

Objective-C提供了一种与众不同的方式——Category，可以动态的为已经存在的类添加新的行为。这样可以保证类的原始设计规模较小，功能增加时再逐步扩展。使用Category对类进行扩展时，不需要访问其源代码，也不需要创建子类。Category使用简单的方式，实现了类的相关方法的模块化，把不同的类方法分配到不同的分类文件中。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

SomeClass.h
@interface SomeClass : NSObject{
}
-(void) print;
@end

#import "SomeClass.h"

@interface SomeClass (Hello)
-(void)hello;
@end

#import "SomeClass+Hello.h"
@implementationSomeClass (Hello)
-(void)hello{
    NSLog (@"name：%@ ", @"Jacky");
}
@end

#import "SomeClass+Hello.h"

SomeClass * sc =[[SomeClass alloc] init];
[sc hello]

这里还有一个约定成俗的习惯，将声明文件和实现文件名称统一采用“原类名+Category”的方式命名。

要开发iOS，Xcode是少不了的，这里摘录一下Xcode的基本使用。

基本

导航区：导航作用，可以查看项目总体结构。
编辑区：用于编写代码的区域。
调试区：用于输出和显示调试信息的区域。
实用区：用于显示属性和提供xib类库的区域。
工具栏：可以选择运行的设备等。

最近的一段时间都是在学习OC语法，然后看代码，改项目中的bug。OC基本语法是比较固定的，网上的文章都大同小异，这里摘录一下方便后面回顾。

基础

Objective-C扩展了ANSI C，是C的超集，也就是说：

• 任何C源程序，不经修改，即可通过Objective-C编译器成功编译。
• Objective-C源程序中可以直接使用任何C语言代码。
  注意以下几点：

1. OC中头文件后缀为.h，实现文件为.m，类似于c++中的.h于.cpp。
2. 在OC语言中混合使用C或者C++代码，包含有C语言或者C++语言时，文件的后缀使用.mm。同时一般如果是纯粹的C++文件，源代码文件后缀为.cpp，头文件使用.hpp为后缀。
3. import和include的功能是一样的，都是将引入的文件原封不动拷贝到当前位置。import的优点：会自动防止重复拷贝，同时兼容C语言的引入。
4. “ ”优先在当前文件路径查找， < >优先在系统环境查找。

前言

iMac到了之后，这2天一直在熟悉系统，准备记点东西写到博客里，发现需要解决Hexo多台电脑同步的问题，其实蛮早之前就打算弄的，方便自己在家里也能写写博客，但是考虑要带电脑到公司，而且这也确实是与工作无关的事情，只能周末来弄，但是周末是吧，大家懂的，压根不想来呀233333，所以便拖到今天了。

原理

先来想想多台电脑同步博客的原理。假设电脑A已经可以正常写博客发布了，这个时候B电脑也想发布博客该如何做呢？我们知道，发不到Github pages上的东西是静态内容，这些是Hexo生成的，这些东西其实不需要我们管，我们只要在hexo d的时候就会帮我们生成然后上传到github。所以我们需要同步的只是源文件。这里的源文件指的就是md文件、theme相关文件、以及博客配置文件等一切跟Hexo无关的文件。

等了一个星期，公司配备的iMac总算是到了，今天装上后体验了一下，有很多地方还是很不习惯，后面需要慢慢适应，这里列几点感悟。

过完一个周末来上班，今天被技术负责人约着谈了一下，主题是：让我转iOS开发。

其实在刚刚听到这个消息的时候，内心是窃喜的。因为自国庆以来，做的主要工作是预研性质的，诸如网络连接、音视频、图像处理这些非常专业的领域。也不是说自己不能够学习，主要是这些领域都是需要非常专业的人来做这些事情。通过我自学，预研，然后来做相关的开发，说实话，我自己都觉得不靠谱。所以一直以来，我对自己的工作都不是很不满意，虽然通过查资料，看文章，了解了相关东西的一点点皮毛，但是这些皮毛感觉没啥用，如果你不在这些专业的领域继续深挖进去，可以说我之前1、2月的工作都是做的无用功。当然，稍微拓宽了自己的知识层面这是不可否认的。

前言

通过前面一段时间的摸索，iOS的Multipeer Connectivity与Android的Wifi-Direct并不兼容，一些三方可能都是需要连接热点才能实现跨平台传输。热点是需要连接到同一个网络环境下的，那么考虑下Socket是否可行呢？理论上，应该是没问题的。为了验证，我这边便开始Android端的测试，至于跨平台就得等到iOS那边一起合作来验证了。

Socket连接

这里分一个Client（采集实时数据），一个server（接收数据进行处理）这样的两个角色。在一个局域网下，他们要互相建立连接首先便是要能互相发现。我的方案是：Server监听一个端口，Client发送一个绑定端口的广播（UDP），广播信息包含Client的ip，Server再收到广播之后，利用收到的ip发送一个单播到Client，单播信息包含Server的ip，Client收到之后便知道Server的ip了，那么便可以建立连接了。

现状

1. iOS：在iOS7中，引入了一个全新的框架——Multipeer Connectivity（多点连接）。利用Multipeer Connectivity框架，即使在没有连接到WiFi（WLAN）或移动网络（xG）的情况下，距离较近的Apple设备（iMac/iPad/iPhone）之间可基于蓝牙和WiFi（P2P WiFi）技术进行发现和连接实现近场通信。
2. Android：Wi-Fi peer-to-peer（P2P，对等网络），它允许具备相应硬件的Android 4.0（API level 14）或者更高版本的设备可以直接通过wifi而不需要其它中间中转节点就能直接通信（Android的Wi-Fi P2P框架符合Wi-Fi联盟的Wi-Fi Direct™直连认证标志）。使用这些API，你可以搜索并连接其它同样支持Wi-Fi P2P的设备，然后再通过一个高速的连接进行互相通信，并且这个连接的有效距离要比蓝牙连接的有效距离要长的多。这对于需要在用户之间共享数据的应用程序非常有用，例如多玩家游戏或者照片分享之类应用。

前言

通过我的上一篇文章，利用Camera实时采集视频，并用MediaCodec编码，可以得到YUV、H264文件了。那么接下来便是采集音频并编码了。

基础概念

在音频开发中，有一些基础的概念是必须要知道的。

采样率（samplerate）

采样就是把模拟信号数字化的过程，不仅仅是音频需要采样，所有的模拟信号都需要通过采样转换为可以用0101来表示的数字信号，示意图如下所示：

蓝色代表模拟音频信号，红色的点代表采样得到的量化数值。采样频率越高，红色的间隔就越密集，记录这一段音频信号所用的数据量就越大，同时音频质量也就越高。根据奈奎斯特理论，采样频率只要不低于音频信号最高频率的两倍，就可以无损失地还原原始的声音。通常人耳能听到频率范围大约在20Hz～20kHz之间的声音，为了保证声音不失真，采样频率应在40kHz以上。常用的音频采样频率有：8kHz、11.025kHz、22.05kHz、16kHz、37.8kHz、44.1kHz、48kHz、96kHz、192kHz等。

量化精度（位宽）

上图中，每一个红色的采样点，都需要用一个数值来表示大小，这个数值的数据类型大小可以是：4bit、8bit、16bit、32bit等等，位数越多，表示得就越精细，声音质量自然就越好，当然，数据量也会成倍增大。常见的位宽是：8bit 或者 16bit。

声道数（channels）

由于音频的采集和播放是可以叠加的，因此，可以同时从多个音频源采集声音，并分别输出到不同的扬声器，故声道数一般表示声音录制时的音源数量或回放时相应的扬声器数量。单声道（Mono）和双声道（Stereo）比较常见，顾名思义，前者的声道数为1，后者为2。

音频帧（frame）

音频数据是流式的，本身并没有明确的一帧帧的概念，在实际的应用中，为了音频算法处理/传输的方便，一般约定俗成取 2.5 ms ~ 60 ms为单位的数据量为一帧音频。 这个时间被称之为“采样时间”，其长度没有特别的标准。我们可以计算一下一帧音频帧的大小。假设某通道的音频信号是采样率为 8 kHz，位宽为16 bit，20 ms 一帧，双通道，则一帧音频数据的大小为：

1

int size = 8000 x 16bit x 0.02s  x 2 = 5120 bit = 640 byte