【iOS, xcode, WebRTC】更新xcode 8后出现的编译错误

由于公司使用在用的webrtc是xcode 8版本及之前年代的。连通编译脚本和配置在内(gyp),均都是按照xcode 5~8的情况进行写的。

后来macos自动升级到10.14后,xcode 8也就无法运行了,该版本的macos最低也仅支持xcode 9。试着换过xcode command,可惜并不管用,原因就是iPhonseos的sdk无法自行定位到我从xcode 8中抽离出来的目录下。

几种方法无果,开始进入兵来将挡,水来土掩的模式。在新版本xcode中,编译webrtc大致有如下几个问题:

1,ARCHS_STANDARD_INCLUDING_64_BIT 提示不支持

Warning: Ignoring unsupported variable $(ARCHS_STANDARD_INCLUDING_64_BIT)

由于在新版本的xcode中,ARCHS_STANDARD_INCLUDING_64_BIT环境变量已经没有了,所以需要手动修改gyp中引用该变量的地方,均改为arm64

2,initWithUUIDBytes, getUUIDBytes报错

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUUID.h:26:49: error: nullability specifier ‘_Nullable’ cannot be applied to non-pointer type ‘uuid_t’ (aka ‘unsigned char [16]’)
– (instancetype)initWithUUIDBytes:(const uuid_t _Nullable)bytes;
^
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUUID.h:29:30: error: nullability specifier ‘_Nonnull’ cannot be applied to non-pointer type ‘uuid_t’ (aka ‘unsigned char [16]’)
– (void)getUUIDBytes:(uuid_t _Nonnull)uuid;

出现这两个错误的原因,主要是由于这两个函数的申明被加入了_Nullable_Nonnull,打开NSUUID.h文件,把这两个修饰直接去掉即可

3,EAGLContext报错

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk/System/Library/Frameworks/OpenGLES.framework/Headers/EAGLDrawable.h:52:12: error: attributes may not be specified on a category
@interface EAGLContext (EAGLContextDrawableAdditions)

通过比较iphoneos 10 sdk和iphonseos 12 sdk发现,opengl申明有点区别。

进去将OPENGLES_DEPRECATED(ios(2.0, 12.0), tvos(9.0, 12.0))直接注释即可。

 

 

该问题已经恶心我快一年多了,由于当时还有xcode 8可用,所以没有过多去管。今天算是间接把该问题解决了。

【ios、x264】将静态库打包成动态库,链接时的text relocations错误

最近在ios上出现将多个sdk放到一个app时,有各种开源静态库冲突的问题;于是考虑将自己用到的库进行打包成动态库版本,以此解决冲突问题。

在进行打包成动态库时,发现x264问题最大。打包出来的库在链接期出现text relocations错误,网上找了以后发现基本都是进行忽略这个错误,事实上这个错误忽略了没用,app启动时还是会出现相应的crash。

换了几个版本的xcode进行测试,发现x264编译会出现不同情况的告警和错误,根据底部罗列的参考文章,估计xcode的编译器可能也有一些bug。

后来模仿android上的编译方式,在x264里加入了–enable-pic和–disable-asm顺利编译通过,但由于osx和xcode版本的因素,模拟器上的并没有编译出来,仅仅编译了armv7和arm64。

 

参考文章:

MacOSX下编译linphone(text-relocation错误说明)

libxxx.so- text relocations问题的终极解决方案(android)

Linker error when using incremental builds on iPhone

Android Gradle编译so库或运行时出现 text relocations 崩溃的正确解决方法

【设计模式】对代理模式的几点理解-

设计模式一直给我的感觉都是天书一样,一方面理解起来困难。另一方面书上的解释也较为枯燥,况且现在也还有很多号称设计模式大神的出现,也可能间接的让大家对同一个模式有了各种千奇百怪的理解。

设计模式这个东西出现初衷本来就是解决工程问题,而在解决工程问题时,每个人的角度不同,观点也就不同,并且在《head frist 设计模式》中,作者也强调过,没有任何一种模式的选择和使用是正确或者错误的,只有适合与否。同时对设计模式理解有偏差,甚至初学者也才会去讨论某某模式好,某某模式如何。对设计模式理解较为全面,工程经验较为丰富的人,只会说某种模式用起来较为自然。

