之前在做直播产品的时候，有个需求：弹幕列表在滑入滑出的时候要有渐变效果。当时想了几种方案但是都没有做到满意的效果，后面便搁置了。直到我看到了这个库：Android任意View边沿渐变透明，看了下效果，正是我当时需要的。虽然时过境迁，现在没有在意这个需求了，但是从心底里还是想知道它是如何实现的。

对，已经是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的设备，然后再通过一个高速的连接进行互相通信，并且这个连接的有效距离要比蓝牙连接的有效距离要长的多。这对于需要在用户之间共享数据的应用程序非常有用，例如多玩家游戏或者照片分享之类应用。