代理模式可以的重点可以看作主要是屏蔽了实现细节,同时也对任务执行做了一个中转。让两个模块之间进行解耦。

例如一个消息队列的实现,对于消息队列来说,实现可复杂可简单。为了让消息队列的使用者能够更清晰的了解如何使用,首先需要对消息队列的一些内置方法进行屏蔽,在C++中,继承是无法做到这一点的,所以只能通过包装的方式来实现。

因此就产生了代理类来将消息队列的实现类进行包装,让消息队列的使用者更加关注与如何使用,让消息队列的实现者来关注如何实现,而对于代理来说,仅仅需要关注如何流转数据和流程即可。

【C++11,自动变量,迭代】c++11下不同for循环的差别

先看如下代码片段

#include <vecotr>
#include <string>

#include "boost/algorithm/string/split.hpp"
#include "boost/algorithm/string/classification.hpp"
#include "boost/algorithm/string.hpp"

std::vector vStrArray; //里面存着一堆字符串,其中有一个字符串是这样的: " a.kbasdasdsad"

for (auto a : vector)
{
  boost::trim(a);
}
#include
#include

#include "boost/algorithm/string/split.hpp"
#include "boost/algorithm/string/classification.hpp"
#include "boost/algorithm/string.hpp"

std::vector vStrArray; //里面存着一堆字符串,其中有一个字符串是这样的: " a.kbasdasdsad"

for (std::vector::iterator a = vector.begin();
     a != vector.end();
     ++a)
{
  boost::trim(*a);
}

编译环境是vs 2015 update 3
分别执行完以后会发现,A代码片段没有任何变化,B代码片段的” a.kbasdasdsad”变成了”a.kbasdasdsad”。

单步的时候发现,a变量在A代码片段中,实际上是已经对被修改了。后来网上查了几篇资料,怎么也没有找到对auto的详细说明。加上c++ 11每个编译器实现可能存在一定的差异,因此只能认为,在auto修饰的for循环里,变量使用了写时复用的方式来处理。
如果要对vector里面的值进行修改,还是只能使用最原始的迭代器方法。

【h264、baseline、flv】使用baseline做双向强交互直播不利的几点因素

再说baseline做强交互不利因素之前,先说说现在直播的场景情况。

 

场景如上图,推流段不是移动平台,就是PC机。当然最近几年也出现专门用来推流的定制盒子,本质不是一个嵌入式windows,就是一个android设备(android设备较多)。

  • 而对于PC机作为推流端来说其实问题并不大,只要在保证带宽足够理想的情况下,采用264的任何一种profile都能尽可能的做到最大延时接近编码器固有延时的效果。同样对于使用何种容器来说问题都不大。

 

  • 但对于移动设备来说,需要匹配的情景就很多了,主要是由于移动设备的电池续航能力、操作系统小类别太多、整体性能表现。在使用264编解码时,一般尽量采用硬编解码,对于实在没有办法的情况下才使用软编解码。就仅仅一个硬编解码上就存在诸多差异,例如有些profile硬件不支持,或者rom上存在一些问题导致本该支持的profile,支持的不好或者根本不支持。

 

  • 除了上述提到的问题以外,其实还有一个隐形问题,那就是用户使用习惯问题。现在的用户越来越偏向于使用web方式展现的产品,一方面对于开发者来说,界面改动较为简单灵活,另一方面对于用户来说,只需要打开浏览器即可,简化使用步骤。

然而上述提到的这些问题,就造就了可能大家会想到flash、h5和native应用,对于native应用来说还好,开发起来虽然周期长,但可塑性比较强。对于flash和h5来说可选择余地就非常小了。

暂时不说flash和h5本身在做双向强交互直播是否可行,先说一说两者采用的协议类型。对于flash来说:

  • 通讯协议为rtmp系列协议(包括rtmpt等),协议本身并不是太复杂,但涉及当初并不是用来做双向强交互的直播协议,因此协议本身就没有在双向强交互上做太多的考虑。

 

  • 由于协议本身所承载的流媒体容器格式为flv或f4v,现在大部分直播平台基本采用的是flv作为容器,同时flv也是一种较为简单易用的容器

 

  • 但由于flv容器格式的限制,在adobe官方手册中就已经说明,flv容器支持的264的profile范围中,目前仅对baseline、extended、main、high、high10、high4:2:2、high4:4:4,在经过简单测试之后,如果不考虑flash端推流的情况下,用户电脑(移动端一般用h5,不用flash)性能具备一定保证的情况下,再根据官方手册并测试(as3手册),没有实际去测试过high10,不过脑补得知high10也是可以的,但延时太大,也有可能会引起其他flash异常。因此往往最佳的选择就在baseline、main、high中选择,因为他们的颜色编码是8bit的。从解码效率和广泛性来说,这三种都可以。

 

  • 但由于是双向直播,因此,在这时就需要考虑编解码器的时延问题。这时,大家一贯的做法就是关闭B帧编码,这样即可极大的提高编解码延时。当关闭了B帧编码之后,剩下几种profile互相比拼的就是在给定的一个平均分辨率、gop的情况下,编解码固有时延和数据码率,以及支持的广泛性。实测之后发现high其实在不同浏览器的flash上表现存在一定差异,主要情形为编解码速度、性能开销等等。因此在flash上使用high这种方式时,还需要综合考虑。

 

接下来说一说h5方式的直播:

  • h5方式的直播一般是通过websocket进行通讯,协议是hls,容器格式为ts、ps。然而我对hls和ts、ps都不是很了解。

 

  • h5支持还有待进一步推广,目前在较新的chrome系浏览器和较新的firefox浏览器上均支持较好。IE系暂时较弱(我把edge理解成IE系)。

 

  • 就目前来说,从开发手机端开发难度,和各手机厂商的支持力度上,无论是webview app还是native app来说,hls+ps/ts也是较优选择。

 

  • 通过看了苹果官方的FAQ得知,hls协议似乎仅仅支持baseline、main、high三种,不清楚是由于ts、ps容器特性导致的,还是hls协议特点。因此在决定使用哪一种profile时,又回到了和flash一样的情况下。

 

通过以上可以得知,实际上在使用x264编码时,最终在profile的选择上基本就限制在了baseline、main、high三种。从算法复杂度上来上讲,baseline是最为简单,而high是较为最为复杂(主要是预测模型比前两者多不少)。

不过在实际工程应用中,我们还是做了一个比较脑残又没有办法的决定,那就是使用baseline。原因有二:

  1. 我们使用的编码库是openh264,早期版本的openh264宏块分割方式较小,也仅仅支持baseline,对main也只是仅限于试验阶段。
  2. 在同样的profile级别下,参数大致相同的情况下,openh264的编码时延比x264的utral模式下略高,但码率略低(未做定量测试,简单定性测试得到的结论)。编码完的数据解码出来的视觉感受差别不大,反正都是渣画质。

考虑到使用场景和当时网络的大环境,确实选择openh264,即是无奈的选择,也是一个极其脑残的选择。说无奈主要是现实,说脑残是因为压根就没有做过定性分析。。。。。。

然后接下来就开始“数落数落”baseline不适合做双向强交互直播的原因。在看x264的代码时,偶然对编码中的预测做了少许的了解。

—- 我是装逼的分割线 1号 —-

传统上对一副图像的处理,一般的理论是基于“分割”,由于图像一般情况下具有前景和后景之分,也就是说,前景和背景之间存在着大量的局部图像细节,对于图像压缩中的思路往往是,尽量将相似的区域用差别不大的统一一个区域去表达,对于差异较大的区域,尽量在用较多的数据量去存储以此保留图像的局部细节。

那么就会存在如何分割图像的问题。如果是一副简单单值图,例如大学时代我做的非矢量图压缩(理论基础差不多),那么只需要根据图像分辨率,做相应的最佳分割快大小计算,并做简单切割即可。将区域内的有色的点和无色的点进行记录,并按做纵向或横向切割成色带,记录色带中有色点或者无色点的坐标值即可。整个思路转换成代码思维,类似于多级联映射表。当然这个做法的关键还在于公式如何设计,即如何动态计算切割区域的大小。由于是做印章方面,所以图像不会太大,因此公式也非常简单。

最终压缩可以理解成单值图的无损压缩,实测试之后,和转换成矢量图之后的文件大小相比,应该两者都会比现在主流的大部分图像编码小非常多。

接着通过类似7z、rar工具里面的二进制压缩算法进行再次压缩,文件最大还能缩小60%左右。一个500k的位图最终生成文件在3k左右。

—- 我是装逼的分割线 2号 —-

由于有上面的实践基础,因此在理解264的压缩时,我也能够理解到“分割”时的重要性。

首先,在baseline模式下,x264的预测模型相对于其他high来说,非常简单。这样的情况就决定了,在局部的细节切块相比high来说有着很多不足,对二进制数据进行压缩前就已经输在起跑线了。即细节丢失比high多。

其次在编码算法上(或者说压缩算法上),baseline仅仅使用cavlc,而对其他两者来说他们既可以使用cavlc也可以使用cabac。没有做过定性或者定考量分析,但通过网上资料获知,cavlc的效率似乎没有cabac高,具体在哪些指标有所体现目前暂时并不清楚。

因此,可以得知。baseline除了在实时性上满足了双向强交互直播对时间的要求,对于相同质量下的压缩比并不是很好。但又由于baseline相对其他profile的简单特点,其实广泛性还是比较不错的。

手里有台android 2.3时代的三星手机,对baseline的视频进行解码,手机基本可以应付(不清楚是硬解还是软解,因为当时的arm好像还有没有对264硬解做太多优化),但相同视频长度的main和high的话,那就有点头疼了。看来baseline对老旧手机还是比较“良好”的。

【x264、宏块、邻居】x264中对宏块预测方向与邻居类型的定义

在x264中,由于单一宏块预测方向与264规范定义实际上是一直的,即预测方向只有:左(left)、上(top)、左上(left-top)、右上(right-top)。

没有其他的另外四个方向,估计可能是zig-zag的数据排列有关,或只是由于对称关系,不需要做重复预测。

有上述4中预测方向,x264中定义了几种邻居关系(下面拿I帧4×4的宏块距离说明):

  • 垂直方向,即I_PRED_4x4_V、I_PRED_4x4_DC_TOP,实际上是向上方向预测(top)
  • 水平方向,即I_PRED_4x4_H、I_PRED_4x4_HU、I_PRED_4x4_DC_LEFT,实际上是向左方向预测(left)
  • 左边和向上方向,即I_PRED_4x4_DC
  • 向上旋转到右上方向,即I_PRED_4x4_DDL、I_PRED_4x4_VL
  • 左边旋转到向上方向,即I_PRED_4x4_DDR、I_PRED_4x4_VR、I_PRED_4x4_HD
  • 左边旋转到向上方向,即I_PRED_4x4_VL
  • I_PRED_4x4_DC_128代表自身?

【x264、图像量化】像素和亚像素

在看x264代码的时候,总是会看到sad、satd、subpixel。

至于sub pixel这个单词还算比较直观,子像素。当时脑补中的理解是,相邻像素按照不同权重计算出来的一种抽象像素,类似插值像素一样。

后来简单查了一下,才知道这玩意是亚像素。

即像素是感光器件上的实际一个像素点,对于亚像素就是感光器件上像素之间的抽象点。网上说是为了提高器件分辨率的一种抽象,但具体上我也没有实际有多少理解。

【x264、视频、编码、宏块】编码成不同帧时,宏块参数的变化情况

出于好奇最近在看x264的源代码。

对于不管是263、264还265编码来说,图像的压缩大题思路实际上是没有太大变化的。

对图像的压缩和编码,分为相关和非相关部分。又由于263、264、265并没有定义一定是无损压缩,所以在压缩和编码上与音频的编码和压缩也有着相似的处理方式;即,按照人的视觉特性进行编码(人眼分辨画面细节的能力是有限的)。

相关性压缩(和编码)又分为帧内相关和帧间相关,即编码出来的I帧就是我们所说帧内相关,B、P帧则是帧间相关。

对于非相关编码部分,大部分都集中在图像的前期处理上,例如归一化、白平衡、色度调节等。步骤大致如下:

  • 在图像预处理完成后(归一化、降噪等),接下来就是x264较多需要做的事情图像编码与压缩(虽然x264自身也会做一些降噪、再降噪、色度调节等)。
  • 先说编码部分,x264里面先将一副raw数据(可能是yuv420,可能是yv12等等),进行切块(即宏块分割,图像简单预测)。
  • 将分割好的图像在做块内再分割(细节预测,找出图像细节部分,对细节部分在切割,变成小块)
  • 接着又对每一个块做相邻之间的差异化计算(其实就是求出差异),这个过程是最复杂的一个。

 

下面是对于不同类型帧切块分类的说明其他具体的解释会在后续说:

 


 

其中对于不同类型的输出帧,宏块的大小如下:

I帧:

16*16、8*8、4*4


P帧:

L0、8*8、SKIP


B帧:

DIRECT、L0L0、L0L1、L0BI、L1L0、L1L1、L1BI、BIL0、BIL1、BIBI、8*8、SKIP

 


 

 

【webrtc、ios sdk 11、 xcode9】webrtc在xcode 9下的uuid_t编译错误

最近osx环境无意间升级了所有的包,并把xcode升级到了9。按部就班的继续编译之前可以正常编译的webrtc,后来不料,除了这么一个错误:

error: nullability specifier ‘_Nullable’ cannot be applied to non-pointer type ‘uuid_t’ (aka ‘unsigned char [16]’)

 

东查西查。最后就查到了之前的猜测,这里有解释:

https://forums.xamarin.com/discussion/103773/will-there-be-support-for-ios-11-sdk

因为xcode自带的是ios sdk 11的。就目前来说,这一点比较坑人,因为ios sdk 11的库和ios sdk 10的库在部分函数上的定义上有所区别。

而webrtc和相应的depot_tools也是今年年初的,因此使用的第三方clang编译器也相对xcode 9的步调来说老了一些。

为了不想增加麻烦,也就不打算用gclient了,因为当时不是我去拿的webrtc代码,也不知道会不会有坑。就果断把xcode降级为xcode 8。

xcode 8的下载地址:

https://developer.apple.com/download/more/

降级的方法:

http://osxdaily.com/2012/02/20/uninstall-xcode/

 

看来用第三方编译器也是让人比较头疼的一件事情。有时候ios上遇到的坑不比android少。。。

 

【osx、ios、xcode】编译x264、ffmpeg时出现sysroot警告

在编译x264和ffmpeg时会出现警告,截图如下:

实际上在命令行中已经看到,已经通过sysroot设置过目标平台的sdk的位置,但还是报错。通过google发现,新版本的xcode对sysroot参数关键字做了修改,将–sysroot改为-isysroot ,其他不变,编译通过。

【编译、ffmpeg、msvc】windows下编译ffmpeg

由于最近使用的ffmpeg及其相关的库太过于老旧,所以需要进行更新。

对于视频方面的编码主要用到h264,音频则用到mp3、aac、speex。

其中最为坑的,还是mp3和aac。因为mp3中的分支太多,为了简化问题,最后还是选用lamemp3作为编码器。在ffmpeg 3.0开始,ffmpeg就停止了aacplus的使用,改为使用fdk aac。并且ffmpeg还自带了一个aac编码器。

在编译过程中由于没有注意到这个问题,因此使用了内置编码器,导致he aac编码出来的数据缺少sbr段。因此需要外部加入fdk aac来完成。

 

  • 先说一说需要提前做的一些准备:

1、lamemp3源代码

2、speex源代码

3、fdk_aac源代码

4、x264源代码

5、ffmpeg源代码

6、安装msys2极其相应的工具(如果在windows上编译)

7、vs2015(如果在windows上编译)

 

lamemp3编译步骤:

直接代开源代码下vc_solution目录,使用vs2015编译即可

 

speex编译步骤:

打开win32目录下的vs2008直接用vs2015编译即可

 

fdk_aac编译步骤:

fdk_aac编译比较坑,不能在msys2中编译,需要用nmake(vs工具链)直接编译就好……

 

x264编译步骤:

在msys2中直接编译即可

 

ffmpeg编译步骤:

1,将speex、mp3、aac中include的部分代码拷贝到ffmpeg根目录下

2,在将相应的lib文件拷贝到根目录下的某个文件,这里用3rdparty来代表目录

3,执行编译命令

./configure –prefix=/c/work/github/ffmpeg_src_3.2/out –toolchain=msvc –enable-libx264 –enable-libmp3lame –enable-libfdk-aac –enable-nonfree –enable-libspeex –enable-gpl –extra-cflags=-IC:\\work\\github\\ffmpeg_src_3.2 –enable-shared –extra-ldflags=-LIBPATH:C:\\work\\github\\ffmpeg_src_3.2\\3rdparty\\lib

4,执行make和 make install之后即可

 

不要轻易的羡慕所谓的高薪,而是要看时薪、前途和钱途

首先说一下为啥会写这个文章,主要还是因为最近遇到某些大公司的人,实在受不了那种高高在山的样子,以及一些小朋友的各种有色眼镜去看待农民工一个月两万的收入。下面就是正文:

 

 

我现在基本不看高薪职位,更不会向往什么大公司。原因很简单,中过不少招,刚刚从这些坑里爬出来。

首先,一个公司对人力的支出成本大致如下:
1,五险一金及其其他可能有的福利或保险(公司部分)
2,房租、办公用品成本均摊费
3,员工工资以其他奖金

我为什么会知道这些?因为当年在某大公司的时候,我和 hr 混的相对熟,他们告诉我的一种算法。所以说,睡前月薪如果 1w,那么按照五险一金全额缴,公司 1+月薪得到的成本可能是 1.3w 起。

不要带着任何有色眼镜去看农民工,工作无高低贵贱之分。如果你们有兄弟姐妹在工地干活,那么你们将会知道这是一个风险巨大没有任何保障的工作。例如,尘肺病,腰肌劳损等。而我们做办公室的,看似体面,但却是风险和保障上相对会好一些。或者不相信就去查一查快递和外卖行业的送货员年交通事故平均值是多少就知道了。

同时也不要迷信任何高薪,以前大公司流行拿所谓的高薪、期权、股票、多少多少薪来吸引一大堆简历,但一旦成功入职后或者转正后;大部分人经历的将是无休止的加班、办公室政治、价值观、拥抱变化等等。
等年长一些,身体一堆病,最后如果不慎病倒或者去世了,搞不好可能还会被公司恶心一把,甚至还会有其他同事会在各种场合数落你;这就是人性的冷漠!

最近几年中小、微型公司也开始流行大公司的套路了。事实上什么叫做合适的薪水?

看时薪和是否有生活成分,如果被工作占据太多时间,那么在我之前呆过的一家公司里曾有这么一句话:“有命赚钱没命花钱”。

现在的社会越来越世俗和浮躁,人和人之间感情也越来越淡薄,甚至有些人把“利用”和“斗争”当作家常便饭,说到底是啥?物质欲太强烈,月薪 1k 的看着月薪 2k 的,月薪 1w 的看着月薪 2w 的,一山望着一山高而已。

我也是经历了一大堆破事,被迫深陷漩涡之中出来后来明白的。一些打着高薪但时薪低的岗位或者公司,均是耍流氓!

【vs2013、msys2】vs2013命令行环境变量不继承到msys2

编译一些开源的时候不得不需要用到msys2。所以需要现在vs2013的命令行环境中启动msys2环境,这样就可以把vs的命令行环境变量继承到msys2。

目前最新版本的msys2会出现不继承的情况,主要由于msys2 中/etc/profile文件中继承脚本的过滤了vs的一些有效环境,参考csdn上一个博客的修改方法,修改成如下:

 

【该下决心改变系列】扭曲的环境塑造部分扭曲的心理

  • 最近状态还是比较偏向于最自然,为啥?

因为,工作强度、难度、压力、同事关系都在出现很大的缓解和回归自然情况。

  • 不过最近得瑟了不少,为啥?

因为曾经一些让我极其恼火的人和事已经远离我不少,看到他们过得还不如我,或者在走我的曾经走过的老路,我有着一种幸灾乐祸的心理。所以最近也在嘲讽一些人,有一些是具有恶意成分,而另一个是纯粹得瑟成分。

 

  • 为什么会说扭曲的环境塑造扭曲的心理?

从和人打交道的角度去看,原因大致分为两个部分,内因和外因。

先说说内因,内因从我的性格特征来说,其实我的性格属于极其孤僻的性格,不喜欢与人打交道。但由于在成长期吃了不少苦头,另外一些社会经验积累的过程中,我学会了伪装。性格孤僻的很简单,就是包容度不高,出现矛盾或者问题时容易压抑在心里不轻易表达出来,对他人的信任度不高或者说不太容易会轻易的相信人,是一种缺乏安全心理的表现。

再来说说外因,由于内因的因素,导致我看待人和人之间关系的时候基调就倾向于消极的一面。在加上现在的社会相对浮躁和虚伪,所以与我相处的人里面,就不乏一些虚伪和浮躁的人。对待这类人的容忍当然就是更小。

接下来在说一说我环境的实际情况。

由于工作一直没有找到一个稳定的切入点,准确的说不知道自己要做些什么。因为在刚毕业3年左右的那个年头,IT行业还没有想现在这样花样繁多。所以工作找起来还是相对困难一些。后来东找西找,还是找了不少奇葩公司,走了不少弯路。拿我所经历到的同事来说,一般分为这么几类:

1,贼眉鼠眼型,这类人一心想着自己的利益,为了自己的利益会做出一些有害于他人的人

2,报复远大型,这类人心里有着一个或者一群远大的理想和报复,在必要的时候为了自己的理想和报复会很玩命的拼搏

3,投机取巧型,这类人属于习惯性使用小聪明,把小聪明当作一种优势去用。这类人里面猪队友是最多,也是最不听劝,而且是危害最大的,应该远离。

4,老实人,字面意义上的老实人。人挺老实,没什么多余的坏心眼,有时容易被人利用。

5,狂妄型,不解释!

6,应该撒泡尿照照镜子类型,这个也不解释。和狂妄类型的区别在于,这类人有莫名其妙的自我优越感。

7,过的开心就好,也没有太大的理想和报复型,这类人群也是最多的,要说危害,也要看情况。如果在内斗极其严重的地方,那这类人就是定时炸弹,如果是安逸的环境,那么大家关系可以很融洽。

8,大脾气型。这类人如果不是天生性格不好,就有可能是老不自觉的觉得自己是老大哥。这类人的本质不一定坏,但是和他们打配合也挺难,容易出现问题。

9,以上某几类的综合。

就拿最近的工作变动来说,我一直在反思我在上一家单位我得到了什么收益,失去了什么。其实我发现,我获得了技术的成长和学习;我失去了精力和时间,我在不该投入的人和事情上上投入太多。同时由于抗压的薄弱导致一些应急反应的出现,间接影响到了最终的成长步调。

具体说一说我走位的ABCDEFG同事,更能表达清楚情况

A年纪比我大2岁,在某个行业待着不小于5年的时间,时间算漫长的,但技术我不作评价,因为时间的长短不等于技术成长。起初我对这位同事看法也蛮简单,就是跟着学点东西。但是上在面试过程和入职前,这位同事让我感到了他是上述的2+3+8+偏向于5的类型人,当时我就给自己做了思想准备,可能接下来将会是一个比较难熬的日子,因为这个同事可能不太好相处。事实上,确实在我入职一周之后的时间里,随着和他逐渐接触和了解后,我发现这个人确实不太好打交道,并且还渐渐萌生了负面的看法和情绪。其实际原因还在于一些事情的做法和结果上。当然随着后续搭配时间越长,我和他的关系就逐渐形成了一个y=-x的抛物线情形。实际上就在现在已经换了工作以后,我还是觉得不能接受一些当时的做法和结果。

B同事年纪比我小,应该是接近90的人(具体年龄记不清了)。坐在我的边上,人其实还是蛮不错的一个人,人没有坏心眼,不过就是有点固执,思想有些不成熟。在遇到工作上的问题时,有时看不清事情的轻重缓急,有点任性,也没有什么理想和报复,有点得过且过。和他关系算稍微好一点的,其实也不算非常好,有时候还是需要演演戏给周围的同事看(不能让别人觉得我是一个难打交道的人)。事实上在游戏和电子产品上,我们还是有一些共同语言,因此也算得上一个朋友,尽管这个朋友关系不是那么牢靠,当然也是还能保持到现在经常QQ上BB的一个人。这个人偏向于8+4。

C同事,中国几大高考大省出来的人。是一个热情并不热心的人,可能认识他的人都会觉得他是一个热心并不热情或者热心有热情的人。但在我眼里只能算热情的人,因为他做的大部分和热情有关的事情里,我都感到并非那么完全的真诚,似乎存在搞好关系的一种目的在里面,除此之外,我觉得这个人还是缺乏一定礼仪或者教养的人。喜欢窥视他人在做什么,并当面或背着讨论起来;有时在和人大交道的时候缺乏一些成年人之间理应的礼仪。一个很有想法,但又不喜欢和别人分享,有点偏向于2+4

D同事,年纪最小的,90后。也是最瘦的。这个人起初给我的感觉,就似乎看到了当年的自己,各种迷茫;也是有一些性格稍微孤僻的人,并且内心极其有想法且不会轻易和不信任的人说的。固执,有时有点算得上偏执。其实没有太多想评价这位同事的,虽然他平时很少的罪人,但是他给我的感觉是偏向于柴米油盐不进的人,比较喜欢独立思考和遵循自己做法的人。在这群同事里面,我不是最先放弃和他保持长久关系的一个,但也算比较靠前的一个。我只能说,看到曾经的我,我总想唠叨几句,所以有时劝他更多只是说给我自己听而已。这个人偏向于2+8+4(之所以会有8,其实这个哥们的脾气并不小,只不过不会轻易的发出来,一旦发出来就是一团怒火。)

F好像是85年,研究生学历。这个同事其实一开始给我的感觉就非常不好,来这里不到一个星期就把我小小的得罪了;当然这都不是问题,最大的问题还是这个人和人打交道的时候太过于滑头,但自己又喜欢按照自己认为的简单的方式去进行。在他身上我看到了一种畸形的技能,他身上有着商人、公务的老油条特点,但又喜欢按照自己所谓的简单方式方法去做,这一点太过于矛盾,在后续和他搭配和的过程里也真的找了不少麻烦。这个人同事关系走的算近的,但并不是很好。确切的形容应该是貌合神离,因为我内心中巴不得赶快远离这个人,太累了。这个人偏向于3+7

G年纪比我大,起初给我的感觉是不太好接近,人也比较固执。做事情一板一眼看似挺认真的,但不太动客观的脑子;我的意思就是说,明明很简单的一件事情,这个同事非要按照自己的方式方法去理解,结果要绕一个大圈圈才能回来。;有时还会带着自己狭隘的思想去理解和处理。后期处理也在这些问题上遇到了不少问题。这个人偏向于8+7

在这个畸形的环境里,我一直梦想着大家能够有所协调的开展工作减轻我的压力。但事实上我浪费太多时间了,为什么?因为这里面有些人获得收益了,他不会觉得是你带来的,只会觉得你反感;还有一些人是基本不听,直接对着干;也有一些人在里面当了渔翁。一个畸形的环境(这里的环境除了工作环境,还有大家的性格特征)塑造畸形的关系;站在今天的角度去看,没有必要,一点必要都没有,但话说回来正因为我走了这个弯路,我又学会了看一些类型的人和对这类人的处理方式、方法;多少也算是一种成长,也算是一种欣慰。

【winxp、vista、webrtc、chromium】放弃支持xp的路上webrtc跟上了!

最近拿了59的分支代码,后来偶然看到webrtc把wavein/waveout函数族相关的代码删除掉,看git注释另外根据chrome弃疗的心语路程,webrtc终于放弃xp了。

但苦了我了。。。。。。因为国内还有着一大群xp用户。。。。