注册
环信即时通讯云

环信即时通讯云

单聊、群聊、聊天室...
环信开发文档

环信开发文档

Demo体验

Demo体验

场景Demo,开箱即用
RTE开发者社区

RTE开发者社区

汇聚音视频领域技术干货,分享行业资讯
技术讨论区

技术讨论区

技术交流、答疑
资源下载

资源下载

收集了海量宝藏开发资源
iOS Library

iOS Library

不需要辛辛苦苦的去找轮子, 这里都有
Android Library

Android Library

不需要辛辛苦苦的去找轮子, 这里都有

iOS开发性能监控

App 的性能问题虽然不会导致 App不可用,但依然会影响到用户体验。如果这个性能问题不断累积,达到临界点以后,问题就会爆发出来。这时,影响到的就不仅仅是用户了,还有负责App开发的你。线下性能监控其中线下监控使用的还是Instruments,Instrume...
继续阅读 »

App 的性能问题虽然不会导致 App不可用,但依然会影响到用户体验。如果这个性能问题不断累积,达到临界点以后,问题就会爆发出来。这时,影响到的就不仅仅是用户了,还有负责App开发的你。

线下性能监控

其中线下监控使用的还是Instruments,Instruments功能很强大,下图是Instruments的各种性能检测工具。


最新版本的Instruments 10还有以下两大优势:

1.Instruments基于os_signpost 架构,可以支持所有平台。

2.Instruments由于标准界面(Standard UI)和分析核心(Analysis Core)技术,使得我们可以非常方便地进行自定义性能监测工具的开发。当你想要给Instruments内置的工具换个交互界面,或者新创建一个工具的时候,都可以通过自定义工具这个功能来实现。

从整体架构来看,Instruments 包括Standard UI 和 Analysis Core 两个组件,它的所有工具都是基于这两个组件开发的。而且,你如果要开发自定义的性能分析工具的话,完全基于这两个组件就可以实现。

开发一款自定义Instruments工具,主要包括以下这几个步骤:

1.在Xcode中,点击File > New > Project;

2.在弹出的Project模板选择界面,将其设置为macOS;

3.选择 Instruments Package,点击后即可开始自定义工具的开发了。如下图所示。


经过上面的三步之后,会在新创建的工程里面生成一个.instrpkg 文件,接下来的开发过程主要就是对这个文件的配置工作了。这些配置工作中最主要的是要完成Standard UI 和 Analysis Core 的配置。

上面这些内容,就是你在开发一个自定义Instruments工具时,需要完成的编码工作了。可以看到,Instruments 10版本的自定义工具开发还是比较简单的。与此同时,苹果公司还提供了大量的代码片段,帮助你进行个性化的配置。你可以点击这个链接,查看官方指南中的详细教程。

再说一下,线上性能监控

对于线上性能监控,我们需要先明白两个原则:
1、监控代码不要侵入到业务代码中;
2、采用性能消耗最小的监控方案。

接下来我们从CPU使用率、FPS的帧率和内存这三个方面,说一下线上性能监控

CPU使用率的线上监控方法

App作为进程运行起来后会有多个线程,每个线程对CPU 的使用率不同。各个线程对CPU使用率的总和,就是当前App对CPU 的使用率。明白了这一点以后,我们也就摸清楚了对CPU使用率进行线上监控的思路。

在iOS系统中,你可以在 usr/include/mach/thread_info.h 里看到线程基本信息的结构体,其中的cpu_usage 就是 CPU使用率。结构体的完整代码如下所示:

struct thread_basic_info {
time_value_t user_time; // 用户运行时长
time_value_t system_time; // 系统运行时长
integer_t cpu_usage; // CPU 使用率
policy_t policy; // 调度策略
integer_t run_state; // 运行状态
integer_t flags; // 各种标记
integer_t suspend_count; // 暂停线程的计数
integer_t sleep_time; // 休眠的时间
};

因为每个线程都会有这个 thread_basic_info 结构体,所以接下来的事情就好办了,你只需要定时(比如,将定时间隔设置为2s)去遍历每个线程,累加每个线程的 cpu_usage 字段的值,就能够得到当前App所在进程的 CPU 使用率了。实现代码如下:

- (integer_t)cpuUsage {
thread_act_array_t threads; //int 组成的数组比如 thread[1] = 5635
mach_msg_type_number_t threadCount = 0; //mach_msg_type_number_t 是 int 类型
const task_t thisTask = mach_task_self();
//根据当前 task 获取所有线程
kern_return_t kr = task_threads(thisTask, &threads, &threadCount);

if (kr != KERN_SUCCESS) {
return 0;
}

integer_t cpuUsage = 0;
// 遍历所有线程
for (int i = 0; i < threadCount; i++) {

thread_info_data_t threadInfo;
thread_basic_info_t threadBaseInfo;
mach_msg_type_number_t threadInfoCount = THREAD_INFO_MAX;

if (thread_info((thread_act_t)threads[i], THREAD_BASIC_INFO, (thread_info_t)threadInfo, &threadInfoCount) == KERN_SUCCESS) {
// 获取 CPU 使用率
threadBaseInfo = (thread_basic_info_t)threadInfo;
if (!(threadBaseInfo->flags & TH_FLAGS_IDLE)) {
cpuUsage += threadBaseInfo->cpu_usage;
}
}
}
assert(vm_deallocate(mach_task_self(), (vm_address_t)threads, threadCount * sizeof(thread_t)) == KERN_SUCCESS);
return cpuUsage;
}

在上面这段代码中,task_threads 方法能够取到当前进程中的线程总数 threadCount 和所有线程的数组 threads。

接下来,我们就可以通过遍历这个数组来获取单个线程的基本信息。其中,线程基本信息的结构体是 thread_basic_info_t,这个结构体里就包含了我们需要的 CPU 使用率的字段 cpu_usage。然后,我们累加这个字段就能够获取到当前的整体 CPU 使用率。

接下来我们说说关于FPS的监控

FPS 线上监控方法

FPS 是指图像连续在显示设备上出现的频率。FPS低,表示App不够流畅,还需要进行优化。

但是,和前面对CPU使用率和内存使用量的监控不同,iOS系统中没有一个专门的结构体,用来记录与FPS相关的数据。但是,对FPS的监控也可以比较简单的实现:通过注册 CADisplayLink 得到屏幕的同步刷新率,记录每次刷新时间,然后就可以得到 FPS。具体的实现代码如下:

- (void)startMonitoring {
if (_link) {
[_link removeFromRunLoop:[NSRunLoop mainRunLoop] forMode:NSRunLoopCommonModes];
[_link invalidate];
_link = nil;
}
_link = [CADisplayLink displayLinkWithTarget:self selector:@selector(fpsDisplayLinkAction:)];
[_link addToRunLoop:[NSRunLoop mainRunLoop] forMode:NSRunLoopCommonModes];
}

- (void)fpsDisplayLinkAction:(CADisplayLink *)link {
if (_lastTime == 0) {
_lastTime = link.timestamp;
return;
}

self.count++;
NSTimeInterval delta = link.timestamp - _lastTime;
if (delta < 1) return;
_lastTime = link.timestamp;
_fps = _count / delta;
NSLog(@"count = %d, delta = %f,_lastTime = %f, _fps = %.0f",_count, delta, _lastTime, _fps);
self.count = 0;
}


内存使用量的线上监控方法


通常情况下,我们在获取 iOS 应用内存使用量时,都是使用task_basic_info 里的 resident_size 字段信息。但是,我们发现这样获得的内存使用量和 Instruments 里看到的相差很大。后来,在 2018 WWDC Session 416 iOS Memory Deep Dive中,苹果公司介绍说 phys_footprint 才是实际使用的物理内存。


内存信息存在 task_info.h (完整路径 usr/include/mach/task.info.h)文件的 task_vm_info 结构体中,其中phys_footprint 就是物理内存的使用,而不是驻留内存 resident_size。结构体里和内存相关的代码如下:

struct task_vm_info {
mach_vm_size_t virtual_size; // 虚拟内存大小
integer_t region_count; // 内存区域的数量
integer_t page_size;
mach_vm_size_t resident_size; // 驻留内存大小
mach_vm_size_t resident_size_peak; // 驻留内存峰值

...

/* added for rev1 */
mach_vm_size_t phys_footprint; // 物理内存

...

我们只要从这个结构体里取出phys_footprint 字段的值,就能够监控到实际物理内存的使用情况了。具体实现代码如下:

- (unsigned long)memoryUsage {    
task_vm_info_data_t vmInfo;
mach_msg_type_number_t count = TASK_VM_INFO_COUNT;
kern_return_t result = task_info(mach_task_self(), TASK_VM_INFO, (task_info_t) &vmInfo, &count);
if (result != KERN_SUCCESS)
return 0;
return vmInfo.phys_footprint;
}

从以上三个线上性能监控方案可以看出,它们的代码和业务逻辑是完全解耦的,监控时基本都是直接获取系统本身提供的数据,没有额外的计算量,因此对 App 本身的性能影响也非常小,满足了我们要考虑的两个原则。

你可以点击这个链接,查看具体demo,欢迎大家点赞。

链接:https://www.jianshu.com/p/cc02a1e1e019

收起阅读 »

CocoaAsyncSocket源码分析---Connect (八)

Connect流程,用一张图来概括总结一下吧:socketchildSocketFD = accept(parentSocketFD, (struct sockaddr *)&addr, &addrLen); 然后调用了newSocketQue...
继续阅读 »

客户端的整个Connect流程,用一张图来概括总结一下吧:



整个客户端连接的流程大致如上图,当然远不及于此,这里我们对地址做了IPV4IPV6的兼容处理,对一些使用socket而产生的网络错误导致进程退出的容错处理。以及在这个过程中,socketQueue、代理queue、全局并发queuestream常驻线程的管理调度等等。

当然其中绝大部分操作都是在socketQueue中进行的。而在socketQueue中,我们也分为两种操作dispatch_syncdispatch_async
因为socketQueue本身就是一个串行queue,所以我们所有的操作都在这个queue中进行保证了线程安全,而需要阻塞后续行为的操作,我们用了sync的方式。其实这样使用sync是及其容易死锁的,但是作者每次在调用sync之前都调用了这么一行判断:

if (dispatch_get_specific(IsOnSocketQueueOrTargetQueueKey))

判断当前队列是否就是这个socketQueue队列,如果是则直接调用,否则就用sync的方式提交到这个queue中去执行。这种防死锁的方式,你学到了么?

接着我们来讲讲服务端Accept流程:

整个流程还是相对Connect来说还是十分简单的,因为这个方法很长,而且大多数是我们直接连接讲到过得内容,所以我省略了一部分的代码,只把重要的展示出来,大家可以参照着源码看。

//监听端口起点
- (BOOL)acceptOnPort:(uint16_t)port error:(NSError **)errPtr
{
return [self acceptOnInterface:nil port:port error:errPtr];
}

- (BOOL)acceptOnInterface:(NSString *)inInterface port:(uint16_t)port error:(NSError **)errPtr
{
LogTrace();

// Just in-case interface parameter is immutable.
//防止参数被修改
NSString *interface = [inInterface copy];

__block BOOL result = NO;
__block NSError *err = nil;

// CreateSocket Block
// This block will be invoked within the dispatch block below.
//创建socket的Block
int(^createSocket)(int, NSData*) = ^int (int domain, NSData *interfaceAddr) {

//创建TCP的socket
int socketFD = socket(domain, SOCK_STREAM, 0);

//一系列错误判断
...
// Bind socket
//用本地地址去绑定
status = bind(socketFD, (const struct sockaddr *)[interfaceAddr bytes], (socklen_t)[interfaceAddr length]);

//监听这个socket
//第二个参数是这个端口下维护的socket请求队列,最多容纳的用户请求数。
status = listen(socketFD, 1024);
return socketFD;
};

// Create dispatch block and run on socketQueue

dispatch_block_t block = ^{ @autoreleasepool {

//一系列错误判断
...

//判断ipv4 ipv6是否支持
...

//得到本机的IPV4 IPV6的地址
[self getInterfaceAddress4:&interface4 address6:&interface6 fromDescription:interface port:port];
...

//判断可以用IPV4还是6进行请求
...

// Create accept sources
//创建接受连接被触发的source
if (enableIPv4)
{
//接受连接的source
accept4Source = dispatch_source_create(DISPATCH_SOURCE_TYPE_READ, socket4FD, 0, socketQueue);

//事件句柄
dispatch_source_set_event_handler(accept4Source, ^{ @autoreleasepool {

//拿到数据,连接数
unsigned long numPendingConnections = dispatch_source_get_data(acceptSource);

LogVerbose(@"numPendingConnections: %lu", numPendingConnections);

//循环去接受这些socket的事件(一次触发可能有多个连接)
while ([strongSelf doAccept:socketFD] && (++i < numPendingConnections));

}});

//取消句柄
dispatch_source_set_cancel_handler(accept4Source, ^{
//...
//关闭socket
close(socketFD);

});

//开启source
dispatch_resume(accept4Source);
}

//ipv6一样
...

//在scoketQueue中同步做这些初始化。
if (dispatch_get_specific(IsOnSocketQueueOrTargetQueueKey))
block();
else
dispatch_sync(socketQueue, block);

//...错误判断
//返回结果
return result;
}

这个方法省略完仍然有这么长,它主要做了这两件事(篇幅原因,尽量精简):

  1. 创建本机地址、创建socket、绑定端口、监听端口。
  2. 创建了一个GCD Source,来监听这个socket读source,这样连接事件一发生,就会触发我们的事件句柄。接着我们调用了doAccept:方法循环去接受所有的连接。

接着我们来看这个接受连接的方法(同样省略了一部分不那么重要的代码):

//连接接受的方法
- (BOOL)doAccept:(int)parentSocketFD
{
LogTrace();

int socketType;
int childSocketFD;
NSData *childSocketAddress;

//IPV4
if (parentSocketFD == socket4FD)
{
socketType = 0;

struct sockaddr_in addr;
socklen_t addrLen = sizeof(addr);
//调用接受,得到接受的子socket
childSocketFD = accept(parentSocketFD, (struct sockaddr *)&addr, &addrLen);
//NO说明没有连接
if (childSocketFD == -1)
{
LogWarn(@"Accept failed with error: %@", [self errnoError]);
return NO;
}
//子socket的地址数据
childSocketAddress = [NSData dataWithBytes:&addr length:addrLen];
}
//一样
else if (parentSocketFD == socket6FD)
{
...
}
//unix domin socket 一样
else // if (parentSocketFD == socketUN)
{
...
}

//socket 配置项的设置... 和connect一样

//响应代理
if (delegateQueue)
{
__strong id theDelegate = delegate;
//代理队列中调用
dispatch_async(delegateQueue, ^{ @autoreleasepool {

// Query delegate for custom socket queue

dispatch_queue_t childSocketQueue = NULL;

//判断是否实现了为socket 生成一个新的SocketQueue,是的话拿到新queue
if ([theDelegate respondsToSelector:@selector(newSocketQueueForConnectionFromAddress:onSocket:)])
{
childSocketQueue = [theDelegate newSocketQueueForConnectionFromAddress:childSocketAddress
onSocket:self];
}

// Create GCDAsyncSocket instance for accepted socket
//新创建一个本类实例,给接受的socket
GCDAsyncSocket *acceptedSocket = [[[self class] alloc] initWithDelegate:theDelegate
delegateQueue:delegateQueue
socketQueue:childSocketQueue];
//IPV4 6 un
if (socketType == 0)
acceptedSocket->socket4FD = childSocketFD;
else if (socketType == 1)
acceptedSocket->socket6FD = childSocketFD;
else
acceptedSocket->socketUN = childSocketFD;
//标记开始 并且已经连接
acceptedSocket->flags = (kSocketStarted | kConnected);

// Setup read and write sources for accepted socket
//初始化读写source
dispatch_async(acceptedSocket->socketQueue, ^{ @autoreleasepool {

[acceptedSocket setupReadAndWriteSourcesForNewlyConnectedSocket:childSocketFD];
}});

//判断代理是否实现了didAcceptNewSocket方法,把我们新创建的socket返回出去
if ([theDelegate respondsToSelector:@selector(socket:didAcceptNewSocket:)])
{
[theDelegate socket:self didAcceptNewSocket:acceptedSocket];
}

}});
}
return YES;
}

  • 这个方法很简单,核心就是调用下面这个函数,去接受连接,并且拿到一个新的socket
childSocketFD = accept(parentSocketFD, (struct sockaddr *)&addr, &addrLen);

  • 然后调用了newSocketQueueForConnectionFromAddress:onSocket:这个代理,可以为新的socket重新设置一个socketQueue
  • 接着我们用这个Socket重新创建了一个GCDAsyncSocket实例,然后调用我们的代理didAcceptNewSocket方法,把这个实例给传出去了。
  • 这里需要注意的是,我们调用didAcceptNewSocket代理方法传出去的实例我们需要自己保留,不然就会被释放掉,那么这个与客户端的连接也就断开了。
  • 同时我们还初始化了这个新socket的读写source,这一步完全和connect中一样,调用同一个方法,这样如果有读写数据,就会触发这个新的socketsource了。

建立连接之后的无数个新的socket,都是独立的,它们处理读写连接断开的逻辑就和客户端socket完全一样了。
而我们监听本机端口的那个socket始终只有一个,这个用来监听触发socket连接,并返回创建我们这无数个新的socket实例。

作为服务端的Accept流程就这么结束了,因为篇幅原因,所以尽量精简了一些细节的处理,不过这些处理在Connect中也是反复出现的,所以基本无伤大雅。如果大家会感到困惑,建议下载github中的源码注释,对照着再看一遍,相信会有帮助的。


接着我们来讲讲Unix Domin Socket建立本地进程通信流程:

基本上这个流程,比上述任何流程还要简单,简单的到即使不简化代码,也没多少行(当然这是建立在客户端Connect流程已经实现了很多公用方法的基础上)。

接着进入正题,我们来看看它发起连接的方法:


//连接本机的url上,IPC,进程间通信
- (BOOL)connectToUrl:(NSURL *)url withTimeout:(NSTimeInterval)timeout error:(NSError **)errPtr;
{
LogTrace();

__block BOOL result = NO;
__block NSError *err = nil;

dispatch_block_t block = ^{ @autoreleasepool {

//判断长度
if ([url.path length] == 0)
{
NSString *msg = @"Invalid unix domain socket url.";
err = [self badParamError:msg];

return_from_block;
}

// Run through standard pre-connect checks
//前置的检查
if (![self preConnectWithUrl:url error:&err])
{
return_from_block;
}

// We've made it past all the checks.
// It's time to start the connection process.

flags |= kSocketStarted;

// Start the normal connection process

NSError *connectError = nil;
//调用另一个方法去连接
if (![self connectWithAddressUN:connectInterfaceUN error:&connectError])
{
[self closeWithError:connectError];

return_from_block;
}

[self startConnectTimeout:timeout];

result = YES;
}};

//在socketQueue中同步执行
if (dispatch_get_specific(IsOnSocketQueueOrTargetQueueKey))
block();
else
dispatch_sync(socketQueue, block);

if (result == NO)
{
if (errPtr)
*errPtr = err;
}

return result;
}

连接方法非常简单,就只是做了一些错误的处理,然后调用了其他的方法,包括一个前置检查,这检查中会去判断各种参数是否正常,如果正常会返回YES,并且把url转换成Uinix domin socket地址的结构体,赋值给我们的属性connectInterfaceUN
接着调用了connectWithAddressUN方法去发起连接。

我们接着来看看这个方法:

//连接Unix域服务器
- (BOOL)connectWithAddressUN:(NSData *)address error:(NSError **)errPtr
{
LogTrace();

NSAssert(dispatch_get_specific(IsOnSocketQueueOrTargetQueueKey), @"Must be dispatched on socketQueue");

// Create the socket

int socketFD;

LogVerbose(@"Creating unix domain socket");

//创建本机socket
socketUN = socket(AF_UNIX, SOCK_STREAM, 0);

socketFD = socketUN;

if (socketFD == SOCKET_NULL)
{
if (errPtr)
*errPtr = [self errnoErrorWithReason:@"Error in socket() function"];

return NO;
}

// Bind the socket to the desired interface (if needed)

LogVerbose(@"Binding socket...");

int reuseOn = 1;
//设置可复用
setsockopt(socketFD, SOL_SOCKET, SO_REUSEADDR, &reuseOn, sizeof(reuseOn));

// Prevent SIGPIPE signals

int nosigpipe = 1;
//进程终止错误信号禁止
setsockopt(socketFD, SOL_SOCKET, SO_NOSIGPIPE, &nosigpipe, sizeof(nosigpipe));

// Start the connection process in a background queue

int aStateIndex = stateIndex;

dispatch_queue_t globalConcurrentQueue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
dispatch_async(globalConcurrentQueue, ^{

const struct sockaddr *addr = (const struct sockaddr *)[address bytes];
//并行队列调用连接
int result = connect(socketFD, addr, addr->sa_len);
if (result == 0)
{
dispatch_async(socketQueue, ^{ @autoreleasepool {
//连接成功的一些状态初始化
[self didConnect:aStateIndex];
}});
}
else
{
// 失败的处理
perror("connect");
NSError *error = [self errnoErrorWithReason:@"Error in connect() function"];

dispatch_async(socketQueue, ^{ @autoreleasepool {

[self didNotConnect:aStateIndex error:error];
}});
}
});

LogVerbose(@"Connecting...");

return YES;
}

主要部分基本和客户端连接相同,并且简化了很多,调用了这一行完成了连接:

int result = connect(socketFD, addr, addr->sa_len);

同样也和客户端一样,在连接成功之后去调用下面这个方法完成了一些资源的初始化:

 [self didConnect:aStateIndex];

基本上连接就这么两个方法了(当然我们省略了一些细节),看完客户端的连接之后,到这就变得非常简单了。

接着我们来看看uinix domin socket作为服务端Accept。

这个Accpet,基本和我们普通Socket服务端的Accept相同。

//接受一个Url,uniex domin socket 做为服务端
- (BOOL)acceptOnUrl:(NSURL *)url error:(NSError **)errPtr;
{
LogTrace();

__block BOOL result = NO;
__block NSError *err = nil;

//基本和正常的socket accept一模一样
// CreateSocket Block
// This block will be invoked within the dispatch block below.
//生成一个创建socket的block,创建、绑定、监听
int(^createSocket)(int, NSData*) = ^int (int domain, NSData *interfaceAddr) {

//creat socket
...
// Set socket options

...
// Bind socket

...

// Listen
...
};

// Create dispatch block and run on socketQueue
//错误判断
dispatch_block_t block = ^{ @autoreleasepool {

//错误判断
...

//判断是否有这个url路径是否正确
...

//调用上面的Block创建socket,并且绑定监听。
...

//创建接受连接的source
acceptUNSource = dispatch_source_create(DISPATCH_SOURCE_TYPE_READ, socketUN, 0, socketQueue);

int socketFD = socketUN;
dispatch_source_t acceptSource = acceptUNSource;
//事件句柄,和accpept一样
dispatch_source_set_event_handler(acceptUNSource, ^{ @autoreleasepool {
//循环去接受所有的每一个连接
...
}});

//取消句柄
dispatch_source_set_cancel_handler(acceptUNSource, ^{

//关闭socket
close(socketFD);
});

LogVerbose(@"dispatch_resume(accept4Source)");
dispatch_resume(acceptUNSource);

flags |= kSocketStarted;

result = YES;
}};

if (dispatch_get_specific(IsOnSocketQueueOrTargetQueueKey))
block();
else
dispatch_sync(socketQueue, block);
//填充错误
if (result == NO)
{
LogInfo(@"Error in accept: %@", err);

if (errPtr)
*errPtr = err;
}

return result;
}

因为代码基本雷同,所以我们省略了大部分代码,大家可以参照着之前的讲解或者源码去理解。这里和普通服务端socket唯一的区别就是,这里服务端绑定的地址是unix domin socket类型的地址,它是一个结构体,里面包含的是我们进行进程通信的纽带-一个本机文件路径。
所以这里服务端简单来说就是绑定的这个文件路径,当这个文件路径有数据可读(即有客户端连接到达)的时候,会触发初始化的source事件句柄,我们会去循环的接受所有的连接,并且新生成一个socket实例,这里和普通的socket完全一样。

就这样我们所有的连接方式已经讲完了,后面这两种方式,为了节省篇幅,确实讲的比较粗略,但是核心的部分都有提到。
另外如果你有理解客户端的Connect流程,那么理解起来应该没有什么问题,这两个流程比前者可简化太多了。


这个框架的Connect篇 全篇结束














收起阅读 »

CocoaAsyncSocket源码分析---Connect (七)

addStreamsToRunLoop这里方法做了两件事:CFStream读写回调的常驻线程,其中调用了好几个函数: + (void)startCFStreamThreadIfNeeded; + (void)cfstreamThread; 在这两个函数中,添...
继续阅读 »

接着我们来到流处理的第三步:addStreamsToRunLoop-添加到runloop上。

Stream相关方法三 -- 加到当前线程的runloop上:

//把stream添加到runloop上
- (BOOL)addStreamsToRunLoop
{
LogTrace();

NSAssert(dispatch_get_specific(IsOnSocketQueueOrTargetQueueKey), @"Must be dispatched on socketQueue");
NSAssert((readStream != NULL && writeStream != NULL), @"Read/Write stream is null");

//判断flag里是否包含kAddedStreamsToRunLoop,没添加过则添加。
if (!(flags & kAddedStreamsToRunLoop))
{
LogVerbose(@"Adding streams to runloop...");

[[self class] startCFStreamThreadIfNeeded];
//在开启的线程中去执行,阻塞式的
[[self class] performSelector:@selector(scheduleCFStreams:)
onThread:cfstreamThread
withObject:self
waitUntilDone:YES];

//添加标识
flags |= kAddedStreamsToRunLoop;
}

return YES;
}


这里方法做了两件事:

  1. 开启了一条用于CFStream读写回调的常驻线程,其中调用了好几个函数:
 + (void)startCFStreamThreadIfNeeded;
+ (void)cfstreamThread;

在这两个函数中,添加了一个runloop,并且绑定了一个定时器事件,让它run起来,使得线程常驻。

  1. 在这个常驻线程中去调用注册方法:
//注册CFStream
+ (void)scheduleCFStreams:(GCDAsyncSocket *)asyncSocket
{
LogTrace();

//断言当前线程是cfstreamThread,不是则报错
NSAssert([NSThread currentThread] == cfstreamThread, @"Invoked on wrong thread");

//获取到runloop
CFRunLoopRef runLoop = CFRunLoopGetCurrent();
//如果有readStream
if (asyncSocket->readStream)
//注册readStream在runloop的kCFRunLoopDefaultMode上
CFReadStreamScheduleWithRunLoop(asyncSocket->readStream, runLoop, kCFRunLoopDefaultMode);

//一样
if (asyncSocket->writeStream)
CFWriteStreamScheduleWithRunLoop(asyncSocket->writeStream, runLoop, kCFRunLoopDefaultMode);
}

这里可以看到,我们流的回调都是在这条流的常驻线程中,至于为什么要这么做,相信大家楼主看过AFNetworking系列文章的会明白。我们之后文章也会就这个框架线程的问题详细讨论的,这里就暂时不详细说明了。
这里主要用了CFReadStreamScheduleWithRunLoop函数完成了runloop的注册:

CFReadStreamScheduleWithRunLoop(asyncSocket->readStream, runLoop, kCFRunLoopDefaultMode);
CFWriteStreamScheduleWithRunLoop(asyncSocket->writeStream, runLoop, kCFRunLoopDefaultMode);

这样,如果stream中有我们监听的事件发生了,就会在这个runloop中触发我们之前设置的读写回调函数。

我们完成了注册,接下来我们就需要打开stream了:

Stream相关方法四 -- 打开stream:

//打开stream
- (BOOL)openStreams
{
LogTrace();

NSAssert(dispatch_get_specific(IsOnSocketQueueOrTargetQueueKey), @"Must be dispatched on socketQueue");
//断言读写stream都不会空
NSAssert((readStream != NULL && writeStream != NULL), @"Read/Write stream is null");

//返回stream的状态

CFStreamStatus readStatus = CFReadStreamGetStatus(readStream);
CFStreamStatus writeStatus = CFWriteStreamGetStatus(writeStream);

//如果有任意一个没有开启
if ((readStatus == kCFStreamStatusNotOpen) || (writeStatus == kCFStreamStatusNotOpen))
{
LogVerbose(@"Opening read and write stream...");

//开启
BOOL r1 = CFReadStreamOpen(readStream);
BOOL r2 = CFWriteStreamOpen(writeStream);

//有一个开启失败
if (!r1 || !r2)
{
LogError(@"Error in CFStreamOpen");
return NO;
}
}

return YES;
}

方法也很简单,通过CFReadStreamGetStatus函数,获取到当前stream的状态,判断没开启则调用CFReadStreamOpen函数去开启,如果开启失败,错误返回。

到这里stream初始化相关的工作就做完了,接着我们还是回到本文方法十一 -- 连接成功后的初始化中

其中第5条,我们谈到了设置socket的I/O模式为非阻塞,相信很多朋友对socket的I/O:同步、异步、阻塞、非阻塞。这四个概念有所混淆。
简单的来说,同步、异步是对于客户端而言的。比如我发起一个调用一个函数,我如果直接去调用,那么就是同步的,否则新开辟一个线程去做,那么对于当前线程而言就是异步的。
阻塞和非阻塞是对于服务端而言。当服务端被客户端调用后,我如果立刻返回调用的结果(无论数据是否处理完)那么就是非阻塞的,又或者等待数据拿到并且处理完(总之一系列逻辑)再返回,那么这种情况就是阻塞的。

好了,有了这个概念,我们接下来看看Linux下的5种I/O模型:
1)阻塞I/O(blocking I/O)
2)非阻塞I/O (nonblocking I/O)

  1. I/O复用(select 和poll) (I/O multiplexing)
    4)信号驱动I/O (signal driven I/O (SIGIO))
    5)异步I/O (asynchronous I/O (the POSIX aio_functions))

我们来简单谈谈这5种模型:
1)阻塞I/O:
简单举个例子,比如我们调用read()去读取消息,如果是在阻塞模式下,我们会一直等待,直到有消息到来为止。
很多小伙伴可能又要说了,这有什么不可以,我们新开辟一条线程,让它等着不就行了,看起来确实没什么不可以。
那是因为你仅仅是站在客户端的角度上来看。试想如果我们服务端也这么做,那岂不是有多少个socket连接,我们得开辟多少个线程去做阻塞IO?
2)非阻塞I/O
于是就有了非阻塞的概念,当我们去read()的时候,直接返回结果,这样在很大概率下,是并没有消息给我们读的。这时候函数就会错误返回-1,并将errno设置为 EWOULDBLOCK,意为IO并没有数据。
这时候就需要我们自己有一个机制,能知道什么时候有数据,在去调用read()。有一个很傻的方式就是不停的循环去调用这个函数,这样有数据来,我们第一时间就读到了。
3)I/O复用模式
I/O复用模式阻塞I/O的改进版,它在read之前,会先去调用select去遍历所有的socket,看哪一个有消息。当然这个过程是阻塞的,直到有消息返回为止。然后在去调用read,阻塞的方式去读取从系统内核中去读取这条消息到进程中来。
4)信号驱动I/O
信号驱动I/O是一个半异步的I/O模式,它首先会调用一个系统sginal相关的函数,把socket和信号绑定起来,然后不管有没有消息直接返回(这一步非阻塞)。这时候系统内核会去检查socket是否有可用数据。有的话则发送该信号给进程,然后进程在去调用read阻塞式的从系统内核读取数据到进程中来(这一步阻塞)。
5)可能聪明的你已经想到了更好的解决方式,这就对了,这就是我们第5种IO模式:异步I/O ,它和第4步一样,也是调用sginal相关函数,把socket和信号绑定起来,同时绑定起来的还有一块数据缓冲区buffer。然后无论有没有数据直接返回(非阻塞)。而系统内核会去检查是否有可用数据,一旦有可用数据,则触发信号,并且把数据填充到我们之前提供的数据缓冲区buffer中。这样我们进程被信号触发,并且直接能从buffer中读取到数据,整个过程没有任何阻塞。
很显然,我们CocoaAyncSocket框架用的就是第5种I/O模式。

接着我们继续看本文方法十一 -- 连接成功后的初始化中第6条,读写source的初始化方法:

本文方法十二 -- 初始化读写source:
//初始化读写source
- (void)setupReadAndWriteSourcesForNewlyConnectedSocket:(int)socketFD
{
//GCD source DISPATCH_SOURCE_TYPE_READ 会一直监视着 socketFD,直到有数据可读
readSource = dispatch_source_create(DISPATCH_SOURCE_TYPE_READ, socketFD, 0, socketQueue);
//_dispatch_source_type_write :监视着 socketFD,直到写数据了
writeSource = dispatch_source_create(DISPATCH_SOURCE_TYPE_WRITE, socketFD, 0, socketQueue);

// Setup event handlers

__weak GCDAsyncSocket *weakSelf = self;

#pragma mark readSource的回调

//GCD事件句柄 读,当socket中有数据流出现,就会触发这个句柄,全自动,不需要手动触发
dispatch_source_set_event_handler(readSource, ^{ @autoreleasepool {
#pragma clang diagnostic push
#pragma clang diagnostic warning "-Wimplicit-retain-self"

__strong GCDAsyncSocket *strongSelf = weakSelf;
if (strongSelf == nil) return_from_block;

LogVerbose(@"readEventBlock");
//从readSource中,获取到数据长度,
strongSelf->socketFDBytesAvailable = dispatch_source_get_data(strongSelf->readSource);
LogVerbose(@"socketFDBytesAvailable: %lu", strongSelf->socketFDBytesAvailable);

//如果长度大于0,开始读数据
if (strongSelf->socketFDBytesAvailable > 0)
[strongSelf doReadData];
else
//因为触发了,但是却没有可读数据,说明读到当前包边界了。做边界处理
[strongSelf doReadEOF];

#pragma clang diagnostic pop
}});

//写事件句柄
dispatch_source_set_event_handler(writeSource, ^{ @autoreleasepool {
#pragma clang diagnostic push
#pragma clang diagnostic warning "-Wimplicit-retain-self"

__strong GCDAsyncSocket *strongSelf = weakSelf;
if (strongSelf == nil) return_from_block;

LogVerbose(@"writeEventBlock");
//标记为接受数据
strongSelf->flags |= kSocketCanAcceptBytes;
//开始写
[strongSelf doWriteData];

#pragma clang diagnostic pop
}});

// Setup cancel handlers

__block int socketFDRefCount = 2;

#if !OS_OBJECT_USE_OBJC
dispatch_source_t theReadSource = readSource;
dispatch_source_t theWriteSource = writeSource;
#endif

//读写取消的句柄
dispatch_source_set_cancel_handler(readSource, ^{
#pragma clang diagnostic push
#pragma clang diagnostic warning "-Wimplicit-retain-self"

LogVerbose(@"readCancelBlock");

#if !OS_OBJECT_USE_OBJC
LogVerbose(@"dispatch_release(readSource)");
dispatch_release(theReadSource);
#endif

if (--socketFDRefCount == 0)
{
LogVerbose(@"close(socketFD)");
//关闭socket
close(socketFD);
}

#pragma clang diagnostic pop
});

dispatch_source_set_cancel_handler(writeSource, ^{
#pragma clang diagnostic push
#pragma clang diagnostic warning "-Wimplicit-retain-self"

LogVerbose(@"writeCancelBlock");

#if !OS_OBJECT_USE_OBJC
LogVerbose(@"dispatch_release(writeSource)");
dispatch_release(theWriteSource);
#endif

if (--socketFDRefCount == 0)
{
LogVerbose(@"close(socketFD)");
//关闭socket
close(socketFD);
}

#pragma clang diagnostic pop
});

// We will not be able to read until data arrives.
// But we should be able to write immediately.

//设置未读数量为0
socketFDBytesAvailable = 0;
//把读挂起的状态移除
flags &= ~kReadSourceSuspended;

LogVerbose(@"dispatch_resume(readSource)");
//开启读source
dispatch_resume(readSource);

//标记为当前可接受数据
flags |= kSocketCanAcceptBytes;
//先把写source标记为挂起
flags |= kWriteSourceSuspended;
}


这个方法初始化了读写source,这个方法主要是GCD source运用

这里GCD Source相关的主要是下面这3个函数

//创建source
dispatch_source_create(dispatch_source_type_t type,
uintptr_t handle,
unsigned long mask,
dispatch_queue_t _Nullable queue);
//为source设置事件句柄
dispatch_source_set_event_handler(dispatch_source_t source,
dispatch_block_t _Nullable handler);
//为source设置取消句柄
dispatch_source_set_cancel_handler(dispatch_source_t source,
dispatch_block_t _Nullable handler);


相信大家用至少用过GCD定时器,接触过这3个函数,这里创建source的函数,根据参数type的不同,可以处理不同的事件:


这里我们用的是DISPATCH_SOURCE_TYPE_READDISPATCH_SOURCE_TYPE_WRITE这两个类型。标识如果handle如果有可读或者可写数据时,会触发我们的事件句柄。

  • 而这里初始化的读写事件句柄内容也很简单,就是去读写数据。
  • 而取消句柄也就是去关闭socket
  • 初始化完成后,我们开启了readSource,一旦有数据过来就触发了我们readSource事件句柄,就可以去监听的socket所分配的缓冲区中去读取数据了,而wirteSource初始化完是挂起的。
  • 除此之外我们还初始化了当前source的状态,用于我们后续的操作。

至此我们客户端的整个Connect流程结束了 ,下章概括总结一下Connect

CocoaAsyncSocket源码分析---Connect (二)

CocoaAsyncSocket源码分析---Connect (三)

CocoaAsyncSocket源码分析---Connect (四)

CocoaAsyncSocket源码分析---Connect (五)

CocoaAsyncSocket源码分析---Connect (六)

CocoaAsyncSocket源码分析---Connect (七)

CocoaAsyncSocket源码分析---Connect (八)


作者:Cooci
链接:https://www.jianshu.com/p/b264eff1f326




收起阅读 »

CocoaAsyncSocket源码分析---Connect (六)

本文方法十一 -- 连接成功后的初始化原因是为了线程安全和socket相关的操作必须在queue中被回调。这个方法基本上很简单,就是关于两个stream函数的调用:这个函数创建了一对读写stream,并且把stream与这个scoket做了绑定。相信用过的朋友...
继续阅读 »

我们接着来看看连接成功后,初始化的方法:

本文方法十一 -- 连接成功后的初始化

//连接成功后调用,设置一些连接成功的状态
- (void)didConnect:(int)aStateIndex
{
LogTrace();

NSAssert(dispatch_get_specific(IsOnSocketQueueOrTargetQueueKey), @"Must be dispatched on socketQueue");

//状态不同
if (aStateIndex != stateIndex)
{
LogInfo(@"Ignoring didConnect, already disconnected");

// The connect operation has been cancelled.
// That is, socket was disconnected, or connection has already timed out.
return;
}

//kConnected合并到当前flag中
flags |= kConnected;
//停止连接超时
[self endConnectTimeout];

#if TARGET_OS_IPHONE
// The endConnectTimeout method executed above incremented the stateIndex.
//上面的endConnectTimeout,会导致stateIndex增加,所以需要重新赋值
aStateIndex = stateIndex;
#endif

// Setup read/write streams (as workaround for specific shortcomings in the iOS platform)
//
// Note:
// There may be configuration options that must be set by the delegate before opening the streams.
//打开stream之前必须用相关配置设置代理
// The primary example is the kCFStreamNetworkServiceTypeVoIP flag, which only works on an unopened stream.
//主要的例子是kCFStreamNetworkServiceTypeVoIP标记,只能工作在未打开的stream中?
//
// Thus we wait until after the socket:didConnectToHost:port: delegate method has completed.
//所以我们要等待,连接完成的代理调用完
// This gives the delegate time to properly configure the streams if needed.
//这些给了代理时间,去正确的配置Stream,如果是必要的话

//创建个Block来初始化Stream
dispatch_block_t SetupStreamsPart1 = ^{

NSLog(@"hello~");
#if TARGET_OS_IPHONE
//创建读写stream失败,则关闭并报对应错误
if (![self createReadAndWriteStream])
{
[self closeWithError:[self otherError:@"Error creating CFStreams"]];
return;
}

//参数是给NO的,就是有可读bytes的时候,不会调用回调函数
if (![self registerForStreamCallbacksIncludingReadWrite:NO])
{
[self closeWithError:[self otherError:@"Error in CFStreamSetClient"]];
return;
}

#endif
};
//part2设置stream
dispatch_block_t SetupStreamsPart2 = ^{
#if TARGET_OS_IPHONE
//状态不一样直接返回
if (aStateIndex != stateIndex)
{
// The socket has been disconnected.
return;
}
//如果加到runloop上失败
if (![self addStreamsToRunLoop])
{
//错误返回
[self closeWithError:[self otherError:@"Error in CFStreamScheduleWithRunLoop"]];
return;
}

//读写stream open
if (![self openStreams])
{
//开启错误返回
[self closeWithError:[self otherError:@"Error creating CFStreams"]];
return;
}

#endif
};

// Notify delegate
//通知代理
//拿到server端的host port
NSString *host = [self connectedHost];
uint16_t port = [self connectedPort];
//拿到unix域的 url
NSURL *url = [self connectedUrl];
//拿到代理
__strong id theDelegate = delegate;

//代理队列 和 Host不为nil 且响应didConnectToHost代理方法
if (delegateQueue && host != nil && [theDelegate respondsToSelector:@selector(socket:didConnectToHost:port:)])
{
//调用初始化stream1
SetupStreamsPart1();

dispatch_async(delegateQueue, ^{ @autoreleasepool {

//到代理队列调用连接成功的代理方法
[theDelegate socket:self didConnectToHost:host port:port];

//然后回到socketQueue中去执行初始化stream2
dispatch_async(socketQueue, ^{ @autoreleasepool {

SetupStreamsPart2();
}});
}});
}
//这个是unix domain 请求回调
else if (delegateQueue && url != nil && [theDelegate respondsToSelector:@selector(socket:didConnectToUrl:)])
{
SetupStreamsPart1();

dispatch_async(delegateQueue, ^{ @autoreleasepool {

[theDelegate socket:self didConnectToUrl:url];

dispatch_async(socketQueue, ^{ @autoreleasepool {

SetupStreamsPart2();
}});
}});
}
//否则只初始化stream
else
{
SetupStreamsPart1();
SetupStreamsPart2();
}

// Get the connected socket

int socketFD = (socket4FD != SOCKET_NULL) ? socket4FD : (socket6FD != SOCKET_NULL) ? socket6FD : socketUN;

//fcntl,功能描述:根据文件描述词来操作文件的特性。http://blog.csdn.net/pbymw8iwm/article/details/7974789
// Enable non-blocking IO on the socket
//使socket支持非阻塞IO
int result = fcntl(socketFD, F_SETFL, O_NONBLOCK);
if (result == -1)
{
//失败 ,报错
NSString *errMsg = @"Error enabling non-blocking IO on socket (fcntl)";
[self closeWithError:[self otherError:errMsg]];

return;
}

// Setup our read/write sources
//初始化读写source
[self setupReadAndWriteSourcesForNewlyConnectedSocket:socketFD];

// Dequeue any pending read/write requests
//开始下一个任务
[self maybeDequeueRead];
[self maybeDequeueWrite];
}

这个方法很长一大串,其实做的东西也很简单,主要做了下面几件事:

  1. 把当前状态flags加上已连接,并且关闭掉我们一开始连接开启的,连接超时的定时器。
  2. 初始化了两个BlockSetupStreamsPart1SetupStreamsPart2,这两个Block做的事都和读写流有关。SetupStreamsPart1用来创建读写流,并且注册回调。另一个SetupStreamsPart2用来把流添加到当前线程的runloop上,并且打开流。
  3. 判断是否有代理queuehost或者url这些参数是否为空、是否代理响应didConnectToHostdidConnectToUrl代理,这两种分别对应了普通socket连接和unix domin socket连接。如果实现了对应的代理,则调用连接成功的代理。
  4. 在调用代理的同时,调用了我们之前初始化的两个读写流相关的Block。这里值得说下的是这两个Block和代理之间的调用顺序:
  • 先执行SetupStreamsPart1后执行SetupStreamsPart2,没什么好说的,问题是代理的执行时间,想想如果我们放在SetupStreamsPart2后面是不是会导致个问题,就是用户收到消息了,但是连接成功的代理还没有被调用,这显然是不合理的。所以我们的调用顺序是SetupStreamsPart1->代理->SetupStreamsPart2

    所以出现了如下代码:


作者:Cooci
链接:https://www.jianshu.com/p/b264eff1f326
  //调用初始化stream1
SetupStreamsPart1();

dispatch_async(delegateQueue, ^{ @autoreleasepool {

//到代理队列调用连接成功的代理方法
[theDelegate socket:self didConnectToHost:host port:port];

//然后回到socketQueue中去执行初始化stream2
dispatch_async(socketQueue, ^{ @autoreleasepool {

SetupStreamsPart2();
}});
}});


原因是为了线程安全和socket相关的操作必须在socketQueue中进行。而代理必须在我们设置的代理queue中被回调。

  1. 拿到当前的本机socket,调用如下函数:
int result = fcntl(socketFD, F_SETFL, O_NONBLOCK);


而在这里,就是为了把socket的IO模式设置为非阻塞。很多小伙伴又要疑惑什么是非阻塞了,先别急,关于这个我们下文会详细的来谈。

  1. 我们初始化了读写source(很重要,所有的消息都是由这个source来触发的,我们之后会详细分析这个方法)。

  2. 我们做完了streamsource的初始化处理,则开始做一次读写任务(这两个方法暂时不讲,会放到之后的ReadWrite篇中去讲)。

我们接着来讲讲这个方法中对其他方法的调用,按照顺序来,先从第2条,两个Block中对stream的处理开始。和stream相关的函数一共有6个:

Stream相关方法一 -- 创建读写stream

//创建读写stream
- (BOOL)createReadAndWriteStream
{
LogTrace();

NSAssert(dispatch_get_specific(IsOnSocketQueueOrTargetQueueKey), @"Must be dispatched on socketQueue");

//如果有一个有值,就返回
if (readStream || writeStream)
{
// Streams already created
return YES;
}
//拿到socket,首选是socket4FD,其次socket6FD,都没有才是socketUN,socketUN应该是Unix的socket结构体
int socketFD = (socket4FD != SOCKET_NULL) ? socket4FD : (socket6FD != SOCKET_NULL) ? socket6FD : socketUN;

//如果都为空,返回NO
if (socketFD == SOCKET_NULL)
{
// Cannot create streams without a file descriptor
return NO;
}

//如果非连接,返回NO
if (![self isConnected])
{
// Cannot create streams until file descriptor is connected
return NO;
}

LogVerbose(@"Creating read and write stream...");

#pragma mark - 绑定Socket和CFStream
//下面的接口用于创建一对 socket stream,一个用于读取,一个用于写入:
CFStreamCreatePairWithSocket(NULL, (CFSocketNativeHandle)socketFD, &readStream, &writeStream);

// The kCFStreamPropertyShouldCloseNativeSocket property should be false by default (for our case).
// But let's not take any chances.

//读写stream都设置成不会随着绑定的socket一起close,release。 kCFBooleanFalse不一起,kCFBooleanTrue一起
if (readStream)
CFReadStreamSetProperty(readStream, kCFStreamPropertyShouldCloseNativeSocket, kCFBooleanFalse);
if (writeStream)
CFWriteStreamSetProperty(writeStream, kCFStreamPropertyShouldCloseNativeSocket, kCFBooleanFalse);

//如果有一个为空
if ((readStream == NULL) || (writeStream == NULL))
{
LogWarn(@"Unable to create read and write stream...");

//关闭对应的stream
if (readStream)
{
CFReadStreamClose(readStream);
CFRelease(readStream);
readStream = NULL;
}
if (writeStream)
{
CFWriteStreamClose(writeStream);
CFRelease(writeStream);
writeStream = NULL;
}
//返回创建失败
return NO;
}
//创建成功
return YES;
}

这个方法基本上很简单,就是关于两个stream函数的调用:

  1. 创建stream的函数:
CFStreamCreatePairWithSocket(NULL, (CFSocketNativeHandle)socketFD, &readStream, &writeStream);

这个函数创建了一对读写stream,并且把stream与这个scoket做了绑定。

  1. 设置stream属性:
CFReadStreamSetProperty(readStream, kCFStreamPropertyShouldCloseNativeSocket, kCFBooleanFalse);
CFWriteStreamSetProperty(writeStream, kCFStreamPropertyShouldCloseNativeSocket, kCFBooleanFalse);

这个函数可以给stream设置一个属性,这里是设置stream不会随着socket的生命周期(close,release)而变化。

接着调用了registerForStreamCallbacksIncludingReadWrite来给stream注册读写回调。

Stream相关方法二 -- 读写回调的注册:

//注册Stream的回调
- (BOOL)registerForStreamCallbacksIncludingReadWrite:(BOOL)includeReadWrite
{
LogVerbose(@"%@ %@", THIS_METHOD, (includeReadWrite ? @"YES" : @"NO"));

NSAssert(dispatch_get_specific(IsOnSocketQueueOrTargetQueueKey), @"Must be dispatched on socketQueue");
//判断读写stream是不是都为空
NSAssert((readStream != NULL && writeStream != NULL), @"Read/Write stream is null");

//客户端stream上下文对象
streamContext.version = 0;
streamContext.info = (__bridge void *)(self);
streamContext.retain = nil;
streamContext.release = nil;
streamContext.copyDescription = nil;

// The open has completed successfully.
// The stream has bytes to be read.
// The stream can accept bytes for writing.
// An error has occurred on the stream.
// The end of the stream has been reached.

//设置一个CF的flag 两种,一种是错误发生的时候,一种是stream事件结束
CFOptionFlags readStreamEvents = kCFStreamEventErrorOccurred | kCFStreamEventEndEncountered ;
//如果包含读写
if (includeReadWrite)
//仍然有Bytes要读的时候 The stream has bytes to be read.
readStreamEvents |= kCFStreamEventHasBytesAvailable;

//给读stream设置客户端,会在之前设置的那些标记下回调函数 CFReadStreamCallback。设置失败的话直接返回NO
if (!CFReadStreamSetClient(readStream, readStreamEvents, &CFReadStreamCallback, &streamContext))
{
return NO;
}

//写的flag,也一样
CFOptionFlags writeStreamEvents = kCFStreamEventErrorOccurred | kCFStreamEventEndEncountered;
if (includeReadWrite)
writeStreamEvents |= kCFStreamEventCanAcceptBytes;

if (!CFWriteStreamSetClient(writeStream, writeStreamEvents, &CFWriteStreamCallback, &streamContext))
{
return NO;
}
//走到最后说明读写都设置回调成功,返回YES
return YES;
}

相信用过CFStream的朋友,应该会觉得很简单,这个方法就是调用了一些CFStream相关函数,其中最主要的这个设置读写回调函数:
Boolean CFReadStreamSetClient(CFReadStreamRef stream, CFOptionFlags streamEvents, CFReadStreamClientCallBack clientCB, CFStreamClientContext *clientContext);
Boolean CFWriteStreamSetClient(CFWriteStreamRef stream, CFOptionFlags streamEvents, CFWriteStreamClientCallBack clientCB, CFStreamClientContext *clientContext);


这个函数共4个参数:
第1个为我们需要设置的stream;
第2个为需要监听的事件选项,包括以下事件:

typedef CF_OPTIONS(CFOptionFlags, CFStreamEventType) {
kCFStreamEventNone = 0, //没有事件发生
kCFStreamEventOpenCompleted = 1, //成功打开流
kCFStreamEventHasBytesAvailable = 2, //流中有数据可读
kCFStreamEventCanAcceptBytes = 4, //流中可以接受数据去写
kCFStreamEventErrorOccurred = 8, //流发生错误
kCFStreamEventEndEncountered = 16 //到达流的结尾
};

其中具体用法,大家可以自行去试试,这里作者只监听了了两种事件kCFStreamEventErrorOccurredkCFStreamEventEndEncountered,再根据传过来的参数去决定是否监听kCFStreamEventCanAcceptBytes

//如果包含读写
if (includeReadWrite)
//仍然有Bytes要读的时候 The stream has bytes to be read.
readStreamEvents |= kCFStreamEventHasBytesAvailable;

而这里我们传过来的参数为NO,导致它并不监听可读数据。显然,我们正常的连接,当有消息发送过来,并不是由stream回调来触发的。这个框架中,如果是TLS传输的socket是用stream来触发的,这个我们后续文章会讲到。

那么有数据的时候,到底是什么来触发我们的读写呢,答案就是读写source,我们接下来就会去创建初始化它。

这里绑定了两个函数,分别对应读和写的回调,分别为:

//读的回调
static void CFReadStreamCallback (CFReadStreamRef stream, CFStreamEventType type, void *pInfo)
//写的回调
static void CFWriteStreamCallback (CFWriteStreamRef stream, CFStreamEventType type, void *pInfo)

关于这两个函数,同样这里暂时不做讨论,等后续文章再来分析。

还有一点需要说一下的是streamContext这个属性,它是一个结构体,包含流的上下文信息,其结构如下:

typedef struct {
CFIndex version;
void *info;
void *(*retain)(void *info);
void (*release)(void *info);
CFStringRef (*copyDescription)(void *info);
} CFStreamClientContext;


这个流的上下文中info指针,其实就是前面所对应的读写回调函数中的pInfo指针,每次回调都会传过去。其它的version就是流的版本标识,之外的3个都需要的是一个函数指针,对应我们传递的pInfo的持有以及释放还有复制的描述信息,这里我们都赋值给nil

下一章我们来到流处理的第三步


CocoaAsyncSocket源码分析---Connect (一)
CocoaAsyncSocket源码分析---Connect (八)
作者:Cooci
链接:https://www.jianshu.com/p/b264eff1f326







收起阅读 »

CocoaAsyncSocket源码分析---Connect (五)

上文我们提到了GCDAsyncSocket的初始化,以及最终connect之前的准备工作,包括一些错误检查;本机地址创建以及socket创建;服务端地址的创建;还有一些本机socket可选项的配置,例如禁止网络出错导致进程关闭的信号等我们去用之前创建的本机地址...
继续阅读 »
上文我们提到了GCDAsyncSocket的初始化,以及最终connect之前的准备工作,包括一些错误检查;本机地址创建以及socket创建;服务端地址的创建;还有一些本机socket可选项的配置,例如禁止网络出错导致进程关闭的信号等

言归正传,继续上文往下讲
上文讲到了本文方法八--创建Socket,其中有这么一行代码:
//和connectInterface绑定
if (![self bindSocket:socketFD toInterface:connectInterface error:errPtr])
{
//绑定失败,直接关闭返回
[self closeSocket:socketFD];

return SOCKET_NULL;
}

我们去用之前创建的本机地址去做socket绑定,接着会调用到如下方法中:

本文方法九--给Socket绑定本机地址
//绑定一个Socket的本地地址
- (BOOL)bindSocket:(int)socketFD toInterface:(NSData *)connectInterface error:(NSError **)errPtr
{
// Bind the socket to the desired interface (if needed)
//无接口就不绑定,connect会自动绑定到一个不冲突的端口上去。
if (connectInterface)
{
LogVerbose(@"Binding socket...");

//判断当前地址的Port是不是大于0
if ([[self class] portFromAddress:connectInterface] > 0)
{
// Since we're going to be binding to a specific port,
// we should turn on reuseaddr to allow us to override sockets in time_wait.

int reuseOn = 1;

//设置调用close(socket)后,仍可继续重用该socket。调用close(socket)一般不会立即关闭socket,而经历TIME_WAIT的过程。
setsockopt(socketFD, SOL_SOCKET, SO_REUSEADDR, &reuseOn, sizeof(reuseOn));
}

//拿到地址
const struct sockaddr *interfaceAddr = (const struct sockaddr *)[connectInterface bytes];
//绑定这个地址
int result = bind(socketFD, interfaceAddr, (socklen_t)[connectInterface length]);

//绑定出错,返回NO
if (result != 0)
{
if (errPtr)
*errPtr = [self errnoErrorWithReason:@"Error in bind() function"];

return NO;
}
}

//成功
return YES;
}

这个方法也非常简单,如果没有connectInterface则直接返回YES,当socket进行连接的时候,会自动绑定一个端口,进行连接。
如果有值,则我们开始绑定到我们一开始指定的地址上。
这里调用了两个和scoket相关的函数:
第一个是我们之前提到的配置scoket参数的函数:

setsockopt(socketFD, SOL_SOCKET, SO_REUSEADDR, &reuseOn, sizeof(reuseOn));

这里调用这个函数的主要目的是为了调用close的时候,不立即去关闭socket连接,而是经历一个TIME_WAIT过程。在这个过程中,socket是可以被复用的。我们注意到之前的connect流程并没有看到复用socket的代码。注意,我们现在走的连接流程是客户端的流程,等我们讲到服务端accept进行连接的时候,我们就能看到这个复用的作用了。

第二个是bind函数
int result = bind(socketFD, interfaceAddr, (socklen_t)[connectInterface length]);

这个函数倒是很简单,就3个参数,socket、需要绑定的地址、地址大小。这样就把socket和这个地址(其实就是端口)捆绑在一起了。

这样我们就做完了最终连接前所有准备工作,本机socket有了,服务端的地址也有了。接着我们就可以开始进行最终连接了:

本文方法十 -- 建立连接的最终方法

//连接最终方法 3 finnal。。。
- (void)connectSocket:(int)socketFD address:(NSData *)address stateIndex:(int)aStateIndex
{
// If there already is a socket connected, we close socketFD and return
//已连接,关闭连接返回
if (self.isConnected)
{
[self closeSocket:socketFD];
return;
}

// Start the connection process in a background queue
//开始连接过程,在后台queue中
__weak GCDAsyncSocket *weakSelf = self;

//获取到全局Queue
dispatch_queue_t globalConcurrentQueue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
//新线程
dispatch_async(globalConcurrentQueue, ^{
#pragma clang diagnostic push
#pragma clang diagnostic warning "-Wimplicit-retain-self"
//调用connect方法,该函数阻塞线程,所以要异步新线程
//客户端向特定网络地址的服务器发送连接请求,连接成功返回0,失败返回 -1。
int result = connect(socketFD, (const struct sockaddr *)[address bytes], (socklen_t)[address length]);

//老样子,安全判断
__strong GCDAsyncSocket *strongSelf = weakSelf;
if (strongSelf == nil) return_from_block;

//在socketQueue中,开辟线程
dispatch_async(strongSelf->socketQueue, ^{ @autoreleasepool {
//如果状态为已经连接,关闭连接返回
if (strongSelf.isConnected)
{
[strongSelf closeSocket:socketFD];
return_from_block;
}

//说明连接成功
if (result == 0)
{
//关闭掉另一个没用的socket
[self closeUnusedSocket:socketFD];
//调用didConnect,生成stream,改变状态等等!
[strongSelf didConnect:aStateIndex];
}
//连接失败
else
{
//关闭当前socket
[strongSelf closeSocket:socketFD];

// If there are no more sockets trying to connect, we inform the error to the delegate
//返回连接错误的error
if (strongSelf.socket4FD == SOCKET_NULL && strongSelf.socket6FD == SOCKET_NULL)
{
NSError *error = [strongSelf errnoErrorWithReason:@"Error in connect() function"];
[strongSelf didNotConnect:aStateIndex error:error];
}
}
}});

#pragma clang diagnostic pop
});
//输出正在连接中
LogVerbose(@"Connecting...");
}

这个方法主要就是做了一件事,调用下面一个函数进行连接:
int result = connect(socketFD, (const struct sockaddr *)[address bytes], (socklen_t)[address length]);


这里需要注意的是这个函数是阻塞,直到结果返回之前,线程会一直停在这行。所以这里用的是全局并发队列,开辟了一个新的线程进行连接,在得到结果之后,又调回socketQueue中进行后续操作。

如果result为0,说明连接成功,我们会关闭掉另外一个没有用到的socket(如果有的话)。然后调用另外一个方法做一些连接成功的初始化操作。
否则连接失败,我们会关闭socket,填充错误并且返回。

我们下一章来看看连接成功后初始化的方法


CocoaAsyncSocket源码分析---Connect (一)
CocoaAsyncSocket源码分析---Connect (八)
作者:Cooci
链接:https://www.jianshu.com/p/b264eff1f326





收起阅读 »

CocoaAsyncSocket源码分析---Connect (四)

//根据host、port + (NSMutableArray *)lookupHost:(NSString *)host port:(uint16_t)port error:(NSError **)errPtr { LogTrace(); ...
继续阅读 »
本文方法五--创建服务端server地址数据:

//根据host、port
+ (NSMutableArray *)lookupHost:(NSString *)host port:(uint16_t)port error:(NSError **)errPtr
{
LogTrace();

NSMutableArray *addresses = nil;
NSError *error = nil;

//如果Host是这localhost或者loopback
if ([host isEqualToString:@"localhost"] || [host isEqualToString:@"loopback"])
{
// Use LOOPBACK address
struct sockaddr_in nativeAddr4;
nativeAddr4.sin_len = sizeof(struct sockaddr_in);
nativeAddr4.sin_family = AF_INET;
nativeAddr4.sin_port = htons(port);
nativeAddr4.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
//占位置0
memset(&(nativeAddr4.sin_zero), 0, sizeof(nativeAddr4.sin_zero));

//ipv6
struct sockaddr_in6 nativeAddr6;
nativeAddr6.sin6_len = sizeof(struct sockaddr_in6);
nativeAddr6.sin6_family = AF_INET6;
nativeAddr6.sin6_port = htons(port);
nativeAddr6.sin6_flowinfo = 0;
nativeAddr6.sin6_addr = in6addr_loopback;
nativeAddr6.sin6_scope_id = 0;

// Wrap the native address structures

NSData *address4 = [NSData dataWithBytes:&nativeAddr4 length:sizeof(nativeAddr4)];
NSData *address6 = [NSData dataWithBytes:&nativeAddr6 length:sizeof(nativeAddr6)];

//两个添加进数组
addresses = [NSMutableArray arrayWithCapacity:2];
[addresses addObject:address4];
[addresses addObject:address6];
}
else
{
//拿到port String
NSString *portStr = [NSString stringWithFormat:@"%hu", port];

//定义三个addrInfo 是一个sockaddr结构的链表而不是一个地址清单

struct addrinfo hints, *res, *res0;

//初始化为0
memset(&hints, 0, sizeof(hints));

//相当于 AF_UNSPEC ,返回的是适用于指定主机名和服务名且适合任何协议族的地址。
hints.ai_family = PF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
hints.ai_protocol = IPPROTO_TCP;

//根据host port,去获取地址信息。

int gai_error = getaddrinfo([host UTF8String], [portStr UTF8String], &hints, &res0);

//出错
if (gai_error)
{ //获取到错误
error = [self gaiError:gai_error];
}
//正确获取到addrInfo
else
{
//
NSUInteger capacity = 0;
//遍历 res0
for (res = res0; res; res = res->ai_next)
{
//如果有IPV4 IPV6的,capacity+1
if (res->ai_family == AF_INET || res->ai_family == AF_INET6) {
capacity++;
}
}
//生成一个地址数组,数组为capacity大小
addresses = [NSMutableArray arrayWithCapacity:capacity];

//再去遍历,为什么不一次遍历完,仅仅是为了限制数组的大小?
for (res = res0; res; res = res->ai_next)
{
//IPV4
if (res->ai_family == AF_INET)
{
// Found IPv4 address.
// Wrap the native address structure, and add to results.
//加到数组中
NSData *address4 = [NSData dataWithBytes:res->ai_addr length:res->ai_addrlen];
[addresses addObject:address4];
}
else if (res->ai_family == AF_INET6)
{
// Fixes connection issues with IPv6
// https://github.com/robbiehanson/CocoaAsyncSocket/issues/429#issuecomment-222477158

// Found IPv6 address.
// Wrap the native address structure, and add to results.
//强转
struct sockaddr_in6 *sockaddr = (struct sockaddr_in6 *)res->ai_addr;
//拿到port
in_port_t *portPtr = &sockaddr->sin6_port;
//如果Port为0
if ((portPtr != NULL) && (*portPtr == 0)) {
//赋值,用传进来的port
*portPtr = htons(port);
}
//添加到数组
NSData *address6 = [NSData dataWithBytes:res->ai_addr length:res->ai_addrlen];
[addresses addObject:address6];
}
}
//对应getaddrinfo 释放内存
freeaddrinfo(res0);

//如果地址里一个没有,报错 EAI_FAIL:名字解析中不可恢复的失败
if ([addresses count] == 0)
{
error = [self gaiError:EAI_FAIL];
}
}
}
//赋值错误
if (errPtr) *errPtr = error;
//返回地址
return addresses;
}

这个方法根据host进行了划分:

  1. 如果hostlocalhost或者loopback,则按照我们之前绑定本机地址那一套生成地址的方式,去生成IPV4和IPV6的地址,并且用NSData包裹住这个地址结构体,装在NSMutableArray中。
  2. 不是本机地址,那么我们就需要根据host和port去创建地址了,这里用到的是这么一个函数:
int getaddrinfo( const char *hostname, const char *service, const struct addrinfo *hints, struct addrinfo **result );


这个函数主要的作用是:根据hostname(IP)service(port),去获取地址信息,并且把地址信息传递到result中。
而hints这个参数可以是一个空指针,也可以是一个指向某个addrinfo结构体的指针,如果填了,其实它就是一个配置参数,返回的地址信息会和这个配置参数的内容有关,如下例:

举例来说:指定的服务既可支持TCP也可支持UDP,所以调用者可以把hints结构中的ai_socktype成员设置成SOCK_DGRAM使得返回的仅仅是适用于数据报套接口的信息。

这里我们可以看到result和hints这两个参数指针指向的都是一个addrinfo的结构体,这是我们继上面以来看到的第4种地址结构体了。它的定义如下:


struct addrinfo {
int ai_flags; /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST */
int ai_family; /* PF_xxx */
int ai_socktype; /* SOCK_xxx */
int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
socklen_t ai_addrlen; /* length of ai_addr */
char *ai_canonname; /* canonical name for hostname */
struct sockaddr *ai_addr; /* binary address */
struct addrinfo *ai_next; /* next structure in linked list */
};

我们可以看到它其中包括了一个IPV4的结构体地址ai_addr,还有一个指向下一个同类型数据节点的指针ai_next

这里讲讲ai_next这个指针,因为我们是去获取server端的地址,所以很可能有不止一个地址,比如IPV4、IPV6,又或者我们之前所说的一个服务器有多个网卡,这时候可能就会有多个地址。这些地址就会用ai_next指针串联起来,形成一个单链表。

然后我们拿到这个地址链表,去遍历它,对应取出IPV4、IPV6的地址,封装成NSData并装到数组中去。

  1. 如果中间有错误,赋值错误,返回地址数组,理清楚这几个结构体与函数,这个方法还是相当容易读的,具体的细节可以看看注释。

接着我们回到本文方法二,就要用这个地址数组去做连接了。


//异步去发起连接
dispatch_async(strongSelf->socketQueue, ^{ @autoreleasepool {

[strongSelf lookup:aStateIndex didSucceedWithAddress4:address4 address6:address6];
}});

这里调用了我们本文方法六--开始连接的方法1
//连接的最终方法 1
- (void)lookup:(int)aStateIndex didSucceedWithAddress4:(NSData *)address4 address6:(NSData *)address6
{
LogTrace();

NSAssert(dispatch_get_specific(IsOnSocketQueueOrTargetQueueKey), @"Must be dispatched on socketQueue");
//至少有一个server地址
NSAssert(address4 || address6, @"Expected at least one valid address");

//如果状态不一致,说明断开连接
if (aStateIndex != stateIndex)
{
LogInfo(@"Ignoring lookupDidSucceed, already disconnected");

// The connect operation has been cancelled.
// That is, socket was disconnected, or connection has already timed out.
return;
}

// Check for problems
//分开判断。
BOOL isIPv4Disabled = (config & kIPv4Disabled) ? YES : NO;
BOOL isIPv6Disabled = (config & kIPv6Disabled) ? YES : NO;

if (isIPv4Disabled && (address6 == nil))
{
NSString *msg = @"IPv4 has been disabled and DNS lookup found no IPv6 address.";

[self closeWithError:[self otherError:msg]];
return;
}

if (isIPv6Disabled && (address4 == nil))
{
NSString *msg = @"IPv6 has been disabled and DNS lookup found no IPv4 address.";

[self closeWithError:[self otherError:msg]];
return;
}

// Start the normal connection process

NSError *err = nil;
//调用连接方法,如果失败,则错误返回
if (![self connectWithAddress4:address4 address6:address6 error:&err])
{
[self closeWithError:err];
}
}

这个方法也比较简单,基本上就是做了一些错误的判断。比如:

  1. 判断在不在这个socket队列。
  2. 判断传过来的aStateIndex和属性stateIndex是不是同一个值。说到这个值,不得不提的是大神用的框架,在容错处理上,做的真不是一般的严谨。从这个stateIndex上就能略见一二。
    这个aStateIndex是我们之前调用方法,用属性传过来的,所以按道理说,是肯定一样的。但是就怕在调用过程中,这个值发生了改变,这时候整个socket配置也就完全不一样了,有可能我们已经置空地址、销毁socket、断开连接等等...等我们后面再来看这个属性stateIndex在什么地方会发生改变。
  3. 判断config中是需要哪种配置,它的参数对应了一个枚举:

enum GCDAsyncSocketConfig
{
kIPv4Disabled = 1 << 0, // If set, IPv4 is disabled
kIPv6Disabled = 1 << 1, // If set, IPv6 is disabled
kPreferIPv6 = 1 << 2, // If set, IPv6 is preferred over IPv4
kAllowHalfDuplexConnection = 1 << 3, // If set, the socket will stay open even if the read stream closes
};

前3个大家很好理解,无非就是用IPV4还是IPV6。
而第4个官方注释意思是,我们即使关闭读的流,也会保持Socket开启。至于具体是什么意思,我们先不在这里讨论,等后文再说。

这里调用了我们本文方法七--开始连接的方法2

//连接最终方法 2。用两个Server地址去连接,失败返回NO,并填充error
- (BOOL)connectWithAddress4:(NSData *)address4 address6:(NSData *)address6 error:(NSError **)errPtr
{
LogTrace();

NSAssert(dispatch_get_specific(IsOnSocketQueueOrTargetQueueKey), @"Must be dispatched on socketQueue");

//输出一些东西?
LogVerbose(@"IPv4: %@:%hu", [[self class] hostFromAddress:address4], [[self class] portFromAddress:address4]);
LogVerbose(@"IPv6: %@:%hu", [[self class] hostFromAddress:address6], [[self class] portFromAddress:address6]);

// Determine socket type

//判断是否倾向于IPV6
BOOL preferIPv6 = (config & kPreferIPv6) ? YES : NO;

// Create and bind the sockets

//如果有IPV4地址,创建IPV4 Socket
if (address4)
{
LogVerbose(@"Creating IPv4 socket");

socket4FD = [self createSocket:AF_INET connectInterface:connectInterface4 errPtr:errPtr];
}
//如果有IPV6地址,创建IPV6 Socket
if (address6)
{
LogVerbose(@"Creating IPv6 socket");

socket6FD = [self createSocket:AF_INET6 connectInterface:connectInterface6 errPtr:errPtr];
}

//如果都为空,直接返回
if (socket4FD == SOCKET_NULL && socket6FD == SOCKET_NULL)
{
return NO;
}

//主选socketFD,备选alternateSocketFD
int socketFD, alternateSocketFD;
//主选地址和备选地址
NSData *address, *alternateAddress;

//IPV6
if ((preferIPv6 && socket6FD) || socket4FD == SOCKET_NULL)
{
socketFD = socket6FD;
alternateSocketFD = socket4FD;
address = address6;
alternateAddress = address4;
}
//主选IPV4
else
{
socketFD = socket4FD;
alternateSocketFD = socket6FD;
address = address4;
alternateAddress = address6;
}
//拿到当前状态
int aStateIndex = stateIndex;
//用socket和address去连接
[self connectSocket:socketFD address:address stateIndex:aStateIndex];

//如果有备选地址
if (alternateAddress)
{
//延迟去连接备选的地址
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(alternateAddressDelay * NSEC_PER_SEC)), socketQueue, ^{
[self connectSocket:alternateSocketFD address:alternateAddress stateIndex:aStateIndex];
});
}

return YES;
}

这个方法也仅仅是连接中过渡的一个方法,做的事也非常简单:

  1. 就是拿到IPV4和IPV6地址,先去创建对应的socket,注意这个socket是本机客户端的,和server端没有关系。这里服务端的IPV4和IPV6地址仅仅是用来判断是否需要去创建对应的本机Socket。这里去创建socket会带上我们之前生成的本地地址信息connectInterface4或者connectInterface6
  2. 根据我们的config配置,得到主选连接和备选连接。 然后先去连接主选连接地址,在用我们一开始初始化中设置的属性alternateAddressDelay,就是这个备选连接延时的属性,去延时连接备选地址(当然如果主选地址在此时已经连接成功,会再次连接导致socket错误,并且关闭)。

这两步分别调用了各自的方法去实现,接下来我们先来看创建本机Socket的方法:

本文方法八--创建Socket:

//创建Socket
- (int)createSocket:(int)family connectInterface:(NSData *)connectInterface errPtr:(NSError **)errPtr
{
//创建socket,用的SOCK_STREAM TCP流
int socketFD = socket(family, SOCK_STREAM, 0);
//如果创建失败
if (socketFD == SOCKET_NULL)
{
if (errPtr)
*errPtr = [self errnoErrorWithReason:@"Error in socket() function"];

return socketFD;
}

//和connectInterface绑定
if (![self bindSocket:socketFD toInterface:connectInterface error:errPtr])
{
//绑定失败,直接关闭返回
[self closeSocket:socketFD];

return SOCKET_NULL;
}

// Prevent SIGPIPE signals
//防止终止进程的信号?
int nosigpipe = 1;
//SO_NOSIGPIPE是为了避免网络错误,而导致进程退出。用这个来避免系统发送signal
setsockopt(socketFD, SOL_SOCKET, SO_NOSIGPIPE, &nosigpipe, sizeof(nosigpipe));

return socketFD;
}

这个方法做了这么几件事:

  1. 创建了一个socket:

 //创建一个socket,返回值为Int。(注scoket其实就是Int类型)
//第一个参数addressFamily IPv4(AF_INET) 或 IPv6(AF_INET6)。
//第二个参数 type 表示 socket 的类型,通常是流stream(SOCK_STREAM) 或数据报文datagram(SOCK_DGRAM)
//第三个参数 protocol 参数通常设置为0,以便让系统自动为选择我们合适的协议,对于 stream socket 来说会是 TCP 协议(IPPROTO_TCP),而对于 datagram来说会是 UDP 协议(IPPROTO_UDP)。
int socketFD = socket(family, SOCK_STREAM, 0);

其实这个函数在之前那篇IM文章中也讲过了,大家参考参考注释看看就可以了,这里如果返回值为-1,说明创建失败。

  1. 去绑定我们之前创建的本地地址,它调用了另外一个方法来实现。
  2. 最后我们调用了如下函数

   setsockopt(socketFD, SOL_SOCKET, SO_NOSIGPIPE, &nosigpipe, sizeof(nosigpipe));

而这里的目的是为了来避免网络错误而出现的进程退出的情况,调用了这行函数,网络错误后,系统不再发送进程退出的信号。
关于这个进程退出的错误可以参考这篇文章:Mac OSX下SO_NOSIGPIPE的怪异表现

未完总结:

connect篇还没有完结,奈何篇幅问题,只能断在这里。下一个方法将是socket本地绑定的方法。再下面就是我们最终的连接方法了,历经九九八十一难,马上就要取到真经了...(然而这仅仅是一个开始...)
下一篇将会承接这一篇的内容继续讲,包括最终连接、连接完成后的source和流的处理。
我们还会去讲讲iOS作为服务端的accpet建立连接的流程。
除此之外还有 unix domin socket(进程间通信)的连接。


CocoaAsyncSocket源码分析---Connect (一)

CocoaAsyncSocket源码分析---Connect (二)

CocoaAsyncSocket源码分析---Connect (三)

CocoaAsyncSocket源码分析---Connect (四)

CocoaAsyncSocket源码分析---Connect (五)

CocoaAsyncSocket源码分析---Connect (六)

CocoaAsyncSocket源码分析---Connect (七)

CocoaAsyncSocket源码分析---Connect (八)


作者:Cooci
链接:https://www.jianshu.com/p/9968ff0280e5

收起阅读 »

CocoaAsyncSocket源码分析---Connect (三)

interface本文方法四--本地地址绑定方法- (void)getInterfaceAddress4:(NSMutableData **)interfaceAddr4Ptr address6:(NSMutableDa...
继续阅读 »

至于有interface,我们所做的额外操作是什么呢,我们接下来看看这个方法:本文方法四--本地地址绑定方法

- (void)getInterfaceAddress4:(NSMutableData **)interfaceAddr4Ptr
address6:(NSMutableData **)interfaceAddr6Ptr
fromDescription:(NSString *)interfaceDescription
port:(uint16_t)port
{
NSMutableData *addr4 = nil;
NSMutableData *addr6 = nil;

NSString *interface = nil;

//先用:分割
NSArray *components = [interfaceDescription componentsSeparatedByString:@":"];
if ([components count] > 0)
{
NSString *temp = [components objectAtIndex:0];
if ([temp length] > 0)
{
interface = temp;
}
}
if ([components count] > 1 && port == 0)
{
//拿到port strtol函数,将一个字符串,根据base参数转成长整型,如base值为10则采用10进制,若base值为16则采用16进制
long portL = strtol([[components objectAtIndex:1] UTF8String], NULL, 10);
//UINT16_MAX,65535最大端口号
if (portL > 0 && portL <= UINT16_MAX)
{
port = (uint16_t)portL;
}
}

//为空则自己创建一个 0x00000000 ,全是0 ,为线路地址
//如果端口为0 通常用于分析操作系统。这一方法能够工作是因为在一些系统中“0”是无效端口,当你试图使用通常的闭合端口连接它时将产生不同的结果。一种典型的扫描,使用IP地址为0.0.0.0,设置ACK位并在以太网层广播。
if (interface == nil)
{

struct sockaddr_in sockaddr4;

//memset作用是在一段内存块中填充某个给定的值,它是对较大的结构体或数组进行清零操作的一种最快方法

//memset(void *s,int ch,size_t n);函数,第一个参数为指针地址,第二个为设置值,第三个为连续设置的长度(大小)
memset(&sockaddr4, 0, sizeof(sockaddr4));
//结构体长度
sockaddr4.sin_len = sizeof(sockaddr4);
//addressFamily IPv4(AF_INET) 或 IPv6(AF_INET6)。
sockaddr4.sin_family = AF_INET;
//端口号 htons将主机字节顺序转换成网络字节顺序 16位
sockaddr4.sin_port = htons(port);
//htonl ,将INADDR_ANY:0.0.0.0,不确定地址,或者任意地址 htonl 32位。 也是转为网络字节序

//ipv4 32位 4个字节 INADDR_ANY,0x00000000 (16进制,一个0代表4位,8个0就是32位) = 4个字节的
sockaddr4.sin_addr.s_addr = htonl(INADDR_ANY);
struct sockaddr_in6 sockaddr6;
memset(&sockaddr6, 0, sizeof(sockaddr6));

sockaddr6.sin6_len = sizeof(sockaddr6);
//ipv6
sockaddr6.sin6_family = AF_INET6;
//port
sockaddr6.sin6_port = htons(port);

//共128位
sockaddr6.sin6_addr = in6addr_any;

//把这两个结构体转成data
addr4 = [NSMutableData dataWithBytes:&sockaddr4 length:sizeof(sockaddr4)];
addr6 = [NSMutableData dataWithBytes:&sockaddr6 length:sizeof(sockaddr6)];
}
//如果localhost、loopback 回环地址,虚拟地址,路由器工作它就存在。一般用来标识路由器
//这两种的话就赋值为127.0.0.1,端口为port
else if ([interface isEqualToString:@"localhost"] || [interface isEqualToString:@"loopback"])
{
// LOOPBACK address

//ipv4
struct sockaddr_in sockaddr4;
memset(&sockaddr4, 0, sizeof(sockaddr4));

sockaddr4.sin_len = sizeof(sockaddr4);
sockaddr4.sin_family = AF_INET;
sockaddr4.sin_port = htons(port);

//#define INADDR_LOOPBACK (u_int32_t)0x7f000001
//7f000001->1111111 00000000 00000000 00000001->127.0.0.1
sockaddr4.sin_addr.s_addr = htonl(INADDR_LOOPBACK);

//ipv6
struct sockaddr_in6 sockaddr6;
memset(&sockaddr6, 0, sizeof(sockaddr6));

sockaddr6.sin6_len = sizeof(sockaddr6);
sockaddr6.sin6_family = AF_INET6;
sockaddr6.sin6_port = htons(port);

sockaddr6.sin6_addr = in6addr_loopback;
//赋值
addr4 = [NSMutableData dataWithBytes:&sockaddr4 length:sizeof(sockaddr4)];
addr6 = [NSMutableData dataWithBytes:&sockaddr6 length:sizeof(sockaddr6)];
}
//非localhost、loopback,去获取本机IP,看和传进来Interface是同名或者同IP,相同才给赋端口号,把数据封装进Data。否则为nil
else
{
//转成cString
const char *iface = [interface UTF8String];

//定义结构体指针,这个指针是本地IP
struct ifaddrs *addrs;
const struct ifaddrs *cursor;

//获取到本机IP,为0说明成功了
if ((getifaddrs(&addrs) == 0))
{
//赋值
cursor = addrs;
//如果IP不为空,则循环链表去设置
while (cursor != NULL)
{
//如果 addr4 IPV4地址为空,而且地址类型为IPV4
if ((addr4 == nil) && (cursor->ifa_addr->sa_family == AF_INET))
{
// IPv4

struct sockaddr_in nativeAddr4;
//memcpy内存copy函数,把src开始到size的字节数copy到 dest中
memcpy(&nativeAddr4, cursor->ifa_addr, sizeof(nativeAddr4));

//比较两个字符串是否相同,本机的IP名,和接口interface是否相同
if (strcmp(cursor->ifa_name, iface) == 0)
{
// Name match
//相同则赋值 port
nativeAddr4.sin_port = htons(port);
//用data封号IPV4地址
addr4 = [NSMutableData dataWithBytes:&nativeAddr4 length:sizeof(nativeAddr4)];
}
//本机IP名和interface不相同
else
{
//声明一个IP 16位的数组
char ip[INET_ADDRSTRLEN];

//这里是转成了10进制。。(因为获取到的是二进制IP)
const char *conversion = inet_ntop(AF_INET, &nativeAddr4.sin_addr, ip, sizeof(ip));

//如果conversion不为空,说明转换成功而且 ,比较转换后的IP,和interface是否相同
if ((conversion != NULL) && (strcmp(ip, iface) == 0))
{
// IP match
//相同则赋值 port
nativeAddr4.sin_port = htons(port);

addr4 = [NSMutableData dataWithBytes:&nativeAddr4 length:sizeof(nativeAddr4)];
}
}
}
//IPV6 一样
else if ((addr6 == nil) && (cursor->ifa_addr->sa_family == AF_INET6))
{
// IPv6

struct sockaddr_in6 nativeAddr6;
memcpy(&nativeAddr6, cursor->ifa_addr, sizeof(nativeAddr6));

if (strcmp(cursor->ifa_name, iface) == 0)
{
// Name match

nativeAddr6.sin6_port = htons(port);

addr6 = [NSMutableData dataWithBytes:&nativeAddr6 length:sizeof(nativeAddr6)];
}
else
{
char ip[INET6_ADDRSTRLEN];

const char *conversion = inet_ntop(AF_INET6, &nativeAddr6.sin6_addr, ip, sizeof(ip));

if ((conversion != NULL) && (strcmp(ip, iface) == 0))
{
// IP match

nativeAddr6.sin6_port = htons(port);

addr6 = [NSMutableData dataWithBytes:&nativeAddr6 length:sizeof(nativeAddr6)];
}
}
}

//指向链表下一个addr
cursor = cursor->ifa_next;
}
//和getifaddrs对应,释放这部分内存
freeifaddrs(addrs);
}
}
//如果这两个二级指针存在,则取成一级指针,把addr4赋值给它
if (interfaceAddr4Ptr) *interfaceAddr4Ptr = addr4;
if (interfaceAddr6Ptr) *interfaceAddr6Ptr = addr6;

这个方法中,主要是大量的socket相关的函数的调用,会显得比较难读一点,其实简单来讲就做了这么一件事:
interface变成进行socket操作所需要的地址结构体,然后把地址结构体包裹在NSMutableData中。

这里,为了让大家能更容易理解,我把这个方法涉及到的socket相关函数以及宏(按照调用顺序)都列出来:


//拿到port strtol函数,将一个字符串,根据base参数转成长整型,
//如base值为10则采用10进制,若base值为16则采用16进制
long strtol(const char *__str, char **__endptr, int __base);

//作用是在一段内存块中填充某个给定的值,它是对较大的结构体或数组进行清零操作的一种最快方法
//第一个参数为指针地址,第二个为设置值,第三个为连续设置的长度(大小)
memset(void *s,int ch,size_t n);

//最大端口号
#define UINT16_MAX 65535

//作用是把主机字节序转化为网络字节序
htons() //参数16位
htonl() //参数32位
//获取占用内存大小
sizeof()
//比较两个指针,是否相同 相同返回0
int strcmp(const char *__s1, const char *__s2)

//内存copu函数,把src开始到len的字节数copy到 dest中
memcpy(dest, src, len)

//inet_pton和inet_ntop这2个IP地址转换函数,可以在将IP地址在“点分十进制”和“二进制整数”之间转换
//参数socklen_t cnt,他是所指向缓存区dst的大小,避免溢出,如果缓存区太小无法存储地址的值,则返回一个空指针,并将errno置为ENOSPC
const char *inet_ntop(int af, const void *src, char *dst, socklen_t cnt);

//得到本机地址
extern int getifaddrs(struct ifaddrs **);
//释放本机地址
extern void freeifaddrs(struct ifaddrs *);
还有一些用到的作为参数的结构体:

//socket通信用的 IPV4地址结构体 
struct sockaddr_in {
__uint8_t sin_len; //整个结构体大小
sa_family_t sin_family; //协议族,IPV4?IPV6
in_port_t sin_port; //端口
struct in_addr sin_addr; //IP地址
char sin_zero[8]; //空的占位符,为了和其他地址结构体保持一致大小,方便转化
};
//IPV6地址结构体,和上面的类似
struct sockaddr_in6 {
__uint8_t sin6_len; /* length of this struct(sa_family_t) */
sa_family_t sin6_family; /* AF_INET6 (sa_family_t) */
in_port_t sin6_port; /* Transport layer port # (in_port_t) */
__uint32_t sin6_flowinfo; /* IP6 flow information */
struct in6_addr sin6_addr; /* IP6 address */
__uint32_t sin6_scope_id; /* scope zone index */
};

//用来获取本机IP的参数结构体
struct ifaddrs {
//指向链表的下一个成员
struct ifaddrs *ifa_next;
//接口名称
char *ifa_name;
//接口标识位(比如当IFF_BROADCAST或IFF_POINTOPOINT设置到此标识位时,影响联合体变量ifu_broadaddr存储广播地址或ifu_dstaddr记录点对点地址)
unsigned int ifa_flags;
//接口地址
struct sockaddr *ifa_addr;
//存储该接口的子网掩码;
struct sockaddr *ifa_netmask;

//点对点的地址
struct sockaddr *ifa_dstaddr;
//ifa_data存储了该接口协议族的特殊信息,它通常是NULL(一般不关注他)。
void *ifa_data;
};


这一段内容算是比较枯涩了,但是也是了解socket编程必经之路。

这里提到了网络字节序和主机字节序。我们创建socket之前,必须把port和host这些参数转化为网络字节序。那么为什么要这么做呢?

不同的CPU有不同的字节序类型 这些字节序是指整数在内存中保存的顺序 这个叫做主机序
最常见的有两种
1. Little endian:将低序字节存储在起始地址
2. Big endian:将高序字节存储在起始地址

这样如果我们到网络中,就无法得知互相的字节序是什么了,所以我们就必须统一一套排序,这样网络字节序就有它存在的必要了。


网络字节顺序是TCP/IP中规定好的一种数据表示格式,它与具体的CPU类型、操作系统等无关。从而可以保证数据在不同主机之间传输时能够被正确解释。网络字节顺序采用big endian排序方式。

除此之外比较重要的就是这几个地址结构体了。它定义了我们当前socket的地址信息。包括IP、Port、长度、协议族等等。当然socket中标识为地址的结构体不止这3种,等我们后续代码来补充。


大家了解了我们上述说的知识点,这个方法也就不难度了。这个方法主要是做了本机IPV4IPV6地址的创建和绑定。当然这里分了几种情况:

  1. interface为空的,我们作为客户端不会出现这种情况。注意之前我们是这个参数不为空才会调入这个方法的。
    而这个一般是用于做服务端监听用的,这里的处理是给本机地址绑定0地址(任意地址)。那么这里这么做作用是什么呢?引用一个应用场景来说明:

如果你的服务器有多个网卡(每个网卡上有不同的IP地址),而你的服务(不管是在udp端口上侦听,还是在tcp端口上侦听),出于某种原因:可能是你的服务器操作系统可能随时增减IP地址,也有可能是为了省去确定服务器上有什么网络端口(网卡)的麻烦 —— 可以要在调用bind()的时候,告诉操作系统:“我需要在 yyyy 端口上侦听,所有发送到服务器的这个端口,不管是哪个网卡/哪个IP地址接收到的数据,都是我处理的。”这时候,服务器程序则在0.0.0.0这个地址上进行侦听。

  1. 如果interfacelocalhost或者loopback则把IP设置为127.0.0.1,这里localhost我们大家都知道。那么什么是loopback呢?
    loopback地址叫做回环地址,他不是一个物理接口上的地址,他是一个虚拟的一个地址,只要路由器在工作,这个地址就存在.它是路由器的唯一标识。
    更详细的内容可以看看百科:loopback

  2. 如果是一个其他的地址,我们会去使用getifaddrs()函数得到本机地址。然后去对比本机名或者本机IP。有一个能相同,我们就认为该地址有效,就进行IPV4和IPV6绑定。否则什么都不做。

至此这个本机地址绑定我们就做完了,我们前面也说过,一般我们作为客户端,是不需要做这一步的。如果我们不绑定,系统会自己绑定本机IP,并且选择一个空闲可用的端口。所以这个方法是iOS用来作为服务端调用的。


方法三--前置检查、方法四--本机地址绑定都说完了,我们继续接着之前的方法二往下看:

之前讲到第3点了:
3.这里把flag标记为kSocketStarted:

flags |= kSocketStarted;

源码中大量的运用了3个位运算符:分别是或(|)、与(&)、取反(~)、运算符。 运用这个标记的好处也很明显,可以很简单的标记当前的状态,并且因为flags所指向的枚举值是用左位移的方式:

enum GCDAsyncSocketFlags
{
kSocketStarted = 1 << 0, // If set, socket has been started (accepting/connecting)
kConnected = 1 << 1, // If set, the socket is connected
kForbidReadsWrites = 1 << 2, // If set, no new reads or writes are allowed
kReadsPaused = 1 << 3, // If set, reads are paused due to possible timeout
kWritesPaused = 1 << 4, // If set, writes are paused due to possible timeout
kDisconnectAfterReads = 1 << 5, // If set, disconnect after no more reads are queued
kDisconnectAfterWrites = 1 << 6, // If set, disconnect after no more writes are queued
kSocketCanAcceptBytes = 1 << 7, // If set, we know socket can accept bytes. If unset, it's unknown.
kReadSourceSuspended = 1 << 8, // If set, the read source is suspended
kWriteSourceSuspended = 1 << 9, // If set, the write source is suspended
kQueuedTLS = 1 << 10, // If set, we've queued an upgrade to TLS
kStartingReadTLS = 1 << 11, // If set, we're waiting for TLS negotiation to complete
kStartingWriteTLS = 1 << 12, // If set, we're waiting for TLS negotiation to complete
kSocketSecure = 1 << 13, // If set, socket is using secure communication via SSL/TLS
kSocketHasReadEOF = 1 << 14, // If set, we have read EOF from socket
kReadStreamClosed = 1 << 15, // If set, we've read EOF plus prebuffer has been drained
kDealloc = 1 << 16, // If set, the socket is being deallocated
#if TARGET_OS_IPHONE
kAddedStreamsToRunLoop = 1 << 17, // If set, CFStreams have been added to listener thread
kUsingCFStreamForTLS = 1 << 18, // If set, we're forced to use CFStream instead of SecureTransport
kSecureSocketHasBytesAvailable = 1 << 19, // If set, CFReadStream has notified us of bytes available
#endif
};


所以flags可以通过|的方式复合横跨多个状态,并且运算也非常轻量级,好处很多,所有的状态标记的意义可以在注释中清晰的看出,这里把状态标记为socket已经开始连接了。

4.然后我们调用了一个全局queue,异步的调用连接,这里又做了两件事:

  • 第一步是拿到我们需要连接的服务端server的地址数组:

//server地址数组(包含IPV4 IPV6的地址  sockaddr_in6、sockaddr_in类型)
NSMutableArray *addresses = [[self class] lookupHost:hostCpy port:port error:&lookupErr];





收起阅读 »

CocoaAsyncSocket源码分析---Connect (二)

connect也就是我们在截图中选中的方法,那我们就从这个方法作为起点,开始讲起吧。保证这个连接操作一定是在我们的接着把Block中连接过程产生的错误进行赋值,并且把连接的结果返回出去//如果有错误,赋值错误 if (errPtr) *errPtr =...
继续阅读 »

这里我们先作为客户端来看看connect



其中和connect相关的方法就这么多,我们一般这么来连接到服务端:

[socket connectToHost:Khost onPort:Kport error:nil];


也就是我们在截图中选中的方法,那我们就从这个方法作为起点,开始讲起吧。

本文方法二--connect总方法
/逐级调用
- (BOOL)connectToHost:(NSString*)host onPort:(uint16_t)port error:(NSError **)errPtr
{
return [self connectToHost:host onPort:port withTimeout:-1 error:errPtr];
}

- (BOOL)connectToHost:(NSString *)host
onPort:(uint16_t)port
withTimeout:(NSTimeInterval)timeout
error:(NSError **)errPtr
{
return [self connectToHost:host onPort:port viaInterface:nil withTimeout:timeout error:errPtr];
}

//多一个inInterface,本机地址
- (BOOL)connectToHost:(NSString *)inHost
onPort:(uint16_t)port
viaInterface:(NSString *)inInterface
withTimeout:(NSTimeInterval)timeout
error:(NSError **)errPtr
{
//{} 跟踪当前行为
LogTrace();

// Just in case immutable objects were passed
//拿到host ,copy防止值被修改
NSString *host = [inHost copy];
//interface?接口?
NSString *interface = [inInterface copy];

//声明两个__block的
__block BOOL result = NO;
//error信息
__block NSError *preConnectErr = nil;

//gcdBlock ,都包裹在自动释放池中
dispatch_block_t block = ^{ @autoreleasepool {

// Check for problems with host parameter

if ([host length] == 0)
{
NSString *msg = @"Invalid host parameter (nil or \"\"). Should be a domain name or IP address string.";
preConnectErr = [self badParamError:msg];

//其实就是return,大牛的代码真是充满逼格
return_from_block;
}

// Run through standard pre-connect checks
//一个前置的检查,如果没通过返回,这个检查里,如果interface有值,则会将本机的IPV4 IPV6的 address设置上。
if (![self preConnectWithInterface:interface error:&preConnectErr])
{
return_from_block;
}

// We've made it past all the checks.
// It's time to start the connection process.
//flags 做或等运算。 flags标识为开始Socket连接
flags |= kSocketStarted;

//又是一个{}? 只是为了标记么?
LogVerbose(@"Dispatching DNS lookup...");

// It's possible that the given host parameter is actually a NSMutableString.
//很可能给我们的服务端的参数是一个可变字符串
// So we want to copy it now, within this block that will be executed synchronously.
//所以我们需要copy,在Block里同步的执行
// This way the asynchronous lookup block below doesn't have to worry about it changing.
//这种基于Block的异步查找,不需要担心它被改变

//copy,防止改变
NSString *hostCpy = [host copy];

//拿到状态
int aStateIndex = stateIndex;
__weak GCDAsyncSocket *weakSelf = self;

//全局Queue
dispatch_queue_t globalConcurrentQueue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
//异步执行
dispatch_async(globalConcurrentQueue, ^{ @autoreleasepool {
//忽视循环引用
#pragma clang diagnostic push
#pragma clang diagnostic warning "-Wimplicit-retain-self"

//查找错误
NSError *lookupErr = nil;
//server地址数组(包含IPV4 IPV6的地址 sockaddr_in6、sockaddr_in类型)
NSMutableArray *addresses = [[self class] lookupHost:hostCpy port:port error:&lookupErr];

//strongSelf
__strong GCDAsyncSocket *strongSelf = weakSelf;

//完整Block安全形态,在加个if
if (strongSelf == nil) return_from_block;

//如果有错
if (lookupErr)
{
//用cocketQueue
dispatch_async(strongSelf->socketQueue, ^{ @autoreleasepool {
//一些错误处理,清空一些数据等等
[strongSelf lookup:aStateIndex didFail:lookupErr];
}});
}
//正常
else
{

NSData *address4 = nil;
NSData *address6 = nil;
//遍历地址数组
for (NSData *address in addresses)
{
//判断address4为空,且address为IPV4
if (!address4 && [[self class] isIPv4Address:address])
{
address4 = address;
}
//判断address6为空,且address为IPV6
else if (!address6 && [[self class] isIPv6Address:address])
{
address6 = address;
}
}
//异步去发起连接
dispatch_async(strongSelf->socketQueue, ^{ @autoreleasepool {

[strongSelf lookup:aStateIndex didSucceedWithAddress4:address4 address6:address6];
}});
}

#pragma clang diagnostic pop
}});

//开启连接超时
[self startConnectTimeout:timeout];

result = YES;
}};
//在socketQueue中执行这个Block
if (dispatch_get_specific(IsOnSocketQueueOrTargetQueueKey))
block();
//否则同步的调起这个queue去执行
else
dispatch_sync(socketQueue, block);

//如果有错误,赋值错误
if (errPtr) *errPtr = preConnectErr;
//把连接是否成功的result返回
return result;
}

这个方法非常长,它主要做了以下几件事:

  • 首先我们需要说一下的是,整个类大量的会出现LogTrace()类似这样的宏,我们点进去发现它的本质只是一个{},什么事都没做。

原来这些宏是为了追踪当前执行的流程用的,它被定义在一个大的#if #else中:

#ifndef GCDAsyncSocketLoggingEnabled
#define GCDAsyncSocketLoggingEnabled 0
#endif
#if GCDAsyncSocketLoggingEnabled
// Logging Enabled - See log level below
// Logging uses the CocoaLumberjack framework (which is also GCD based).
// https://github.com/robbiehanson/CocoaLumberjack
//
// It allows us to do a lot of logging without significantly slowing down the code.
#import "DDLog.h"
#define LogAsync YES
#define LogContext GCDAsyncSocketLoggingContext
#define LogObjc(flg, frmt, ...) LOG_OBJC_MAYBE(LogAsync, logLevel, flg, LogContext, frmt, ##__VA_ARGS__)
#define LogC(flg, frmt, ...) LOG_C_MAYBE(LogAsync, logLevel, flg, LogContext, frmt, ##__VA_ARGS__)
#define LogError(frmt, ...) LogObjc(LOG_FLAG_ERROR, (@"%@: " frmt), THIS_FILE, ##__VA_ARGS__)
#define LogWarn(frmt, ...) LogObjc(LOG_FLAG_WARN, (@"%@: " frmt), THIS_FILE, ##__VA_ARGS__)
#define LogInfo(frmt, ...) LogObjc(LOG_FLAG_INFO, (@"%@: " frmt), THIS_FILE, ##__VA_ARGS__)
#define LogVerbose(frmt, ...) LogObjc(LOG_FLAG_VERBOSE, (@"%@: " frmt), THIS_FILE, ##__VA_ARGS__)
#define LogCError(frmt, ...) LogC(LOG_FLAG_ERROR, (@"%@: " frmt), THIS_FILE, ##__VA_ARGS__)
#define LogCWarn(frmt, ...) LogC(LOG_FLAG_WARN, (@"%@: " frmt), THIS_FILE, ##__VA_ARGS__)
#define LogCInfo(frmt, ...) LogC(LOG_FLAG_INFO, (@"%@: " frmt), THIS_FILE, ##__VA_ARGS__)
#define LogCVerbose(frmt, ...) LogC(LOG_FLAG_VERBOSE, (@"%@: " frmt), THIS_FILE, ##__VA_ARGS__)
#define LogTrace() LogObjc(LOG_FLAG_VERBOSE, @"%@: %@", THIS_FILE, THIS_METHOD)
#define LogCTrace() LogC(LOG_FLAG_VERBOSE, @"%@: %s", THIS_FILE, __FUNCTION__)
#ifndef GCDAsyncSocketLogLevel
#define GCDAsyncSocketLogLevel LOG_LEVEL_VERBOSE
#endif
// Log levels : off, error, warn, info, verbose
static const int logLevel = GCDAsyncSocketLogLevel;
#else
// Logging Disabled
#define LogError(frmt, ...) {}
#define LogWarn(frmt, ...) {}
#define LogInfo(frmt, ...) {}
#define LogVerbose(frmt, ...) {}
#define LogCError(frmt, ...) {}
#define LogCWarn(frmt, ...) {}
#define LogCInfo(frmt, ...) {}
#define LogCVerbose(frmt, ...) {}
#define LogTrace() {}
#define LogCTrace(frmt, ...) {}
#endif


而此时因为GCDAsyncSocketLoggingEnabled默认为0,所以仅仅是一个{}。当标记为1时,这些宏就可以用来输出我们当前的业务流程,极大的方便了我们的调试过程。

  • 接着我们回到正题上,我们定义了一个Block,所有的连接操作都被包裹在这个Block中。我们做了如下判断:

    //在socketQueue中执行这个Block
if (dispatch_get_specific(IsOnSocketQueueOrTargetQueueKey))
block();
//否则同步的调起这个queue去执行
else
dispatch_sync(socketQueue, block);

保证这个连接操作一定是在我们的socketQueue中,而且还是以串行同步的形式去执行,规避了线程安全的问题。

  • 接着把Block中连接过程产生的错误进行赋值,并且把连接的结果返回出去
//如果有错误,赋值错误
if (errPtr) *errPtr = preConnectErr;
//把连接是否成功的result返回
return result;

接着来看这个方法声明的Block内部,也就是进行连接的真正主题操作,这个连接过程将会调用许多函数,一环扣一环,我会尽可能用最清晰、详尽的语言来描述...

1.这个Block首先做了一些错误的判断,并调用了一些错误生成的方法。类似:

if ([host length] == 0)
{
NSString *msg = @"Invalid host parameter (nil or \"\"). Should be a domain name or IP address string.";
preConnectErr = [self badParamError:msg];

//其实就是return,大牛的代码真是充满逼格
return_from_block;
}
//用该字符串生成一个错误,错误的域名,错误的参数
- (NSError *)badParamError:(NSString *)errMsg
{
NSDictionary *userInfo = [NSDictionary dictionaryWithObject:errMsg forKey:NSLocalizedDescriptionKey];

return [NSError errorWithDomain:GCDAsyncSocketErrorDomain code:GCDAsyncSocketBadParamError userInfo:userInfo];
}

2.接着做了一个前置的错误检查:
if (![self preConnectWithInterface:interface error:&preConnectErr])
{
return_from_block;
}
这个检查方法,如果没通过返回NO。并且如果interface有值,则会将本机的IPV4 IPV6的 address设置上。即我们之前提到的这两个属性:
  //本机的IPV4地址
NSData * connectInterface4;
//本机的IPV6地址
NSData * connectInterface6;

我们来看看这个前置检查方法:

本文方法三--前置检查方法
//在连接之前的接口检查,一般我们传nil  interface本机的IP 端口等等
- (BOOL)preConnectWithInterface:(NSString *)interface error:(NSError **)errPtr
{
//先断言,如果当前的queue不是初始化quueue,直接报错
NSAssert(dispatch_get_specific(IsOnSocketQueueOrTargetQueueKey), @"Must be dispatched on socketQueue");

//无代理
if (delegate == nil) // Must have delegate set
{
if (errPtr)
{
NSString *msg = @"Attempting to connect without a delegate. Set a delegate first.";
*errPtr = [self badConfigError:msg];
}
return NO;
}
//没有代理queue
if (delegateQueue == NULL) // Must have delegate queue set
{
if (errPtr)
{
NSString *msg = @"Attempting to connect without a delegate queue. Set a delegate queue first.";
*errPtr = [self badConfigError:msg];
}
return NO;
}

//当前不是非连接状态
if (![self isDisconnected]) // Must be disconnected
{
if (errPtr)
{
NSString *msg = @"Attempting to connect while connected or accepting connections. Disconnect first.";
*errPtr = [self badConfigError:msg];
}
return NO;
}

//判断是否支持IPV4 IPV6 &位与运算,因为枚举是用 左位移<<运算定义的,所以可以用来判断 config包不包含某个枚举。因为一个值可能包含好几个枚举值,所以这时候不能用==来判断,只能用&来判断
BOOL isIPv4Disabled = (config & kIPv4Disabled) ? YES : NO;
BOOL isIPv6Disabled = (config & kIPv6Disabled) ? YES : NO;

//是否都不支持
if (isIPv4Disabled && isIPv6Disabled) // Must have IPv4 or IPv6 enabled
{
if (errPtr)
{
NSString *msg = @"Both IPv4 and IPv6 have been disabled. Must enable at least one protocol first.";
*errPtr = [self badConfigError:msg];
}
return NO;
}

//如果有interface,本机地址
if (interface)
{
NSMutableData *interface4 = nil;
NSMutableData *interface6 = nil;

//得到本机的IPV4 IPV6地址
[self getInterfaceAddress4:&interface4 address6:&interface6 fromDescription:interface port:0];

//如果两者都为nil
if ((interface4 == nil) && (interface6 == nil))
{
if (errPtr)
{
NSString *msg = @"Unknown interface. Specify valid interface by name (e.g. \"en1\") or IP address.";
*errPtr = [self badParamError:msg];
}
return NO;
}

if (isIPv4Disabled && (interface6 == nil))
{
if (errPtr)
{
NSString *msg = @"IPv4 has been disabled and specified interface doesn't support IPv6.";
*errPtr = [self badParamError:msg];
}
return NO;
}

if (isIPv6Disabled && (interface4 == nil))
{
if (errPtr)
{
NSString *msg = @"IPv6 has been disabled and specified interface doesn't support IPv4.";
*errPtr = [self badParamError:msg];
}
return NO;
}
//如果都没问题,则赋值
connectInterface4 = interface4;
connectInterface6 = interface6;
}

// Clear queues (spurious read/write requests post disconnect)
//清除queue(假的读写请求 ,提交断开连接)
//读写Queue清除
[readQueue removeAllObjects];
[writeQueue removeAllObjects];

return YES;
}

又是非常长的一个方法,但是这个方法还是非常好读的。

  • 主要是对连接前的一个属性参数的判断,如果不齐全的话,则填充错误指针,并且返回NO。

  • 在这里如果我们interface这个参数不为空话,我们会额外多执行一些操作。
    首先来讲讲这个参数是什么,简单来讲,这个就是我们设置的本机IP+端口号。照理来说我们是不需要去设置这个参数的,默认的为localhost(127.0.0.1)本机地址。而端口号会在本机中取一个空闲可用的端口。
    而我们一旦设置了这个参数,就会强制本地IP和端口为我们指定的。其实这样设置反而不好,其实大家也能想明白,这里端口号如果我们写死,万一被其他进程给占用了。那么肯定是无法连接成功的。
    所以就有了我们做IM的时候,一般是不会去指定客户端bind某一个端口。而是用系统自动去选择。

  • 我们最后清空了当前读写queue中,所有的任务。

至于有interface,我们所做的额外操作是什么呢,我们接下来看下一章






作者:Cooci
链接:https://www.jianshu.com/p/9968ff0280e5






收起阅读 »

CocoaAsyncSocket源码分析---Connect (一)

CocoaAsyncSocket是谷歌的开发者,基于BSD-Socket写的一个IM框架,它给Mac和iOS提供了易于使用的、强大的异步套接字库,向上封装出简单易用OC接口。省去了我们面向Socket以及数据流Stream等繁琐复杂的编程。本文为一个系列,旨在...
继续阅读 »
CocoaAsyncSocket是谷歌的开发者,基于BSD-Socket写的一个IM框架,它给Mac和iOS提供了易于使用的、强大的异步套接字库,向上封装出简单易用OC接口。省去了我们面向Socket以及数据流Stream等繁琐复杂的编程。
本文为一个系列,旨在让大家了解CocoaAsyncSocket是如何基于底层进行封装、工作的。

附上一张socket流程图



正文:
首先我们来看看框架:

整个库就这么两个类,一个基于TCP,一个基于UDP。其中基于TCP的GCDAsyncSocket,大概8000多行代码。而GCDAsyncUdpSocket稍微少一点,也有5000多行。
所以单纯从代码量上来看,这个库还是做了很多事的。

顺便提一下,之前这个框架还有一个runloop版的,不过因为功能重叠和其它种种原因,后续版本便废弃了,现在仅有GCD版本。

本系列我们将重点来讲GCDAsyncSocket这个类。

我们先来看看这个类的属性:

@implementation GCDAsyncSocket
{
//flags,当前正在做操作的标识符
uint32_t flags;
uint16_t config;

//代理
__weak id<GCDAsyncSocketDelegate> delegate;
//代理回调的queue
dispatch_queue_t delegateQueue;

//本地IPV4Socket
int socket4FD;
//本地IPV6Socket
int socket6FD;
//unix域的套接字
int socketUN;
//unix域 服务端 url
NSURL *socketUrl;
//状态Index
int stateIndex;

//本机的IPV4地址
NSData * connectInterface4;
//本机的IPV6地址
NSData * connectInterface6;
//本机unix域地址
NSData * connectInterfaceUN;

//这个类的对Socket的操作都在这个queue中,串行
dispatch_queue_t socketQueue;

dispatch_source_t accept4Source;
dispatch_source_t accept6Source;
dispatch_source_t acceptUNSource;

//连接timer,GCD定时器
dispatch_source_t connectTimer;
dispatch_source_t readSource;
dispatch_source_t writeSource;
dispatch_source_t readTimer;
dispatch_source_t writeTimer;

//读写数据包数组 类似queue,最大限制为5个包
NSMutableArray *readQueue;
NSMutableArray *writeQueue;

//当前正在读写数据包
GCDAsyncReadPacket *currentRead;
GCDAsyncWritePacket *currentWrite;
//当前socket未获取完的数据大小
unsigned long socketFDBytesAvailable;

//全局公用的提前缓冲区
GCDAsyncSocketPreBuffer *preBuffer;

#if TARGET_OS_IPHONE
CFStreamClientContext streamContext;
//读的数据流
CFReadStreamRef readStream;
//写的数据流
CFWriteStreamRef writeStream;
#endif
//SSL上下文,用来做SSL认证
SSLContextRef sslContext;

//全局公用的SSL的提前缓冲区
GCDAsyncSocketPreBuffer *sslPreBuffer;
size_t sslWriteCachedLength;

//记录SSL读取数据错误
OSStatus sslErrCode;
//记录SSL握手的错误
OSStatus lastSSLHandshakeError;

//socket队列的标识key
void *IsOnSocketQueueOrTargetQueueKey;

id userData;

//连接备选服务端地址的延时 (另一个IPV4或IPV6)
NSTimeInterval alternateAddressDelay;
}

这个里定义了一些属性,可以先简单看看注释,这里我们仅仅先暂时列出来,给大家混个眼熟。
在接下来的代码中,会大量穿插着这些属性的使用。所以大家不用觉得困惑,具体作用,我们后面会一一讲清楚的。

接着我们来看看本文方法一--初始化方法:
//层级调用
- (id)init
{
return [self initWithDelegate:nil delegateQueue:NULL socketQueue:NULL];
}

- (id)initWithSocketQueue:(dispatch_queue_t)sq
{
return [self initWithDelegate:nil delegateQueue:NULL socketQueue:sq];
}

- (id)initWithDelegate:(id)aDelegate delegateQueue:(dispatch_queue_t)dq
{
return [self initWithDelegate:aDelegate delegateQueue:dq socketQueue:NULL];
}

- (id)initWithDelegate:(id)aDelegate delegateQueue:(dispatch_queue_t)dq socketQueue:(dispatch_queue_t)sq
{
if((self = [super init]))
{
delegate = aDelegate;
delegateQueue = dq;

//这个宏是在sdk6.0之后才有的,如果是之前的,则OS_OBJECT_USE_OBJC为0,!0即执行if语句
//对6.0的适配,如果是6.0以下,则去retain release,6.0之后ARC也管理了GCD
#if !OS_OBJECT_USE_OBJC

if (dq) dispatch_retain(dq);
#endif

//创建socket,先都置为 -1
//本机的ipv4
socket4FD = SOCKET_NULL;
//ipv6
socket6FD = SOCKET_NULL;
//应该是UnixSocket
socketUN = SOCKET_NULL;
//url
socketUrl = nil;
//状态
stateIndex = 0;

if (sq)
{
//如果scoketQueue是global的,则报错。断言必须要一个非并行queue。
NSAssert(sq != dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_LOW, 0),
@"The given socketQueue parameter must not be a concurrent queue.");
NSAssert(sq != dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0),
@"The given socketQueue parameter must not be a concurrent queue.");
NSAssert(sq != dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0),
@"The given socketQueue parameter must not be a concurrent queue.");
//拿到scoketQueue
socketQueue = sq;
//iOS6之下retain
#if !OS_OBJECT_USE_OBJC
dispatch_retain(sq);
#endif
}
else
{
//没有的话创建一个, 名字为:GCDAsyncSocket,串行
socketQueue = dispatch_queue_create([GCDAsyncSocketQueueName UTF8String], NULL);
}

// The dispatch_queue_set_specific() and dispatch_get_specific() functions take a "void *key" parameter.
// From the documentation:
//
// > Keys are only compared as pointers and are never dereferenced.
// > Thus, you can use a pointer to a static variable for a specific subsystem or
// > any other value that allows you to identify the value uniquely.
//
// We're just going to use the memory address of an ivar.
// Specifically an ivar that is explicitly named for our purpose to make the code more readable.
//
// However, it feels tedious (and less readable) to include the "&" all the time:
// dispatch_get_specific(&IsOnSocketQueueOrTargetQueueKey)
//
// So we're going to make it so it doesn't matter if we use the '&' or not,
// by assigning the value of the ivar to the address of the ivar.
// Thus: IsOnSocketQueueOrTargetQueueKey == &IsOnSocketQueueOrTargetQueueKey;

//比如原来为 0X123 -> NULL 变成 0X222->0X123->NULL
//自己的指针等于自己原来的指针,成二级指针了 看了注释是为了以后省略&,让代码更可读?
IsOnSocketQueueOrTargetQueueKey = &IsOnSocketQueueOrTargetQueueKey;

void *nonNullUnusedPointer = (__bridge void *)self;

//dispatch_queue_set_specific给当前队里加一个标识 dispatch_get_specific当前线程取出这个标识,判断是不是在这个队列
//这个key的值其实就是一个一级指针的地址 ,第三个参数把自己传过去了,上下文对象?第4个参数,为销毁的时候用的,可以指定一个函数
dispatch_queue_set_specific(socketQueue, IsOnSocketQueueOrTargetQueueKey, nonNullUnusedPointer, NULL);
//读的数组 限制为5
readQueue = [[NSMutableArray alloc] initWithCapacity:5];
currentRead = nil;

//写的数组,限制5
writeQueue = [[NSMutableArray alloc] initWithCapacity:5];
currentWrite = nil;

//设置大小为 4kb
preBuffer = [[GCDAsyncSocketPreBuffer alloc] initWithCapacity:(1024 * 4)];

#pragma mark alternateAddressDelay??
//交替地址延时?? wtf
alternateAddressDelay = 0.3;
}
return self;
}


其中值得一提的是第三种:UnixSocket,这个是用于Unix Domin Socket通信用的。
那么什么是Unix Domain Socket呢?
原来它是在socket的框架上发展出一种IPC(进程间通信)机制,虽然网络socket也可用于同一台主机的进程间通讯(通过loopback地址127.0.0.1),但是UNIX Domain Socket用于IPC 更有效率 :

  • 不需要经过网络协议栈
  • 不需要打包拆包、计算校验和、维护序号和应答等,只是将应用层数据从一个进程拷贝到另一个进程。这是因为,IPC机制本质上是可靠的通讯,而网络协议是为不可靠的通讯设计的。UNIX Domain Socket也提供面向流和面向数据包两种API接口,类似于TCP和UDP,但是面向消息的UNIX Domain Socket也是可靠的,消息既不会丢失也不会顺序错乱。

基本上它是当今应用于IPC最主流的方式。至于它到底和普通的socket通信实现起来有什么区别,别着急,我们接着往下看。

3.生成了一个socketQueue,这个queue是串行的,接下来我们看代码就会知道它贯穿于这个类的所有地方。所有对socket以及一些内部数据的相关操作,都需要在这个串行queue中进行。这样使得整个类没有加一个锁,就保证了整个类的线程安全。

4.创建了两个读写队列(本质数组),接下来我们所有的读写任务,都会先追加在这个队列最后,然后每次取出队列中最前面的任务,进行处理。

5.创建了一个全局的数据缓冲区:preBuffer,我们所操作的数据,大部分都是要先存入这个preBuffer中,然后再从preBuffer取出进行处理的。

6.初始化了一个交替延时变量:alternateAddressDelay,这个变量先简单的理解下:就是进行另一个服务端地址请求的延时。后面我们一讲到,大家就明白了。

初始化方法就到此为止了。

接着我们有socket了,我们如果是客户端,就需要去connect服务器。

又或者我们是服务端的话,就需要去bind端口,并且accept,等待客户端的连接。(基本上也没有用iOS来做服务端的吧...)

connect总方法见下篇


全篇地址

CocoaAsyncSocket源码分析---Connect (一)

CocoaAsyncSocket源码分析---Connect (二)

CocoaAsyncSocket源码分析---Connect (三)

CocoaAsyncSocket源码分析---Connect (四)

CocoaAsyncSocket源码分析---Connect (五)

CocoaAsyncSocket源码分析---Connect (六)

CocoaAsyncSocket源码分析---Connect (七)


作者:Cooci

链接:https://www.jianshu.com/p/9968ff0280e5







收起阅读 »

汉字笔顺动画技术剖析

背景 汉字笔顺动画是常见的语文教育需求,我们导入网上开源的 Hanzi Writter 并部署编辑器,应用在大力智能作业灯上。在原版前端实现基础上我们扩展了 Android 和 iOS 端实现,提供更优化的笔顺动画性能。增强对笔顺绘制的控制能力,实现了指定笔...
继续阅读 »

背景


汉字笔顺动画是常见的语文教育需求,我们导入网上开源的 Hanzi Writter 并部署编辑器,应用在大力智能作业灯上。在原版前端实现基础上我们扩展了 Android 和 iOS 端实现,提供更优化的笔顺动画性能。增强对笔顺绘制的控制能力,实现了指定笔顺/笔段渲染,支持笔顺批改和描红能力。



关键技术


1. 字形数据提取


字形是单个字符的外观形状,而字体是具有相同外观样式和排版尺寸的字形集合。基于字形数据,我们可以实现每个文字的渲染和笔顺动画。那么该如何拿到字形数据呢?TTF就是不错的选择。TTF(TrueTypeFont)是一种曲线描边字体文件格式,由Apple公司和Microsoft公司共同推出,其文件扩展名为.ttf。它支持多种字体,如语文课本中常见的楷体。TTF文件由一系列表组成,其中glyf表就包括了字形数据,即字形的轮廓定义和调整指令。依据下述流程可以提取字形数据:



  1. 对不同字体的boundary进行适配,全部转换成1024*1024,并对上下左右进行微调。

  2. 提取所有字形glyph的轮廓点contours和path数据。



提取出字形数据后,使用SVG将对应文字绘制出来。



2. Stroke Extraction 笔画拆取


在第一节中实现了字形数据的提取,它包括字形的轮廓点contours及path(a)。但是仅依靠这些数据无法实现笔顺动画,因为它们只有轮廓信息,没有笔画信息,只要有交叉重叠,都会识别成同一个体(b)。因此,要实现笔顺动画,就必须从源数据中拆取出所有笔画的轮廓数据,即笔画拆取。



2.1 解决思路


由于笔画之间存在交叉重叠(c),若要实现笔画拆取,就需要将笔画交接处的凹点连通起来。这些处于交叉处特殊的拐角点称为corner,连通两个corner形成bridge,表明他们同属于一个笔画。


当顺时针跟踪端点:



  • 连通前:依据轮廓点顺序。


  • 连通后:会依据bridge直接联通对应corner,从而实现笔画的拆分。




因此,笔画拆取工作主要分为以下四步:



2.2 EndPoint Parsing Corner检测


在Hanzi Writter开源库中,笔画拆取算法主要围绕corner展开。那corner是什么呢?详细来说,corner是位于两个笔画轮廓交界的特殊端点,通常情况下,他会有另一个corner与之匹配,如C1和C2。C1和C2相邻且处于笔画A的轮廓同侧,连通C1和C2就可以将笔画A和笔画B拆分开来,得到笔画A自己的轮廓数据。这些corner具有显著的局部特征,它们是字形的凹点,经过该点处的path会沿着顺时针急剧弯曲。计算出所有端点的角度和距离,判断是否拥有该特征,就可以检测哪些端点为corner。



function Endpoint(paths, index) {
this.index = index;
const path = paths[index[0]];
const n = path.length;
this.indices = [[index[0], (index[1] + n - 1) % n], index];
this.segments = [path[(index[1] + n - 1) % n], path[index[1]]];
this.point = this.segments[0].end;
assert(Point.valid(this.point), this.apoint);
assert(Point.equal(this.point, this.segments[1].start), path);
this.tangents = [
Point.subtract(this.segments[0].end, this.segments[0].start),
Point.subtract(this.segments[1].end, this.segments[1].start),
];
const threshold = Math.pow(MIN_CORNER_TANGENT_DISTANCE, 2);
if (this.segments[0].control !== undefined &&
Point.distance2(this.point, this.segments[0].control) > threshold) {
this.tangents[0] = Point.subtract(this.point, this.segments[0].control);
}
if (this.segments[1].control !== undefined &&
Point.distance2(this.point, this.segments[1].control) > threshold) {
this.tangents[1] = Point.subtract(this.segments[1].control, this.point);
}
this.angles = this.tangents.map(Point.angle);
const diff = Angle.subtract(this.angles[1], this.angles[0]);
this.corner = diff < -MIN_CORNER_ANGLE;
return this;
}

2.3 Corner Match Scoring 通过NN评分Corner匹配度


检测出一组corner数据后,就要对这些corner进行一对一匹配,但在匹配前还需要评判哪些corner更有可能连接起来。开源库采用神经网络算法计算corner间的匹配度,它将成为匹配算法中的权重值,使匹配结果更贴近现实情况。


const scoreCorners = (ins, out, classifier) => {
return classifier(getFeatures(ins, out));
}


import {NEURAL_NET_TRAINED_FOR_STROKE_EXTRACTION} from '/lib/net';
import {stroke_extractor} from '/lib/stroke_extractor';

Meteor.startup(() => {
const input = new convnetjs.Vol(1, 1, 8 /* feature vector dimensions */);
const net = new convnetjs.Net();
net.fromJSON(NEURAL_NET_TRAINED_FOR_STROKE_EXTRACTION);
const weight = 0.8;

const trainedClassifier = (features) => {
input.w = features;
const softmax = net.forward(input).w;
return softmax[1] - softmax[0];
}

stroke_extractor.combinedClassifier = (features) => {
return stroke_extractor.handTunedClassifier(features) +
weight*trainedClassifier(features);
}
});

2.4 Corner Matching 通过匈牙利算法进行Corner匹配


在2.3小节中已经通过神经网络产生了权重,接下来就可以使用最简单的匈牙利算法,实现corner匹配。




const matchCorners = (corners, classifier) => {
const matrix = [];
for (let i = 0; i < corners.length; i++) {
matrix.push([]);
for (let j = 0; j < corners.length; j++) {
matrix[i].push(scoreCorners(corners[i], corners[j], classifier)); //corner之间相关性
}
}
for (let i = 0; i < corners.length; i++) {
for (let j = 0; j < corners.length; j++) {
const reversed_score = matrix[j][i] - REVERSAL_PENALTY;
if (reversed_score > matrix[i][j]) {
matrix[i][j] = reversed_score;
}
}
}
return (new Hungarian(matrix)).x_match;
}

2.5 Make Bridges 连通配对端点拆分笔画


依据2.4小节的匹配结果返回一组bridge,其中每个bridge包含两个corner。跟踪轮廓的同时连通corner,就可以提取出每个笔画的轮廓数据,实现笔画拆分。值得注意的是,当遇到多个bridge时,选择与当前path构成最大角度的bridge。



const getBridges = (endpoints, classifier) => {
const result = [];
const corners = endpoints.filter((x) => x.corner);
const matching = matchCorners(corners, classifier);
for (let i = 0; i < corners.length; i++) {
const j = matching[i];
if (j <= i && matching[j] === i) {
continue;
}
result.push([Point.clone(corners[i].point), Point.clone(corners[j].point)]);
}
result.map(checkBridge);
return result;
}

const stroke_paths = extractStrokes(paths, endpoints, bridges, log);
const strokes = stroke_paths.map((x) => svg.convertPathsToSVGPath([x]));

3. Medians 笔画中点生成


在第二节中实现了笔画的拆分,得到每个笔画的轮廓数据。依据轮廓数据可以进一步生成笔画的中点骨架。轮廓决定单个笔画的绘制范围,而中点则决定了绘制的顺序和方向。结合轮廓和中点数据,就可以实现单个笔画的绘制动画。接下来就让我们一起了解,如何通过轮廓数据生成中点。



3.1 Polygon Approximation 端点加密


首先,为了提高中点生成结果的可靠性,需要先采用矢量图形的多边形近似方法进行轮廓点加密。TrueType字体利用二次贝赛尔曲线和直线来描述字形的轮廓,因此加密公式如下:




svg.getPolygonApproximation = (path, approximation_error) => {
const result = [];
approximation_error = approximation_error || 64;
for (let x of path) {
const control = x.control || Point.midpoint(x.start, x.end);
const distance = Math.sqrt(Point.distance2(x.start, x.end));
const num_points = Math.floor(distance/approximation_error);
for (let i = 0; i < num_points; i++) {
const t = (i + 1)/(num_points + 1);
const s = 1 - t;
result.push([s*s*x.start[0] + 2*s*t*control[0] + t*t*x.end[0],
s*s*x.start[1] + 2*s*t*control[1] + t*t*x.end[1]]);
}
result.push(x.end);
}
return result;
}

3.2 Polygon Voronoi 通过冯洛诺伊图(泰森多边形)生成中点


得到加密的轮廓点数据后,就可以通过泰森多边形生成中点。那什么是泰森多边形呢?


首先对一组零散控制点做如下操作:



  1. 将三个相邻控制点连成一个三角形

  2. 对三角形的每条边做垂直平分线

  3. 这些垂直平分线会组成连续多边形


这些连续多边形就是泰森多边形,又叫冯洛诺伊图(Voronoi diagram),得名于Georgy Voronoi。在IS和地理分析中经常采用泰森多边形进行快速插值,分析地理实体的影响区域,是解决邻接度问题的又一常用工具。



通过原理可以了解到,泰森多边形每个顶点是对应三角形的外接圆圆心,因此它到这些控制点的距离相等。


  var sites = [{x:300,y:300}, {x:100,y:100}, {x:200,y:500}, {x:250,y:450}, {x:600,y:150}];
// xl, xr means x left, x right
// yt, yb means y top, y bottom
var bbox = {xl:0, xr:800, yt:0, yb:600};
var voronoi = new Voronoi();
// pass an object which exhibits xl, xr, yt, yb properties. The bounding
// box will be used to connect unbound edges, and to close open cells
result = voronoi.compute(sites, bbox);
// render, further analyze, etc.

按照这个思路,可以将笔画的轮廓点作为控制点,生成泰森多边形。提取泰森多边形的顶点作为笔画中心点。



const findStrokeMedian = (stroke) => {
...
for (let approximation of [16, 64]) {
polygon = svg.getPolygonApproximation(paths[0], approximation);
voronoi = voronoi || new Voronoi;
const sites = polygon.map((point) => ({x: point[0], y: point[1]}));
const bounding_box = {xl: -size, xr: size, yt: -size, yb: size};
try {
diagram = voronoi.compute(sites, bounding_box);
break;
} catch(error) {
console.error(`WARNING: Voronoi computation failed at ${approximation}.`);
}
}
...
}

4. 笔画顺序


第三节实现了单个笔画的绘制动画,但还是需要解决笔画之间的顺序问题。解决问题的关键,就是依据汉字结构,将目标汉字不断拆解成已知顺序的字。


在开源库中提供了汉字分解数据库,关键字段如下:



以【胡】为例,?表示胡为左右结构,左边为古,右边为月。



以【湖】为例,拆解过程如下:




拆解完笔顺后,需要将所有零散的中点数据,与当前所拥有的中点再做一遍匈牙利算法匹配,最终可得到一个相对正确的笔画顺序结果,生成json文件。下面为汉字“丁”的笔顺结果文件。


{"strokes": ["M 531 651 Q 736 675 868 663 Q 893 662 899 670 Q 906 683 894 696 Q 863 724 817 744 Q 801 750 775 740 Q 712 725 483 694 Q 185 660 168 657 Q 162 658 156 657 Q 141 657 141 645 Q 140 632 160 618 Q 178 605 211 594 Q 221 590 240 599 Q 348 629 470 644 L 531 651 Z", "M 435 100 Q 407 107 373 116 Q 360 120 361 112 Q 361 103 373 94 Q 445 39 491 -5 Q 503 -15 518 2 Q 560 60 553 141 Q 541 447 548 561 Q 548 579 550 596 Q 556 624 549 635 Q 545 642 531 651 C 509 671 457 671 470 644 Q 485 629 485 573 Q 488 443 488 148 Q 487 112 477 99 Q 464 92 435 100 Z"], "medians": [[[153, 645], [177, 634], [219, 628], [416, 663], [794, 706], [823, 702], [887, 679]], [[478, 644], [518, 610], [518, 101], [495, 55], [450, 68], [369, 110]]]}

5. 相关参考


本文重点剖析了开源库中笔顺动画的关键技术,相关参考资料如下:



  1. hanziwriter.org/

  2. www.skishore.me/makemeahanz…

  3. github.com/skishore/ma…

收起阅读 »

从一个10年程序员的角度告诉你:搞懂Java面向对象有多容易?

前言: 1)java 面向对象语言,面向过程围绕过程(解决问题步骤),面向对象围绕实体(名词,特性(属性),行为(动作、方法))。它们设计思想区别在于关心核心不同的。 主流都是面向对象的。 实际开发,先按面向对象思想进行设计,具体实现时面向过程(人...
继续阅读 »


前言:



  • 1)java
    面向对象语言,面向过程围绕过程(解决问题步骤),面向对象围绕实体(名词,特性(属性),行为(动作、方法))。它们设计思想区别在于关心核心不同的。


主流都是面向对象的。


实际开发,先按面向对象思想进行设计,具体实现时面向过程(人习惯)



  • 2)java 怎么支持面向对象呢?


a. 万物皆对象,所有的类都是 Object 子类


b. java 中支持单继承,多重继承,Tiger 是 Animal 子类,Animal 是 Object 的子类。满足单继承(每次都一个父类,超类)


c. 面向对象的 4 大特性:封装、继承、多态、抽象



  • 3)封装的优点


a. 隐藏细节,开发者关注内容就少,好写代码,


b. 安全,你不需要知道我内部实现细节,private 修饰后,外部不能访问。


c. 方便修改,私有,外部不能访问,修改不影响其他类(送耦合)



  • 4)继承


a. extends 继承


a.1 继承实现类 class


a.2 继承抽象类 abstract class (必须有抽象方法,子类去实现)


b. implements 实现


实现接口 interface (里面全是抽象方法,子类去实现)


面向对象



  • 1)面向过程(早期)、面向对象(主流)、面向服务(SOA、微服务)(主流,在面向对象基础上)


  • 2)面向过程和面向对象的区别?



编程思想,做一件同样事情,做的思路不同。


思路不同在哪里?


例子:把大象放到冰箱里。(本意:把公大象放到格力冰箱中)需求变更


面向过程:开发步骤(流水账)
a. 把冰箱门打开



  • b. 把什么放进去:大象


  • c. 把大象放入冰箱


  • d. 把冰箱门关上



找出主体:名词(冰箱、大象),围绕它做事


找出动作:动词(打开、放入、关上),强调过程


面向过程:找出把名词主体,和动作(动词)连接起来,最后怎么完成整个过程!


面向对象:



  • a. 找出主体(名词:冰箱、大象)


  • b. 创建模型:(额外考虑,感觉画蛇添足)



冰箱:容大、颜色、品牌、耗电、打开、关上


大象:产地、公母、皮、腿



  • c. 执行步骤


打开冰箱,把大象放入冰箱,关上门


它考虑额外事情,目前为止用户不关心。


在实际开发中,用户不遵守他的话,他说的话不算数。


实际开发中,无法完全(合同),无法严格按合同执行,开发者就必须适应用户的需求变更。


从这一实际角度出发,面向过程思考好还是面向对象思考好!


如果按照面向过程思考,它不能适应用户需求变更,要修改代码,加班加点完成。前面考虑不够完善。


如果按照面向对象思考,它提前考虑很多细节,超过用户要求,表面上多考虑了,但是当用户需求变化,刚好就在我们多考虑范畴中!代码不需改,改动量很少。按期完成,无需额外资金投入。


面向对象要考虑很多,考虑范围,不能太广,过度设计。设计都需要人力物力。


有一个平衡点,设计多大范围合适呢? 系统分析师(高薪!)8 年


到超市购买商品


第一次用户提出需求:要购买白酒和花生米


第二次用户提出需求:要购买白酒和花生米,买猪头肉(需求变更)


第三次用户提出需求:+ 凉菜


用户变化 n 次


面向过程:


1)到哪个超市


2)挑选商品(白酒、花生米)2 种,


3)购买,结束


每次需求都要改,有可能之前代码框架都无法适应新需求,翻天覆地重做。


面向对象:


1)都有哪些超市,都有哪些商品,对超市商品全部建模 2000 种商品


2)到某个超市,挑选商品(白酒、花生米、猪头肉、凉菜)


3)购买,结束


总的来说:面向对象优于面向过程设计,主流设计思想面向对象设计!


java 是怎么支持面向对象设计的?


java 面向对象,c 面向过程,c++面向对象,python 面向对象,javascript 面向对象,vue 框架面向对象


java 四大特性:围绕面向对象而言:封装、继承、多态、抽象


封装


面向过程过程中每个细节都需要开发者去了解,封装改变这样方式,它先进行建模,把名称创建对象,设置它的属性(代表这个事物的特点)和方法(表现一些动作)


把生活中的物品抽象成 java 中的对象


对象为了简单,有些内容对外暴露,有些内容隐藏。隐藏就体现了封装。


例子:手机


如果知道手机所有细节,我们现在都用不上手机。



  • 1)对外暴露:屏幕、键盘、话筒、耳机、充电器

  • 2)隐藏:怎么通讯,运行 app


对有些内容使用者是不关心它的内部实现,手机把这些内容进行封装,用户使用就简单了。


代码如何实现封装呢?


有些功能用户不能去访问,用户不需要知道内容封装。


它需要知道,我们会单独给它接口 api


手机:
1)创建一个类:Phone


2)类中封装,对外看不到,创建属性 call、keys,私有 private (体现了封装)


3)对外暴露:怎么开发 call,怎么开发 keys?公有 public


package cn.tedu.oop;
//模拟手机建模(建立模型)需求中的名词
public class Phone {
//成员变量,可以在多个方法中直接调用
private String call; //模拟打电话特性
private String keys; //模拟手机键盘特性
//如何对外暴露私有的属性,对其进行操作。
//使用getXxx(获取)和setXxx(设置)方法来操作私有属性
//这个业界的规范,开发工具都直接支持自动产生对应属性的get和set方法
//私有属性外部不能访问,但在类的内部的方法可以直接访问
public String getCall() {
return call;
}
//外部怎么去设置成员变量值呢?setCall方法的参数
public void setCall(String call) {
//前面成员变量,后面是参数,参数就保存了用户设置值,
//以后用户使用get方法就可以获取新的值
//参数名和成员变量的名称重复,怎么区分谁是谁呢?
//this.value就可以区分,this代表本类,对象,this.value代表成员变量,就不是参数名
this.call = call;
}
public String getKeys() {
return keys;
}//加入Java开发交流君样:756584822一起吹水聊天
public void setKeys(String keys) {
//警察,监听电话,
//用户只管调用setKeys方法,它并不知道这块代码
if( keys.equals("110") ) { //判断keys值是否为110
System.out.println("通知警察");
}
this.keys = keys;
}
}

在这里插入图片描述


封装的好处


1)把不让外界知道的信息就隐藏起来,外部无法操作。代码比较安全,外部无法操作。


2)代码只能内部处理。当代码修改,所有调用地方都要随之改变,这种结构紧耦合。如果代码只能内部修改,修改后,外部丝毫不影响,这种结构松耦合。程序能实现松耦合就松耦合。封装就实现松耦合结构。内部修改不影响其他代码。


3)封装后,里面程序实现细节,对应调用者来说不关心,只关心如何使用。把复杂问题变简单。


继承


什么叫继承?


java 中继承和生活继承是一样一样的。父类(父亲)和子类(自己)。父亲父亲,子类子类。


java 继承单继承,c 语言允许多继承(c 语言代码质量出错,很难找的其中一个原因)。在这里插入图片描述
结论:java 中单继承,但是可以多层


java 中如何实现继承关系?


实现继承关系提供 2 个方式:


1)extends 关键字(继承):语法 extends 后面跟类(class 实现类、abstract class 抽象类)


Tiger extends Animal


Eagle extends Animal


特点:Animal 是一个实现类,它具体实现 eat 方法


抽象类特点:它有部分实现(父类自己实现)和部分规定不实现的(子类去实现)


Tiger extends AbstractAnimal(抽象类中有抽象方法,抽象方法父类不实现,压到子类去实现)


2)implements 关键字(实现):语法 implements 后面跟接口(interface)


接口特点:所有方法都是抽象方法,一点活都不干,它指手画脚(它要规定子类实现方法)


为什么要使用继承?


我们可以从父类继承它的属性和方法,在子类中直接调用父类资源(属性和方法),方法和属性都是 public。在这里插入图片描述
在这里插入图片描述
通过对上面两个类的观察:


1)它们有共性,eat 方法一样


2)它们有个性,Tiger 类它有自己的 run()方法,Eagle 类它有自己的 fly()方法。


有共性有不同!在这里插入图片描述
缺点:


共性的方法,出现在多个类中,如果业务需要修改,要修改多处,工作量大,容易造成失误,这个类改,那个类


忘改,造成结果不一致!


继承


解决办法?就是继承!


1)要把共性方法抽取出来,放到一个单独类中 Animal


2)把共性方法就从当前类中删除


3)两个类连接起来,使用继承,Tiger extends Animal,可以在子类中直接访问父类方法 eat()
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述


抽象类


在这里插入图片描述
在这里插入图片描述
在这里插入图片描述


接口


在这里插入图片描述
在这里插入图片描述
在这里插入图片描述


实现类和抽象类和接口区别


在这里插入图片描述


为什么需要抽象类?


学框架,框架中很多抽象类。例如:spring 框架


框架要做很多底层公用事情,让我们写代码利用框架,程序更加健壮,更加安全,


业务需求私有事情,还得我们去实现


公用框架实现,私有我们自己实现,我们自己写代码怎么和框架对接。框架进行规定!


规范私有类(抽象方法声明)


为什么需要接口?


提倡面向接口开发,你可以实现接口,别人可不可以接口。


java JDBC 数据库一套规范,java 自身规定接口,其他厂商去实现


mysql 数据库厂商,Mysql 的实现;oracle 数据库厂商,oracle 的实现。


小结


今日给大家分享的是面向对象,这对于很多小白来说很友好的,大家都能看得懂!
生命不止坚毅鱼奋斗,有梦想才是有意义的追求
给大家推荐一个免费的学习交流群:
最后,祝大家早日学有所成,拿到满意offer,快速升职加薪,走上人生巅峰。
Java开发交流君样:756584822

收起阅读 »

不懂泛型,怎么装逼,一文把泛型说的明明白白,安排!!!

目录 前言 1、泛型的概念 2、泛型的使用 3、泛型原理,泛型擦除 3.1 IDEA 查看字节码 3.2 泛型擦除原理 4、?和 T 的区别 5、super extends 6、注意点 1、静态方法无法访问类的泛型 2、创建之后无法修改类...
继续阅读 »

图片


目录


前言


1、泛型的概念


2、泛型的使用


3、泛型原理,泛型擦除


3.1 IDEA 查看字节码


3.2 泛型擦除原理


4、?和 T 的区别


5、super extends


6、注意点


1、静态方法无法访问类的泛型


2、创建之后无法修改类型


3、类型判断问题


4、创建类型实例


7、总结




前言


 


泛型是Java中的高级概念,也是构建框架必备技能,比如各种集合类都是泛型实现的,今天详细聊聊Java中的泛型概念,希望有所收获。记得点赞,关注,分享哦。


1、泛型的概念


泛型的作用就是把类型参数化,也就是我们常说的类型参数


平时我们接触的普通方法的参数,比如public void fun(String s);参数的类型是String,是固定的


现在泛型的作用就是再将String定义为可变的参数,即定义一个类型参数T,比如public static <T> void fun(T t);这时参数的类型就是T的类型,是不固定的


泛型常见的字母有以下:


? 表示不确定的类型
T (type) 表示具体的一个java类型
K V (key value) 分别代表java键值中的Key Value
E (element) 代表Element

这些字母随意使用,只是代表类型,也可以用单词。


2、泛型的使用


泛型有三种使用方式,分别为:泛型类、泛型接口、泛型方法。


类的使用地方是


方法的使用地方



  • Java泛型类


  • Java泛型方法


  • Java泛型接口



/**
* @author 香菜
*/
public class Player<T> {// 泛型类
  private T name;
  public T getName() {
      return name;
  }
  public void setName(T name) {
      this.name = name;
  }
}


 


public class Apple extends Fruit {
  public <T> void getInstance(T t){// 泛型方法
      System.out.println(t);
  }
}


public interface Generator<T> {
   
      public T next();
   
  }


3、泛型原理,泛型擦除


3.1 IDEA 查看字节码


1、创建Java文件,并编译,确认生成了class


图片


2、idea ->选中Java 文件 ->View


图片


3.2 泛型擦除原理


我们通过例子来看一下,先看一个非泛型的版本:


图片


从字节码可以看出,在取出对象的的时候我们做了强制类型转换。


下面我们给出一个泛型的版本,从字节码的角度来看看:


图片


在编译过程中,类型变量的信息是能拿到的。所以,set方法在编译器可以做类型检查,非法类型不能通过编译。但是对于get方法,由于擦除机制,运行时的实际引用类型为Object类型。为了“还原”返回结果的类型,编译器在get之后添加了类型转换。所以,在Player.class文件main方法主体第18行有一处类型转换的逻辑。它是编译器自动帮我们加进去的


所以在泛型类对象读取和写入的位置为我们做了处理,为代码添加约束。


泛型参数将会被擦除到它的第一个边界(边界可以有多个,重用 extends 关键字,通过它能给与参数类型添加一个边界)。编译器事实上会把类型参数替换为它的第一个边界的类型。如果没有指明边界,那么类型参数将被擦除到Object。


4、?和 T 的区别


?使用场景 和Object一样,和C++的Void 指针一样,基本上就是不确定类型,可以指向任何对象。一般用在引用。


T 是泛型的定义类型,在运行时是确定的类型。


5、super extends


通配符限定:


<? extends T>:子类型的通配符限定,以查询为主,比如消费者集合场景


<? super T>:超类型的通配符限定,以添加为主,比如生产者集合场景


super 下界通配符 ,向下兼容子类及其子孙类, T super Child 会被擦除为 Object


extends 上界通配符  ,向下兼容子类及其子孙类, T extends Parent 会被擦除为 Parent



class Fruit {}
class Apple extends Fruit {}
class FuShi extends Apple {}
class Orange extends Fruit {}

import java.util.ArrayList;
import java.util.List;

public class Aain {
 public static void main(String[] args) {
       //上界
       List<? extends Fruit> topList = new ArrayList<Apple>();
       topList.add(null);
       //add Fruit对象会报错
       //topList.add(new Fruit());
       Fruit fruit1 = topList.get(0);

       //下界
       List<? super Apple> downList = new ArrayList<>();
       downList.add(new Apple());
       downList.add(new FuShi());
       //get Apple对象会报错
       //Apple apple = downList.get(0);
}

上界 <? extend Fruit> ,表示所有继承Fruit的子类,但是具体是哪个子类,但是肯定是Fruit


下界 <? super Apple>,表示Apple的所有父类,包括Fruit,一直可以追溯到老祖宗Object 。


归根结底可以用一句话表示,那就是编译器可以支持向上转型,但不支持向下转型。具体来讲,我可以把Apple对象赋值给Fruit的引用,但是如果把Fruit对象赋值给Apple的引用就必须得用cast。


6、注意点


1、静态方法无法访问类的泛型


图片


可以看到Idea 提示无法引用静态上下文。


2、创建之后无法修改类型


List<Player> 无法插入其他的类型,已经确定类型的不可以修改类型


3、类型判断问题


问题:因为类型在编译完之后无法获取具体的类型,所以在运行时是无法判断类的类型。


我们可以通过下面的代码来解决泛型的类型信息由于擦除无法进行类型判断的问题:


/**
* 判断类型
* @author 香菜
* @param <T>
*/
public class GenClass<T> {
   Class<?> classType;
   public GenClass(Class<?> classType) {
       this.classType = classType;
  }
   public boolean isInstance(Object object){
       return classType.isInstance(object);
  }
}

解决方案:我们通过在创建对象的时候在构造函数中传入具体的class类型,然后通过这个Class对象进行类型判断。


4、创建类型实例


问题:泛型代码中不能new T()的原因有两个,一是因为擦除,不能确定类型;而是无法确定T是否包含无参构造函数。


在之前的文章中,有一个需求是根据不同的节点配置实例化创建具体的执行节点,即根据IfNodeCfg 创建具体的IfNode.


/**
* 创建实例
* @author 香菜
*/
public abstract class AbsNodeCfg<T> {
   public abstract T getInstance();
}

public class IfNodeCfg extends AbsNodeCfg<IfNode>{
   @Override
   public IfNode getInstance() {
       return new IfNode();
  }
}

 



/**
* 创建实例
* @author 香菜
*/
public class IfNode {
}

解决方案:通过上面的方式可以根据具体的类型,创建具体的实例,扩展的时候直接继承AbsNodeCfg,并且实现具体的节点就可以了。


7、总结


泛型相当于创建了一组的类,方法,虚拟机中没有泛型类型对象的概念,在它眼里所有对象都是普通对象


图片


有疑问的可以留言,我们一起讨论,没有问题的也可以留言,我们交个朋友


打字不容易,点赞,转发,关注三连,谢谢大家支持。

收起阅读 »

程序员五一被拉去相亲,结果彻底搞懂了HTTP常用状态码

我有一个朋友…… 叫小星,是个北漂程序员。 小星年纪不小了,还是个单身狗。家里很着急,小星也很着急。 可是,小星起身一看,眼前一闪闪闪闪闪闪闪闪闪…… ——全是秃头抠脚大汉…… 前一阵子好不容易来个实习生小姑娘,分给小星带,小星高兴坏了,结果姑娘...
继续阅读 »


我有一个朋友……


叫小星,是个北漂程序员。


小星年纪不小了,还是个单身狗。家里很着急,小星也很着急。


可是,小星起身一看,眼前一闪闪闪闪闪闪闪闪闪……


——全是秃头抠脚大汉……


img


前一阵子好不容易来个实习生小姑娘,分给小星带,小星高兴坏了,结果姑娘没呆三天,受不了公司的九九六跑了。


所以,部门彻底沦为了和尚部门,拔剑四顾心茫然,不见妹子只见男。



404(Not Found):服务器无法根据客户端的请求找到资源(网页)



茫然


老妈打电话又催了,小星说工作忙,没有女同事。


老妈问和你一起长大的小美还联系吗?


小美已经嫁做人妇,孩子都会叫爸爸了。



  • 301(Moved Permanently):永久移动。请求的资源已被永久的移动到新URI。


痛哭


那你大学时谈过的小静呢?


小静已经重新开始,找了新的男朋友。



302(Found):临时移动。与301类似。但资源只是临时被移动。



哭泣

那我帮你安排相亲好了。


什么……好吧。


五一回家,老妈给小星安排了相亲。小星蔫头巴脑地去见相亲的小姐姐了,没想到,小姐姐还挺白净,小星一下子就支棱起来了。


小星高兴地和妹子聊了起来。妹子说她最近去过西安旅游,平时会去游泳,喜欢吃一些小吃。


——这,九九六的工作节奏基本剥夺了小星的业余生活,小星冷汗连连,只能“嗯”、“啊”。


终于,妹子问了一句,你的工作怎么样?


小星的脸上一下子泛起了红光,眼神里带着一种神圣的色彩。


你知道能应对亿级流量的高并发架构如何搭建吗?你知道高并发下保证幂等性的几种方式吗?你知道保证Redis高可用的几种方法吗……啊吧啊吧



400(Bad Request):客户端请求的语法错误,服务器无法理解。



什么东西


妹子说,我吹了风,感觉头有点疼,今天就先到这吧。



500(Internal Server Error):服务器内部错误,无法完成请求。



尴尬又不失礼貌的微笑


小星垂头丧气地回家了,老妈一看小星这个样子,就知道什么情况。


— 没有关系,明天我给你安排了第二场,好好休息准备,明天好好表现。


小星夜里失眠了,辗转反侧。


明天的姑娘是什么样?和照片上差别大吗?应该很温柔吧?……


到了半夜,小星终于睡着了。


小星做了一个好梦,他和一个叫小萌的姑娘在一起了。过了一段时间,小星想?乛?乛?,小萌:? ?° ?? ?° ?,讨厌,,才确定关系多久。



403(Forbidden):服务器理解请求客户端的请求,但是拒绝执行此请求。



害羞


但是耐不住小星的软磨硬泡,还是……结果闹出人命了,但是孩子还不能生。


因为没有结婚证和准生证。



401(Unauthorized):请求需要有通过HTTP认证(BASIC认证,DIGEST认证)的认证信息。



突然领证


后来,小星和小萌结婚了,生了一个可爱的孩子,一家三口过上了幸福的生活。



200(OK):请求成功。



突然,一个容嬷嬷跳了出来。


臭小子,彩礼钱没给够,挨我一针吧!


小星一下子惊醒。


还好,只是一场梦。


天已经亮了,小星强打精神,去参加今天的相亲了。


至于结果,标题里已经说明了。


表情







End!

纯属瞎侃,请勿当真!——“任由你 自由的 耗在我苦中作乐”


参考:


【1】:浪漫故事:常见HTTP状态码的另类解析

收起阅读 »

Android开发基础之控件CheckBox

目录 一、基础属性 二、自定义样式 1、去掉CheckBox的勾选框 2、自定义背景颜色 3、自定义勾选框的背景图片 三、监听事件       &nb...
继续阅读 »





       


一、基础属性























































1、layout_width 宽度
2、layout_height 高度
3、id 设置组件id
4、text 设置显示的内容
5、textColor 设置字体颜色
6、textStyle 设置字体风格:normal(无效果)、bold(加粗)、italic(斜体)
7、textSize 字体大小,单位常用sp
8、background 控件背景颜色
9、checked 默认选中该选项
10、orientation 内部控件排列的方向,例如水平排列或垂直排列
11、paddingXXX 内边距,该控件内部控件间的距离
12、background 控件背景颜色或图片

       
1、layout_width
2、layout_height


        组件宽度和高度有4个可选值,如下图:
在这里插入图片描述


       
3、id


// activity_main.xml
android:id="@+id/cb1" // 给当前控件取个id叫cb1

// MainActivity.java
CheckBox cb1=findViewById(R.id.cb1); // 按id获取控件
cb1.setText("hh"); // 对这个控件设置显示内容

        如果在.java和.xml文件中对同一属性进行了不同设置,比如.java中设置控件内容hh,.xml中设置内容为aa,最后显示的是.java中的内容hh。


       
4、text
       可以直接在activity_main.xml中写android:text="嘻嘻",也可以在strings.xml中定义好字符串,再在activity_main.xml中使用这个字符串。


// strings.xml
<string name="str1">嘻嘻</string>

// activity_main.xml
android:text="@string/str1"

       
5、textColor
       与text类似,可以直接在activity_main.xml中写android:textColor="#FF0000FF",也可以在colors.xml中定义好颜色,再在activity_main.xml中使用这个颜色。


       
       


9、checked
       checked=“true”,默认这个RadioButton是选中的。该属性只有在RadioGroup中每个RadioButton都设置了id的条件下才有效。


       


       


10、orientation


内部控件的排列方式:



  • orientation=“vertical”,垂直排列

  • orientation=“horizontal”,水平排列


       


11、paddingXXX


内边距,该控件与内部的控件间的距离,常用的padding有以下几种:



  • padding,该控件与内部的控件间的距离

  • paddingTop,该控件与内部的控件间的上方的距离

  • paddingBottom,该控件与内部的控件间的下方的距离

  • paddingRight,该控件与内部的控件间的左侧的距离

  • paddingLeft,该控件与内部的控件间的右侧的距离


       


程序示例:


<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_height="match_parent"
android:layout_width="match_parent"
android:orientation="vertical">

<TextView
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:id="@+id/tv1"
android:text="你喜欢做什么?"
android:textSize="50sp"
android:textColor="@color/i_purple_700">

</TextView>
<CheckBox
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:id="@+id/cb1"
android:text="吃饭"
android:textSize="50sp"
android:checked="true">

</CheckBox>
<CheckBox
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:id="@+id/cb2"
android:text="睡觉"
android:textSize="50sp"
android:checked="true">

</CheckBox>
<CheckBox
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:id="@+id/cb3"
android:text="工作"
android:textSize="50sp"
android:checked="true">

</CheckBox>
<CheckBox
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:id="@+id/cb4"
android:text="玩耍"
android:textSize="50sp"
android:checked="true">

</CheckBox>
</LinearLayout>

效果:


       


       


       


二、自定义样式


       


1、去掉CheckBox的勾选框


       在CheckBox的属性里写上button="@null"
程序示例:


<CheckBox
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:id="@+id/cb1"
android:text="吃饭"
android:textSize="50sp"
android:button="@null">

</CheckBox>

效果:


“吃饭”前面的勾选框没有了,不过这样做,你最好设置选中时一个背景,未选中时一个背景,不然像图上那样根本看不出来选没选中“吃饭”。


       


2、自定义背景颜色


新建一个选择器selector
在这里插入图片描述
在这里插入图片描述


       


你取的名字.xml文件内编写代码:



  • item android:state_checked=“false” , 未选中这个CheckBox时的样式

  • item android:state_checked=“true” ,选中这个CheckBox时的样式

  • solid android:color="@color/yellow_100" ,设置实心的背景颜色

  • stroke android:width=“10dp” ,设置边框粗细
               android:color="@color/i_purple_700" ,设置边框颜色

  • corners android:radius=“50dp” ,设置边框圆角大小


程序示例:
blue_selector.xml


<?xml version="1.0" encoding="utf-8"?>
<selector xmlns:android="http://schemas.android.com/apk/res/android">
<item android:state_checked="false">
<shape android:shape="rectangle">
<solid android:color="@color/blue_100"></solid>
<stroke android:color="@color/blue_700" android:width="5dp"></stroke>
<corners android:radius="30dp"></corners>
</shape>
</item>
<item android:state_checked="true">
<shape android:shape="rectangle">
<solid android:color="@color/blue_500"></solid>
<corners android:radius="30dp"></corners>
</shape>
</item>
</selector>

activity_main.xml


<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_height="match_parent"
android:layout_width="match_parent"
android:orientation="vertical">

<TextView
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:id="@+id/tv1"
android:text="你喜欢做什么?"
android:textSize="50sp"
android:textColor="@color/i_purple_700"
android:paddingBottom="20dp"
android:paddingTop="20dp">

</TextView>
<CheckBox
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:id="@+id/cb1"
android:text="吃饭"
android:textSize="50sp"
android:background="@drawable/blue_selector">

</CheckBox>
<CheckBox
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:id="@+id/cb2"
android:text="睡觉"
android:textSize="50sp"
android:background="@drawable/purple_selector">

</CheckBox>
<CheckBox
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:id="@+id/cb3"
android:text="工作"
android:textSize="50sp"
android:background="@drawable/blue_selector">

</CheckBox>
<CheckBox
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:id="@+id/cb4"
android:text="玩耍"
android:textSize="50sp"
android:background="@drawable/purple_selector">

</CheckBox>
</LinearLayout>

都未选:


都选中:


       


       


3、自定义勾选框的背景图片


导入背景图片:
在这里插入图片描述
在这里插入图片描述
       


然后新建一个选择器selector
在这里插入图片描述
在这里插入图片描述


       


你取的名字.xml文件内编写代码:



  • item android:state_checked=“false” , 未选中这个CheckBox时的样式

  • item android:state_checked=“true” ,选中这个CheckBox时的样式

  • drawable="@drawable/ic_pink_heart",设置背景图片


程序示例:
bg_checkbox.xml


<?xml version="1.0" encoding="utf-8"?>
<selector xmlns:android="http://schemas.android.com/apk/res/android">
<item android:drawable="@drawable/ic_pink_heart" android:state_checked="true"></item>
<item android:drawable="@drawable/ic_heart_broken" android:state_checked="false"></item>
</selector>

activity_main.xml里写button="@drawable/bg_checkbox",使用写好的背景文件bg_checkbox.xml


<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_height="match_parent"
android:layout_width="match_parent"
android:orientation="vertical">

<TextView
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:id="@+id/tv1"
android:text="你喜欢做什么?"
android:textSize="50sp"
android:textColor="@color/i_purple_700"
android:paddingBottom="20dp"
android:paddingTop="20dp">

</TextView>
<CheckBox
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:id="@+id/cb1"
android:text="吃饭"
android:textSize="50sp"
android:button="@drawable/bg_checkbox">

</CheckBox>
<CheckBox
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:id="@+id/cb2"
android:text="睡觉"
android:textSize="50sp"
android:button="@drawable/bg_checkbox">

</CheckBox>
<CheckBox
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:id="@+id/cb3"
android:text="工作"
android:textSize="50sp"
android:button="@drawable/bg_checkbox">

</CheckBox>
<CheckBox
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:id="@+id/cb4"
android:text="玩耍"
android:textSize="50sp"
android:button="@drawable/bg_checkbox">

</CheckBox>
</LinearLayout>

都未选:


都选中:


当然这个图标换成√或者×都是可以的。


       


       


       


三、监听事件


        在MainActivity.java内添加监听,当CheckBox的选中状态发生变化时,就会执行写好的操作:


public class MainActivity extends AppCompatActivity {
private CheckBox cb1;
private CheckBox cb2;
private CheckBox cb3;
private CheckBox cb4;

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);

// 获取控件id
cb1=findViewById(R.id.cb1);
cb2=findViewById(R.id.cb2);
cb3=findViewById(R.id.cb3);
cb4=findViewById(R.id.cb4);
// 监听选中状态
cb1.setOnCheckedChangeListener(new CompoundButton.OnCheckedChangeListener() {
@Override
public void onCheckedChanged(CompoundButton buttonView, boolean isChecked) {
Toast.makeText(MainActivity.this,isChecked?"选中":"未选中",Toast.LENGTH_SHORT).show();
}
});
cb2.setOnCheckedChangeListener(new CompoundButton.OnCheckedChangeListener() {
@Override
public void onCheckedChanged(CompoundButton buttonView, boolean isChecked) {
Toast.makeText(MainActivity.this,isChecked?"选中":"未选中",Toast.LENGTH_SHORT).show();
}
});
cb3.setOnCheckedChangeListener(new CompoundButton.OnCheckedChangeListener() {
@Override
public void onCheckedChanged(CompoundButton buttonView, boolean isChecked) {
Toast.makeText(MainActivity.this,isChecked?"选中":"未选中",Toast.LENGTH_SHORT).show();
}
});
cb4.setOnCheckedChangeListener(new CompoundButton.OnCheckedChangeListener() {
@Override
public void onCheckedChanged(CompoundButton buttonView, boolean isChecked) {
Toast.makeText(MainActivity.this,isChecked?"选中":"未选中",Toast.LENGTH_SHORT).show();
}
});
}
}

       


选中某个CheckBox时,弹出选中提示信息:


       

收起阅读 »

Android自定义弧型View

好久没动手玩View自定义,有点生疏了。效果如下 思路很简单,onDraw绘制弧线、绘制Text canvas.drawArc(oval, startAngle, sweepAngle, false, paint); canvas.drawText...
继续阅读 »


好久没动手玩View自定义,有点生疏了。效果如下


思路很简单,onDraw绘制弧线、绘制Text



canvas.drawArc(oval, startAngle, sweepAngle, false, paint);

canvas.drawText(integralValue, rectF.centerX(), baseline, textPaint);


draw 动画效果实现:invalidate


canvas.drawArc(oval, startAngle, i, false, paint);

if(i<sweepAngle){
i = i+10;//sweepAngle :240,所以这里+10没问题,具体细节具体修改
getHandler().postDelayed(new Runnable() {
@Override
public void run() {
invalidate();
}
},50);
}

绘制的效果差别有点大不理想,先给画笔添加抗锯齿和画笔圆角


textPaint.setAntiAlias(true);
textPaint.setTypeface(Typeface.DEFAULT_BOLD);

drawText让文字居中对齐,一定要算好边界和baseLine



RectF rectF = new RectF(borderWidth * 2 + arcMargin, borderWidth * 2 + arcMargin, getMeasuredWidth() - arcMargin - borderWidth * 2, getMeasuredHeight() - arcMargin - borderWidth * 2);

//计算baseline
Paint.FontMetrics fontMetrics = textPaint.getFontMetrics();
float distance = (fontMetrics.bottom - fontMetrics.top) / 2 - fontMetrics.bottom;
float baseline = rectF.centerY() + distance;
canvas.drawText(integralValue, rectF.centerX(), baseline, textPaint);

积分商城文本背景可以用shape绘制,这里直接代码搞一个drawable


   /**
* 设置圆角背景
*
* @param
* @param radiiValue 设置图片四个角圆形半径
* @return
*/
@SuppressLint("WrongConstant")
public static GradientDrawable getBackgroundShapeDrawable(int color, float radiiValue) {
float[] radii = new float[] { radiiValue, radiiValue, radiiValue, radiiValue, radiiValue, radiiValue, radiiValue,radiiValue };
GradientDrawable drawable = new GradientDrawable();
drawable.setShape(GradientDrawable.RECTANGLE);
drawable.setGradientType(GradientDrawable.RECTANGLE);
drawable.setCornerRadii(radii);
drawable.setColor(color);
return drawable;
}

居中文字大小不能固定值,防止超出弧型,要跟据文字长度动态调整



textPaint.setTextSize(getIntegralTextSize(integralValue));

protected int getIntegralTextSize(String text) {
int flag = 80;
if (text.length() == 8) {
flag = 70;
} else if (text.length() == 9) {
flag = 60;
} else if (text.length() >= 10) {
flag = 50;
}

return flag;
}

源码就不上传了,实现起来还是不难用了十几分钟,等下班咯

收起阅读 »

音视频开发必备基础知识点整理

IM
日常工作中都会接触到音视频的开发,比如目前工作中都会涉及到 TSPlayer、IjkPlayer、MediaPlayer 提供播放能力,不管是什么 Player,其上层调用都是大同小异,但是具体实现以及能够支持的能力各不相同,要想继续深入就必须深入音视频的学习...
继续阅读 »


日常工作中都会接触到音视频的开发,比如目前工作中都会涉及到 TSPlayer、IjkPlayer、MediaPlayer 提供播放能力,不管是什么 Player,其上层调用都是大同小异,但是具体实现以及能够支持的能力各不相同,要想继续深入就必须深入音视频的学习,Android 开发的几个主要方向分别是应用、Framework、音视频、NDK等,如果继续在 Android 领域,这些坑还是是必须要填的,主要内容如下:



1.视频编码
2.音频编码
3.多媒体播放组件
4.帧率
5.分辨率
6.编码格式
7.封装格式
8.码率
9.颜色空间
10.采样率
11.量化精度
12.声道




视频编码


视频编码指的是通过特定的压缩技术,将某个视频文件格式转换为另一种视频格式文件的方式,视频传输中主要编解码标准如下:



  • 运动静止图像专家组的 M-JPEG



    • M-JPEG 是一种图像压缩编码标准,是 Motion-JPEG 的简称,JPEG 标准主要是用来处理静止图像,而 M-JPEG 把运动的视频序列作为连续的静止图像来处理,这种压缩方式单独完整地压缩每一帧,在编辑过程中可随机存储每一帧,可进行精确到帧的编辑,M-JPEG 只对帧内的空间冗余进行压缩,不对帧间的时间冗余进行压缩,故压缩效率不高。


  • 国际标准化组织(ISO)运动图像专家组的 MPEG 系列标准



    • MPEG 标准主要有五个:MPEG-1、MPEG-2、MPEG-4、MPEG-7 及 MPEG-21 等,MPEG 标准的视频压缩编码技术主要利用了具有运动补偿的帧间压缩编码技术以减小时间冗余度,利用 DCT 技术以减小图像的空间冗余度,利用熵编码则在信息表示方面减小了统计冗余度。这几种技术的综合运用,大大增强了压缩性能。


  • 国际电联(ITU-T)的 H.261、H.263、H.264等



    • H.261:第一个实用的数字视频解码标准,采用的压缩算法是运动补偿帧间预测与分块 DCT 相结合的混合编码,其运动补偿使用用全像素精度和环路滤波,支持 CIF 和 QCIF 两种分辨率。

    • H.263:H.263 与 H.261 编码算法一样,但是做了一点改善,使得 H.263 标准在低码率下能够提供比 H.261 更好的图像效果,其运动补偿使用半像素精度,支持 CIF、QCIF 、SQCIF、4CIF和16CIF 五种分辨率。

    • H.264:H.264则是由两个组织 ISO 和 ITU-T 联合组建的联合视频组(JVT)共同制定的新数字视频编码标准,所以它既是 ITU-T 的H.264,又是 ISO/IEC 的 MPEG-4 高级视频编码(Advanced Video Coding,AVC)的第 10 部分,因此,不论是MPEG-4 AVC、MPEG-4 Part 10,还是 ISO/IEC 14496-10,都是指 H.264,H.264 是基于传统框架的混合编码系统,做了局部优化,注重编码效率和可靠性。H.264 在具有高压缩比的同时还拥有高质量流畅的图像,经过 H.264 压缩的视频数据,在网络传输过程中所需要的带宽更少,是压缩率最高的视频压缩标准。



音频编码


常见的音频编解码标准如下:



  • ITU:G.711、G.729 等

  • MPEG:MP3、AAC 等

  • 3GPP:AMR、AMR-WB、AMR-WB+等

  • 还有企业制定的标准,如 Dolby AC-3、DTS 、WMA 等


常见的介绍如下:



  • MP3(MPEG-1 audio layer 3):一种音频压缩技术,它被设计用来大幅度地降低音频数据量,利用 MPEG Audio Layer 3 的技术,将音乐以 1:10 甚至 1:12 的压缩率,压缩成容量较小的文件,而对于大多数用户来说重放的音质与最初的不压缩音频相比没有明显的下降,它是利用人耳对高频声音信号不敏感的特性,将时域波形信号转换成频域信号,并划分成多个频段,对不同的频段使用不同的压缩率,对高频加大压缩比(甚至忽略信号),对低频信号使用小压缩比,保证信号不失真,这样就相当于抛弃人耳基本听不到的高频声音,只保留能听到的低频部分,从而对音频进行一定压缩,此外 MP3 属于有损压缩的文件格式。


  • AAC:Advanced Audio Coding 的缩写,最初是基于 MPEG-2 的音频编码技术,MPEG-4 出现后,AAC 重新集成了其特性,且加入了SBR 技术和 PS 技术,为了区别于传统的 MPEG-2 AAC 又称为MPEG-4 AAC,AAC 是一种专为声音数据设计的文件压缩格式,相较 MP3,AAC 格式的音质更佳,文件更小,但是 AAC 是一种有损压缩格式,随着大容量设备的出现,其优势将越来越小。


  • WMA:Windows Media Audio 的缩写,是微软公司开发的一系列音频编解码器,也指相应的数字音频编码格式,WMA 包括四种不同的编解码器:WMA,原始的WMA编解码器,作为 MP3 和 RealAudio 编解码器的竞争者;WMA Pro,支持更多声道和更高质量的音频[;WMA Lossless,无损编解码器;WMA Voice,用于储存语音,使用的是低码率压缩。一些使用 Windows Media Audio 编码格式编码其所有内容的纯音频 ASF 文件也使用 WMA 作为扩展名,其特点是支持加密,非法拷贝到本地是无法播放的,WMA 也属于有损压缩的文件格式。



更多音视频编解码标准可以参考:音频编解码标准


多媒体播放组件


Android 多媒体播放组件包含 MediaPlayer、MediaCodec、OMX 、StageFright、AudioTrack 等,具体如下:



  • MediaPlayer:为应用层提供的播放控制接口

  • MediaCodec:提供访问底层媒体编解码器的接口

  • OpenMAX :Open Media Acceleration,又缩写为 OMX,开放多媒体加速层,是一个多媒体应用程序标准,Android 主要的多媒体引擎StageFright 是透过 IBinder 使用 OpenMax,用于编解码处理。

  • StageFright:Android 2.2 开始引入用来替换预设的媒体播放引擎 OpenCORE,Stagefright 是位于 Native 层的媒体播放引擎,内置了基于软件的编解码器,且适用于热门媒体格式,其编解码功能是利用OpenMAX 框架,引入的是 OpenCORE 的 omx-component 部分,在 Android 中是以共享库的形式存在,对应 libstagefright.so。

  • AudioTrack:管理和播放单个音频资源,仅支持 PCM 流,如大多数的 WAV 格式的音频文件就是就是 PCM 流,这类音频文件支持 AudioTrack 直接进行播放。


常见的多媒体框架及解决方案


常见的多媒体框架及解决方案有 VLC 、 FFmpeg 、 GStream 等,具体如下:



  • VLC : 即 Video LAN Client,是一款自由、开源的跨平台多媒体播放器及框架 。

  • FFmpeg:多媒体解决方案,不是多媒体框架,广泛用于音视频开发中。

  • GStreamer : 一套构建流媒体应用的开源多媒体框架 。


帧率


帧率是用于测量显示帧数的量度。单位为「每秒显示帧数」(Frame per Second,FPS)或「赫兹,Hz」,表示每秒的帧数(FPS)或者说帧率表示图形处理器处理场时每秒钟能够更新的次数,高的帧率可以得到更流畅、更逼真的动画,一般来说 30fps 就是可以接受的,但是将性能提升至 60fps 则可以明显提升交互感和逼真感,但是一般来说超过 75fps 一般就不容易察觉到有明显的流畅度提升了,如果帧率超过屏幕刷新率只会浪费图形处理的能力,因为监视器不能以这么快的速度更新,这样超过刷新率的帧率就浪费掉了。


分辨率


视频分辨率是指视频成像产品所形成的图像大小或尺寸,常见的 1080P、4K 等有代表什么呢,P 本身的含义是逐行扫描,表示视频像素的总行数,1080P 表示总共有 1080 行的像素数,而 K 表示视频像素的总列数,4K 表示有 4000 列的像素数,通常来说,1080P 就是指 1080 x 1920 的分辨率,4 k 指 3840 x 2160 的分辨率。


刷新率


刷新率就是屏幕每秒画面被刷新的次数,刷新率分为垂直刷新率和水平刷新率,一般提到的刷新率通常指垂直刷新率,垂直刷新率表示屏幕的图象每秒钟重绘多少次,也就是每秒钟屏幕刷新的次数,以 Hz(赫兹)为单位,刷新率越高越好,图象就越稳定,图像显示就越自然清晰,对眼睛的影响也越小,刷新频率越低,图像闪烁和抖动的就越厉害,眼睛疲劳得就越快,一般来说,如能达到 80Hz 以上的刷新频率就可完全消除图像闪烁和抖动感,眼睛也不会太容易疲劳。


编码格式


针对音视频来说,编码格式对应的就是音频编码和视频编码,对照前面的音频编码标准和视频编码标准,每种编码标准都对应的编码算法,其目的是通过一定编码算法实现数据的压缩、减少数据的冗余。


封装格式


直接看下百度百科的关于封装格式的介绍,封装格式(也叫容器),就是将已经编码压缩好的视频轨和音频轨按照一定的格式放到一个文件中,也就是说仅仅是一个外壳,或者大家把它当成一个放视频轨和音频轨的文件夹也可以,说得通俗点,视频轨相当于饭,而音频轨相当于菜,封装格式就是一个碗,或者一个锅,用来盛放饭菜的容器。


码率


码率,也就是比特率(Bit rate),指单位时间内传输或处理的比特的数量,单位为 bps(bit per second)也可表示为 b/s,比特率越高,单位时间传送的数据量(位数)越大,多媒体行业在指音频或视频在单位时间内的数据传输率时通常使用码率,单位是 kbps,一般来说,如果是 1M 的宽带,在网上只能看码流不超过 125kbps 的视频,超过 125kbps 的视频只能等视频缓冲才能顺利观看。


码率一般分为固定码率和可变码率:



  • 固定码率会保证码流的码率恒定,但是会牺牲视频质量,比如为了保证码率恒定,某些图像丰富的内容就是失去某些图像细节而变得模糊。

  • 可变码率指的是输出码流的码率是可变的,因为视频信源本身的高峰信息量是变化的,从确保视频传输质量和充分利用信息的角度来说,可变码率视频编码才是最合理的。


码率的高低与视频质量和文件提交成正比,但当码率超过一定数值后,对视频质量没有影响。


颜色空间



  • YUV:一种颜色编码方法,一般使用在在影像处理组件中,YUV 在对照片或视频编码时,考虑到人类的感知能力,允许降低色度的带宽,其中 Y 表示明亮度、U 表示色度、V 表示浓度,Y′UV、YUV、YCbCr、YPbPr 所指涉的范围,常有混淆或重叠的情况。从历史的演变来说,其中 YUV 和 Y’UV 通常用来编码电视的模拟信号,而 YCbCr 则是用来描述数字的影像信号,适合视频与图片压缩以及传输,例如 MPEG、JPEG,现在 YUV 通常已经在电脑系统上广泛使用。

  • RGB:原色光模式,又称 RGB 颜色模型或红绿蓝颜色模型,是一种加色模型,将红(Red)、绿(Green)、[蓝(Blue)三原色的色光以不同的比例相加,以合成产生各种色彩光,目前的大多数显示器都采用 RGB 这种颜色标准。


YUV 主要用于优化彩色视频信号的传输,使其向后相容老式黑白电视,与 RGB 视频信号传输相比,它最大的优点在于只需占用极少的带宽。


采样率


采样率,表示每秒从连续信号中提取并组成离散信号的采样个数,用赫兹(Hz)来表示,采样率是指将模拟信号转换成数字信号时的采样频率,人耳能听到的声音一般在 20Hz~20KHz 之间,根据采样定理,采样频率大于信号中最高频率的 2 倍时,采样之后的数字信号便能完整的反应真实信号,常见的采样率如下:



  • 8000 Hz:电话所用采样率, 对于人的说话已经足够

  • 11025 Hz:AM调幅广播所用采样率

  • 22050 Hz 和 24,000 Hz:FM调频广播所用采样率

  • 44100Hz:音频CD,常用于 MPEG-1 音频(VCD,SVCD,MP3)所用采样率

  • 47,250 Hz:商用 PCM 录音机所用采样率

  • 48,000 Hz:miniDV、数字电视、DVD、DAT、电影和专业音频所用的数字声音所用采样率


CD 音乐的标准采样频率为 44.1KHz,这也是目前声卡与计算机作业间最常用的采样频率,目前比较盛行的蓝光的采样率就相当的高,达到了 192kHz。而目前的声卡,绝大多数都可以支持 44.1kHz、48kHz、96kHz,高端产品可支持 192kHz 甚至更高,总之,采样率越高,获得的声音文件质量越好,占用存储空间也就越大。


量化精度


声波在转换为数字信号的过程中不只有采样率影响原始声音的完整性,还有一个重要影响因素是量化精度,采样频率针对的是每秒钟所采样的数量,而量化精度则是对于声波的振幅进行切割,切割的数量是以最大振幅切成 2 的 n 次方计算,n 就是 bit 数,而 bit 数就是音频分辨率。


另外,bit 的数目还决定了声波振幅的范围(即动态范围,最大音量与最小音量的差距),如果这个位数越大,则能够表示的数值越大,描述波形更精确,每一个 Bit 的数据可以记录约等于 6dB 动态的信号,一般来说,16Bit 可以提供最大 96dB 的动态范围(加高频颤动后 只有 92dB),据此可以推断出 20Bit 可以达到 120dB 的动态范围,动态范围大了,会有什么好处呢?动态范围是指系统的输出噪音功率和最大不失真音量功率的比值,这个值越大,则系统可以承受很高的动态。


声道


声道指声音在录制或播放时在不同空间位置采集或回放的相互独立的音频信号,所以声道数也就是声音录制时的音源数量或回放时相应的扬声器数量,常见声道有单声道、立体声道、4 声道、5.1 声道、7.1 声道等 ,具体如下:



  • 单声道:设置一个扬声器。

  • 立体声道:把单声道一个扬声器扩展为左右对称的两个扬声器,声音在录制过程中被分配到两个独立的声道,从而达到了很好的声音定位效果,这种技术在音乐欣赏中显得尤为有用,昕众可以清晰地分辨出各种乐器来自何方,从而使音乐更富想象力,更加接近临场感受。立体声技术广泛应用于自 Sound Blaster Pro 以后的大量声卡,成为了 影响深远的音频标准。

  • 4 声道:4 声道环绕规定了 4 个发音点,分别是前左、前右、后左、后右,昕众则被包围在中间,同时还建议增加一个低音音箱,以加强对低频信号的回放处理,这也就是如今 4.1 声道音箱系统广泛流行的原因,就整体效果而言,4 声道系统可以为听众带来来自多个不 同方向的声音环绕,可以获得身 临各种不同环境的昕觉感受,给用户以全新的体验。

  • 5.1 声道:其实 5.1 声道系统来源于 4.1 声道系统,将环绕声道一分为二,分为左环绕和右环绕,中央位置增加重低音效果。

  • 7.1 声道:7.1 声道系统在 5.1 声道系统的基础上又增加了中左和中右两个发音点,简单来说就是在听者的周围建立起一套前后相对平衡的声场,增加了 后中声场声道。


最后



大家如果还想了解更多Android 开发、音视频开发相关的更多知识点,可以点进我的GitHub项目中:https://github.com/733gh/Android-T3自行查看,里面记录了许多的Android 知识点。最后还请大家点点赞支持下!!!




收起阅读 »

【JavaWeb】关于WebSocket的IM在线聊天技术

IM
最近在弄IM的在线聊天,发现layim又停摆了,所以下决心看看以前学的socket技术,这次的想法是不用swing,使用javaweb的jsp实现在线聊天。 我计划的大致实现步骤分这样几大步: 1、首先实现简单的demo。 2、然后结合线程,实现多客户端连接...
继续阅读 »

最近在弄IM的在线聊天,发现layim又停摆了,所以下决心看看以前学的socket技术,这次的想法是不用swing,使用javaweb的jsp实现在线聊天。


我计划的大致实现步骤分这样几大步:
1、首先实现简单的demo。
2、然后结合线程,实现多客户端连接服务端发送消息;
3、实现后台服务端转发客户端消息至所有客户端,同时在客户端显示;
4、使用前端jsp或者html展示的界面使用js技术发送信息并接收处理。


5、这是后话这期不弄,优化界面,使用html5。






也伴随着HTML5推出的WebSocket,真正实现了Web的实时通信,使B/S模式具备了C/S模式的实时通信能力。WebSocket的工作流程是这样的:浏览器通过JavaScript向服务端发出建立WebSocket连接的请求,在WebSocket连接建立成功后,客户端和服务端就可以通过TCP连接传输数据。因为WebSocket连接本质上是TCP连接,不需要每次传输都带上重复的头部数据,所以它的数据传输量比轮询和Comet技术小了很多。这里就不详细地介绍WebSocket规范,主要介绍下WebSocket在Java Web中的实现。


也就是我demo




新建一个dynamic web项目:


客户端(Web主页)代码:



<%@ page language="java" import="java.util.*" pageEncoding="UTF-8"%>
<%
String path = request.getContextPath();
String basePath = request.getScheme()+"://"+request.getServerName()+":"+request.getServerPort()+path+"/";
%>

<!DOCTYPE HTML>
<html>
<head>
<base href="<%=basePath%>">
<title>My WebSocket</title>
</head>

<body>
Welcome<br/>
<input id="text" type="text" /><button οnclick="send()">Send</button> <button οnclick="closeWebSocket()">Close</button>
<div id="message">
</div>
</body>

<script type="text/javascript">
var websocket = null;

//判断当前浏览器是否支持WebSocket
if('WebSocket' in window){
websocket = new WebSocket("ws://localhost:8080/MyWebSocket/websocket");
}
else{
alert('Not support websocket')
}

//连接发生错误的回调方法
websocket.onerror = function(){
setMessageInnerHTML("error");
};

//连接成功建立的回调方法
websocket.onopen = function(event){
setMessageInnerHTML("open");
}

//接收到消息的回调方法
websocket.onmessage = function(){
setMessageInnerHTML(event.data);
}

//连接关闭的回调方法
websocket.onclose = function(){
setMessageInnerHTML("close");
}

//监听窗口关闭事件,当窗口关闭时,主动去关闭websocket连接,防止连接还没断开就关闭窗口,server端会抛异常。
window.onbeforeunload = function(){
websocket.close();
}

//将消息显示在网页上
function setMessageInnerHTML(innerHTML){
document.getElementById('message').innerHTML += innerHTML + '<br/>';
}

//关闭连接
function closeWebSocket(){
websocket.close();
}

//发送消息
function send(){
var message = document.getElementById('text').value;
websocket.send(message);
}
</script>
</html>



Java Web后台代码


package com.jy.im.websocket;
import java.io.IOException;
import java.util.concurrent.CopyOnWriteArraySet;

import javax.websocket.OnClose;
import javax.websocket.OnError;
import javax.websocket.OnMessage;
import javax.websocket.OnOpen;
import javax.websocket.Session;
import javax.websocket.server.ServerEndpoint;

//该注解用来指定一个URI,客户端可以通过这个URI来连接到WebSocket。类似Servlet的注解mapping。无需在web.xml中配置。
@ServerEndpoint("/websocket")
public class MyWebSocket {
//静态变量,用来记录当前在线连接数。应该把它设计成线程安全的。
private static int onlineCount = 0;

//concurrent包的线程安全Set,用来存放每个客户端对应的MyWebSocket对象。若要实现服务端与单一客户端通信的话,可以使用Map来存放,其中Key可以为用户标识
private static CopyOnWriteArraySet<MyWebSocket> webSocketSet = new CopyOnWriteArraySet<MyWebSocket>();

//与某个客户端的连接会话,需要通过它来给客户端发送数据
private Session session;

/**
* 连接建立成功调用的方法
* @param session 可选的参数。session为与某个客户端的连接会话,需要通过它来给客户端发送数据
*/
@OnOpen
public void onOpen(Session session){
this.session = session;
webSocketSet.add(this); //加入set中
addOnlineCount(); //在线数加1
System.out.println("有新连接加入!当前在线人数为" + getOnlineCount());
}

/**
* 连接关闭调用的方法
*/
@OnClose
public void onClose(){
webSocketSet.remove(this); //从set中删除
subOnlineCount(); //在线数减1
System.out.println("有一连接关闭!当前在线人数为" + getOnlineCount());
}

/**
* 收到客户端消息后调用的方法
* @param message 客户端发送过来的消息
* @param session 可选的参数
*/
@OnMessage
public void onMessage(String message, Session session) {
System.out.println("来自客户端的消息:" + message);

//群发消息
for(MyWebSocket item: webSocketSet){
try {
item.sendMessage(message);
} catch (IOException e) {
e.printStackTrace();
continue;
}
}
}

/**
* 发生错误时调用
* @param session
* @param error
*/
@OnError
public void onError(Session session, Throwable error){
System.out.println("发生错误");
error.printStackTrace();
}

/**
* 这个方法与上面几个方法不一样。没有用注解,是根据自己需要添加的方法。
* @param message
* @throws IOException
*/
public void sendMessage(String message) throws IOException{
this.session.getBasicRemote().sendText(message);
//this.session.getAsyncRemote().sendText(message);
}

public static synchronized int getOnlineCount() {
return onlineCount;
}

public static synchronized void addOnlineCount() {
MyWebSocket.onlineCount++;
}

public static synchronized void subOnlineCount() {
MyWebSocket.onlineCount--;
}
}







收起阅读 »

Android移动端IM开发之应用层实现TCP长连接多路复用

IM
这里只是提供一个长连接多路复用的实现思路 什么是长连接多路复用 从字面意思看就是一台设备只有一条长连接连向服务器,其他集成这个IM SDK的app都会共享这条长连接,TCP长连接的维护是比较耗资源的,而且也会增加耗电,所以实现长连接共享就表示在一定程度...
继续阅读 »


这里只是提供一个长连接多路复用的实现思路


什么是长连接多路复用



  1. 从字面意思看就是一台设备只有一条长连接连向服务器,其他集成这个IM SDK的app都会共享这条长连接,TCP长连接的维护是比较耗资源的,而且也会增加耗电,所以实现长连接共享就表示在一定程度上降低了耗电也节省了内存

  2. java里面还有一个IO多路复用,这个用在服务端的比较多,用来解决并发问题,服务器的IM框架netty也用到了IO多路复用,原先是一个客户端对应一个IO,服务器要为每个客户端单独开一个线程来处理客户端的消息请求,但是使用了IO多路复用后,可能多个客户端共享一条IO链路,节省了资源,不必为每个客户端来单独开一个线程处理,具体服务端怎么实现我也没去深究,想多了解就上网找找资料或者看下netty的源码实现


IM的长连接多路复用的实现


IM的长连接多路复用的实现我觉得分为两部分,一部分是服务端的实现,一部分是客户端的实现
1. 一般一台手机设备会对应一个唯一的设备id,这个设备id对于服务器来说是绝对唯一的,是标识设备唯一性的一个标志,所以IM的接入服务器可以根据设备id来检测并控制每台设备连到服务器的长连接数量,接入服务器可以让同一台设备如果有两条不同的tcp连接连进来,那么可以断开其中一条tcp而只保持唯一一条tcp连接,这是从服务端保证单台设备TCP连接的唯一性
2. android客户端会集成响应的IM SDK,一般tcp长连接由service来维护,至于进程保活其实也就是service保活,因为push进程一般是和app的进程分开的;那么要实现在android手机设备上tcp连接的唯一性其实也就是保证维护tcp连接的service的唯一性,在android sdk中是可以有办法来判断service是否在运行的:


public static boolean isServiceRunning(Context mContext, String clsName) {
boolean isRunning = false;
ActivityManager myAM = (ActivityManager) mContext.getSystemService(Context.ACTIVITY_SERVICE);
List<ActivityManager.RunningServiceInfo> myList = myAM.getRunningServices(Integer.MAX_VALUE);
if (myList == null || myList.size() <= 0) {
return false;
}
for (int i = 0; i < myList.size(); i++) {
String mName = myList.get(i).service.getClassName().toString();
if (mName.equals(clsName)) {
isRunning = true;
break;
}
}
return isRunning;
}

其实思路很简单,检测到这个service已经运行了,那么就不start service了,而只要bind service来获取binder对象就足够了,然后可以通过aidl来实现跨进程通信了,但是这里有两个概念,就是必须指定宿主app和寄生app,宿主app就是负责维护唯一的tcp长连接,寄生app的收发消息就通过宿主app来路由,这样就做到了tcp长连接共享,所以在检测到宿主app维护长连接的service没有启动的时候寄生app就可以start service并且bind service,但是注意了,这里不能通过简单的action来启动service,要指定正确的ComponentName,或者把宿主app的context传进来:


Intent serviceIntent = new Intent();
serviceIntent.setComponent(new ComponentName(componentPckName, ConnectionService.class.getName()));
serviceIntent.setPackage(context.getPackageName());
serviceIntent.setAction(ConnectionService.ACTION);

如上componentPckName必须是宿主app的package name或者宿主app的context,那么在寄生app里面启动service才能正确启动宿主app的service,这就相当于唤醒了宿主app了,如果寄生app只是简单的通过action来start service那么它将会为自己启动一个service,而不会去启动宿主app的service,到这里寄生app其实已经开始公用宿主app的service,我已经实现了,aidl调用正常,这样也省却了im连接成功后的初始化操作,只需要在长连接第一次连接成功的时候初始化以下,后面其他的app直接bind service获取binder来直接调用aidl接口就行了。这里有一个可以优化的地方,多进程之间的通信我采用的是aidl来实现,aidl代码冗余,而且传输数据比较慢,比什么慢?我觉得比tcp长连接慢,也就是说可以用本地的tcp长连接来实现进程间的通信,把宿主app当作一个服务器,寄生app相当于客户端,然后每个寄生app都建立一条和宿主app的长连接来实现数据传输,但是要使用长连接来传输数据就必须要制定数据编码格式,因为长连接的数据传输的流传输,有粘包问题,所以要对数据进行编码校验然后解码,而且要维护这条长连接也要有一些工作量,例如长连接断线重连等,所以有利有弊,目前我暂时选择的是aidl来实现进程之间的通信,有可能以后会改成tcp长连接的通信,tcp长连接可以实现宿主app和寄生app互相监听,让service的存活率更高,我同时也不得不承认,这很流氓。。。

收起阅读 »

Android中开发IM即时通讯功能的方案

IM
最近准备做IM功能,在技术预研当中,其实可行方案还是比较多的,就看怎么选了这里有必要普及一下xmpp是个什么东西?引用某娘的定义:      XMPP是一种基于标准通用标记语言的子集XML的协议,它继承了在XML环境中灵活的发展性...
继续阅读 »

最近准备做IM功能,在技术预研当中,其实可行方案还是比较多的,就看怎么选了


这里有必要普及一下xmpp是个什么东西?

引用某娘的定义:

      XMPP是一种基于标准通用标记语言的子集XML的协议,它继承了在XML环境中灵活的发展性。因此,基于XMPP的应用具有超强的可扩展性。经过扩展以后的XMPP可以通过发送扩展的信息来处理用户的需求,以及在XMPP的顶端建立如内容发布系统和基于地址的服务等应用程序。而且,XMPP包含了针对服务器端的软件协议,使之能与另一个进行通话,这使得开发者更容易建立客户应用程序或给一个配好系统添加功能。

网络结构:

      XMPP中定义了三个角色,客户端,服务器,网关。通信能够在这三者的任意两个之间双向发生。服务器同时承担了客户端信息记录,连接管理和信息的路由功能。网关承担着与异构即时通信系统的互联互通,异构系统可以包括SMS(短信),MSNICQ等。基本的网络形式是单客户端通过TCP/IP连接到单服务器,然后在之上传输XML。

功能:

      传输的是与即时通讯相关的指令。在以前这些命令要么用2进制的形式发送(比如QQ),要么用纯文本指令加空格加参数加换行符的方式发送(比如MSN)。而XMPP传输的即时通讯指令的逻辑与以往相仿,只是协议的形式变成了XML格式的纯文本。


一句话总结就是一个可以用于IM功能的协议,传输的是xml数据


移动端IM大概有以下这些方案,但不仅于这些

1.第三方平台

比如环信,融云,leancloud,容联云等等。直接使用sdk就可以实现了,最简单最直接,而且稳定性已经不错了,连UI界面都带有了,可以自行修改,缺点是要收费,比如环信日活跃用户30万以上开始收费,融云基础功能不收费,VIP级别的功能要收费。如果让我选应该会在环信和融云之间选,环信的话一个是市场占有率比较大,二个是技术客服基本都能找到在线的,融云客服的话需要像写邮件一样找技术解决问题,不是在线的交流,我觉得挺不好的,融云的demo倒是做得比环信好看,环信的看上去很粗糙的感觉。据使用过的朋友反馈融云sdk比较好接入,环信稍微麻烦点,使用的时候都会有一些坑的地方要处理。


2.spark+smack+openfire套餐

安卓使用asmack,测试使用spark,服务器使用openfire。asmack可以说是smack的Android平台的支持版提供xmpp协议的实现,就是一些个api,spark就是一个可以用来在pc相互同信的客户端,openfire部署也比较简单,next,next就差不多了。这套方案还算比较成熟的了,当然没有第三方的方便,工作量也增多了,这套也是基于xmpp协议同时也就有xmpp协议的一些缺点。


3.使用第三方推送的sdk

利用推送的及时性来做im也是可以的,推送也不收费吧。


4.Socket长链接

socket大家都懂了的,感觉做个小东西还可以,但是正真商用要做的处理还是挺多的,网络优化,稳定性等等。


5.基于xmpp自己做

xmpp协议本来就是可以坐im功能的,据了解环信就是自己基于xmpp来做的,50人上下的团队14年开始做的,现在两年左右已经融了两三轮资了。不过xmpp基于xml,冗长直接导致费流量费电,特别是移动端,可以考虑在传输的时候自己加一层二进制协议,如果环信真是xmpp来做应该也会在这方面做优化的。还有mqtt,sip等协议也是可以自己做。如果im不是核心功能不推荐自己做,费时费力。



收起阅读 »

IM开发干货分享:我是如何解决大量离线消息导致客户端卡顿的

IM
1、引言 好久没写技术文章了,今天这篇不是原理性文章,而是为大家分享一下由笔者主导开发实施的IM即时通讯聊天系统,针对大量离线消息(包括消息漫游)导致的用户体验问题的升级改造全过程。 文章中,我将从如下几个方面进行介绍: 1)这款IM产品的主要业务及...
继续阅读 »

1、引言


好久没写技术文章了,今天这篇不是原理性文章,而是为大家分享一下由笔者主导开发实施的IM即时通讯聊天系统,针对大量离线消息(包括消息漫游)导致的用户体验问题的升级改造全过程。


文章中,我将从如下几个方面进行介绍:



  • 1)这款IM产品的主要业务及特点;

  • 2)IM系统业务现状和痛点;

  • 3)升级改造之路;

  • 4)消息ACK逻辑的优化。


下述内容都是根据笔者开发IM的亲身经历总结下来的宝贵经验,干货满满,期待你的点赞。


学习交流:



- 即时通讯/推送技术开发交流5群:215477170 [推荐]


- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM





2、IM开发干货系列文章


本文是系列文章中的第25篇,总目录如下:



IM消息送达保证机制实现(一):保证在线实时消息的可靠投递


IM消息送达保证机制实现(二):保证离线消息的可靠投递


如何保证IM实时消息的“时序性”与“一致性”?


IM单聊和群聊中的在线状态同步应该用“推”还是“拉”?


IM群聊消息如此复杂,如何保证不丢不重?


一种Android端IM智能心跳算法的设计与实现探讨(含样例代码)


移动端IM登录时拉取数据如何作到省流量?


通俗易懂:基于集群的移动端IM接入层负载均衡方案分享


浅谈移动端IM的多点登陆和消息漫游原理


IM开发基础知识补课(一):正确理解前置HTTP SSO单点登陆接口的原理


IM开发基础知识补课(二):如何设计大量图片文件的服务端存储架构?


IM开发基础知识补课(三):快速理解服务端数据库读写分离原理及实践建议


IM开发基础知识补课(四):正确理解HTTP短连接中的Cookie、Session和Token


IM群聊消息的已读回执功能该怎么实现?


IM群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写)?


IM开发基础知识补课(五):通俗易懂,正确理解并用好MQ消息队列


一个低成本确保IM消息时序的方法探讨


IM开发基础知识补课(六):数据库用NoSQL还是SQL?读这篇就够了!


IM里“附近的人”功能实现原理是什么?如何高效率地实现它?


IM开发基础知识补课(七):主流移动端账号登录方式的原理及设计思路


IM开发基础知识补课(八):史上最通俗,彻底搞懂字符乱码问题的本质


IM的扫码登功能如何实现?一文搞懂主流应用的扫码登陆技术原理


IM要做手机扫码登陆?先看看微信的扫码登录功能技术原理


IM开发基础知识补课(九):想开发IM集群?先搞懂什么是RPC!


IM开发实战干货:我是如何解决大量离线聊天消息导致客户端卡顿的》(本文)



另外,如果您是IM开发初学者,强烈建议首先阅读《新手入门一篇就够:从零开发移动端IM》。


3、此IM产品的主要业务及特点


和传统互联网行业有所不同,笔者所在的公司(名字就不透露了)是一家做娱乐社交app的公司,包括小游戏、聊天、朋友圈feed等。


大家应该都有体会:游戏业务在技术上和产品形态上与电商、旅游等行业有着本质上的区别。


大部分做后端开发的朋友,都在开发接口。客户端或浏览器h5通过HTTP请求到我们后端的Controller接口,后端查数据库等返回JSON给客户端。大家都知道,HTTP协议有短连接、无状态、三次握手四次挥手等特点。而像游戏、实时通信等业务反而很不适合用HTTP协议。


原因如下:



  • 1)HTTP达不到实时通信的效果,可以用客户端轮询但是太浪费资源;

  • 2)三次握手四次挥手有严重的性能问题;

  • 3)无状态。


比如说,两个用户通过App聊天,一方发出去的消息,对方要实时感知到消息的到来。两个人或多个人玩游戏,玩家要实时看到对方的状态,这些场景用HTTP根本不可能实现!因为HTTP只能pull(即“拉”),而聊天、游戏业务需要push(即“推”)。


4、IM系统业务现状和痛点


4.1 业务现状


笔者负责整个公司的实时聊天系统,类似与微信、QQ那样,有私聊、群聊、发消息、语音图片、红包等功能。


下面我详细介绍一下,整个聊天系统是如何运转的。


首先:为了达到实时通信的效果,我们基于Netty开发了一套长链接网关gateway(扩展阅读:《Netty干货分享:京东京麦的生产级TCP网关技术实践总结》),采用的协议是MQTT协议,客户端登录时App通过MQTT协议连接到gateway(NettyServer),然后通过MQTT协议把聊天消息push给NettyServer,NettyServer与NettyClient保持长链接,NettyClient用于处理业务逻辑(如敏感词拦截、数据校验等)处理,最后将消息push给NettyServer,再由NettyServer通过MQTT push给客户端。


其次:客户端与服务端想要正常通信,我们需要制定一套统一的协议。拿聊天举例,我们要和对方聊天,需要通过uid等信息定位到对方的Channel(Netty中的通道,相当于一条socket连接),才能将消息发送给正确的客户端,同时客户端必须通过协议中的数据(uid、groupId等),将消息显示在私聊或者群聊的会话中。


协议中主要字段如下(我们将数据编码成protobuf格式进行传输):



{


    "cmd":"chat",


    "time":1554964794220,


    "uid":"69212694",


    "clientInfo":{


        "deviceId":"b3b1519c-89ec",


        "deviceInfo":"MI 6X"


    },


    "body":{


        "v":1,


        "msgId":"5ab2fe83-59ec-44f0-8adc-abf26c1e1029",


        "chatType":1,


        "ackFlg":1,


        "from":"69212694",


        "to":"872472068",


        "time":1554964793813,


        "msg":{


            "message":"聊天消息"


        }


    }


}



补充说明:如果你不了Protobuf格式是什么,请详读《Protobuf通信协议详解:代码演示、详细原理介绍等》。


如上json,协议主要字段包括: 



如果客户端不在线,我们服务端需要把发送的消息存储在离线消息表中,等下次对方客户端上线,服务端NettyServer通过长链接把离线消息push给客户端。


4.2 业务痛点


随着业务蓬勃发展,用户的不断增多,用户创建的群、加入的群和好友不断增多和聊天活跃度的上升,某些用户不在线期间,产生大量的离线消息(尤其是针对群聊,离线消息特别多)。


等下次客户端上线时,服务端会给客户端强推全部的离线消息,导致客户端卡死在登录后的首页。并且产品提出的需求,要扩大群成员的人数(由之前的百人群扩展到千人群、万人群等)。


这样一来,某些客户端登录后必定会因为大量离线消息而卡死,用户体验极为不好。


和客户端的同事一起分析了一下原因:



  • 1)用户登录,服务端通过循环分批下发所有离线消息,数据量较大;

  • 2)客户端登录后进入首页,需要加载的数据不光有离线消息,还有其他初始化数据;

  • 3)不同价位的客户端处理数据能力有限,处理聊天消息时,需要把消息存储到本地数据库,并且刷新UI界面,回复给服务端ack消息,整个过程很耗性能。


(庆幸的是,在线消息目前没有性能问题)。


所以针对上述问题,结合产品对IM系统的远大规划,我们服务端决定优化离线消息(稍微吐槽一下,客户端处理能力不够,为什么要服务端做优化?服务端的性能远没达到瓶颈。。。)。


5、升级改造之路


值得庆幸的是,笔者100%参与这次系统优化的全部过程,包括技术选型、方案制定和最后的代码编写。在此期间,笔者思考出多种方案,然后和服务端、客户端同事一起讨论,最后定下来一套稳定的方案。


5.1 方案一(被pass掉的一个方案)


? 【问题症状】:


客户端登录卡顿的主要原因是,服务端会强推大量离线消息给客户端,客户端收到离线消息后会回复服务端ack,然后将消息存储到本地数据库、刷新UI等。客户端反馈,即使客户端采用异步方式也会有比较严重的性能问题。


? 【于是我想】:


为什么客户端收到消息后还没有将数据存储到数据库就回复给服务端ack?很有可能存储失败,这本身不合理,这是其一。其二,服务端强推导致客户端卡死,不关心客户端的处理能力,不合理。


? 【伪代码如下】:



int max = 100;


//从新库读


while(max > 0) {


    List<OfflineMsgInfo> offlineMsgListNew = shardChatOfflineMsgDao.getByToUid(uid, 20);


    if(CollectionUtils.isEmpty(offlineMsgListNew)) {


        break;


    }


    handleOfflineMsg(uid, offlineMsgListNew, checkOnlineWhenSendingOfflineMsg);


    max--;


}



? 【初步方案】:


既然强推不合理,我们可以换一种方式,根据客户端不同机型的处理能力的不同,服务端采用不同的速度下发。


我们可以把整个过程当成一种生产者消费者模型,服务端是消息生产者,客户端是消息消费者。客户端收到消息,将消息存储在本地数据库,刷新UI界面后,再向服务端发送ack消息,服务端收到客户端的ack消息后,再推送下一批消息。


这么一来,消息下发速度完全根据客户端的处理能力,分批下发。但这种方式仍然属于推方式。


? 【悲剧结果】:


然而,理想很丰满,现实却很骨感。


针对这个方案,客户端提出一些问题:



  • 1)虽然这种方案,客户端不会卡死,但是如果当前用户的离线消息特别多,那么收到所有离线消息的时间会非常长;

  • 2)客户端每次收到消息后会刷新界面,很有可能客户端会发生,界面上下乱跳的画面。


so,这个方案被否定了。。。


5.2 方案二


? 【我的思考】:


既然强推的数据量过大,我们是否可以做到,按需加载?客户端需要读取离线消息的时候服务端给客户端下发,不需要的时候,服务端就不下发。


? 【技术方案】:针对离线消息,我们做了如下方案的优化


1)我们增加了离线消息计数器的概念:保存了每个用户的每个会话,未读的消息的元数据(包括未读消息数,最近的一条未读消息、时间戳等数据),这个计数器用于客户端显示未读消息的的红色气泡。这个数据属于增量数据,只保留离线期间收到的消息元数据。


消息格式如下:



{


    "sessionId1":{


        "count":20,


        "lastMsg":[


            "最后N条消息"


        ],


        "timestamp":1234567890


    },


    "sessionId2":{


    }


}



 


 


2)客户端每次登录时,服务端不推送全量离线消息,只推送离线消息计数器(这部分数据存储在redis里,并且数据量很小),这个数量用户显示在客户端消息列表的未读消息小红点上。


3)客户端拿到这些离线消息计数器数据,遍历会话列表,依次将未读消息数量累加(注意:不是覆盖,服务端保存客户端离线后的增量数据),然后通知服务端清空离线消息计数器的增量数据。


4)当客户端进入某会话后,上拉加载时,通过消息的msgId等信息发送HTTP请求给服务端,服务端再去分页查询离线消息返回给客户端。


5)客户端收到消息并保存在本地数据库后,向服务端发送ack,然后服务端删除离线消息表的离线消息。


? 【预期结果】:


客户端、服务端的技术人员认可这个方案。我们通过推拉结合的方式,解决了客户端加载离线消息卡顿的问题。(改造前是强推,改造后采用推拉结合的方式)


流程图如下:



? 【新的问题】:


方案虽然通过了,但是引发了一个新问题:即客户端消息衔接问题。


问题描述如下:客户端登录后进入会话页面,因为客户端本身就保存着历史消息,那么客户端下拉加载新消息时,到底怎么判断要加载本地历史消息?还是要请求服务端加载离线消息呢?


经过一番思考,服务端和客户端最终达成了一致的方案:



  • 1)在未读消息计数器的小红点逻辑中,服务端会把每个会话的最近N条消息一起下发给客户端;

  • 2)客户端进入会话时,会根据未读消息计数器的最近N条消息展示首页数据;

  • 3)客户端每次下拉加载时,请求服务端,服务端按时间倒排离线消息返回当前会话最近一页离线消息,直到离线消息库中的数据全部返回给客户端;

  • 4)当离线消息库中没有离线消息后,返回给客户端一个标识,客户端根据这个标识,在会话页面下一次下拉加载时不请求服务端的离线消息,直接请求本地数据库。


6、消息ACK逻辑的优化


最后,我们也对消息ack的逻辑进行了优化。


优化前:服务端采用push模型给客户端推消息,不论是在线消息还是离线消息,ack的逻辑都一样,其中还用到了kafka、redis等中间件,流程很复杂(我在这里就不详细展开介绍ack的具体流程了,反正不合理)。


离线消息和在线消息不同的是,我们不存储在线消息,而离线消息会有一个单独的库存储。完全没必要用在线消息的ack逻辑去处理离线消息,反而很不合理,不仅流程上有问题,也浪费kafka、redis等中间件性能。


优化后:我们和客户端决定在每次下拉加载离线消息时,将收到的上一批离线消息的msgId或消息偏移量等信息发送给服务端,服务端直接根据msgId删除离线库中已经发送给客户端的离线消息,再返回给客户端下一批离线消息。


另外:我们还增加了消息漫游功能,用户切换手机登录后仍然可以查到历史消息,这部分内容我就不展开详细介绍给大家了。


7、设计优化方案时的文档截图(仅供参考)


下面是优化的方案文档截图,请大家参考。


 



 



 


 



 


 



 


附录:更多IM开发相关文章汇总



[1] IM开发热门文章:


新手入门一篇就够:从零开发移动端IM


移动端IM开发者必读(一):通俗易懂,理解移动网络的“弱”和“慢”


移动端IM开发者必读(二):史上最全移动弱网络优化方法总结


从客户端的角度来谈谈移动端IM的消息可靠性和送达机制


现代移动端网络短连接的优化手段总结:请求速度、弱网适应、安全保障


腾讯技术分享:社交网络图片的带宽压缩技术演进之路


小白必读:闲话HTTP短连接中的Session和Token


IM开发基础知识补课:正确理解前置HTTP SSO单点登录接口的原理


移动端IM中大规模群消息的推送如何保证效率、实时性?


移动端IM开发需要面对的技术问题


开发IM是自己设计协议用字节流好还是字符流好?


请问有人知道语音留言聊天的主流实现方式吗?


IM消息送达保证机制实现(一):保证在线实时消息的可靠投递


IM消息送达保证机制实现(二):保证离线消息的可靠投递


如何保证IM实时消息的“时序性”与“一致性”?


一个低成本确保IM消息时序的方法探讨


IM单聊和群聊中的在线状态同步应该用“推”还是“拉”?


IM群聊消息如此复杂,如何保证不丢不重?


谈谈移动端 IM 开发中登录请求的优化


移动端IM登录时拉取数据如何作到省流量?


浅谈移动端IM的多点登录和消息漫游原理


完全自已开发的IM该如何设计“失败重试”机制?


通俗易懂:基于集群的移动端IM接入层负载均衡方案分享


微信对网络影响的技术试验及分析(论文全文)


即时通讯系统的原理、技术和应用(技术论文)


开源IM工程“蘑菇街TeamTalk”的现状:一场有始无终的开源秀


QQ音乐团队分享:Android中的图片压缩技术详解(上篇)


QQ音乐团队分享:Android中的图片压缩技术详解(下篇)


腾讯原创分享(一):如何大幅提升移动网络下手机QQ的图片传输速度和成功率


腾讯原创分享(二):如何大幅压缩移动网络下APP的流量消耗(上篇)


腾讯原创分享(三):如何大幅压缩移动网络下APP的流量消耗(下篇)


如约而至:微信自用的移动端IM网络层跨平台组件库Mars已正式开源


基于社交网络的Yelp是如何实现海量用户图片的无损压缩的?


腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)


腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)


字符编码那点事:快速理解ASCII、Unicode、GBK和UTF-8


全面掌握移动端主流图片格式的特点、性能、调优等


子弹短信光鲜的背后:网易云信首席架构师分享亿级IM平台的技术实践


IM开发基础知识补课(五):通俗易懂,正确理解并用好MQ消息队列


微信技术分享:微信的海量IM聊天消息序列号生成实践(算法原理篇)


自已开发IM有那么难吗?手把手教你自撸一个Andriod版简易IM (有源码)


融云技术分享:解密融云IM产品的聊天消息ID生成策略


IM开发基础知识补课(六):数据库用NoSQL还是SQL?读这篇就够了!


适合新手:从零开发一个IM服务端(基于Netty,有完整源码)


拿起键盘就是干:跟我一起徒手开发一套分布式IM系统


适合新手:手把手教你用Go快速搭建高性能、可扩展的IM系统(有源码)


IM里“附近的人”功能实现原理是什么?如何高效率地实现它?


IM开发基础知识补课(七):主流移动端账号登录方式的原理及设计思路


IM开发基础知识补课(八):史上最通俗,彻底搞懂字符乱码问题的本质


IM“扫一扫”功能很好做?看看微信“扫一扫识物”的完整技术实现


IM的扫码登录功能如何实现?一文搞懂主流应用的扫码登录技术原理


IM要做手机扫码登录?先看看微信的扫码登录功能技术原理


IM消息ID技术专题(一):微信的海量IM聊天消息序列号生成实践(算法原理篇)


IM消息ID技术专题(二):微信的海量IM聊天消息序列号生成实践(容灾方案篇)


IM消息ID技术专题(三):解密融云IM产品的聊天消息ID生成策略


IM消息ID技术专题(四):深度解密美团的分布式ID生成算法


IM消息ID技术专题(五):开源分布式ID生成器UidGenerator的技术实现


IM开发宝典:史上最全,微信各种功能参数和逻辑规则资料汇总


IM开发干货分享:我是如何解决大量离线聊天消息导致客户端卡顿的


>> 更多同类文章 …… 


[2] IM群聊相关的技术文章:


快速裂变:见证微信强大后台架构从0到1的演进历程(一)


如何保证IM实时消息的“时序性”与“一致性”?


IM单聊和群聊中的在线状态同步应该用“推”还是“拉”?


IM群聊消息如此复杂,如何保证不丢不重?


微信后台团队:微信后台异步消息队列的优化升级实践分享


移动端IM中大规模群消息的推送如何保证效率、实时性?


现代IM系统中聊天消息的同步和存储方案探讨


关于IM即时通讯群聊消息的乱序问题讨论


IM群聊消息的已读回执功能该怎么实现?


IM群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写)?


一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践


[技术脑洞] 如果把14亿中国人拉到一个微信群里技术上能实现吗?


IM群聊机制,除了循环去发消息还有什么方式?如何优化?


网易云信技术分享:IM中的万人群聊技术方案实践总结


阿里钉钉技术分享:企业级IM王者——钉钉在后端架构上的过人之处


>> 更多同类文章 ……


[3] 有关IM架构设计的文章:


浅谈IM系统的架构设计


简述移动端IM开发的那些坑:架构设计、通信协议和客户端


一套海量在线用户的移动端IM架构设计实践分享(含详细图文)


一套原创分布式即时通讯(IM)系统理论架构方案


从零到卓越:京东客服即时通讯系统的技术架构演进历程


蘑菇街即时通讯/IM服务器开发之架构选择


腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT


微信后台基于时间序的海量数据冷热分级架构设计实践


微信技术总监谈架构:微信之道——大道至简(演讲全文)


如何解读《微信技术总监谈架构:微信之道——大道至简》


快速裂变:见证微信强大后台架构从0到1的演进历程(一)


17年的实践:腾讯海量产品的技术方法论


移动端IM中大规模群消息的推送如何保证效率、实时性?


现代IM系统中聊天消息的同步和存储方案探讨


IM开发基础知识补课(二):如何设计大量图片文件的服务端存储架构?


IM开发基础知识补课(三):快速理解服务端数据库读写分离原理及实践建议


IM开发基础知识补课(四):正确理解HTTP短连接中的Cookie、Session和Token


WhatsApp技术实践分享:32人工程团队创造的技术神话


微信朋友圈千亿访问量背后的技术挑战和实践总结


王者荣耀2亿用户量的背后:产品定位、技术架构、网络方案等


IM系统的MQ消息中间件选型:Kafka还是RabbitMQ?


腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面


以微博类应用场景为例,总结海量社交系统的架构设计步骤


快速理解高性能HTTP服务端的负载均衡技术原理


子弹短信光鲜的背后:网易云信首席架构师分享亿级IM平台的技术实践


知乎技术分享:从单机到2000万QPS并发的Redis高性能缓存实践之路


IM开发基础知识补课(五):通俗易懂,正确理解并用好MQ消息队列


微信技术分享:微信的海量IM聊天消息序列号生成实践(算法原理篇)


微信技术分享:微信的海量IM聊天消息序列号生成实践(容灾方案篇)


新手入门:零基础理解大型分布式架构的演进历史、技术原理、最佳实践


一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践


阿里技术分享:深度揭秘阿里数据库技术方案的10年变迁史


阿里技术分享:阿里自研金融级数据库OceanBase的艰辛成长之路


社交软件红包技术解密(一):全面解密QQ红包技术方案——架构、技术实现等


社交软件红包技术解密(二):解密微信摇一摇红包从0到1的技术演进


社交软件红包技术解密(三):微信摇一摇红包雨背后的技术细节


社交软件红包技术解密(四):微信红包系统是如何应对高并发的


社交软件红包技术解密(五):微信红包系统是如何实现高可用性的


社交软件红包技术解密(六):微信红包系统的存储层架构演进实践


社交软件红包技术解密(七):支付宝红包的海量高并发技术实践


社交软件红包技术解密(八):全面解密微博红包技术方案


社交软件红包技术解密(九):谈谈手Q红包的功能逻辑、容灾、运维、架构等


社交软件红包技术解密(十):手Q客户端针对2020年春节红包的技术实践


即时通讯新手入门:一文读懂什么是Nginx?它能否实现IM的负载均衡?


即时通讯新手入门:快速理解RPC技术——基本概念、原理和用途


多维度对比5款主流分布式MQ消息队列,妈妈再也不担心我的技术选型了


从游击队到正规军(一):马蜂窝旅游网的IM系统架构演进之路


从游击队到正规军(二):马蜂窝旅游网的IM客户端架构演进和实践总结


IM开发基础知识补课(六):数据库用NoSQL还是SQL?读这篇就够了!


瓜子IM智能客服系统的数据架构设计(整理自现场演讲,有配套PPT)


阿里钉钉技术分享:企业级IM王者——钉钉在后端架构上的过人之处


从游击队到正规军(三):基于Go的马蜂窝旅游网分布式IM系统技术实践


微信后台基于时间序的新一代海量数据存储架构的设计实践


IM开发基础知识补课(九):想开发IM集群?先搞懂什么是RPC!


>> 更多同类文章 ……



(本文同步发布于:http://www.52im.net/thread-3036-1-1.html


收起阅读 »

自已开发IM有那么难吗?手把手教你自撸一个Andriod版简易IM(有源码)

IM
本文由作者FreddyChen原创分享,为了更好的体现文章价值,引用时有少许改动,感谢原作者。 1、写在前面 一直想写一篇关于im即时通讯分享的文章,无奈工作太忙,很难抽出时间。今天终于从公司离职了,打算好好休息几天再重新找工作,趁时间空闲,决定静下心...
继续阅读 »

本文由作者FreddyChen原创分享,为了更好的体现文章价值,引用时有少许改动,感谢原作者。



1、写在前面


一直想写一篇关于im即时通讯分享的文章,无奈工作太忙,很难抽出时间。今天终于从公司离职了,打算好好休息几天再重新找工作,趁时间空闲,决定静下心来写一篇文章,毕竟从前辈那里学到了很多东西。


工作了五年半,这三四年来一直在做社交相关的项目,有直播、即时通讯、短视频分享、社区论坛等产品,深知即时通讯技术在一个项目中的重要性,本着开源分享的精神,也趁这机会总结一下,所以写下了这篇文章。


* 重要提示:本文不是一篇即时通讯理论文章,文章内容全部由实战代码组织而成,如果你对即时通讯(IM)技术理论了解的太少,建议先详细阅读:《新手入门一篇就够:从零开发移动端IM》。


本文实践内容将涉及以下即时通讯技术内容:



1)Protobuf序列化;


2)TCP拆包与粘包;


3)长连接握手认证;


4)心跳机制;


5)重连机制;


6)消息重发机制;


7)读写超时机制;


8)离线消息;


9)线程池。



不想看文章的同学,可以直接到Github下载本文源码:



1)原始地址:https://github.com/FreddyChen/NettyChat


2)备用地址:https://github.com/52im/NettyChat



接下来,让我们进入正题。


(本文同步发布于:http://www.52im.net/thread-2671-1-1.html


2、本文阅读对象


本文适合没有任何即时通讯(IM)开发经验的小白开发者阅读,文章将教你从零开始,围绕一个典型即时通讯(IM)系统的方方面面,手把手为你展示如何基于Netty+TCP+Protobuf来开发出这样的系统。非常适合从零入门的Android开发者。


本文不适合没有编程的准开发者阅读,因为即时通讯(IM)系统属于特定的业务领域,如果你连一般的逻辑代码都很难编写出来,不建议阅读本文。本文显然不是一个编程语言入门教程。


3、关于作者



本文原文内容由FreddyChen原创分享,作者现从事Android程序开发,他的技术博客地址:https://juejin.im/user/5bd7affbe51d4547f763fe72 


4、为什么使用TCP?


这里需要简单解释一下,TCP/UDP的区别,简单地总结一下。


优点:


1)TCP:优点体现在稳定、可靠上,在传输数据之前,会有三次握手来建立连接,而且在数据传递时,有确认、窗口、重传、拥塞控制机制,在数据传完之后,还会断开连接用来节约系统资源。


2)UDP:优点体现在快,比TCP稍安全,UDP没有TCP拥有的各种机制,是一个无状态的传输协议,所以传递数据非常快,没有TCP的这些机制,被攻击利用的机制就少一些,但是也无法避免被攻击。


缺点:


1)TCP:缺点就是慢,效率低,占用系统资源高,易被攻击,TCP在传递数据之前要先建立连接,这会消耗时间,而且在数据传递时,确认机制、重传机制、拥塞机制等都会消耗大量时间,而且要在每台设备上维护所有的传输连接。


2)UDP:缺点就是不可靠,不稳定,因为没有TCP的那些机制,UDP在传输数据时,如果网络质量不好,就会很容易丢包,造成数据的缺失。


适用场景:


1)TCP:当对网络通讯质量有要求时,比如HTTP、HTTPS、FTP等传输文件的协议, POP、SMTP等邮件传输的协议。


2)UDP:对网络通讯质量要求不高时,要求网络通讯速度要快的场景。


至于WebSocket,后续可能会专门写一篇文章来介绍。综上所述,决定采用TCP协议。


关于TCP和UDP的对比和选型的详细文章,请见:



简述传输层协议TCP和UDP的区别


为什么QQ用的是UDP协议而不是TCP协议?


移动端即时通讯协议选择:UDP还是TCP?


网络编程懒人入门(四):快速理解TCP和UDP的差异


网络编程懒人入门(五):快速理解为什么说UDP有时比TCP更有优势


Android程序员必知必会的网络通信传输层协议——UDP和TCP



或者,如果你对TCP、UDP协议了解的太少,可以阅读一下文章:



TCP/IP详解 - 第11章·UDP:用户数据报协议


TCP/IP详解 - 第17章·TCP:传输控制协议


TCP/IP详解 - 第18章·TCP连接的建立与终止


TCP/IP详解 - 第21章·TCP的超时与重传


脑残式网络编程入门(一):跟着动画来学TCP三次握手和四次挥手


技术往事:改变世界的TCP/IP协议(珍贵多图、手机慎点)


通俗易懂-深入理解TCP协议(上):理论基础


网络编程懒人入门(三):快速理解TCP协议一篇就够


迈向高阶:优秀Android程序员必知必会的网络基础



5、为什么使用Protobuf?


对于App网络传输协议,我们比较常见的、可选的,有三种,分别是json/xml/protobuf,老规矩,我们先分别来看看这三种格式的优缺点。


PS:如果你不了解protobuf是什么,建议详细阅读:《Protobuf通信协议详解:代码演示、详细原理介绍等》。


优点:


1)json:优点就是较XML格式更加小巧,传输效率较xml提高了很多,可读性还不错。


2)xml:优点就是可读性强,解析方便。


3)protobuf:优点就是传输效率快(据说在数据量大的时候,传输效率比xml和json快10-20倍),序列化后体积相比Json和XML很小,支持跨平台多语言,消息格式升级和兼容性还不错,序列化反序列化速度很快。


缺点:


1)json:缺点就是传输效率也不是特别高(比xml快,但比protobuf要慢很多)。


2)xml:缺点就是效率不高,资源消耗过大。


3)protobuf:缺点就是使用不太方便。


在一个需要大量的数据传输的场景中,如果数据量很大,那么选择protobuf可以明显的减少数据量,减少网络IO,从而减少网络传输所消耗的时间。考虑到作为一个主打社交的产品,消息数据量会非常大,同时为了节约流量,所以采用protobuf是一个不错的选择。


更多有关IM相关的协议格式选型方面的文章,可进一步阅读:



如何选择即时通讯应用的数据传输格式


强列建议将Protobuf作为你的即时通讯应用数据传输格式


全方位评测:Protobuf性能到底有没有比JSON快5倍?


移动端IM开发需要面对的技术问题(含通信协议选择)


简述移动端IM开发的那些坑:架构设计、通信协议和客户端


理论联系实际:一套典型的IM通信协议设计详解


58到家实时消息系统的协议设计等技术实践分享


详解如何在NodeJS中使用Google的Protobuf


技术扫盲:新一代基于UDP的低延时网络传输层协议——QUIC详解


金蝶随手记团队分享:还在用JSON? Protobuf让数据传输更省更快(原理篇)


金蝶随手记团队分享:还在用JSON? Protobuf让数据传输更省更快(实战篇)


>> 更多同类文章 ……



6、为什么使用Netty?


首先,我们来了解一下,Netty到底是个什么东西。网络上找到的介绍:Netty是由JBOSS提供的基于Java NIO的开源框架,Netty提供异步非阻塞、事件驱动、高性能、高可靠、高可定制性的网络应用程序和工具,可用于开发服务端和客户端。


PS:如果你对Java的经典IO、NIO或者Netty框架不了解,请阅读以下文章:



史上最强Java NIO入门:担心从入门到放弃的,请读这篇!


少啰嗦!一分钟带你读懂Java的NIO和经典IO的区别


写给初学者:Java高性能NIO框架Netty的学习方法和进阶策略


NIO框架详解:Netty的高性能之道



为什么不用Java BIO?


1)一连接一线程:由于线程数是有限的,所以这样非常消耗资源,最终也导致它不能承受高并发连接的需求。


2)性能低:因为频繁的进行上下文切换,导致CUP利用率低。


3)可靠性差:由于所有的IO操作都是同步的,即使是业务线程也如此,所以业务线程的IO操作也有可能被阻塞,这将导致系统过分依赖网络的实时情况和外部组件的处理能力,可靠性大大降低。


为什么不用Java NIO?


1)NIO的类库和API相当复杂,使用它来开发,需要非常熟练地掌握Selector、ByteBuffer、ServerSocketChannel、SocketChannel等。


2)需要很多额外的编程技能来辅助使用NIO,例如,因为NIO涉及了Reactor线程模型,所以必须必须对多线程和网络编程非常熟悉才能写出高质量的NIO程序。


3)想要有高可靠性,工作量和难度都非常的大,因为服务端需要面临客户端频繁的接入和断开、网络闪断、半包读写、失败缓存、网络阻塞的问题,这些将严重影响我们的可靠性,而使用原生NIO解决它们的难度相当大。


4)JDK NIO中著名的BUG--epoll空轮询,当select返回0时,会导致Selector空轮询而导致CUP100%,官方表示JDK1.6之后修复了这个问题,其实只是发生的概率降低了,没有根本上解决。


为什么用Netty?


1)API使用简单,更容易上手,开发门槛低;


2)功能强大,预置了多种编解码功能,支持多种主流协议;


3)定制能力高,可以通过ChannelHandler对通信框架进行灵活地拓展;


4)高性能,与目前多种NIO主流框架相比,Netty综合性能最高;


5)高稳定性,解决了JDK NIO的BUG;


6)经历了大规模的商业应用考验,质量和可靠性都有很好的验证。


为什么不用第三方SDK,如:融云、环信、腾讯TIM?


这个就见仁见智了,有的时候,是因为公司的技术选型问题,因为用第三方的SDK,意味着消息数据需要存储到第三方的服务器上,再者,可扩展性、灵活性肯定没有自己开发的要好,还有一个小问题,就是收费。比如,融云免费版只支持100个注册用户,超过100就要收费,群聊支持人数有限制等等...



▲ 以上截图内容来自某云IM官网


Mina其实跟Netty很像,大部分API都相同,因为是同一个作者开发的。但感觉Mina没有Netty成熟,在使用Netty的过程中,出了问题很轻易地可以找到解决方案,所以,Netty是一个不错的选择。


PS:有关MINA和Netty框架的关系和对比,详见以下文章:



有关“为何选择Netty”的11个疑问及解答


开源NIO框架八卦——到底是先有MINA还是先有Netty?


选Netty还是Mina:深入研究与对比(一)


选Netty还是Mina:深入研究与对比(二)



好了,废话不多说,直接开始吧。


7、准备工作


首先,我们新建一个Project,在Project里面再新建一个Android Library,Module名称暂且叫做im_lib,如图所示:



然后,分析一下我们的消息结构,每条消息应该会有一个消息唯一id,发送者id,接收者id,消息类型,发送时间等,经过分析,整理出一个通用的消息类型,如下:



msgId:消息id


fromId:发送者id


toId:接收者id


msgType:消息类型


msgContentType:消息内容类型


timestamp:消息时间戳


statusReport:状态报告


extend:扩展字段



根据上述所示,我整理了一个思维导图,方便大家参考:



这是基础部分,当然,大家也可以根据自己需要自定义比较适合自己的消息结构。


我们根据自定义的消息类型来编写proto文件:



syntax = "proto3";// 指定protobuf版本


option java_package = "com.freddy.im.protobuf";// 指定包名


option java_outer_classname = "MessageProtobuf";// 指定生成的类名


 


message Msg {


    Head head = 1;// 消息头


    string body = 2;// 消息体


}


 


message Head {


    string msgId = 1;// 消息id


    int32 msgType = 2;// 消息类型


    int32 msgContentType = 3;// 消息内容类型


    string fromId = 4;// 消息发送者id


    string toId = 5;// 消息接收者id


    int64 timestamp = 6;// 消息时间戳


    int32 statusReport = 7;// 状态报告


    string extend = 8;// 扩展字段,以key/value形式存放的json


}



然后执行命令(我用的mac,windows命令应该也差不多):



然后就会看到,在和proto文件同级目录下,会生成一个java类,这个就是我们需要用到的东东:



我们打开瞄一眼:



东西比较多,不用去管,这是google为我们生成的protobuf类,直接用就行,怎么用呢?


直接用这个类文件,拷到我们开始指定的项目包路径下就可以啦:



添加依赖后,可以看到,MessageProtobuf类文件已经没有报错了,顺便把netty的jar包也导进来一下,还有fastjson的:



建议用netty-all-x.x.xx.Final的jar包,后续熟悉了,可以用精简的jar包。


至此,准备工作已结束,下面,我们来编写java代码,实现即时通讯的功能。


8、代码封装


为什么需要封装呢?说白了,就是为了解耦,为了方便日后切换到不同框架实现,而无需到处修改调用的地方。


举个栗子,比如Android早期比较流行的图片加载框架是Universal ImageLoader,后期因为某些原因,原作者停止了维护该项目,目前比较流行的图片加载框架是Picasso或Glide,因为图片加载功能可能调用的地方非常多,如果不作一些封装,早期使用了Universal ImageLoader的话,现在需要切换到Glide,那改动量将非常非常大,而且还很有可能会有遗漏,风险度非常高。


那么,有什么解决方案呢?


很简单,我们可以用工厂设计模式进行一些封装,工厂模式有三种:简单工厂模式、抽象工厂模式、工厂方法模式。在这里,我采用工厂方法模式进行封装,具体区别,可以参见:《通俗讲讲我对简单工厂、工厂方法、抽象工厂三种设计模式的理解》。


我们分析一下,ims(IM Service,下文简称ims)应该是有初始化、建立连接、重连、关闭连接、释放资源、判断长连接是否关闭、发送消息等功能。


基于上述分析,我们可以进行一个接口抽象:




OnEventListener是与应用层交互的listener:



IMConnectStatusCallback是ims连接状态回调监听器:



然后写一个Netty tcp实现类:




接下来,写一个工厂方法:



封装部分到此结束,接下来,就是实现了。


9、初始化


我们先实现init(Vector serverUrlList, OnEventListener listener, IMSConnectStatusCallback callback)方法,初始化一些参数,以及进行第一次连接等:



其中,MsgDispatcher是消息转发器,负责将接收到的消息转发到应用层:



ExecutorServiceFactory是线程池工厂,负责调度重连及心跳线程:





10、连接及重连


resetConnect()方法作为连接的起点,首次连接以及重连逻辑,都是在resetConnect()方法进行逻辑处理。


我们来瞄一眼:



可以看到,非首次进行连接,也就是连接一个周期失败后,进行重连时,会先让线程休眠一段时间,因为这个时候也许网络状况不太好,接着,判断ims是否已关闭或者是否正在进行重连操作,由于重连操作是在子线程执行,为了避免重复重连,需要进行一些并发处理。


开始重连任务后,分四个步骤执行:



1)改变重连状态标识;


2)回调连接状态到应用层;


3)关闭之前打开的连接channel;


4)利用线程池执行一个新的重连任务。



ResetConnectRunnable是重连任务,核心的重连逻辑都放到这里执行:





toServer()是真正连接服务器的地方:



initBootstrap()是初始化Netty Bootstrap:



注:NioEventLoopGroup线程数设置为4,可以满足QPS是一百多万的情况了,至于应用如果需要承受上千万上亿流量的,需要另外调整线程数。(参考自:《netty实战之百万级流量NioEventLoopGroup线程数配置》)


接着,我们来看看TCPChannelInitializerHanlder



其中,ProtobufEncoderProtobufDecoder是添加对protobuf的支持,LoginAuthRespHandler是接收到服务端握手认证消息响应的处理handler,HeartbeatRespHandler是接收到服务端心跳消息响应的处理handler,TCPReadHandler是接收到服务端其它消息后的处理handler,先不去管,我们重点来分析下LengthFieldPrependerLengthFieldBasedFrameDecoder,这就需要引申到TCP的拆包与粘包啦。


11、TCP的拆包与粘包


什么是TCP拆包?为什么会出现TCP拆包?


简单地说,我们都知道TCP是以“流”的形式进行数据传输的,而且TCP为提高性能,发送端会将需要发送的数据刷入缓冲区,等待缓冲区满了之后,再将缓冲区中的数据发送给接收方,同理,接收方也会有缓冲区这样的机制,来接收数据。拆包就是在socket读取时,没有完整地读取一个数据包,只读取一部分。


什么是TCP粘包?为什么会出现TCP粘包?


同上。粘包就是在socket读取时,读到了实际意义上的两个或多个数据包的内容,同时将其作为一个数据包进行处理。


引用一张图片来解释一下在TCP出现拆包、粘包以及正常状态下的三种情况:



了解了TCP出现拆包/粘包的原因,那么,如何解决呢?


通常来说,有以下四种解决方式:



1)消息定长;


2)用回车换行符作为消息结束标志;


3)用特殊分隔符作为消息结束标志,如\t、\n等,回车换行符其实就是特殊分隔符的一种;


4)将消息分为消息头和消息体,在消息头中用字段标识消息总长度。



netty针对以上四种场景,给我们封装了以下四种对应的解码器:



1)FixedLengthFrameDecoder,定长消息解码器;


2)LineBasedFrameDecoder,回车换行符消息解码器;


3)DelimiterBasedFrameDecoder,特殊分隔符消息解码器;


4)LengthFieldBasedFrameDecoder,自定义长度消息解码器。



我们用到的就是LengthFieldBasedFrameDecoder自定义长度消息解码器,同时配合LengthFieldPrepender编码器使用,关于参数配置,建议参考《netty--最通用TCP黏包解决方案:LengthFieldBasedFrameDecoder和LengthFieldPrepender》这篇文章,讲解得比较细致。


我们配置的是消息头长度为2个字节,所以消息包的最大长度需要小于65536个字节,netty会把消息内容长度存放消息头的字段里,接收方可以根据消息头的字段拿到此条消息总长度,当然,netty提供的LengthFieldBasedFrameDecoder已经封装好了处理逻辑,我们只需要配置lengthFieldOffset、lengthFieldLength、lengthAdjustment、initialBytesToStrip即可,这样就可以解决TCP的拆包与粘包,这也就是netty相较于原生nio的便捷性,原生nio需要自己处理拆包/粘包等问题。


12、长连接握手认证


接着,我们来看看LoginAuthHandler和HeartbeatRespHandler。


LoginAuthRespHandler:是当客户端与服务端长连接建立成功后,客户端主动向服务端发送一条登录认证消息,带入与当前用户相关的参数,比如token,服务端收到此消息后,到数据库查询该用户信息,如果是合法有效的用户,则返回一条登录成功消息给该客户端,反之,返回一条登录失败消息给该客户端,这里,就是在接收到服务端返回的登录状态后的处理handler。


比如:



可以看到,当接收到服务端握手消息响应后,会从扩展字段取出status,如果status=1,则代表握手成功,这个时候就先主动向服务端发送一条心跳消息,然后利用Netty的IdleStateHandler读写超时机制,定期向服务端发送心跳消息,维持长连接,以及检测长连接是否还存在等。


HeartbeatRespHandler:是当客户端接收到服务端登录成功的消息后,主动向服务端发送一条心跳消息,心跳消息可以是一个空包,消息包体越小越好,服务端收到客户端的心跳包后,原样返回给客户端,这里,就是收到服务端返回的心跳消息响应的处理handler。


比如:



这个就比较简单,收到心跳消息响应,无需任务处理,直接打印一下方便我们分析即可。


13、心跳机制及读写超时机制


心跳包是定期发送,也可以自己定义一个周期,比如:《移动端IM实践:实现Android版微信的智能心跳机制》,为了简单,此处规定应用在前台时,8秒发送一个心跳包,切换到后台时,30秒发送一次,根据自己的实际情况修改一下即可。心跳包用于维持长连接以及检测长连接是否断开等。


PS:更多心跳保活方面的文章请见:



Android端消息推送总结:实现原理、心跳保活、遇到的问题等


为何基于TCP协议的移动端IM仍然需要心跳保活机制?


微信团队原创分享:Android版微信后台保活实战分享(网络保活篇)


移动端IM实践:WhatsApp、Line、微信的心跳策略分析



接着,我们利用Netty的读写超时机制,来实现一个心跳消息管理handler:



可以看到,利用userEventTriggered()方法回调,通过IdleState类型,可以判断读超时/写超时/读写超时,这个在添加IdleStateHandler时可以配置,下面会贴上代码。


首先我们可以在READER_IDLE事件里,检测是否在规定时间内没有收到服务端心跳包响应,如果是,那就触发重连操作。在WRITER_IDEL事件可以检测客户端是否在规定时间内没有向服务端发送心跳包,如果是,那就主动发送一个心跳包。发送心跳包是在子线程中执行,我们可以利用之前写的work线程池进行线程管理。


addHeartbeatHandler()代码如下:



从图上可看到,在IdleStateHandler里,配置的读超时为心跳间隔时长的3倍,也就是3次心跳没有响应时,则认为长连接已断开,触发重连操作。写超时则为心跳间隔时长,意味着每隔heartbeatInterval会发送一个心跳包。读写超时没用到,所以配置为0。


onConnectStatusCallback(int connectStatus)为连接状态回调,以及一些公共逻辑处理:



连接成功后,立即发送一条握手消息,再次梳理一下整体流程:


1)客户端根据服务端返回的host及port,进行第一次连接;


2)连接成功后,客户端向服务端发送一条握手认证消息(1001);


3)服务端在收到客户端的握手认证消息后,从扩展字段里取出用户token,到本地数据库校验合法性;


4)校验完成后,服务端把校验结果通过1001消息返回给客户端,也就是握手消息响应;


5)客户端收到服务端的握手消息响应后,从扩展字段取出校验结果。若校验成功,客户端向服务端发送一条心跳消息(1002),然后进入心跳发送周期,定期间隔向服务端发送心跳消息,维持长连接以及实时检测链路可用性,若发现链路不可用,等待一段时间触发重连操作,重连成功后,重新开始握手/心跳的逻辑。


看看TCPReadHandler收到消息是怎么处理的:




可以看到,在channelInactive()exceptionCaught()方法都触发了重连,channelInactive()方法在当链路断开时会调用,exceptionCaught()方法在当出现异常时会触发,另外,还有诸如channelUnregistered()channelReadComplete()等方法可以重写,在这里就不贴了,相信聪明的你一眼就能看出方法的作用。


我们仔细看一下channelRead()方法的逻辑,在if判断里,先判断消息类型,如果是服务端返回的消息发送状态报告类型,则判断消息是否发送成功,如果发送成功,从超时管理器中移除,这个超时管理器是干嘛的呢?


下面讲到消息重发机制的时候会详细地讲。在else里,收到其他消息后,会立马给服务端返回一个消息接收状态报告,告诉服务端,这条消息我已经收到了,这个动作,对于后续需要做的离线消息会有作用。如果不需要支持离线消息功能,这一步可以省略。最后,调用消息转发器,把接收到的消息转发到应用层即可。


代码写了这么多,我们先来看看运行后的效果,先贴上缺失的消息发送代码及ims关闭代码以及一些默认配置项的代码。


发送消息:



关闭ims:



ims默认配置:



还有,应用层实现的ims client启动器:



由于代码有点多,不太方便全部贴上,如果有兴趣可以下载本文的完整demo进行体验。


额,对了,还有一个简易的服务端代码,如下:





14、运行调试


我们先来看看连接及重连部分(由于录制gif比较麻烦,体积较大,所以我先把重连间隔调小成3秒,方便看效果)。


启动服务端:



启动客户端:



可以看到,正常的情况下已经连接成功了,接下来,我们来试一下异常情况。


比如服务端没启动,看看客户端的重连情况:



这次我们先启动的是客户端,可以看到连接失败后一直在进行重连,由于录制gif比较麻烦,在第三次连接失败后,我启动了服务端,这个时候客户端就会重连成功。


然后,我们再来调试一下握手认证消息即心跳消息:



可以看到,长连接建立成功后,客户端会给服务端发送一条握手认证消息(1001),服务端收到握手认证消息会,给客户端返回了一条握手认证状态消息,客户端收到握手认证状态消息后,即启动心跳机制。gif不太好演示,下载demo就可以直观地看到。


接下来,在讲完消息重发机制及离线消息后,我会在应用层做一些简单的封装,以及在模拟器上运行,这样就可以很直观地看到运行效果。


15、消息重发机制


消息重发,顾名思义,即使对发送失败的消息进行重发。考虑到网络环境的不稳定性、多变性(比如从进入电梯、进入地铁、移动网络切换到wifi等),在消息发送的时候,发送失败的概率其实不小,这时消息重发机制就很有必要了。


有关即时通讯(IM)应用中的消息送达保证机制,可以详细阅读以下文章:



IM消息送达保证机制实现(一):保证在线实时消息的可靠投递


IM群聊消息如此复杂,如何保证不丢不重?


完全自已开发的IM该如何设计“失败重试”机制?



我们先来看看实现的代码逻辑。


MsgTimeoutTimer:




MsgTimeoutTimerManager:




然后,我们看看收消息的TCPReadHandler的改造:



最后,看看发送消息的改造:



说一下逻辑吧:发送消息时,除了心跳消息、握手消息、状态报告消息外,消息都加入消息发送超时管理器,立马开启一个定时器,比如每隔5秒执行一次,共执行3次,在这个周期内,如果消息没有发送成功,会进行3次重发,达到3次重发后如果还是没有发送成功,那就放弃重发,移除该消息,同时通过消息转发器通知应用层,由应用层决定是否再次重发。如果消息发送成功,服务端会返回一个消息发送状态报告,客户端收到该状态报告后,从消息发送超时管理器移除该消息,同时停止该消息对应的定时器即可。


另外,在用户握手认证成功时,应该检查消息发送超时管理器里是否有发送超时的消息,如果有,则全部重发:



16、离线消息


由于离线消息机制,需要服务端数据库及缓存上的配合,代码就不贴了,太多太多。


我简单说一下实现思路吧:客户端A发送消息到客户端B,消息会先到服务端,由服务端进行中转。


这个时候,客户端B存在两种情况:



1)长连接正常,就是客户端网络环境良好,手机有电,应用处在打开的情况;


2)废话,那肯定就是长连接不正常咯。这种情况有很多种原因,比如wifi不可用、用户进入了地铁或电梯等网络不好的场所、应用没打开或已退出登录等,总的来说,就是没有办法正常接收消息。



如果是长连接正常,那没什么可说的,服务端直接转发即可。


如果长连接不正常,需要这样处理:


服务端接收到客户端A发送给客户端B的消息后,先给客户端A回复一条状态报告,告诉客户端A,我已经收到消息,这个时候,客户端A就不用管了,消息只要到达服务端即可。然后,服务端先尝试把消息转发到客户端B,如果这个时候客户端B收到服务端转发过来的消息,需要立马给服务端回一条状态报告,告诉服务端,我已经收到消息,服务端在收到客户端B返回的消息接收状态报告后,即认为此消息已经正常发送,不需要再存库。


如果客户端B不在线,服务端在做转发的时候,并没有收到客户端B返回的消息接收状态报告,那么,这条消息就应该存到数据库,直到客户端B上线后,也就是长连接建立成功后,客户端B主动向服务端发送一条离线消息询问,服务端在收到离线消息询问后,到数据库或缓存去查客户端B的所有离线消息,并分批次返回,客户端B在收到服务端的离线消息返回后,取出消息id(若有多条就取id集合),通过离线消息应答把消息id返回到服务端,服务端收到后,根据消息id从数据库把对应的消息删除即可。


以上是单聊离线消息处理的情况,群聊有点不同,群聊的话,是需要服务端确认群组内所有用户都收到此消息后,才能从数据库删除消息,就说这么多,如果需要细节的话,可以私信我。


更多有关离线消息处理思路的文章,可以详细阅读:



IM消息送达保证机制实现(二):保证离线消息的可靠投递


IM群聊消息如此复杂,如何保证不丢不重?


浅谈移动端IM的多点登陆和消息漫游原理



不知不觉,NettyTcpClient中定义了很多变量,为了防止大家不明白变量的定义,还是贴上代码吧:



18、最终运行


运行一下,看看效果吧:



运行步骤是:



1)首先,启动服务端。


2)然后,修改客户端连接的ip地址为192.168.0.105(这是我本机的ip地址),端口号为8855,fromId,也就是userId,定义成100001,toId为100002,启动客户端A。


3)再然后,fromId,也就是userId,定义成100002,toId为100001,启动客户端B。


4)客户端A给客户端B发送消息,可以看到在客户端B的下面,已经接收到了消息。


5)用客户端B给客户端A发送消息,也可以看到在客户端A的下面,也已经接收到了消息。



至于,消息收发测试成功。至于群聊或重连等功能,就不一一演示了,还是那句话,下载demo体验一下吧:https://github.com/52im/NettyChat


由于gif录制体积较大,所以只能简单演示一下消息收发,具体下载demo体验吧。如果有需要应用层UI实现(就是聊天页及会话页的封装)的话,我再分享出来吧。


19、写在最后


终于写完了,这篇文章大概写了10天左右,有很大部分的原因是自己有拖延症,每次写完一小段,总静不下心来写下去,导致一直拖到现在,以后得改改。第一次写技术分享文章,有很多地方也许逻辑不太清晰,由于篇幅有限,也只是贴了部分代码,建议大家把源码下载下来看看。一直想写这篇文章,以前在网上也尝试过找过很多im方面的文章,都找不到一篇比较完善的,本文谈不上完善,但包含的模块很多,希望起到一个抛砖引玉的作用,也期待着大家跟我一起发现更多的问题并完善,最后,如果这篇文章对你有用,希望在github上给我一个star哈。。。


应大家要求,精简了netty-all-4.1.33.Final.jar包,原netty-all-4.1.33.Final.jar包大小为3.9M。


经测试发现目前im_lib库只需要用到以下jar包:



netty-buffer-4.1.33.Final.jar


netty-codec-4.1.33.Final.jar


netty-common-4.1.33.Final.jar


netty-handler-4.1.33.Final.jar


netty-resolver-4.1.33.Final.jar


netty-transport-4.1.33.Final.jar



所以,抽取以上jar包,重新打成了netty-tcp-4.1.33-1.0.jar(已经上传到github工程了),目前自测没有问题,如果发现bug,请告诉我,谢谢。


附上原jar及裁剪后jar包的大小对比:




代码已更新到Github:


https://github.com/52im/NettyChat


附录:更多网络编程/即时通讯/消息推送的实战入门文章



手把手教你用Netty实现网络通信程序的心跳机制、断线重连机制
NIO框架入门(一):服务端基于Netty4的UDP双向通信Demo演示
NIO框架入门(二):服务端基于MINA2的UDP双向通信Demo演示
NIO框架入门(三):iOS与MINA2、Netty4的跨平台UDP双向通信实战
NIO框架入门(四):Android与MINA2、Netty4的跨平台UDP双向通信实战
微信小程序中如何使用WebSocket实现长连接(含完整源码)
Web端即时通讯安全:跨站点WebSocket劫持漏洞详解(含示例代码)
解决MINA数据传输中TCP的粘包、缺包问题(有源码)
开源IM工程“蘑菇街TeamTalk”2015年5月前未删减版完整代码 [附件下载]
用于IM中图片压缩的Android工具类源码,效果可媲美微信 [附件下载]
高仿Android版手机QQ可拖拽未读数小气泡源码 [附件下载]
一个WebSocket实时聊天室Demo:基于node.js+socket.io [附件下载]
Android聊天界面源码:实现了聊天气泡、表情图标(可翻页) [附件下载]
高仿Android版手机QQ首页侧滑菜单源码 [附件下载]
开源libco库:单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]
分享java AMR音频文件合并源码,全网最全
微信团队原创Android资源混淆工具:AndResGuard [有源码]
一个基于MQTT通信协议的完整Android推送Demo [附件下载]
Android版高仿微信聊天界面源码 [附件下载]
高仿手机QQ的Android版锁屏聊天消息提醒功能 [附件下载]
高仿iOS版手机QQ录音及振幅动画完整实现 [源码下载]
Android端社交应用中的评论和回复功能实战分享[图文+源码]
Android端IM应用中的@人功能实现:仿微博、QQ、微信,零入侵、高可扩展[图文+源码]
仿微信的IM聊天时间显示格式(含iOS/Android/Web实现)[图文+源码]



(本文同步发布于:http://www.52im.net/thread-2671-1-1.html

收起阅读 »

从零开始开发IM(即时通讯)服务端

IM
精选:★→2020年最新的常问企业面试题大全以及答案 作者:yuanrw 原文地址 https://juejin.im/post/5d6b3949f265da03c34c13e5 好消息:IM1.0.0 版本已经上线啦,支持特性: ...
继续阅读 »

精选:★→2020年最新的常问企业面试题大全以及答案



作者:yuanrw


原文地址 https://juejin.im/post/5d6b3949f265da03c34c13e5



好消息:IM1.0.0 版本已经上线啦,支持特性



  • 私聊发送文本 / 文件


  • 已发送 / 已送达 / 已读回执


  • 支持使用 ldap 登录


  • 支持接入外部的登录认证系统


  • 提供客户端 jar 包,方便客户端开发
    github 链接: github.com/yuanrw/IM



前言


首先讲讲 IM(即时通讯)技术可以用来做什么:
聊天:qq、微信
直播:斗鱼直播、抖音
实时位置共享、游戏多人互动等等
可以说几乎所有高实时性的应用场景都需要用到 IM 技术。


本篇将带大家从零开始搭建一个轻量级的 IM 服务端,麻雀虽小,五脏俱全,我们搭建的 IM 服务端实现以下功能



  1. 一对一的文本消息、文件消息通信


  2. 每个消息有 “已发送”/“已送达”/“已读” 回执


  3. 存储离线消息


  4. 支持用户登录,好友关系等基本功能。


  5. 能够方便地水平扩展



通过这个项目能学到什么?


这个项目涵盖了很多后端必备知识



  • rpc 通信


  • 数据库


  • 缓存


  • 消息队列


  • 分布式、高并发的架构设计


  • docker 部署



消息通信


文本消息


我们先从最简单的特性开始实现:一个普通消息的发送
消息格式如下:


message ChatMsg{
id = 1;
//消息id
fromId = Alice
//发送者userId
destId = Bob
//接收者userId
msgBody = hello
//消息体
}
复制代码


如上图,我们现在有两个用户:Alice 和 Bob 连接到了服务器,当 Alice 发送消息


message(hello)


给 Bob,服务端接收到消息,根据消息的 destId 进行转发,转发给 Bob。


发送回执


那我们要怎么来实现回执的发送呢?
我们定义一种回执数据格式 ACK,MsgType 有三种,分别是 sent(已发送), delivered(已送达), read(已读):


message AckMsg {
id;
//消息id
fromId;
//发送者id
destId;
//接收者id
msgType;
//消息类型
ackMsgId;
//确认的消息id
}
enum MsgType {
DELIVERED;
READ;
}
复制代码

当服务端接受到 Alice 发来的消息时:



  1. 向 Alice 发送一个 sent(hello)表示消息已经被发送到服务器。



message AckMsg {
id = 2;
fromId = Alice;
destId = Bob;
msgType = SENT;
ackMsgId = 1;
}
复制代码



  1. 服务器把



hello


转发给 Bob 后,立刻向 Alice 发送


delivered(hello)


表示消息已经发送给 Bob。


message AckMsg {
id = 3;
fromId = Bob;
destId = Alice;
msgType = DELIVERED;
ackMsgId = 1;
}
复制代码



  1. Bob 阅读消息后,客户端向服务器发送



read(hello)


表示消息已读


message AckMsg {
id = 4;
fromId = Bob;
destId = Alice;
msgType = READ;
ackMsgId = 1;
}
复制代码

这个消息会像一个普通聊天消息一样被服务器处理,最终发送给 Alice。



在服务器这里不区分 ChatMsg和 AckMsg,处理过程都是一样的:解析消息的 destId并进行转发。


水平扩展


当用户量越来越大,必然需要增加服务器的数量,用户的连接被分散在不同的机器上。此时,就需要存储用户连接在哪台机器上。
我们引入一个新的模块来管理用户的连接信息。


管理用户状态



模块叫做 user status,共有三个接口:


public interface UserStatusService {
/**
* 用户上线,存储userId与机器id的关系
*
* @param userId
* @param connectorId
* @return 如果当前用户在线,则返回他连接的机器id,否则返回null
*/
String online(String userId, String connectorId);
/**
* 用户下线
*
* @param userId
*/
void offline(String userId);
/**
* 通过用户id查找他当前连接的机器id
*
* @param userId
* @return
*/
String getConnectorId(String userId);
}
复制代码

这样我们就能够对用户连接状态进行管理了,具体的实现应考虑服务的用户量、期望性能等进行实现。
此处我们使用 redis 来实现,将 userId 和 connectorId 的关系以 key-value 的形式存储。


消息转发


除此之外,还需要一个模块在不同的机器上转发消息,如下结构:



此时我们的服务被拆分成了 connector和 transfer两个模块, connector模块用于维持用户的长链接,而 transfer的作用是将消息在多个 connector之间转发。
现在 Alice 和 Bob 连接到了两台 connector 上,那么消息要如何传递呢?



  1. Alice 上线,连接到 机器[1]上时




  • 将 Alice 和它的连接存入内存中。


  • 调用 user status的 online方法记录 Alice 上线。




  • Alice 发送了一条消息给 Bob




    • 机器[1]收到消息后,解析 destId,在内存中查找是否有 Bob。


    • 如果没有,代表 Bob 未连接到这台机器,则转发给 transfer



  • transfer调用 user status的 getConnectorId(Bob)方法找到 Bob 所连接的 connector,返回 机器[2],则转发给 机器[2]


  • 流程图:

    总结:



    • 引入 user status模块管理用户连接, transfer模块在不同的机器之间转发,使服务可以水平扩展。


    • 为了满足实时转发, transfer需要和每台 connector机器都保持长链接。


    离线消息

    如果用户当前不在线,就必须把消息持久化下来,等待用户下次上线再推送,这里使用 mysql 存储离线消息。
    为了方便地水平扩展,我们使用消息队列进行解耦



    • transfer接收到消息后如果发现用户不在线,就发送给消息队列入库。


    • 用户登录时,服务器从库里拉取离线消息进行推送。


    用户登录、好友关系

    用户的注册登录、账户管理、好友关系链等功能更适合使用 http 协议,因此我们将这个模块做成一个 restful 服务,对外暴露 http 接口供客户端调用。

    至此服务端的基本架构就完成了:

    总结

    以上就是这篇博客的所有内容,本篇帮大家构建了 IM 服务端的架构,但还有很多细节需要我们去思考,例如:



    • 如何保证消息的顺序和唯一


    • 多个设备在线如何保证消息一致性


    • 如何处理消息发送失败


    • 消息的安全性


    • 如果要存储聊天记录要怎么做


    • 数据库分表分库


    • 服务高可用
      ……


    更多细节实现就留到下一篇啦~

    IM1.0.0 版本已上线,github 链接: github.com/yuanrw/IM
    觉得对你有帮助请点个 star 吧~!

    (完)

    推荐阅读

    Spring Boot整合JWT实现用户认证(附源码)

    IDEA新特性:提前知道代码怎么走

    还在担心写的一手烂SQL,送你4款工

    瞬间几千次的重复提交,我用 SpringBoot+Redis 扛住了

    爬了知乎“神回复”,笑得根本停不下来

    这 17 个 JVM 参数,高级 Java 必须掌握!


    好文!必须点赞


收起阅读 »

iOS-编译过程

编译器iOS编译和打包时,编译器直接将代码编译成机器码,然后直接在CPU上运行。而不用使用解释器运行代码。因为这样执行效率更高,运行速度更快。C,C++,OC都是使用的编译器生成相关的可执行文件。解释器:解释器会在运行时解释执行代码,获取一段代码后就会将其翻译...
继续阅读 »

编译器

iOS编译和打包时,编译器直接将代码编译成机器码,然后直接在CPU上运行。而不用使用解释器运行代码。因为这样执行效率更高,运行速度更快。C,C++,OC都是使用的编译器生成相关的可执行文件。

解释器:解释器会在运行时解释执行代码,获取一段代码后就会将其翻译成目标代码(就是字节码(Bytecode)),然后一句一句地执行目标代码。也就是说是在运行时才去解析代码,比直接运行编译好的可执行文件自然效率就低,但是跑起来之后可以不用重启启动编译,直接修改代码即可看到效果,类似热更新,可以帮我们缩短整个程序的开发周期和功能更新周期。

编译器:把一种编程语言(原始语言)转换为另一种编程语言(目标语言)的程序叫做编译器

采用编译器生成机器码执行的好处是效率高,缺点是调试周期长。
解释器执行的好处是编写调试方便,缺点是执行效率低。

编译器分为前端和后端
  • 前端:前端负责语法分析、词法分析,生成中间代码
  • 后端:后端以中间代码作为输入,进行架构无关的代码优化,接着针对不同架构生成不同的机器码
    在2007年之前LLVM使用GCC作为前端来对用户程序进行语义分析产生 IF(Intermidiate Format)。GCC系统庞大而笨重,因此,Apple决定从零开始写C、C++、Objective-C语言的前端Clang,以求完全替代掉GCC。
现在苹果公司使用的编译器是 LLVM,前端是Clang,相比于 Xcode 5 版本前使用的 GCC,编译速度提高了 3 倍。同时,苹果公司也反过来主导了 LLVM 的发展,让 LLVM 可以针对苹果公司的硬件进行更多的优化。
Clang于2007年开始开发,C编译器最早完成,在2009年的时候,Objective-C编译器已经完全可以用于生产环境,而在一年之后,Clang基本实现了对C++编译的支持。

对于Apple来说Objective C/C/C++使用的编译器前端是clang,后端都是LLVM

LLVM 是编译器工具链技术的一个集合。而其中的 lld 项目,就是内置链接器。编译器会对每个文件进行编译,生成 Mach-O(可执行文件);链接器会将项目中的多个 Mach-O 文件合并成一个。

编译过程

  • 预处理:Clang会预处理你的代码,比如把宏嵌入到对应的位置、注释被删除,条件编译被处理
  • 词法分析:词法分析器读入源文件的字符流,将他们组织称有意义的词素(lexeme)序列,对于每个词素,此法分析器产生词法单元(token)作为输出。并且会用Loc来记录位置。
  • 语法分析:这一步是把词法分析生成的标记流,解析成一个抽象语法树(abstract syntax tree -- AST),同样地,在这里面每一节点也都标记了其在源码中的位置。
    AST 是抽象语法树,结构上比代码更精简,遍历起来更快,所以使用 AST 能够更快速地进行静态检查。
  • 静态分析:把源码转化为抽象语法树之后,编译器就可以对这个树进行静态分析处理。静态分析会对代码进行错误检查,如出现方法被调用但是未定义、定义但是未使用的变量等,以此提高代码质量。当然,还可以通过使用 Xcode 自带的静态分析工具(Product -> Analyze)进行手动分析。最后 AST 会生成 IR,IR 是一种更接近机器码的语言,区别在于和平台无关,通过 IR 可以生成多份适合不同平台的机器码。静态分析的阶段会进行类型检查,比如给属性设置一个与其自身类型不相符的对象,编译器会给出一个可能使用不正确的警告。在此阶段也会检查时候有未使用过的变量等。
  • 中间代码生成和优化:此阶段LLVM 会对代码进行编译优化,例如针对全局变量优化、循环优化、尾递归优化等,最后输出汇编代码xx.ll文件。
    生成汇编代码: 汇编器LLVM会将汇编码转为机器码。此时的代码就是.o文件,即二进制文件。
  • 链接:连接器把编译产生的.o文件和(dylib,a,tbd)文件,生成一个mach-o文件。mach-o文件级可执行文件。编译过程全部结束,生成了可执行文件Mach-O

连接器

Mach-O 文件里面的内容,主要就是代码和数据:代码是函数的定义;数据是全局变量的定义,包括全局变量的初始值。不管是代码还是数据,它们的实例都需要由符号将其关联起来。

为什么呢?因为 Mach-O 文件里的那些代码,比如 if、for、while 生成的机器指令序列,要操作的数据会存储在某个地方,变量符号就需要绑定到数据的存储地址。你写的代码还会引用其他的代码,引用的函数符号也需要绑定到该函数的地址上。而链接器的作用,就是完成变量、函数符号和其地址绑定这样的任务。而这里我们所说的符号,就可以理解为变量名和函数名。

那为什么要让链接器做符号和地址绑定这样一件事儿呢?

如果地址和符号不做绑定的话,要让机器知道你在操作什么内存地址,你就需要在写代码时给每个指令设好内存地址。写这样的代码的过程,就像你直接在和不同平台的机器沟通,连编译生成 AST 和 IR 的步骤都省掉了,甚至优化平台相关的代码都需要你自己编写。

可读性和可维护性都会很差,比如修改代码后对地址的维护就会让你崩溃。而这种“崩溃”的罪魁祸首就是代码和内存地址绑定得太早。
用汇编语言来让这种绑定滞后。随着编程语言的进化,我们很快就发现,采用任何一种高级编程语言,都可以解决代码和内存绑定过早产生的问题,同时还能扫掉使用汇编写程序的烦恼。

链接器为什么还要把项目中的多个 Mach-O 文件合并成一个

项目中文件之间的变量和接口函数都是相互依赖的,所以这时我们就需要通过链接器将项目中生成的多个 Mach-O 文件的符号和地址绑定起来。

没有这个绑定过程的话,单个文件生成的 Mach-O 文件是无法正常运行起来的。因为,如果运行时碰到调用在其他文件中实现的函数的情况时,就会找不到这个调用函数的地址,从而无法继续执行。

链接器在链接多个目标文件的过程中,会创建一个符号表,用于记录所有已定义的和所有未定义的符号。链接时如果出现相同符号的情况,就会出现“ld: dumplicate symbols”的错误信息;如果在其他目标文件里没有找到符号,就会提示“Undefined symbols”的错误信息。

链接器做了什么
  • 在项目文件中查找目标代码文件里没有定义的变量
  • 扫描项目中的不同文件,将所有符号定义和引用地址收集起来,并放到全局符号表中
  • 计算合并后长度及位置,生成同类型的段进行合并,建立绑定
  • 对项目中不同文件里的变量进行地址重定位
  • 去除无用函数:链接器在整理函数的调用关系时,会以 main 函数为源头,跟随每个引用,并将其标记为 live。跟随完成后,那些未被标记 live 的函数,就是无用函数。然后,链接器可以通过打开 Dead code stripping 开关,来开启自动去除无用代码的功能。并且,这个开关是默认开启的。

动态库链接

在真实的 iOS 开发中,你会发现很多功能都是现成可用的,比如 系统库、GUI 框架、I/O、网络等。链接这些共享库到你的 Mach-O 文件,也是通过链接器来完成的。

链接的共用库分为静态库和动态库:静态库是编译时链接的库,需要链接进你的 Mach-O 文件里,如果需要更新就要重新编译一次,无法动态加载和更新;而动态库是运行时链接的库,使用 dyld 就可以实现动态加载。
Mach-O 文件是编译后的产物,而动态库在运行时才会被链接,并没参与 Mach-O 文件的编译和链接,所以 Mach-O 文件中并没有包含动态库里的符号定义。也就是说,这些符号会显示为“未定义”,但它们的名字和对应的库的路径会被记录下来。运行时通过 dlopen 和 dlsym 导入动态库时,先根据记录的库路径找到对应的库,再通过记录的名字符号找到绑定的地址。

dlopen 会把共享库载入运行进程的地址空间,载入的共享库也会有未定义的符号,这样会触发更多的共享库被载入。dlopen 也可以选择是立刻解析所有引用还是滞后去做。dlopen 打开动态库后返回的是引用的指针,dlsym 的作用就是通过 dlopen 返回的动态库指针和函数符号,得到函数的地址然后使用。

使用 dyld 加载动态库,有两种方式:有程序启动加载时绑定和符号第一次被用到时绑定。为了减少启动时间,大部分动态库使用的都是符号第一次被用到时再绑定的方式。
加载过程开始会修正地址偏移,iOS 会用 ASLR 来做地址偏移避免攻击,确定 Non-Lazy Pointer 地址进行符号地址绑定,加载所有类,最后执行 load 方法和 Clang Attribute 的 constructor 修饰函数。每个函数、全局变量和类都是通过符号的形式定义和使用的,当把目标文件链接成一个 Mach-O 文件时,链接器在目标文件和动态库之间对符号做解析处理。

dylib 这种格式,表示是动态链接的,编译的时候不会被编译到执行文件中,在程序执行的时候才 link,这样就不用算到包大小里,而且不更新执行程序就能够更新库。
系统上的动态链接器会使用共享缓存,共享缓存在 /var/db/dyld/。当加载 Mach-O 文件时,动态链接器会先检查是否有共享缓存。每个进程都会在自己的地址空间映射这些共享缓存,这样做可以起到优化 App 启动速度的作用。

编译和启动速度

编译阶段由于有了链接器,代码可以写在不同的文件里,每个文件都能够独立编成 Mach-O 文件进行标记。编译器可以根据你修改的文件范围来减少编译,通过这种方式提高每次编译的速度。

这也是为什么文件越多,链接器链接 Mach-O 文件所需绑定的遍历操作就会越多,编译速度也会越慢。
开发时启动优化:对于大型APP项目在开发调试阶段,是不是代码改完以后可以先不去链接项目里的所有文件,只编译当前修改的文件动态库,通过运行时加载动态库及时更新,看到修改的结果。这样调试的速度,不就能够得到质的提升了么?



转自链接:https://www.jianshu.com/p/d946961551b0
收起阅读 »

iOS- 核心动画分类以及基本使用

1、UIView和核心动画区别?核心动画只能添加到CALayer, 核心动画一切都是假象,并不会改变真实的值。如果需要与用户交互就使用UIView的动画. 不需要与用户交互可以使用核心动画。在转场动画中,核心动画的类型比较多。根据⼀个路径做动画,只能用核心动画...
继续阅读 »

1、UIView和核心动画区别?

核心动画只能添加到CALayer, 核心动画一切都是假象,并不会改变真实的值。如果需要与用户交互就使用UIView的动画. 不需要与用户交互可以使用核心动画。

在转场动画中,核心动画的类型比较多。根据⼀个路径做动画,只能用核心动画(帧动画) 、动画组:同时做多个动画。

2、核心动画的分类

核心动画继承结构
图中的黑色虚线代表“继承”某个类,红色虚线代表“遵守”某个协议


CAAnimation是所有动画对象的父类,负责控制动画的持续时间和速度,是个抽象类,不能直接使用,应该使用它具体的子类
属性说明:(红色代表来自CAMediaTiming协议的属性)

  • duration:动画的持续时间
  • repeatCount:重复次数,无限循环可以设置HUGE_VALF或者MAXFLOAT
  • repeatDuration:重复时间
  • removedOnCompletion:默认为YES,代表动画执行完毕后就从图层上移除,图形会恢复到动画执行前的状态。如果想让图层保持显示动画执行后的状态,那就设置为NO,不过还要设置fillModekCAFillModeForwards

    -fillMode:决定当前对象在非active时间段的行为。比如动画开始之前或者动画结束之后


  • beginTime:可以用来设置动画延迟执行时间,若想延迟2s,就设置为CACurrentMediaTime()+2CACurrentMediaTime()为图层的当前时间


  • timingFunction:速度控制函数,控制动画运行的节奏


  • delegate:动画代理

  • fillMode属性值(要想fillMode有效,最好设置removedOnCompletion = NO
    kCAFillModeRemoved这个是默认值,也就是说当动画开始前和动画结束后,动画对layer都没有影响,动画结束后,layer会恢复到之前的状态
    kCAFillModeForwards 当动画结束后,layer会一直保持着动画最后的状态
    kCAFillModeBackwards 在动画开始前,只需要将动画加入了一个layer,layer便立即进入动画的初始状态并等待动画开始。
    kCAFillModeBoth这个其实就是上面两个的合成.动画加入后开始之前,layer便处于动画初始状态,动画结束后layer保持动画最后的状态

    速度控制函数(CAMediaTimingFunction)
    kCAMediaTimingFunctionLinear(线性):匀速,给你一个相对静态的感觉
    kCAMediaTimingFunctionEaseIn(渐进):动画缓慢进入,然后加速离开
    kCAMediaTimingFunctionEaseOut(渐出):动画全速进入,然后减速的到达目的地
    kCAMediaTimingFunctionEaseInEaseOut(渐进渐出):动画缓慢的进入,中间加速,然后减速的到达目的地。这个是默认的动画行为。
    CAAnimationDelegate代理方法只是监听动画的开始和结束
@protocol CAAnimationDelegate <NSObject>
@optional

/* Called when the animation begins its active duration. */

- (void)animationDidStart:(CAAnimation *)anim;

/* Called when the animation either completes its active duration or
* is removed from the object it is attached to (i.e. the layer). 'flag'
* is true if the animation reached the end of its active duration
* without being removed. */

- (void)animationDidStop:(CAAnimation *)anim finished:(BOOL)flag;

@end

CALayer上动画的暂停和恢复

- (void)pauseLayerAnimation:(CALayer *)layer {
CFTimeInterval pauseTimes = [layer convertTime:CACurrentMediaTime() fromLayer:nil];
// speed动画的运行速度,当为0时会停止动画,speed越大说明动画执行速度越快
layer.speed = 0.0;
// 让layer的时间停留在pauseTimes
// 动画的时间偏移,也就是上次动画的暂停/继续 距离本次动画的继续/暂停的时间差
layer.timeOffset = pauseTimes;
NSLog(@":pauseTimes:%f", pauseTimes);
}
- (void)resumeLayerAnimation:(CALayer *)layer {
CFTimeInterval pauseTimes = layer.timeOffset;
//让CALayer的时间继续行走
layer.speed = 1;
// 取消上次记录的停留时刻
layer.timeOffset = 0.0;
//取消上次设置的时间
layer.beginTime = 0.0;

CFTimeInterval timeSincePause = CACurrentMediaTime()-pauseTimes;
layer.beginTime = timeSincePause;

NSLog(@":timeSincePause:%f", timeSincePause);

}


第一次暂停和开始是正常的,之后就会出现偏移,暂时搞不清楚是什么原因???????????????

原因:

-(CFTimeInterval)convertTime:(CFTimeInterval)t fromLayer:(CALayer)l; -(CFTimeInterval)convertTime:(CFTimeInterval)t toLayer:(CALayer)l;这两个方法混用了

2、CABasicAnimation——基本动画


基本动画,是CAPropertyAnimation的子类


属性说明:

fromValue:keyPath相应属性的初始值

toValue:keyPath相应属性的结束值

动画过程说明:
随着动画的进行,在长度为duration的持续时间内,keyPath相应属性的值从fromValue渐渐地变为toValue
keyPath内容是CALayer的可动画Animatable属性
如果fillMode==kCAFillModeForwards同时removedOnComletion=NO,那么在动画执行完毕后,图层会保持显示动画执行后的状态。但在实质上,图层的属性值还是动画执行前的初始值,并没有真正被改变。
CABasicAnimation *basicAnim = [CABasicAnimation animation];

basicAnim.keyPath = @"position.y";
basicAnim.fromValue = @(self.redView.layer.position.y);
basicAnim.toValue = @(self.redView.layer.position.y + 300);

basicAnim.duration = 2.0;
// 动画完成时不移除动画
basicAnim.removedOnCompletion = NO;
// 动画完成时保持最后的状态
/**
kCAFillModeRemoved 这个是默认值,也就是说当动画开始前和动画结束后,动画对layer都没有影响,动画结束后,layer会恢复到之前的状态
kCAFillModeForwards 当动画结束后,layer会一直保持着动画最后的状态
kCAFillModeBackwards 在动画开始前,只需要将动画加入了一个layer,layer便立即进入动画的初始状态并等待动画开始。
kCAFillModeBoth 这个其实就是上面两个的合成.动画加入后开始之前,layer便处于动画初始状态,动画结束后layer保持动画最后的状态
*/
basicAnim.fillMode = kCAFillModeForwards;
// 动画重复次数
basicAnim.repeatCount = MAXFLOAT;
// 自动返转(怎么去,怎么返回)
basicAnim.autoreverses = YES;

basicAnim.delegate = self;
// 延迟2S开始动画
basicAnim.beginTime = CACurrentMediaTime()+2;

[self.redView.layer addAnimation:basicAnim forKey:nil];

3、CAKeyframeAnimation——关键帧动画


关键帧动画,也是CAPropertyAnimation的子类,与CABasicAnimation的区别是:

CABasicAnimation只能从一个数值(fromValue)变到另一个数值(toValue),而

CAKeyframeAnimation会使用一个NSArray保存这些数值。

属性说明:values:上述的·NSArray·对象。里面的元素称为“关键帧”(keyframe)。动画对象会在指定的时间(duration)内,依次显示values数组中的每一个关键帧


path:可以设置一个CGPathRef、CGMutablePathRef,让图层按照路径轨迹移动。path只对CALayeranchorPointposition起作用。如果设置了path,那么values将被忽略

keyTimes:可以为对应的关键帧指定对应的时间点,其取值范围为0到1.0,keyTimes中的每一个时间值都对应values中的每一帧。如果没有设置keyTimes,各个关键帧的时间是平分的

CABasicAnimation可看做是只有2个关键帧的CAKeyframeAnimation
UIBezierPath *path = [UIBezierPath bezierPathWithArcCenter:self.iconImageView.center radius:100 startAngle:0 endAngle:M_PI clockwise:YES];

CAKeyframeAnimation *keyFrameAnima = [CAKeyframeAnimation animation];
keyFrameAnima.path = path.CGPath;

keyFrameAnima.keyPath = @"position";
keyFrameAnima.duration = 2;
keyFrameAnima.repeatCount = MAXFLOAT;
keyFrameAnima.autoreverses = YES;
[self.iconImageView.layer addAnimation:keyFrameAnima forKey:nil];

4、CAAnimationGroup——动画组

动画组,是CAAnimation的子类,可以保存一组动画对象,将CAAnimationGroup对象加入层后,组中所有动画对象可以同时并发运行

  • 属性说明:
    animations:用来保存一组动画对象的NSArray
    默认情况下,一组动画对象是同时运行的,也可以通过设置动画对象的beginTime属性来更改动画的开始时间
- (void)addAnimationGrounp {
// 创建一个基础动画
CABasicAnimation *basicAnima = [CABasicAnimation animation];
basicAnima.keyPath = @"transform.scale";
basicAnima.fromValue = @1.0;
basicAnima.toValue = @0;

// 创建一个帧动画
CAKeyframeAnimation *keyframeAnim = [CAKeyframeAnimation animation];
keyframeAnim.path = [UIBezierPath bezierPathWithArcCenter:CGPointMake(170, self.redView.center.y) radius:100 startAngle:M_PI endAngle:M_PI*2 clockwise:YES].CGPath;

keyframeAnim.keyPath = @"position";

// 动画组
CAAnimationGroup *animGroup = [CAAnimationGroup animation];
animGroup.animations = @[basicAnima,keyframeAnim];
animGroup.duration = 2.0;
animGroup.repeatCount = MAXFLOAT;
animGroup.autoreverses = YES;
[self.redView.layer addAnimation:animGroup forKey:nil];
}

5、CATransition——转场动画

CATransition是CAAnimation的子类,用于做转场动画,能够为层提供移出屏幕和移入屏幕的动画效果。UINavigationController就是通过CATransition`实现了将控制器的视图推入屏幕的动画效果

如果父视图中的两个子视图互相切换,转场动画应加给父视图!

动画属性:

  • type:动画过渡类型
  • subtype:动画过渡方向
  • startProgress:动画起点(在整体动画的百分比)
  • endProgress:动画终点(在整体动画的百分比)
CATransition *transiont = [CATransition animation];
/**
fade , //淡入淡出
push, //推挤
reveal, //揭开
moveIn, //覆盖
cube, //立方体
suckEffect, //吮吸
oglFlip, //翻转
rippleEffect, //波纹(水滴)
pageCurl, //翻页
pageUnCurl, //反翻页
cameraIrisHollowOpen, //开镜头
cameraIrisHollowClose, //关镜头
*/
transiont.type =@"pageCurl";
transiont.subtype = @"fromBottom";
transiont.duration = 0.5;

// 动画从哪个点开始
transiont.startProgress = 0;
// 动画到哪个点结束
transiont.endProgress = 0.5;


[self.imageView.layer addAnimation:transiont forKey:nil];

转场动画的过渡效果如下:


收起阅读 »

iOS--开发中遇到的der,csr,crt,p12,pem文件到底是什么

关于pem文件的话,上一篇文章已经有提到:iOS---利用OpenSSL演示RSA加密解密,PEM在工作中,pem文件,我们是不会直接使用的,需要从pem文件里面提取csr文件。csr文件步骤1:从private.pem文件里,提取rsacert.csr文件,...
继续阅读 »

关于pem文件的话,上一篇文章已经有提到:iOS---利用OpenSSL演示RSA加密解密,PEM

在工作中,pem文件,我们是不会直接使用的,需要从pem文件里面提取csr文件。

csr文件

步骤1:从private.pem文件里,提取rsacert.csr文件,终端命令“openssl req -new -key private.pem -out rsacert.csr”


这个步骤是不是似曾相识,这个步骤我们也可以在钥匙串里面,从证书颁发机构创建这个文件。

总结。csr文件,:是请求证书文件,是用于从证书颁发机构请求证书用的文件。
(趣味:麻省理工设计RSA算法的三位数学家成立了一个机构,收费帮别的组织签名赚钱,一般收费是5000一年)

crt文件

步骤2:利用命令“openssl x509 -req -days 3650 -in rsacert.csr -signkey private.pem -out rsacert.crt”自己签名。
-days 3650 代表有效期10年,(5万块到手)
-in rsacert.csr 传递一个文件
-signkey private.pem 代表用私钥private.pem文件进行签名。


总结。crt文件,是用于从证书颁发机构签过名的文件。https就需要这个文件,放在自己服务器上用于别人接收。是一个base64格式的。

der文件

步骤3:利用命令“openssl x509 -outform der -in rsacert.crt -out rsacert.der”生成一个rsacert.der文件

总结。der文件主要包括就是公钥和一些信息。

p12文件

步骤4:利用命令“openssl pkcs12 -export -out p.p12 -inkey private.pem -in rsacert.crt”生成一个p.p12文件
-in rsacert.crt 我们从rsacert.crt 生成了 der文件, 同时,也从rsacert.crt 里面生成p12文件。
pkcs12 原来,p12是pkcs12的缩写。

输入密码的时候,是不是想起来,导出p12文件的时候,有一个输入密码的操作。


总结。p12文件主要包括就是私钥和一些信息。

这便是我们经常接触到的,钥匙串帮我们做的事情,通过命令行演示,如果有问题,请指出来,及时修改。

转自:https://www.jianshu.com/p/83b67244458a

收起阅读 »

Swift高级分享 - 在Swift中提取视图控制器操作

视图控制器往往在为Apple平台构建的大多数应用程序中起着非常重要的作用。他们管理我们UI的关键方面,提供系统功能的桥梁,如设备方向和状态栏外观,并经常响应用户交互 - 如按钮点击和文本输入。由于它们通常具有这样的关键作用,因此许多视图控制器最终遭受常见的大规...
继续阅读 »

视图控制器往往在为Apple平台构建的大多数应用程序中起着非常重要的作用。他们管理我们UI的关键方面,提供系统功能的桥梁,如设备方向和状态栏外观,并经常响应用户交互 - 如按钮点击和文本输入。

由于它们通常具有这样的关键作用,因此许多视图控制器最终遭受常见的大规模视图控制器问题并不奇怪- 当它们最终承担太多责任时,导致大量交织在一起的逻辑,通常与视图混合在一起和布局代码。

虽然我们已经探索了多种减轻和分解大视图控制器的方法 - 例如使用合成,将导航代码移动到专用类型,重用数据源和使用逻辑控制器 - 本周,我们来看一下技术这让我们可以提取视图控制器的核心操作,而无需引入任何其他抽象或架构概念。

尴尬的意识

许多类型的架构和结构问题的一个非常常见的根本原因是某些类型只是意识到太多的域和细节。当给定类型的“意识领域”增长时,通常会履行其职责,并且 - 作为直接影响 - 它包含的代码量。

假设我们正在为消息传递应用程序构建一个作曲家视图,为了能够从用户的联系人中添加收件人并启用消息发送,我们目前允许我们的视图控制器直接访问我们的数据库和网络代码:

class MessageComposerViewController: UIViewController {
private var message: Message
private let userDatabase: UserDatabase
private let networking: Networking

init(recipients: [Recipient],
userDatabase: UserDatabase,
networking: Networking) {
self.message = Message(recipients: recipients)
self.userDatabase = userDatabase
self.networking = networking
super.init(nibName: nil, bundle: nil)
}
}

上面可能看起来不是什么大问题 - 我们使用依赖注入,并不像我们的视图控制器有大量依赖。然而,当我们的视图控制器还没有变成一个巨大的一个,只是还没有,它确实有它需要处理的动作相当多的数量-如添加收件人,取消和发送邮件-它目前正在对所有的它自己的:

private extension MessageComposerViewController {
func handleAddRecipientButtonTap() {
let picker = RecipientPicker(database: userDatabase)

picker.present(in: self) { [weak self] recipient in
self?.message.recipients.append(recipient)
self?.renderRecipientsView()
}
}

func handleCancelButtonTap() {
if message.text.isEmpty {
dismiss(animated: true)
} else {
dismissAfterAskingForConfirmation()
}
}

func handleSendButtonTap() {
let sender = MessageSender(networking: networking)

sender.send(message) { [weak self] error in
if let error = error {
self?.display(error)
} else {
self?.dismiss(animated: true)
}
}
}
}

让视图控制器执行自己的操作可能非常方便,对于更简单的视图控制器,它很可能不会导致任何问题 - 但正如我们只看到上面的摘录所看到的那样MessageComposerViewController,它通常需要我们的视图控制器知道他们理想情况下不应过于关注的事情 - 例如网络,创建逻辑对象,以及对父母如何呈现它们做出假设。

由于大多数视图控制器已经非常忙于创建和管理视图,设置布局约束以及检测用户交互等内容 - 让我们看看我们是否可以提取上述操作,并使我们的视图控制器更简单(并且不太清楚)处理。

操作

动作通常有两种不同的变体 - 同步和异步。某些操作只需要我们快速处理或转换给定值,并直接返回,而其他操作则需要更多时间来执行。

为了对这两种动作进行建模,让我们创建一个通用Action枚举 - 实际上并没有任何情况 - 但是包含两个类型别名,一个用于同步动作,一个用于异步动作:

enum Action<I, O> {
typealias Sync = (UIViewController, I) -> O
typealias Async = (UIViewController, I, @escaping (O) -> Void) -> Void
}

我们使用的原因,enum我们的Action包装上面,以防止它被实例化的类型,而不是只充当一个“抽象的命名空间”。

使用上面的类型别名,我们现在可以定义一个元组,其中包含我们MessageComposerViewController可以执行的所有操作- 如下所示:

private extension MessageComposerViewController {
func handleAddRecipientButtonTap() {
actions.addRecipient(self, message) { [weak self] newMessage in
self?.message = newMessage
self?.renderRecipientsView()
}
}

func handleCancelButtonTap() {
actions.cancel(self, message)
}

func handleSendButtonTap() {
let loadingVC = add(LoadingViewController())

actions.finish(self, message) { [weak self] error in
loadingVC.remove()
error.map { self?.display($0) }
}
}
}

值得注意的是,作为此重构的一部分,我们还改进了收件人添加到邮件的方式。我们不是让视图控制器本身执行其模型的变异,而是简单地返回一个新Message值作为其addRecipient动作的结果。

上述方法的优点在于我们的视图控制器现在可以专注于视图控制器最擅长的 - 控制视图 - 并让创建它的上下文处理网络和呈现等细节RecipientPicker。以下是我们现在可以在另一个视图控制器上呈现消息编写器的方法,例如在协调器或导航器中:

func presentMessageComposerViewController(
for recipients: [Recipient],
in presentingViewController: UIViewController
) {
let composer = MessageComposerViewController(
recipients: recipients,
actions: (
addRecipient: { [userDatabase] vc, message, handler in
let picker = RecipientPicker(database: userDatabase)

picker.present(in: vc) { recipient in
var message = message
message.recipients.append(recipient)
handler(message)
}
},
cancel: { vc, message in
if message.text.isEmpty {
vc.dismiss(animated: true)
} else {
vc.dismissAfterAskingForConfirmation()
}
},
finish: { [networking] vc, message, handler in
let sender = MessageSender(networking: networking)

sender.send(message) { error in
handler(error)

if error == nil {
vc.dismiss(animated: true)
}
}
}
)
)

presentingViewController.present(composer, animated: true)
}

太可爱了!由于我们所有的视图控制器的操作现在都只是函数,因此我们的代码变得更加灵活,更容易测试 - 因为我们可以轻松地模拟行为并验证在各种情况下调用正确的操作。

可操作的概述

从私有方法和专用集合中提取操作的另一大好处是,可以更容易地了解给定视图控制器执行的操作类型 - 例如ProductViewController,这具有四个同步的非常清晰的列表和异步操作:

extension ProductViewController {
typealias Actions = (
load: Action<Product.ID, Result<Product, Error>>.Async,
purchase: Action<Product.ID, Error?>.Async,
favorite: Action<Product.ID, Void>.Sync,
share: Action<Product, Void>.Sync
)
}

添加对新操作的支持通常也变得非常简单,因为我们不必为每个视图控制器注入新的依赖项并编写特定的实现,我们可以更轻松地利用共享逻辑并简单地向我们的Actions元组添加新成员- 然后在调用时调用它发生了相应的用户交互。

最后,操作可以实现类型自定义和更简单的重构等功能,而无需通常需要的“仪式”来解锁此类功能 - 例如,在使用协议时,或切换到新的,更严格的架构设计模式时。

例如,假设我们想要MessageComposerViewController从之前返回到我们,并添加对保存未完成消息草稿的支持。我们现在可以实现整个功能,甚至无需触及我们的实际视图控制器代码 - 我们所要做的就是更新其cancel操作:

let composer = MessageComposerViewController(
recipients: recipients,
actions: (
...
cancel: { [draftManager] vc, message in
if message.text.isEmpty {
vc.dismiss(animated: true)
} else {
vc.presentConfirmation(forReason: .saveDraft) {
outcome in
switch outcome {
case .accepted:
draftManager.saveDraft(message)
vc.dismiss(animated: true)
case .rejected:
vc.dismiss(animated: true)
case .cancelled:
break
}
}
}
},
...
)
)

结论


在处理复杂的视图控制器时,没有“银色子弹” - 特别是那些已经超出其原始意识和责任范围的控制器。像往常一样,拥有多种不同的技术 - 并在最合适的地方部署它们 - 通常是以高效和务实的方式创建真正强大的系统的关键。


虽然更复杂的技术(如使用逻辑控制器视图模型,或使用协议分离关注点)非常适合我们想要在整个代码库中进行更加结构化的,根本性的更改 - 提取操作可以大大有助于我们的视图控制器更简单,不需要任何重大改变或新的抽象。

链接:https://www.jianshu.com/p/558dfb843688
收起阅读 »

ES6 exports 与 import 使用

在创建JavaScript模块时,export 用于从模块中导出实时绑定的函数、对象或原始值,以便其他程序可以通过 import使用它们。被导出的绑定值依然可以在本地进行修改。在使用import 进行导入时,这些绑定值只能被导入模块所读取,...
继续阅读 »

在创建JavaScript模块时,export 用于从模块中导出实时绑定的函数、对象或原始值,以便其他程序可以通过 import使用它们。
被导出的绑定值依然可以在本地进行修改。
在使用import 进行导入时,这些绑定值只能被导入模块所读取,但在 export 导出模块中对这些绑定值进行修改,所修改的值也会实时地更新。

exports

ES6模块只支持静态导出,只可以在模块的最外层作用域使用export,不可在条件语句与函数作用域中使用。

Named exports (命名导出)

这种方式主要用于导出多个函数或者变量, 明确知道导出的变量名称。
使用:只需要在变量或函数前面加 export 关键字即可。
使用场景:比如 utils、tools、common 之类的工具类函数集,或者全站统一变量

  1. export 后面不可以是表达式,因为表达式只有值,没有名字。
  2. 每个模块包含任意数量的导出。
// lib.js
export const sqrt = Math.sqrt;
export function square(x) {
return x * x;
}
export function diag(x, y) {
return sqrt(square(x) + square(y));
}


// index.js 使用方式1
import { square, diag } from 'lib';
console.log(square(11)); // 121

// index.js 使用方式2
import * as lib from 'lib';
console.log(lib.square(11)); // 121

简写格式,统一列出需要输出的变量,例如上面的lib.js可以改写成

// lib.js
const sqrt = Math.sqrt;
function square(x) {
return x * x;
}
function add (x, y) {
return x + y;
}
export { sqrt, square, add };

Default exports (默认导出)

这种方式主要用于导出类文件或一个功能比较单一的函数文件;
使用:只需要在变量或函数前面加 export default 关键字即可。

  1. 每个模块最多只能有一个默认导出;
  2. 默认导出可以视为名字是default的模块输出变量;
  3. 默认导出后面可以是表达式,因为它只需要值。

导出一个值:

export default 123;

导出一个函数:

// myFunc.js
export default function () { ... };

// index.js
import myFunc from 'myFunc';
myFunc();

导出一个类:

// MyClass.js
class MyClass{
constructor() {}
}
export default MyClass;
// 或者
export { MyClass as default, … };

// index.js
import MyClass from 'MyClass';

export default 与 export 的区别:

  • 不需要知道导出的具体变量名;
  • 导入【import】时不需要 { } 包裹;

Combinations exports (混合导出)

混合导出是 Named exports 和 Default exports 组合导出。

混合导出后,默认导入一定放在命名导入前面;
// lib.js
export const myValue = '';
export const MY_CONST = '';
export function myFunc() {
...
}
export function* myGeneratorFunc() {
...
}
export default class MyClass {
...
}

// index.js
import MyClass, { myValue, myFunc } from 'lib';

Re-exporting (别名导出)

一般情况下,export 导出的变量名是原文件中的变量名,但也可以用 as 关键字来指定别名。这样做是为了简化或者语义化 export 的函数名。

同一个变量允许使用不同名字输出多次
// lib.js
function getName() {
...
};
function setName() {
...
};

export {
getName as get,
getName as getUserName,
setName as set
}

Module Redirects (中转模块导出)

为了方便使用模块导入,在一个父模块中“导入-导出”不同模块。简单来说:创建单个模块,集中多个模块的多个导出。
使用:使用 export from 语法实现;

export * from 'lib'; // 没有设置 export default
export * as myFunc2 from 'myFunc'; // 【ES2021】没有设置 export default
export { default as function1, function2 } from 'bar.js';

上述例子联合使用导入和导出:

import { default as function1, function2 } from 'bar.js';
export { function1, function2 };

尽管此时 export 与 import 等效,但以下语法在语法上无效:

import DefaultExport from 'bar.js'; // 有效的
export DefaultExport from 'bar.js'; // 无效的

正确的做法是重命名这个导出:

export { default as DefaultExport } from 'bar.js';

Importing

// Named imports
import { foo, bar as b } from './some-module.mjs';

// Namespace import
import * as someModule from './some-module.mjs';

// Default import
import someModule from './some-module.mjs';

// Combinations:
import someModule, * as someModule from './some-module.mjs';
import someModule, { foo, bar as b } from './some-module.mjs';

// Empty import (for modules with side effects)
import './some-module.mjs';


原文:https://segmentfault.com/a/1190000039957496

收起阅读 »

开源一个自用的Android IM库,基于Netty+TCP+Protobuf实现(4)

调试 我们先来看看连接及重连部分(由于录制gif比较麻烦,体积较大,所以我先把重连间隔调小成3秒,方便看效果)。 启动服务端: 启动客户端: 可以看到,正常的情况下已经连接成功了,接下来,我们来试一下异常情况,比如服务端没启动,看看客户端的重连情况: 这...
继续阅读 »

调试


我们先来看看连接及重连部分(由于录制gif比较麻烦,体积较大,所以我先把重连间隔调小成3秒,方便看效果)。



  • 启动服务端:启动服务端

  • 启动客户端:启动客户端


可以看到,正常的情况下已经连接成功了,接下来,我们来试一下异常情况,比如服务端没启动,看看客户端的重连情况:
调试重连
这次我们先启动的是客户端,可以看到连接失败后一直在进行重连,由于录制gif比较麻烦,在第三次连接失败后,我启动了服务端,这个时候客户端就会重连成功。


然后,我们再来调试一下握手认证消息即心跳消息:
握手消息及心跳消息测试
可以看到,长连接建立成功后,客户端会给服务端发送一条握手认证消息(1001),服务端收到握手认证消息会,给客户端返回了一条握手认证状态消息,客户端收到握手认证状态消息后,即启动心跳机制。gif不太好演示,下载demo就可以直观地看到。


接下来,在讲完消息重发机制及离线消息后,我会在应用层做一些简单的封装,以及在模拟器上运行,这样就可以很直观地看到运行效果。




消息重发机制


消息重发,顾名思义,即使对发送失败的消息进行重发。考虑到网络环境的不稳定性、多变性(比如从进入电梯、进入地铁、移动网络切换到wifi等),在消息发送的时候,发送失败的概率其实不小,这时消息重发机制就很有必要了。

我们先来看看实现的代码逻辑。
MsgTimeoutTimer:
MsgTimeoutTimer1
MsgTimeoutTimer2
MsgTimeoutTimerManager:
MsgTimeoutTimerManager1
MsgTimeoutTimerManager2

然后,我们看看收消息的TCPReadHandler的改造:
加入消息重发机制的TCPReadHandler
最后,看看发送消息的改造:
加入消息重发机制的发送消息


说一下逻辑吧:发送消息时,除了心跳消息、握手消息、状态报告消息外,消息都加入消息发送超时管理器,立马开启一个定时器,比如每隔5秒执行一次,共执行3次,在这个周期内,如果消息没有发送成功,会进行3次重发,达到3次重发后如果还是没有发送成功,那就放弃重发,移除该消息,同时通过消息转发器通知应用层,由应用层决定是否再次重发。如果消息发送成功,服务端会返回一个消息发送状态报告,客户端收到该状态报告后,从消息发送超时管理器移除该消息,同时停止该消息对应的定时器即可。

另外,在用户握手认证成功时,应该检查消息发送超时管理器里是否有发送超时的消息,如果有,则全部重发:
握手认证成功检查是否有发送超时的消息




离线消息


由于离线消息机制,需要服务端数据库及缓存上的配合,代码就不贴了,太多太多,我简单说一下实现思路吧:
客户端A发送消息到客户端B,消息会先到服务端,由服务端进行中转。这个时候,客户端B存在两种情况:



  • 1.长连接正常,就是客户端网络环境良好,手机有电,应用处在打开的情况。

  • 2.废话,那肯定就是长连接不正常咯。这种情况有很多种原因,比如wifi不可用、用户进入了地铁或电梯等网络不好的场所、应用没打开或已退出登录等,总的来说,就是没有办法正常接收消息。


如果是长连接正常,那没什么可说的,服务端直接转发即可。

如果长连接不正常,需要这样处理:服务端接收到客户端A发送给客户端B的消息后,先给客户端A回复一条状态报告,告诉客户端A,我已经收到消息,这个时候,客户端A就不用管了,消息只要到达服务端即可。然后,服务端先尝试把消息转发到客户端B,如果这个时候客户端B收到服务端转发过来的消息,需要立马给服务端回一条状态报告,告诉服务端,我已经收到消息,服务端在收到客户端B返回的消息接收状态报告后,即认为此消息已经正常发送,不需要再存库。如果客户端B不在线,服务端在做转发的时候,并没有收到客户端B返回的消息接收状态报告,那么,这条消息就应该存到数据库,直到客户端B上线后,也就是长连接建立成功后,客户端B主动向服务端发送一条离线消息询问,服务端在收到离线消息询问后,到数据库或缓存去查客户端B的所有离线消息,并分批次返回,客户端B在收到服务端的离线消息返回后,取出消息id(若有多条就取id集合),通过离线消息应答把消息id返回到服务端,服务端收到后,根据消息id从数据库把对应的消息删除即可。

以上是单聊离线消息处理的情况,群聊有点不同,群聊的话,是需要服务端确认群组内所有用户都收到此消息后,才能从数据库删除消息,就说这么多,如果需要细节的话,可以私信我。




不知不觉,NettyTcpClient中定义了很多变量,为了防止大家不明白变量的定义,还是贴上代码吧:
定义了很多变量的NettyTcpClient


应用层封装


这个就见仁见智啦,每个人代码风格不同,我把自己简单封装的代码贴上来吧:

MessageProcessor消息处理器:
MessageProcessor1
MessageProcessor2
IMSEventListener与ims交互的listener:
IMSEventListener1
IMSEventListener2
IMSEventListener3
MessageBuilder消息转换器:
MessageBuilder1
MessageBuilder2
MessageBuilder3
AbstractMessageHandler抽象的消息处理handler,每个消息类型对应不同的messageHandler:
AbstractMessageHandler
SingleChatMessageHandler单聊消息处理handler:
SingleChatMessageHandler
GroupChatMessageHandler群聊消息处理handler:
GroupChatMessageHandler
MessageHandlerFactory消息handler工厂:
MessageHandlerFactory
MessageType消息类型枚举:
MessageType
IMSConnectStatusListenerIMS连接状态监听器:
IMSConnectStatusListener
由于每个人代码风格不同,封装代码都有自己的思路,所以,在此就不过多讲解,只是把自己简单封装的代码全部贴上来,作一个参考即可。只需要知道,接收到消息时,会回调OnEventListener的dispatchMsg(MessageProtobuf.Msg msg)方法:
应用层接收ims消息入口
发送消息需要调用imsClient的sendMsg(MessageProtobuf.Msg msg)方法:
应用层调用ims发送消息入口
即可,至于怎样去封装得更好,大家自由发挥吧。




最后,为了测试消息收发是否正常,我们需要改动一下服务端:
改动后的服务端1
改动后的服务端2
改动后的服务端3
改动后的服务端4
改动后的服务端5
可以看到,当有用户握手成功后,会保存该用户对应的channel到容器里,给用户发送消息时,根据用户id从容器里取出对应的channel,利用该channel发送消息。当用户断开连接后,会把该用户对应的channel从容器里移除掉。


运行一下,看看效果吧:
最终运行效果



  • 首先,启动服务端。

  • 然后,修改客户端连接的ip地址为192.168.0.105(这是我本机的ip地址),端口号为8855,fromId,也就是userId,定义成100001,toId为100002,启动客户端A。

  • 再然后,fromId,也就是userId,定义成100002,toId为100001,启动客户端B。

  • 客户端A给客户端B发送消息,可以看到在客户端B的下面,已经接收到了消息。

  • 用客户端B给客户端A发送消息,也可以看到在客户端A的下面,也已经接收到了消息。


至于,消息收发测试成功。至于群聊或重连等功能,就不一一演示了,还是那句话,下载demo体验一下吧。。。


由于gif录制体积较大,所以只能简单演示一下消息收发,具体下载demo体验吧。。。


如果有需要应用层UI实现(就是聊天页及会话页的封装)的话,我再分享出来吧。



作者:FreddyChen
链接:https://juejin.cn/post/6844903815846559757
来源:掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
收起阅读 »

开源一个自用的Android IM库,基于Netty+TCP+Protobuf实现(3)

TCP的拆包与粘包 什么是TCP拆包?为什么会出现TCP拆包? 简单地说,我们都知道TCP是以“流”的形式进行数据传输的,而且TCP为提高性能,发送端会将需要发送的数据刷入缓冲区,等待缓冲区满了之后,再将缓冲区中的数据发送给接收方,同理,接收方也会有缓冲区...
继续阅读 »

TCP的拆包与粘包




  • 什么是TCP拆包?为什么会出现TCP拆包?


    简单地说,我们都知道TCP是以“流”的形式进行数据传输的,而且TCP为提高性能,发送端会将需要发送的数据刷入缓冲区,等待缓冲区满了之后,再将缓冲区中的数据发送给接收方,同理,接收方也会有缓冲区这样的机制,来接收数据。

    拆包就是在socket读取时,没有完整地读取一个数据包,只读取一部分。




  • 什么是TCP粘包?为什么会出现TCP粘包?


    同上。

    粘包就是在socket读取时,读到了实际意义上的两个或多个数据包的内容,同时将其作为一个数据包进行处理。




引用网上一张图片来解释一下在TCP出现拆包、粘包以及正常状态下的三种情况,如侵请联系我删除:
TCP拆包、粘包、正常状态
了解了TCP出现拆包/粘包的原因,那么,如何解决呢?通常来说,有以下四种解决方式:



  • 消息定长

  • 用回车换行符作为消息结束标志

  • 用特殊分隔符作为消息结束标志,如\t、\n等,回车换行符其实就是特殊分隔符的一种。

  • 将消息分为消息头和消息体,在消息头中用字段标识消息总长度。


netty针对以上四种场景,给我们封装了以下四种对应的解码器:



  • FixedLengthFrameDecoder,定长消息解码器

  • LineBasedFrameDecoder,回车换行符消息解码器

  • DelimiterBasedFrameDecoder,特殊分隔符消息解码器

  • LengthFieldBasedFrameDecoder,自定义长度消息解码器。


我们用到的就是LengthFieldBasedFrameDecoder自定义长度消息解码器,同时配合LengthFieldPrepender编码器使用,关于参数配置,建议参考netty--最通用TCP黏包解决方案:LengthFieldBasedFrameDecoder和LengthFieldPrepender这篇文章,讲解得比较细致。我们配置的是消息头长度为2个字节,所以消息包的最大长度需要小于65536个字节,netty会把消息内容长度存放消息头的字段里,接收方可以根据消息头的字段拿到此条消息总长度,当然,netty提供的LengthFieldBasedFrameDecoder已经封装好了处理逻辑,我们只需要配置lengthFieldOffset、lengthFieldLength、lengthAdjustment、initialBytesToStrip即可,这样就可以解决TCP的拆包与粘包,这也就是netty相较于原生nio的便捷性,原生nio需要自己处理拆包/粘包等问题。




长连接握手认证


接着,我们来看看LoginAuthHandlerHeartbeatRespHandler



  • LoginAuthRespHandler是当客户端与服务端长连接建立成功后,客户端主动向服务端发送一条登录认证消息,带入与当前用户相关的参数,比如token,服务端收到此消息后,到数据库查询该用户信息,如果是合法有效的用户,则返回一条登录成功消息给该客户端,反之,返回一条登录失败消息给该客户端,这里,就是在接收到服务端返回的登录状态后的处理handler,比如:LoginAuthRespHandler


可以看到,当接收到服务端握手消息响应后,会从扩展字段取出status,如果status=1,则代表握手成功,这个时候就先主动向服务端发送一条心跳消息,然后利用Netty的IdleStateHandler读写超时机制,定期向服务端发送心跳消息,维持长连接,以及检测长连接是否还存在等。



  • HeartbeatRespHandler是当客户端接收到服务端登录成功的消息后,主动向服务端发送一条心跳消息,心跳消息可以是一个空包,消息包体越小越好,服务端收到客户端的心跳包后,原样返回给客户端,这里,就是收到服务端返回的心跳消息响应的处理handler,比如:HeartbeatRespHandler


这个就比较简单,收到心跳消息响应,无需任务处理,直接打印一下方便我们分析即可。




心跳机制及读写超时机制


心跳包是定期发送,也可以自己定义一个周期,比如Android微信智能心跳方案,为了简单,此处规定应用在前台时,8秒发送一个心跳包,切换到后台时,30秒发送一次,根据自己的实际情况修改一下即可。心跳包用于维持长连接以及检测长连接是否断开等。


接着,我们利用Netty的读写超时机制,来实现一个心跳消息管理handler:
HeartbeatHandler
可以看到,利用userEventTriggered()方法回调,通过IdleState类型,可以判断读超时/写超时/读写超时,这个在添加IdleStateHandler时可以配置,下面会贴上代码。首先我们可以在READER_IDLE事件里,检测是否在规定时间内没有收到服务端心跳包响应,如果是,那就触发重连操作。在WRITER_IDEL事件可以检测客户端是否在规定时间内没有向服务端发送心跳包,如果是,那就主动发送一个心跳包。发送心跳包是在子线程中执行,我们可以利用之前写的work线程池进行线程管理。

addHeartbeatHandler()代码如下:
addHeartbeatHandler
从图上可看到,在IdleStateHandler里,配置的读超时为心跳间隔时长的3倍,也就是3次心跳没有响应时,则认为长连接已断开,触发重连操作。写超时则为心跳间隔时长,意味着每隔heartbeatInterval会发送一个心跳包。读写超时没用到,所以配置为0。


onConnectStatusCallback(int connectStatus)为连接状态回调,以及一些公共逻辑处理:
onConnectStatusCallback
连接成功后,立即发送一条握手消息,再次梳理一下整体流程:



  • 客户端根据服务端返回的host及port,进行第一次连接。

  • 连接成功后,客户端向服务端发送一条握手认证消息(1001)

  • 服务端在收到客户端的握手认证消息后,从扩展字段里取出用户token,到本地数据库校验合法性。

  • 校验完成后,服务端把校验结果通过1001消息返回给客户端,也就是握手消息响应。

  • 客户端收到服务端的握手消息响应后,从扩展字段取出校验结果。若校验成功,客户端向服务端发送一条心跳消息(1002),然后进入心跳发送周期,定期间隔向服务端发送心跳消息,维持长连接以及实时检测链路可用性,若发现链路不可用,等待一段时间触发重连操作,重连成功后,重新开始握手/心跳的逻辑。


看看TCPReadHandler收到消息是怎么处理的:
TCPReadHandler1
TCPReadHandler2
可以看到,在channelInactive()及exceptionCaught()方法都触发了重连,channelInactive()方法在当链路断开时会调用,exceptionCaught()方法在当出现异常时会触发,另外,还有诸如channelUnregistered()、channelReadComplete()等方法可以重写,在这里就不贴了,相信聪明的你一眼就能看出方法的作用。

我们仔细看一下channelRead()方法的逻辑,在if判断里,先判断消息类型,如果是服务端返回的消息发送状态报告类型,则判断消息是否发送成功,如果发送成功,从超时管理器中移除,这个超时管理器是干嘛的呢?下面讲到消息重发机制的时候会详细地讲。在else里,收到其他消息后,会立马给服务端返回一个消息接收状态报告,告诉服务端,这条消息我已经收到了,这个动作,对于后续需要做的离线消息会有作用。如果不需要支持离线消息功能,这一步可以省略。最后,调用消息转发器,把接收到的消息转发到应用层即可。


代码写了这么多,我们先来看看运行后的效果,先贴上缺失的消息发送代码及ims关闭代码以及一些默认配置项的代码。

发送消息:发送消息
关闭ims:关闭ims
ims默认配置:ims默认配置
还有,应用层实现的ims client启动器:
IMSClientBootstrap
由于代码有点多,不太方便全部贴上,如果有兴趣可以下载demo体验。
额,对了,还有一个简易的服务端代码,如下:
NettyServerDemo1
NettyServerDemo2
NettyServerDemo3





作者:FreddyChen
链接:https://juejin.cn/post/6844903815846559757
来源:掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
收起阅读 »

开源一个自用的Android IM库,基于Netty+TCP+Protobuf实现(2)

封装 为什么需要封装呢?说白了,就是为了解耦,为了方便日后切换到不同框架实现,而无需到处修改调用的地方。举个栗子,比如Android早期比较流行的图片加载框架是Universal ImageLoader,后期因为某些原因,原作者停止了维护该项目,目前比较流行的...
继续阅读 »

封装


为什么需要封装呢?说白了,就是为了解耦,为了方便日后切换到不同框架实现,而无需到处修改调用的地方。举个栗子,比如Android早期比较流行的图片加载框架是Universal ImageLoader,后期因为某些原因,原作者停止了维护该项目,目前比较流行的图片加载框架是Picasso或Glide,因为图片加载功能可能调用的地方非常多,如果不作一些封装,早期使用了Universal ImageLoader的话,现在需要切换到Glide,那改动量将非常非常大,而且还很有可能会有遗漏,风险度非常高。


那么,有什么解决方案呢?


很简单,我们可以用工厂设计模式进行一些封装,工厂模式有三种:简单工厂模式、抽象工厂模式、工厂方法模式。在这里,我采用工厂方法模式进行封装,具体区别,可以参见:通俗讲讲我对简单工厂、工厂方法、抽象工厂三种设计模式的理解


我们分析一下,ims(IM Service,下文简称ims)应该是有初始化建立连接重连关闭连接释放资源判断长连接是否关闭发送消息等功能,基于上述分析,我们可以进行一个接口抽象:
抽象的ims接口1
抽象的ims接口2
OnEventListener是与应用层交互的listener:
OnEventListener
IMConnectStatusCallback是ims连接状态回调监听器:
IMConnectStatusCallback


然后写一个Netty tcp实现类:
Netty tcp ims1
Netty tcp ims2


接下来,写一个工厂方法:
ims实例工厂方法


封装部分到此结束,接下来,就是实现了。




初始化


我们先实现init(Vector serverUrlList, OnEventListener listener, IMSConnectStatusCallback callback)方法,初始化一些参数,以及进行第一次连接等:
初始化参数


其中,MsgDispatcher是消息转发器,负责将接收到的消息转发到应用层:
MsgDispatcher


ExecutorServiceFactory是线程池工厂,负责调度重连及心跳线程:
ExecutorServiceFactory1
ExecutorServiceFactory2
ExecutorServiceFactory3




连接及重连


resetConnect()方法作为连接的起点,首次连接以及重连逻辑,都是在resetConnect()方法进行逻辑处理,我们来瞄一眼:
resetConnect
可以看到,非首次进行连接,也就是连接一个周期失败后,进行重连时,会先让线程休眠一段时间,因为这个时候也许网络状况不太好,接着,判断ims是否已关闭或者是否正在进行重连操作,由于重连操作是在子线程执行,为了避免重复重连,需要进行一些并发处理。开始重连任务后,分四个步骤执行:



  • 改变重连状态标识

  • 回调连接状态到应用层

  • 关闭之前打开的连接channel

  • 利用线程池执行一个新的重连任务


ResetConnectRunnable是重连任务,核心的重连逻辑都放到这里执行:
ResetConnectRunnable1
ResetConnectRunnable2
ResetConnectRunnable3


toServer()是真正连接服务器的地方:
toServer


initBootstrap()是初始化Netty Bootstrap:
initBootstrap
注:NioEventLoopGroup线程数设置为4,可以满足QPS是一百多万的情况了,至于应用如果需要承受上千万上亿流量的,需要另外调整线程数。参考自:netty实战之百万级流量NioEventLoopGroup线程数配置


接着,我们来看看TCPChannelInitializerHanlder
TCPChannelInitializerHandler
其中,ProtobufEncoderProtobufDecoder是添加对protobuf的支持,LoginAuthRespHandler是接收到服务端握手认证消息响应的处理handler,HeartbeatRespHandler是接收到服务端心跳消息响应的处理handler,TCPReadHandler是接收到服务端其它消息后的处理handler,先不去管,我们重点来分析下LengthFieldPrependerLengthFieldBasedFrameDecoder,这就需要引申到TCP的拆包与粘包啦。


作者:FreddyChen
链接:https://juejin.cn/post/6844903815846559757
来源:掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
收起阅读 »

开源一个自用的Android IM库,基于Netty+TCP+Protobuf实现(1)

写在前面 一直想写一篇关于im即时通讯分享的文章,无奈工作太忙,很难抽出时间。今天终于从公司离职了,打算好好休息几天再重新找工作,趁时间空闲,决定静下心来写一篇文章,毕竟从前辈那里学到了很多东西。工作了五年半,这三四年来一直在做社交相关的项目,有 直播、 即时...
继续阅读 »

写在前面


一直想写一篇关于im即时通讯分享的文章,无奈工作太忙,很难抽出时间。今天终于从公司离职了,打算好好休息几天再重新找工作,趁时间空闲,决定静下心来写一篇文章,毕竟从前辈那里学到了很多东西。工作了五年半,这三四年来一直在做社交相关的项目,有
直播
即时通讯
短视频分享
社区论坛
等产品,深知即时通讯技术在一个项目中的重要性,本着开源分享的精神,也趁这机会总结一下,所以写下这篇文章,文中有不对之处欢迎批评与指正。


本文将介绍:



  • Protobuf序列化

  • TCP拆包与粘包

  • 长连接握手认证

  • 心跳机制

  • 重连机制

  • 消息重发机制

  • 读写超时机制

  • 离线消息

  • 线程池

  • AIDL跨进程通信


本想花一部分时间介绍一下利用AIDL实现多进程通信,提升应用保活率,无奈这种方法在目前大部分Android新版本上已失效,而且也比较复杂,所以考虑再三,把AIDL这一部分去掉,需要了解的童鞋可以私信我。


先来看看效果:
最终运行效果


不想看文章的同学可以直接移步到Github fork源码:github地址


接下来,让我们进入正题。




为什么使用TCP?


这里需要简单解释一下,TCP/UDP/WebSocket的区别。
这里就很好地解释了TCP/UDP的优缺点和区别,以及适用场景,简单地总结一下:




  • 优点:



    • TCP的优点体现在稳定可靠上,在传输数据之前,会有三次握手来建立连接,而且在数据传递时,有确认、窗口、重传、拥塞控制机制,在数据传完之后,还会断开连接用来节约系统资源。

    • UDP的优点体现在比TCP稍安全,UDP没有TCP拥有的各种机制,是一个无状态的传输协议,所以传递数据非常快,没有TCP的这些机制,被攻击利用的机制就少一些,但是也无法避免被攻击。




  • 缺点:



    • TCP缺点就是效率低占用系统资源高易被攻击,TCP在传递数据之前要先建立连接,这会消耗时间,而且在数据传递时,确认机制、重传机制、拥塞机制等都会消耗大量时间,而且要在每台设备上维护所有的传输连接。

    • UDP缺点就是不可靠不稳定,因为没有TCP的那些机制,UDP在传输数据时,如果网络质量不好,就会很容易丢包,造成数据的缺失。




  • 适用场景:



    • TCP:当对网络通讯质量有要求时,比如HTTP、HTTPS、FTP等传输文件的协议, POP、SMTP等邮件传输的协议。

    • UDP:对网络通讯质量要求不高时,要求网络通讯速度要快的场景。




至于WebSocket,后续可能会专门写一篇文章来介绍。
综上所述,决定采用TCP协议。




为什么使用Protobuf?


对于App网络传输协议,我们比较常见的、可选的,有三种,分别是json/xml/protobuf,老规矩,我们先分别来看看这三种格式的优缺点:




  • 优点:



    • json优点就是较XML格式更加小巧,传输效率较xml提高了很多,可读性还不错。

    • xml优点就是可读性强,解析方便。

    • protobuf优点就是传输效率快(据说在数据量大的时候,传输效率比xml和json快10-20倍),序列化后体积相比Json和XML很小,支持跨平台多语言,消息格式升级和兼容性还不错,序列化反序列化速度很快。




  • 缺点:



    • json缺点就是传输效率也不是特别高(比xml快,但比protobuf要慢很多)。

    • xml缺点就是效率不高,资源消耗过大。

    • protobuf缺点就是使用不太方便。




在一个需要大量的数据传输的场景中,如果数据量很大,那么选择protobuf可以明显的减少数据量,减少网络IO,从而减少网络传输所消耗的时间。考虑到作为一个主打社交的产品,消息数据量会非常大,同时为了节约流量,所以采用protobuf是一个不错的选择。




为什么使用Netty?


首先,我们来了解一下,Netty到底是个什么东西。网络上找到的介绍:Netty是由JBOSS提供的基于Java NIO的开源框架,Netty提供异步非阻塞、事件驱动、高性能、高可靠、高可定制性的网络应用程序和工具,可用于开发服务端和客户端。




  • 为什么不用Java BIO?



    • 一连接一线程,由于线程数是有限的,所以这样非常消耗资源,最终也导致它不能承受高并发连接的需求。

    • 性能低,因为频繁的进行上下文切换,导致CUP利用率低。

    • 可靠性差,由于所有的IO操作都是同步的,即使是业务线程也如此,所以业务线程的IO操作也有可能被阻塞,这将导致系统过分依赖网络的实时情况和外部组件的处理能力,可靠性大大降低。




  • 为什么不用Java NIO?



    • NIO的类库和API相当复杂,使用它来开发,需要非常熟练地掌握Selector、ByteBuffer、ServerSocketChannel、SocketChannel等。

    • 需要很多额外的编程技能来辅助使用NIO,例如,因为NIO涉及了Reactor线程模型,所以必须必须对多线程和网络编程非常熟悉才能写出高质量的NIO程序。

    • 想要有高可靠性,工作量和难度都非常的大,因为服务端需要面临客户端频繁的接入和断开、网络闪断、半包读写、失败缓存、网络阻塞的问题,这些将严重影响我们的可靠性,而使用原生NIO解决它们的难度相当大。

    • JDK NIO中著名的BUG--epoll空轮询,当select返回0时,会导致Selector空轮询而导致CUP100%,官方表示JDK1.6之后修复了这个问题,其实只是发生的概率降低了,没有根本上解决。




  • 为什么用Netty?



    • API使用简单,更容易上手,开发门槛低

    • 功能强大,预置了多种编解码功能,支持多种主流协议

    • 定制能力高,可以通过ChannelHandler对通信框架进行灵活地拓展

    • 高性能,与目前多种NIO主流框架相比,Netty综合性能最高

    • 高稳定性,解决了JDK NIO的BUG

    • 经历了大规模的商业应用考验,质量和可靠性都有很好的验证。




以上摘自:为什么要用Netty开发



  • 为什么不用第三方SDK,如:融云、环信、腾讯TIM?


这个就见仁见智了,有的时候,是因为公司的技术选型问题,因为用第三方的SDK,意味着消息数据需要存储到第三方的服务器上,再者,可扩展性、灵活性肯定没有自己开发的要好,还有一个小问题,就是收费。比如,融云免费版只支持100个注册用户,超过100就要收费,群聊支持人数有限制等等...
融云收费


Mina其实跟Netty很像,大部分API都相同,因为是同一个作者开发的。但感觉Mina没有Netty成熟,在使用Netty的过程中,出了问题很轻易地可以找到解决方案,所以,Netty是一个不错的选择。


好了,废话不多说,直接开始吧。




准备工作



  • 首先,我们新建一个Project,在Project里面再新建一个Android Library,Module名称暂且叫做im_lib,如图所示:


新建项目




  • 然后,分析一下我们的消息结构,每条消息应该会有一个消息唯一id,发送者id,接收者id,消息类型,发送时间等,经过分析,整理出一个通用的消息类型,如下:



    • msgId 消息id

    • fromId 发送者id

    • toId 接收者id

    • msgType 消息类型

    • msgContentType 消息内容类型

    • timestamp 消息时间戳

    • statusReport 状态报告

    • extend 扩展字段


    根据上述所示,我整理了一个思维导图,方便大家参考:
    消息结构

    这是基础部分,当然,大家也可以根据自己需要自定义比较适合自己的消息结构。


    我们根据自定义的消息类型来编写proto文件。
    编写proto文件
    然后执行命令(我用的mac,windows命令应该也差不多):
    执行protoc命令
    然后就会看到,在和proto文件同级目录下,会生成一个java类,这个就是我们需要用到的东东:
    生成的protobuf java类文件
    我们打开瞄一眼:
    打开的protobuf java类文件
    东西比较多,不用去管,这是google为我们生成的protobuf类,直接用就行,怎么用呢?直接用这个类文件,拷到我们开始指定的项目包路径下就可以啦:
    导入protobuf java类文件到项目中
    添加依赖后,可以看到,MessageProtobuf类文件已经没有报错了,顺便把netty的jar包也导进来一下,还有fastjson的:
    导入protobuf以及netty的依赖
    建议用netty-all-x.x.xx.Final的jar包,后续熟悉了,可以用精简的jar包。


    至此,准备工作已结束,下面,我们来编写java代码,实现即时通讯的功能。


作者:FreddyChen
链接:https://juejin.cn/post/6844903815846559757
来源:掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
收起阅读 »

一个小型合作的流水线——Android Handler

当我们遇到多线程的问题,考虑到线程间消息传递的时候,首先想到的肯定是 Handler。虽然写这篇文章的初衷并不是想探究 Handler 的机制,但我们还是先从这个被说烂了的话题开始。 Handler 的工作原理 首先,在了解 Handler 之前,我们需要了解...
继续阅读 »

当我们遇到多线程的问题,考虑到线程间消息传递的时候,首先想到的肯定是 Handler。虽然写这篇文章的初衷并不是想探究 Handler 的机制,但我们还是先从这个被说烂了的话题开始。


Handler 的工作原理


首先,在了解 Handler 之前,我们需要了解有四个关键的类是组成 Handler 的基础。它们分别是



  • Handler 负责协调安排未来某个时间点的消息或可运行状态,以及对不同线程的运行机制进行合理的排队

  • Looper 主要作用如其名,一个循环的机制,为线程运行消息循环分发

  • MessageQueue 一个链式队列数据结构,将消息实体串联成链

  • Message 消息实体,存储我们需要传递的消息的内容和信息等


Looper 和 MessageQueue——Handler 的流水线


ActivityThread 类中,作为入口方法的 main() 方法中,通过调用 Looperloop() 方法,启动 Looper 的循环机制(这里我们注意到,在方法的最后,抛出了一个主线程循环意外退出的异常,说明 Android 的主流程都是通过 Handler 来驱动的)。


/**
* ActivityThread
*/
public static void main(String[] args) {

// ...
Looper.prepareMainLooper();
// ...
Looper.loop();

throw new RuntimeException("Main thread loop unexpectedly exited");
}
复制代码

进入 loop() 方法,这里我们可以看到一个死循环,传说中的死循环这么快就跟我们见面了吗?其实不然,我们平时面试时更关注的死循环并不是这个,或者说它只是其中的一部分。废话先不说,这段代码精简后的大致作用可以归纳为:从 MessageQueue 的对象队列里取出一个未处理的消息,即 Message 实例,然后获取 Message 对象的 target 属性,它是一个 Handler 对象,然后通过 dispatchMessage() 方法来将消息进行分发。


/**
* Looper
*/
public static void loop() {
final MessageQueue queue = me.mQueue;

// Make sure the identity of this thread is that of the local process,
// and keep track of what that identity token actually is.
// 我最开始读到这段源码的时候,很困惑这个方法为什么调用了两遍,后来经过思索想明白了原因,这里稍作记录。
// 这个方法调用的是 native 的代码,源码如下:
// int64_t IPCThreadState::clearCallingIdentity()
// {
// int64_t token = ((int64_t)mCallingUid<<32) | mCallingPid;
// clearCaller();
// return token;
// }
// void IPCThreadState::clearCaller()
// {
// mCallingPid = getpid(); //当前进程pid赋值给mCallingPid
// mCallingUid = getuid(); //当前进程uid赋值给mCallingUid
// }
// 具体作用可以网上自行搜索,这个方法的作用,简而言之,就是将(可能是)其他进程的 pid 和 uid 清除,更换为自己的,
// 而 token 是用来存储原来进程的 pid 和 uid 的64位整型,所以第一遍调用时返回的是之前进程的 pid 和 uid 信息,
// 再次调用时,返回的才是当前进程的,而被我精简掉的源码里需要通过这个 token 来判断进程是否切换过,所以这个方法在这里会调用两遍
Binder.clearCallingIdentity();
final long ident = Binder.clearCallingIdentity();

for (;;) {
Message msg = queue.next(); // might block
if (msg == null) {
// No message indicates that the message queue is quitting.
return;
}
try {
msg.target.dispatchMessage(msg);

} catch (Exception exception) {
throw exception;
}

msg.recycleUnchecked();
}
}
复制代码

因为 dispatchMessage() 方法比较简单,所以我们先越过过程看结果,看看这个方法的实现。


/**
* Handler
*/
public void dispatchMessage(@NonNull Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}
复制代码

这里就直接调用了 Handler 对象的 handleMessage() 方法,并传递 Message 的实例,所以我们在使用 Handler 时在这个方法中就可以接收到我们需要的消息实体(callback 默认不实现,实现后变更为调用相应的方法)。


好,结果我们已经知道了,那现在我们回过头来,研究一下上面 Looper 类的 loop() 方法中调用的 queue.next() 方法是如何拿到消息实体的(后面的注释已经提醒我们这个方法可能会阻塞)。


/**
* MessageQueue
*/
Message next() {
// Return here if the message loop has already quit and been disposed.
// This can happen if the application tries to restart a looper after quit
// which is not supported.
final long ptr = mPtr;
if (ptr == 0) {
return null;
}

int pendingIdleHandlerCount = -1; // -1 only during first iteration
// 这个变量作为 nativePollOnce 方法的参数表示休眠的时间
// 当值为 -1 时,表示无限休眠,直到有线程唤醒
// 当值为 0 时,表示立即唤醒
int nextPollTimeoutMillis = 0;
for (;;) {
if (nextPollTimeoutMillis != 0) {
Binder.flushPendingCommands();
}

// 根据 nextPollTimeoutMillis 变量的值进行休眠
nativePollOnce(ptr, nextPollTimeoutMillis);

synchronized (this) {
// Try to retrieve the next message. Return if found.
final long now = SystemClock.uptimeMillis();
Message prevMsg = null;
Message msg = mMessages;
// 如果 Message 的 target 为 null,则说明它是 Looper synchronization barrier 的临界点
if (msg != null && msg.target == null) {
// Stalled by a barrier. Find the next asynchronous message in the queue.
do {
prevMsg = msg;
msg = msg.next;and the message is the earliest asynchronous message in the queue
} while (msg != null && !msg.isAsynchronous());
}
// 经过上面的循环后,到达这里的 Message 要么是 null,要么是 isAsynchronous() 方法返回 true
if (msg != null) {
if (now < msg.when) {
// Next message is not ready. Set a timeout to wake up when it is ready.
// 消息的发送时间未到,此时的 nextPollTimeoutMillis 为距离 msg 的发送时间的时间间隔,
// 那 nativePollOnce() 方法休眠相应的时间后,msg 即到了它该发送的时间
nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
} else {
// Got a message.
mBlocked = false;
if (prevMsg != null) {
prevMsg.next = msg.next;
} else {
mMessages = msg.next;
}
msg.next = null;
if (DEBUG) Log.v(TAG, "Returning message: " + msg);
msg.markInUse();
return msg;
}
} else {
// No more messages.
// 没有更多的消息,此时 nextPollTimeoutMillis 赋值为 -1,
// 那 nativePollOnce() 方法将导致线程永久休眠,直到有其他线程将其唤醒
nextPollTimeoutMillis = -1;
}

// Process the quit message now that all pending messages have been handled.
if (mQuitting) {
dispose();
return null;
}
}
}
}
复制代码

next() 方法看起来很长,但是它的主要工作只有一件事,就是找到符合要求的 Message 实例并返回。但是这个方法又特别重要,有一个常问的重要的面试考点。我们上面已经提到了,Looperloop() 方法中有一个死循环,作用是源源不断地从 MessageQueue 中「打捞」 Message 实体,而「打捞」的动作正是通过 next() 方法完成的。在 next() 方法中,也有一个死循环,完成上面的「打捞」工作。具体的细节我在代码中作了部分注释,可以帮助理解。其中提到了一个概念——「Looper synchronization barrier」,关于它的介绍我们放在下面的内容里。


好了,介绍完了 Handler 机制中的死循环,它是死循环双重嵌套的形式,那么面试问题来了:请问 Handler 机制中的死循环是如何做到不阻塞主线程的呢?网上搜索到的答案通常是死循环也未必会阻塞主线程,只要不在 onCreate()onStart() 等生命周期中阻塞就不会导致界面的卡死,其次在 MessageQueue 中没有 Message 实体时,线程会进入到一个休眠的状态,在有新消息来临时线程才会被唤醒,balabala小魔仙……我们看到 next() 方法的死循环的一开始有一句代码 nativePollOnce(),它是一个 native 的方法,通过执行 Linux 中的 epoll 机制来是线程休眠和运行,它和 nativeWake() 方法配对使用,在类文件的开头均有声明。所以每次在执行完一遍 next() 方法后,都会根据 nextPollTimeoutMillis 变量的值来决定休眠的时间。如果没有可被「打捞」的消息,那么线程将被永久休眠,等待被唤醒。那么在哪里唤醒的呢,我们暂时不管,在这里先记住线程休眠,主线程被阻塞,等待一个白马王子将其唤醒。至于白马王子何时到来,我们静待。


Handler——消息操作台


现在,我们再从消息发送的源头追溯——通过 Handler 的一系列 sendMessage() 方法,将消息发送出去。


我们以 sendEmptyMessage() 方法为例,经过一系列的调用后,最终会执行 enqueueMessage() 方法,该方法又会调用 MessageQueueenqueueMessage() 方法,该方法代码如下:


/**
* MessageQueue
*/
boolean enqueueMessage(Message msg, long when) {

synchronized (this) {

msg.markInUse();
msg.when = when;
Message p = mMessages;
boolean needWake;
if (p == null || when == 0 || when < p.when) {
// New head, wake up the event queue if blocked.
msg.next = p;
mMessages = msg;
needWake = mBlocked;
} else {
// Inserted within the middle of the queue. Usually we don't have to wake
// up the event queue unless there is a barrier at the head of the queue
// and the message is the earliest asynchronous message in the queue.
needWake = mBlocked && p.target == null && msg.isAsynchronous();
Message prev;
for (;;) {
prev = p;
p = p.next;
if (p == null || when < p.when) {
break;
}
if (needWake && p.isAsynchronous()) {
needWake = false;
}
}
msg.next = p; // invariant: p == prev.next
prev.next = msg;
}

// We can assume mPtr != 0 because mQuitting is false.
if (needWake) {
nativeWake(mPtr);
}
}
return true;
}
复制代码

好耶,「白马王子」来了!看到了吧,nativeWake() 方法显真身了,当有新的消息压入队列,消息需要被处理,此时就需要唤醒睡眠的线程。但是「白马王子」


的到来是需要条件的,即 needWake,那到底是怎样的条件呢?想想无非是判断当前的线程是否处于可能阻塞的状态,我们来看看。


在第一个条件 p == null || when == 0 || when < p.when 下,相比于罗列所有的满足条件的情况,更简单的方法是判断我们前面的线程被阻塞的情况是不是在这里被判定为 needWake, 因为在等待新的消息,所以 mMessage 值为 null,此时的 needWake = mBlocked,而 mBlocked 的线程被阻塞的情况下值是为 true 的,所以这里会被判定为需要被唤醒。而在 else 分支中,其实条件为p != null && when != 0 && when >= p.when,这说明消息队列中的消息并没有被取完,而是正在一个循环中,通常情况下是不需要再唤醒它,除非像注释中所说的 there is a barrier at the head of the queue and the message is the earliest asynchronous message in the queue


到这里,Handler 的大概工作流程就可以串联起来了——循环队列相当于物流,消息相当于商品,物流无时无刻在运转,当你需要新的商品时,商品被商家发送至物流,然后分发到目标客户即你的手中。


Looper synchronization barrier


在看源码的时候,不止一次会接触到这个概念,而且在上面我们也已经率先使用了这个概念,那么这个概念到底是个什么?搞清楚这个问题,我们需要从它的特征入手,在 MessageQueuenext() 方法中,我们说如果 mMessages.target == null,那么它就是一个 barrier 的临界点,我们通过查找 mMessage 的写引用,最终定位到 MessageQueue#postSyncBarrier() 这个方法。我这里摘录它的注释,相信大家对这个概念就会有一个清晰的认识。



Posts a synchronization barrier to the Looper's message queue.


Message processing occurs as usual until the message queue encounters the synchronization barrier that has been posted. When the barrier is encountered, later synchronous messages in the queue are stalled (prevented from being executed) until the barrier is released by calling {@link #removeSyncBarrier} and specifying the token that identifies the synchronization barrier.


This method is used to immediately postpone execution of all subsequently posted synchronous messages until a condition is met that releases the barrier. Asynchronous messages (see {@link Message#isAsynchronous} are exempt from the barrier and continue to be processed as usual.


This call must be always matched by a call to {@link #removeSyncBarrier} with the same token to ensure that the message queue resumes normal operation. Otherwise the application will probably hang!



在了解这个概念之前还需要知道一个属性的存在,那就是 Message#isAsynchronous()


好了,总结一下就是 Looper synchronization barrierMessageQueue 中那些 target == nullMessage,它们不需要被发送,只作为一种队列状态的判断标识。当 Message.isAsynchronous() == true 时,遇到 Looper synchronization barrier 时,Looper 会被阻塞,直到 removeSyncBarrier() 方法(和 postSyncBarrier() 方法成对使用)移除这个标识。但是如果 Message.isAsynchronous() == false 时,则不会被 barrier 阻断,具体使用场景见上方注释。


太多的代码和解说赶不上一张图片更能让人形成概念,那我从网上找了一张图片稍作加工,希望可以比较形象地说明 Handler 机制中各个类之间的分工。



映射关系


为了话题的自然过渡,这里我们思考一个问题,一个线程可以有多个 Looper 吗?一个 Looper 可以对应多个 MessageQueue 吗?从源码中看,一个线程是无法创建多个 Looper 和多个 MessageQueue 的,那么多个 LooperMessageQueue 会导致什么问题呢?最主要的就是我们上面说的消息同步性的问题了,多个消息队列和循环体如何保证消息的次序限制以及同步分发就是一个很复杂的问题。那么系统又是如何保证每个线程的 Looper 的唯一性的呢?那就是使用 ThreadLocal 了。


ThreadLocal


由于本篇内容旨在讨论 Handler 的相关机制,所以对于 ThreadLocal 的机制不做过多讨论。


Looper#prepare() 方法在 Looper 使用前必须调用,在这个方法里可以看到 ThreadLocal 的应用。


/**
* Looper
*/
static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();

private static void prepare(boolean quitAllowed) {
if (sThreadLocal.get() != null) {
throw new RuntimeException("Only one Looper may be created per thread");
}
sThreadLocal.set(new Looper(quitAllowed));
}
复制代码

sThreadLocal 对象是一个全局的静态对象,通过使用 sThreadLocal#set() 方法来存储 Looper 的实例,而 ThreadLocal 把真正的对象存储交给了它的静态内部类 ThreadLocalMap,这是一个自定义的 hash map,具体内部实现请自行阅读源码。


/**
* ThreadLocal
*/

public void set(T value) {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null)
map.set(this, value);
else
createMap(t, value);
}

ThreadLocalMap getMap(Thread t) {
return t.threadLocals;
}

public T get() {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null) {
ThreadLocalMap.Entry e = map.getEntry(this);
if (e != null) {
@SuppressWarnings("unchecked")
T result = (T)e.value;
return result;
}
}
return setInitialValue();
}
复制代码

可以看到,ThreadLocalMap 又和 Thread 绑定,每个 Thread 对应一个唯一的 ThreadLocalMap 实例, ThreadLocalMapkey 的类型是 ThreadLocal,而在 Looper 中的 sThreadLocal 作为静态对象,进程内唯一,通过这样的关系,可以唯一对应到 TreadLocalMap 中的某个元素,实现读取。


碎碎念


前面两个月经历找工作和工作后的一堆琐事,导致很久没有更新。这篇也是匆忙赶工,逻辑上和图文代码编排上都有一些问题,还请多多包涵。之前做的是 Flutter 的工作,现在又回到了 Android,Flutter 的内容也会继续带着更新,后面我会尽量保持正常的更新频率,但是水平确实有限,最后还是请大家雅正和包涵。


作者:Sandfone
链接:https://juejin.cn/post/6926698513082351623
来源:掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
收起阅读 »

Jetpack Compose 初体验(二)

Jetpack Compose 初体验(一)二、主题 基本布局已经差不多啦,那么我们再来搞一些共性的东西,就像我们黄种人都有一样的肤色——散在土地里的黄,有种顽强,非常东方…… 以前的 View 系统其实也有关于 theme 的定义,那些被定义的 style,...
继续阅读 »

Jetpack Compose 初体验(一)

二、主题


基本布局已经差不多啦,那么我们再来搞一些共性的东西,就像我们黄种人都有一样的肤色——散在土地里的黄,有种顽强,非常东方……


以前的 View 系统其实也有关于 theme 的定义,那些被定义的 style,在官方定义的一系列 theme 的基础上加以扩展,形成我们 app 的主题。


Compose 框架提供了 Material Design 的实现,Material Design Theme 自然也被应用到 Compose 中,Material Design Theme 包括了对颜色、文本样式和形状等属性的定义,咱们自定义这些属性后,包括 button、cards、switches 等控件都会相应的改变它们的默认样式。


1.颜色


颜色在前端开发中真的是无处不在了,Color 可以帮助我们快速地构建颜色模型。


你可以泡着吃:


val red = Color(0xffff0000)
复制代码

可以扭着吃:


val blue = Color(red = 0f, green = 0f, blue = 1f)
复制代码

欸,你还可以干吃:


val black = Color.Black
复制代码

只要你喜欢,你甚至可以空翻360度加转体一周半的时候吃:


// 我不会空翻,也不会转体,期待你的表现,加油!
复制代码

Compose 提供了 Colors数来创建成套的浅色或深色:


val Purple200 = Color(0xFFBB86FC)
val Purple500 = Color(0xFF6200EE)
val Purple700 = Color(0xFF3700B3)
val Teal200 = Color(0xFF03DAC5)

private val DarkColorPalette = darkColors(
primary = Purple200,
primaryVariant = Purple700,
secondary = Teal200,
onPrimary = Color.Green
)

private val LightColorPalette = lightColors(
primary = Purple500,
primaryVariant Customize= Purple700,
secondary = Teal200,
onPrimary = Color.Green

/* Other default colors to override
background = Color.White,
surface = Color.White,
onPrimary = Color.White,
onSecondary = Color.Black,
onBackground = Color.Black,
onSurface = Color.Black,
*/
)
复制代码

然后,就可以传递给 MaterialTheme 使用喽:


@Composable
fun TestComposeTheme(darkTheme: Boolean = isSystemInDarkTheme(), content: @Composable() () -> Unit) {
val colors = if (darkTheme) {
DarkColorPalette
} else {
LightColorPalette
}

MaterialTheme(
colors = colors,
typography = Typography,
shapes = Shapes,
content = content
)
}
复制代码

怎么样,还自动适配深色模式。


而且,我们也可以随时随地获取到主题色:


Text(
text = "Hello theming",
color = MaterialTheme.colors.primary
)
复制代码

表面颜色和内容颜色又是另一个概念了,许多组件都接受一对颜色和「内容颜色」:


Surface(
color: Color = MaterialTheme.colors.surface,
contentColor: Color = contentColorFor(color),


TopAppBar(
backgroundColor: Color = MaterialTheme.colors.primarySurface,
contentColor: Color = contentColorFor(backgroundColor),

复制代码

这样一来,您不仅可以设置可组合项的颜色,而且还能为包含在可组合项中的内容提供默认颜色。默认情况下,许多可组合项都使用这种内容颜色。例如,Text 的颜色基于其父项的内容颜色,而 Icon :「俺也一样」,它可以使用该颜色来设置其色调。


contentColorFor() 方法可以为任何主题颜色检索适当的“on”颜色。例如,如果您设置 primary 背景,就会将 onPrimary 设置内容颜色。如果您设置非主题背景颜色,还应指定合理的内容颜色。使用 LocalContentColor 可检索与当前背景形成对比的当前内容颜色。


我们以上面自定义的 Theme 来试验,使用它作为我们的主题:


@Preview
@Composable
fun TestColor() {
TestComposeTheme {
Button(onClick = {}) {
Text(
"hello world"
)
}
}
}Customize
复制代码

效果:


image-20210429183615573.png


2.字体排版


字体排版主要通过 TypographyTextStyle 类来完成。Typography 构造函数可以提供每种样式的默认值,因此您可以省略不希望自定义的任何样式:


val Rubik = FontFamily(
Font(R.font.rubik_regular),
Font(R.font.rubik_medium, FontWeight.W500),
Font(R.font.rubik_bold, FontWeight.Bold)
)

val MyTypography = Typography(
h1 = TextStyle(
fontFamily = Rubik,
fontWeight = FontWeight.W300,
fontSize = 96.sp
),
body1 = TextStyle(
fontFamily = Rubik,
fontWeight = FontWeight.W600,
fontSize = 16.sp
)
/*...*/
)
MaterialTheme(typography = MyTypography, /*...*/)
复制代码

如果您希望自始至终使用同一字体,请指定 defaultFontFamily 参数,并省略所有 TextStyle 元素的 fontFamily


val typography = Typography(defaultFontFamily = Rubik)
MaterialTheme(typography = typography, /*...*/)
复制代码

使用时,可以从主题检索 TextStyle,如以下示例所示:


Text(
text = "Subtitle2 styled",
style = MaterialTheme.typography.subtitle2
)
复制代码

3.形状


Compose 中可以轻松地定义各种形状,比如圆角或者操场跑道形状,在传统 View 系统中实现都比较麻烦。


我们现在修改一下上面的 Button 的形状来看看效果:


val Shapes = Shapes(
small = CutCornerShape(
topStart = 16.dp,
topEnd = 0.dp,
bottomStart = 16.dp,
bottomEnd = 0.dp
),
medium = RoundedCornerShape(percent = 50),
large = RoundedCornerShape(0.dp)
)
复制代码

image-20210429192726472.png


这里有一点需要注意的是,默认情况下,许多组件使用这些形状。例如,Button、TextField 和 FloatingActionButton 默认为 small,AlertDialog 默认为 medium,而 ModalDrawerLayout 默认为 large。如需查看完整的对应关系,请参阅形状方案参考文档。


三、列表


列表也是个常见的家伙,Android View 系统中早期的 ListView 和后来的 RecyclerView, Flutter 里的 ListView 等。


一个列表就是许多个元素排排站,整齐笔直。那一个纵向(或横向)的布局中动态地添加进许多的元素不就好了。


@Composable
fun MessageList(messages: List) {
Column {
messages.forEach { message ->
MessageRow(message)
}
}
}
复制代码

来,你猜,RecyclerView 是不是这么写的。这里有个最大的问题,假如你是个交际花,好友从这里排到法国,列表多到滑一晚上滑不到头,那么一次加载是不是要耗费巨大的资源,搞不好卡死了王思聪联系不上你那就太不给面了,不好。


RecyclerView 最大的一个优点是它可以懒加载列表项,一次只加载一个屏幕的条目(四舍五入就是我对)。Compose 中可没有 RecyclerView,但是同样有针对这一问题优化的组件,LazyColumnLazyRow 是垂直和水平方向的懒加载列表控件。我们先来看一下效果:


@Preview
@Composable
fun TestList() {
LazyColumn(modifier = Modifier.fillMaxWidth(),
contentPadding = PaddingValues(16.dp),
verticalArrangement = Arrangement.spacedBy(4.dp)) {
// Add a single item
item {
Text(text = "First item")
}

// Add 5 items
items(10000) { index ->
Text(text = "Item: $index")
}

// Add another single item
item {
Text(text = "Last item")
}
}
}
复制代码

这里加载了一万个元素的列表,看看这丝滑的效果吧(建议就着德芙食用)。


lazy_column.gif


我们还可以像上面一样,通过 contentPadding 设置内容边距,verticalArrangement 则是可以设置 item 间间距,以及均匀地排列元素以充满父空间。


比较遗憾地是 LazyColumnLazyRow 暂时无法设置例如添加元素时地动画,期待后续的加入吧。


LazyColumn 可以轻松地实现粘性标题,只需使用 stickyHeader() 函数即可:


// TODO: This ideally would be done in the ViewModel
val grouped = contacts.groupBy { it.firstName[0] }

@OptIn(ExperimentalFoundationApi::class)
@Composable
fun ContactsList(grouped: Map>) {
LazyColumn {
grouped.forEach { (initial, contactsForInitial) ->
stickyHeader {
CharacterHeader(initial)
}

items(contactsForInitial) { contact ->
ContactListItem(contact)
}
}
}
}
复制代码

上面的代码演示了如何通过 Map 数据结构实现粘性标题的数据展示。


既然有列表,那么肯定会有宫格列表,LazyVerticalGrid 则能够帮助我们实现需求。更多用法查看相关 API(没错,我就是 LazyBoy,但我的尊严决定了我不会滚)。


在实际项目开发中,我们经常会遇到将数据分页展示的情况,以减少数据请求压力。借助 Paging 3.0 库 可以来进行分页,Paging 库是 Jetpack 中重要的一项新特性,可帮助您一次加载和显示多个小的数据块。按需载入部分数据会减少网络带宽和系统资源的使用量。


如需显示分页内容列表,可以使用 collectAsLazyPagingItems() 扩展函数,然后将返回的 LazyPagingItems 传入 LazyColumn 中的 items()。与视图中的 Paging 支持类似,您可以通过检查 item 是否为 null,在加载数据时显示占位符:


import androidx.paging.compose.collectAsLazyPagingItems
import androidx.paging.compose.items

@Composable
fun MessageList(pager: Pager) {
val lazyPagingItems = pager.flow.collectAsLazyPagingItems()

LazyColumn {
items(lazyPagingItems) { message ->
if (message != null) {
MessageRow(message)
} else {
MessagePlaceholder()
}
}
}
}

作者:Sandfone
链接:https://juejin.cn/post/6958979036181692424
来源:掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
收起阅读 »

Jetpack Compose 初体验(一)

你是否受够了 Android 中 UI 编写的体验——在 xml 文件中编写复杂的层级结构和繁多的属性,动态化的视图逻辑又被分裂到 Activity 中?哦,这该死的友好度和割裂感! 这两年,Flutter 大行其道,不论是网上的讨论度还是实际的落地项目,风头...
继续阅读 »

你是否受够了 Android 中 UI 编写的体验——在 xml 文件中编写复杂的层级结构和繁多的属性,动态化的视图逻辑又被分裂到 Activity 中?哦,这该死的友好度和割裂感!


这两年,Flutter 大行其道,不论是网上的讨论度还是实际的落地项目,风头一时无两。所以从这个角度来说,作为 UI 框架的 Flutter,无疑是成功的。本着借鉴的思想(或许吧,谁知道呢),Android 在 Jetpack 项目中新增了一套全新的视图开发套件——Compose。它有着和 Flutter 一样好看的(姑且这么认为吧)外表,但究竟只是一个好看的花瓶还是才貌双全,这得我们自己去寻找答案。


Compose 当前还处于测试版本,想要使用它,我们需要首先下载 Android studio 的 canary 版本以提供支持。你可以在这里下载或者在你现有的 Android studio 中打开 File -> Settings -> Appearance & Behavior -> System Settings -> Updates 菜单,然后切换到 canary 渠道再点击 Check Now 按钮即可更新到最新的 canary 版本。


一、布局


1.可组合函数


使用 Compose 创建一个界面是简单的,只需通过 @Composable 注解定义一个可组合函数,在函数中返回界面元素组件即可。


@Composable
fun Greeting(name: String) {
Text(text = "Hello $name!")
}
复制代码

该函数可以接收参数。函数内可以是一个组件,也可以是多个组件的组合。


通过 setContent 方法块可以设置页面内容,类似于之前的 setContentView() 方法。


setContent {
Text(text = "Hello Compose!")
}
复制代码

相比于之前的界面书写过程,Compose 更「神奇」的一个体现在于它可以直接在 Android studio 中预览我们编写的界面和组件,而无需让程序运行在设备中。


我们只需要在可组合函数的基础上再新增一个 @Preview 注解,但是需要注意的是,预览函数不接受参数,所以比较好的做法是在可组合函数的基础上编写其对应的预览函数。


@Preview
@Composable
fun DefaultPreview() {
Greeting("Android")
}
复制代码

预览函数对你的应用在设备上的最终呈现不会产生影响,Android studio 提供了一个预览窗口可以实时看到预览函数所呈现的效果。


image-20210412225335487.png


2.布局


我们编写的应用界面几乎任何时候都不会是简简单单的单一的控件,而是一定数量的独立控件在空间上的一种组合。


首先,我们就盲猜,如果我想竖直方向排列三个文字组件,肯定不是像下面这样随便组合三个 Text 控件。它怎么可能那么聪明,能知道你是想横着排还是竖着排,想并排排还是旋转开。怎么可能有人比苏菲更懂你!


@Composable
fun VerticalText() {
Text("Hello World!")
Text("Hello Again World!")
Text("How old are you, World!")
}
复制代码

image-20210413003422129.png


那,就组合喽。


@Composable
fun VerticalText() {
Column {
Text("Hello World!")
Text("Hello Again World!")
Text("How old are you, World!")
}
}
复制代码

给三个 Text 约定个竖框框,它们就能乖乖地排起队。


image-20210413005809783.png


这里,悄摸摸地说一句,这要是没有偷瞄 Flutter 的考卷 向优秀的思想借鉴,我把三个 Text 布局在我脑门上!


当然,只有这么生硬的排列可不行,我们还需要加点属性,使得整个布局更和谐点——例如,加点边距。


我们希望给 Column 加一个内边距,那么我们就应该给 Column 添加一个属性。Modifier 类用来给组件添加装饰或者行为,如背景、边距、点击事件等。


@Preview(showBackground = true)
@Composable
fun VerticalText() {
Column(
modifier = Modifier.padding(16.dp)
) {
Text("Hello World!")
Text("Hello Again World!")
Text("How old are you, World!")
}
}
复制代码

image-20210413210728702.png


现在,为了让界面看起来不那么单调,我们给这个界面加上下面这一张图片。


![](Compose 初体验.assets/hello_world_new_black.png)


将这张图片拷贝到 drawable 资源文件夹下面,然后通过下面的方式引用。


@Preview(showBackground = true)
@Composable
fun VerticalText() {
Column(
modifier = Modifier.padding(16.dp)
) {
Image(
painter = painterResource(id = R.drawable.hello_world_new_black),
contentDescription = null
)
Text("Hello World!")
Text("Hello Again World!")
Text("How old are you, World!")
}
}
复制代码

Image 的其中一个构造函数支持以下参数,其中 painter 参数和 contentDescription 参数没有默认值,为必传参数。


image-20210420220142848.png


这样,图片就被构造出来啦,看一下效果:


image-20210420220432840.png


那怎么该对图片进行一些约束呢?作为一个头图,我不希望它这么哗众取宠,做图片要低调一点。


在上面,我们认识了 Modifier,那就寻求它的帮助,让我们的图片小一些吧。


Image(
painter = painterResource(id = R.drawable.hello_world_new_black),
contentDescription = null,
modifier = Modifier
.width(126.dp)
.height(62.dp),
contentScale = ContentScale.Inside
)
复制代码

借助 Modifier 将图片的高度和宽度分别进行限定。然后通过 contentScale 参数对图片的缩放方式进行约束。ContentScale.Inside 保持图片比例不变的情况下尽可能地充满父控件的体积。


把上面的 Image 放入 preview 方法,看一下效果:


image-20210420221651702.png


现在头图就被我们拿捏得死死的,但是它还不是很好看,没脖子,加个脖子。


@Preview(showBackground = true)
@Composable
fun VerticalText() {
Column(
modifier = Modifier.padding(16.dp)
) {
Image(
painter = painterResource(id = R.drawable.hello_world_new_black),
contentDescription = null,
modifier = Modifier
.width(126.dp)
.height(62.dp),
contentScale = ContentScale.Inside
)

Spacer(modifier = Modifier.height(16.dp))

Text("Hello World!")
Text("Hello Again World!")
Text("How old are you, World!")
}
}
复制代码

image-20210420222219906.png


这样是不是好看多了,嗯,是的。


3.Material Design


谷歌霸霸的产品当然是支持 Material Design 的,那咱就看看。


做头图不要锋芒毕露,做图处事要圆滑一点。给头图加个圆角是个不错的想法。


在 Android 传统的 UI 编写中,圆角图片一直没有很简单的解决方案,需要通过诸如自定义 ImageView 的方式来实现。但是,朋友们,当你使用 Compose 框架的时候,只需要一行代码就可以圆角图片的显示!家祭无忘告乃翁。


@Preview(showBackground = true)
@Composable
fun VerticalText() {
Column(
modifier = Modifier.padding(16.dp)
) {
Image(
painter = painterResource(id = R.drawable.hello_world_new_black),
contentDescription = null,
modifier = Modifier
.width(126.dp)
.height(62.dp)
.clip(shape = RoundedCornerShape(4.dp)),
contentScale = ContentScale.Inside
)

Spacer(modifier = Modifier.height(16.dp))

Text("Hello World!")
Text("Hello Again World!")
Text("How old are you, World!")
}
}
复制代码

这里还是通过 Modifier 来实现需求,怎么样,现在的头图是不是圆滑可爱了很多。


image-20210420223334597.png


头图这么求上进,文字也不能落后,一篇好的文章要主次分明,错落有致。


声明 Typography 对象,然后给 Text 添加 style 属性,来控制文字的样式。


@Preview(showBackground = true)
@Composable
fun VerticalText() {
val typography = MaterialTheme.typography
Column(
modifier = Modifier.padding(16.dp)
) {
Image(
painter = painterResource(id = R.drawable.hello_world_new_black),
contentDescription = null,
modifier = Modifier
.width(126.dp)
.height(62.dp)
.clip(shape = RoundedCornerShape(4.dp)),
contentScale = ContentScale.Inside
)

Spacer(modifier = Modifier.height(16.dp))

Text("Hello World!", style = typography.h3)
Text("Hello Again World!", style = typography.body1)
Text("How old are you, World!", style = typography.body2)
}
}
复制代码

Typography 提供如下预设属性,囊括标题、子标题、段落体、按钮等。


image-20210420225524291.png


最终效果如下:


image-20210420225406851.png


怎么样,是不是主次开始变得分明了?结构变得清晰了?情节展开得顺滑了?故事开始自然了?……


当然,其他的诸如最大行数、字体、对齐方式等都可以被配置。


作者:Sandfone
链接:https://juejin.cn/post/6958979036181692424
来源:掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
收起阅读 »

iOS 列表界面如何优雅实现模块化与动态化

前言去年做了一个小组件,前些时间考虑到项目中可能会大规模实施,完善简化后新开了一个 repo: YBHandyList 。有些朋友抛出了 nimbus、IGListKit 等业界应用很广的库,前些时间网易工程师也推出了 M80TableViewComponen...
继续阅读 »

前言

去年做了一个小组件,前些时间考虑到项目中可能会大规模实施,完善简化后新开了一个 repo: YBHandyList 。

有些朋友抛出了 nimbus、IGListKit 等业界应用很广的库,前些时间网易工程师也推出了 M80TableViewComponent。理论上这些组件的原理大同小异,虽然它们各有优势,但却不太能满足笔者对架构清晰度的要求。

本文分析 YBHandyList 的应用价值,希望能解开一些朋友的疑惑。

业务痛点

iOS 界面开发中 UITableView / UICollectionView 的出场率极高,它们都是使用代理方法配置数据源,虽然这样的设计理念符合了单一职责原则,但在列表变得复杂时代理方法的处理将变得力不从心:

  • 同一个 Cell / Header / Footer 处理逻辑分散在各个代理方法中,不便于管理。

  • 当列表数据动态变化时,每一个代理方法里的判断逻辑都将变得复杂,且这些逻辑很可能会相互关联。

显然,在这样的场景下将是维护的灾难,特别是当你接手别人的代码发现每个 UITableView 代理方法里都有几十个if-else,它们人多势众,量你不敢动它们任何一个。

由此可见,若想维护性高需要解开每一个 Cell 之间的逻辑耦合,也就是通常意义的模块化,由此才能更轻易的实现动态化。解决方案其实很简单,只需要一个中间类,将分散的配置集中起来(在代理方法里取这个中间类的对应值):

@interface Config : NSObject
@property (nonatomic, assign) CGFloat height;
@property (nonatomic, strong) Class cls;
@property (nonatomic, strong) id model;
@end

然而对于业务工程师来说,每次写这样的代码都意味着时间成本,所以制作一个基础组件是很有必要的,它需要满足以下特性:

  • 模块化配置 Cell / Header / Footer。

  • 更容易实施列表动态化。

  • 能拓展原生能实现的所有场景。

为此,YBHandyList 应运而生,它足够简单以至于从设计到编码基本就花了一天时间。

YBHandyList 的优势

原理:


代码简单轻量

YBHandyList 保留最小功能,代码量很少,核心思路就一句话:将 UITableView / UICollectionView 的数据源从代理方法配置转化为数组配置。

在其它库当中可以看到高度缓存、访问迭代器等逻辑,笔者认为这样的基础设施不应该侵入过多业务,它们本应该是业务关注的逻辑,这样的语法糖只能在简单场景下少写些代码,当业务变得复杂时往往这样的优势就不存在了。

YBHandyList 的语法糖非常收敛,简单的一个延展,你甚至可以选择不使用语法糖,直接使用代理实现类。

由此,新手工程师也能对实施代码充满信心。

业务侵入性低

YBHandyList 采用 IOP 设计,最大限度的降低了业务侵入性,只需要在 Cell / Header / Footer 中实现几个代理方法就行了。

去基类化设计让数据流动过程更加纯粹,不需要考虑父类做了什么,没做什么。在老业务中可能存在类似BaseTableViewCell 的东西,YBHandyList 也能优雅的接入,这种场景下继承的设计范式将力不从心。

这种架构规范类组件接入的成本非常重要,而舍弃的成本也不容忽视,由于 IOP 天然的优势,YBHandyList 结构代码的舍弃将轻而易举,不拖泥带水。

直观的动态化控制

构建界面只需要关注所有id<Config>在数据源数组中的顺序,就像搭积木一样拼接起来,数组中的顺序就是对应 Cell 在界面中的显示顺序,由此就能通过改变数据源数组的顺序轻易的实现动态化控制。

在 MVVM 架构中实施

YBHandyList 的设计方式让它在各种架构中都能无障碍实施,下面以 MVVM 举例(仅说明 UITableViewCell 的实施,具体可以看 DEMO):


可以看到,Cell 与 UITableView 非直接耦合,所以若需要将 Cell 的事件传递出来最好通过 Cell 的 ViewModel,ViewModel 作为连接 Cell 与外界的桥梁。

Cell 的 ViewModel 也可以在主 ViewModel 中构建,这样 Controller 中就不用导入这些类,不过当 Cell 的 ViewModel 需要将事件传递到 Controller 时,就会需要一些胶水代码通过主 ViewModel 间接传递。

数据绑定并非必须做的事情,你可以用 RAC,或者另外一个选择:EasyReact,可以参考笔者的文章:美团 EasyReact 源码剖析:图论与响应式编程。

更安全和优雅的复用

很多时候,我们会将具体业务的处理逻辑放 Cell 中或者其 ViewModel 中,那么它们就很难复用,因为复用是建立在无具体业务侵入的前提下。

实际上只需要将具体业务的处理逻辑抽离出来,处理过后再放在 ViewModel 中,Cell 拿到 ViewModel 再进行具体业务无关的界面刷新。如此,ViewModel 将可以在任何地方复用。

使用 YBHandyList 后,ViewModel 把 Cell 与外部业务解开耦合,只把需要暴露的东西写在ViewModel .h中,外部业务无需导入 Cell 便能通过 ViewModel 直接复用,更加的安全。

能拓展原生支持的场景

一个基础设施最怕的就是不能满足所有场景的情况下还封闭了拓展的入口。YBHandyList 通过继承默认代理实现类就能拓展实现其它的 UITableView / UICollectionView 代理方法。

这看起来有些繁琐,使用多代理技术能避免额外的创建代理实现类,但这样会导致代码不再简单和透明。换个角度想,代理实现类中将大量复杂逻辑处理过后,仅仅回调给外部业务一个简单的方法,达到为外部模块瘦身的目的。

后语

笔者一直偏好简洁的代码设计,让核心功能最小化实现,当它无法覆盖所有的场景时一定要有原生拓展能力。语法糖的主要意义是减少使用者的思考成本而不单单是为了少写两句代码,它不应该侵入功能收敛的核心代码。要做好这一切,就一定要透过现象看清问题的本质。

链接:https://www.jianshu.com/p/f0a74d5744b8

收起阅读 »

iOS 应用内打开三方地图app直接导航

当然因为有需求喽。疯狂试探- (BOOL)canOpenURL:(NSURL *)url NS_AVAILABLE_IOS(3_0);常用地图应用的url Scheme://百度地图 baidumap //高德地图 iosamap //谷歌地图 comgo...
继续阅读 »

当然因为有需求喽。

疯狂试探
- (BOOL)canOpenURL:(NSURL *)url NS_AVAILABLE_IOS(3_0);

常用地图应用的url Scheme:

//百度地图  
baidumap
//高德地图
iosamap
//谷歌地图
comgooglemaps
//腾讯地图
qqmap
//其他地图省略
….

苹果地图不需要,iOS API提供了一个跳转打开方法。
注意IOS9之后,plist里面设置url scheme白名单

<key>LSApplicationQueriesSchemes</key>
<array>
<string>qqmap</string>
<string>comgooglemaps</string>
<string>iosamap</string>
<string>baidumap</string>
</array>

在下用的是高德坐标
高德转坐标类型枚举

//        AMapCoordinateTypeBaidu = 0,    ///<Baidu
// AMapCoordinateTypeMapBar, ///<MapBar
// AMapCoordinateTypeMapABC, ///<MapABC
// AMapCoordinateTypeSoSoMap, ///<SoSoMap
// AMapCoordinateTypeAliYun, ///<AliYun
// AMapCoordinateTypeGoogle, ///<Google
// AMapCoordinateTypeGPS, ///<GPS

在下试过转百度用AMapCoordinateTypeBaidu,这样一一对应的方式转,但跳转之后误差很大,后来我试着杂交匹配一下,所有地图使用Google转法最准,所以除高德地图都用了Google转出的坐标

重点来了!!!!

- (void)pushMapLan:(CGFloat)lan Lon:(CGFloat)lon pointName:(NSString *)title {

UIAlertController *alertSheet = [UIAlertController alertControllerWithTitle:title message:@"请选择以下驾车导航方式" preferredStyle:UIAlertControllerStyleActionSheet];

// 高德坐标转换百度坐标
CLLocationCoordinate2D gps = AMapCoordinateConvert(CLLocationCoordinate2DMake(lan,lon), AMapCoordinateTypeGoogle);
// --------------------------------------------------

if ([[UIApplication sharedApplication] canOpenURL:[NSURL URLWithString:@"baidumap://"]]) {
NSMutableDictionary *baiduMapDic = [NSMutableDictionary dictionary];
baiduMapDic[@"title"] = @"百度地图";
NSString *urlString = [[NSString stringWithFormat:@"baidumap://map/direction?origin={{我的位置}}&destination=latlng:%f,%f|name=北京&mode=driving&coord_type=gcj02",gps.latitude,gps.longitude] stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
baiduMapDic[@"url"] = urlString;
[alertSheet addAction:[UIAlertAction actionWithTitle:baiduMapDic[@"title"] style:UIAlertActionStyleDefault handler:^(UIAlertAction * _Nonnull action) {
[[UIApplication sharedApplication] openURL:[NSURL URLWithString:baiduMapDic[@"url"]]];
}]];
}

//高德地图
if ([[UIApplication sharedApplication] canOpenURL:[NSURL URLWithString:@"iosamap://"]]) {
NSMutableDictionary *gaodeMapDic = [NSMutableDictionary dictionary];
gaodeMapDic[@"title"] = @"高德地图";
NSString *urlString = [[NSString stringWithFormat:@"iosamap://navi?sourceApplication=%@&backScheme=%@&lat=%f&lon=%f&dev=0&style=2",@"导航功能",@"poapoaaldoerccbadersvsruhdk",lan,lon] stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
gaodeMapDic[@"url"] = urlString;
[alertSheet addAction:[UIAlertAction actionWithTitle:gaodeMapDic[@"title"] style:UIAlertActionStyleDefault handler:^(UIAlertAction * _Nonnull action) {
[[UIApplication sharedApplication] openURL:[NSURL URLWithString:gaodeMapDic[@"url"]]];
}]];
}

//谷歌地图
if ([[UIApplication sharedApplication] canOpenURL:[NSURL URLWithString:@"comgooglemaps://"]]) {
NSMutableDictionary *googleMapDic = [NSMutableDictionary dictionary];
googleMapDic[@"title"] = @"谷歌地图";
NSString *urlString = [[NSString stringWithFormat:@"comgooglemaps://?x-source=%@&x-success=%@&saddr=&daddr=%f,%f&directionsmode=driving",@"驾车导航",@"poapoaaldoerccbadersvsruhdk",gps.latitude,gps.longitude] stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
googleMapDic[@"url"] = urlString;
[alertSheet addAction:[UIAlertAction actionWithTitle:googleMapDic[@"title"] style:UIAlertActionStyleDefault handler:^(UIAlertAction * _Nonnull action) {
[[UIApplication sharedApplication] openURL:[NSURL URLWithString:googleMapDic[@"url"]]];
}]];
}

//腾讯地图
if ([[UIApplication sharedApplication] canOpenURL:[NSURL URLWithString:@"qqmap://"]]) {
NSMutableDictionary *qqMapDic = [NSMutableDictionary dictionary];

qqMapDic[@"title"] = @"腾讯地图";
NSString *urlString = [[NSString stringWithFormat:@"qqmap://map/routeplan?from=我的位置&type=drive&tocoord=%f,%f&to=终点&coord_type=1&policy=0",gps.latitude,gps.longitude] stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
qqMapDic[@"url"] = urlString;
[alertSheet addAction:[UIAlertAction actionWithTitle:qqMapDic[@"title"] style:UIAlertActionStyleDefault handler:^(UIAlertAction * _Nonnull action) {
[[UIApplication sharedApplication] openURL:[NSURL URLWithString:qqMapDic[@"url"]]];
}]];
}
NSMutableDictionary *iosMapDic = [NSMutableDictionary dictionary];
iosMapDic[@"title"] = @"苹果地图";
[alertSheet addAction:[UIAlertAction actionWithTitle:iosMapDic[@"title"] style:UIAlertActionStyleDestructive handler:^(UIAlertAction * _Nonnull action) {
CLLocationCoordinate2D gps = AMapCoordinateConvert(CLLocationCoordinate2DMake(lan,lon), AMapCoordinateTypeGoogle);

MKMapItem *currentLoc = [MKMapItem mapItemForCurrentLocation];
MKMapItem *toLocation = [[MKMapItem alloc] initWithPlacemark:[[MKPlacemark alloc] initWithCoordinate:gps addressDictionary:nil]];
toLocation.name = title;
NSArray *items = @[currentLoc,toLocation];
NSDictionary *dic = @{
MKLaunchOptionsDirectionsModeKey : MKLaunchOptionsDirectionsModeDriving,
MKLaunchOptionsMapTypeKey : @(MKMapTypeStandard),
MKLaunchOptionsShowsTrafficKey : @(YES)
};

[MKMapItem openMapsWithItems:items launchOptions:dic];
}]];

[alertSheet addAction:[UIAlertAction actionWithTitle:@"取消" style:UIAlertActionStyleCancel handler:^(UIAlertAction * _Nonnull action) {
}]];

[self presentViewController:alertSheet animated:YES completion:nil];

}

关于转换坐标,如果你用的是高德坐标系,除了高德地图不用转坐标系外,其他的都以高德sdk里转Google的方式转,保证目的地精确。
其他的就自己探索咯!
建议 第三方的转换方法【github】地址,找不到合适的尝试这个。

链接:https://www.jianshu.com/p/8622b6ff83b3

收起阅读 »

Swift之构建非常优雅的便利API—Swift中的计算属性

使Swift成为如此强大且通用的语言的主要原因在于,当我们选择在为特定问题形成解决方案时选择使用哪种语言功能时,我们通常可以使用多种选项。然而,这种多样性也可能引起混淆和争论,特别是当我们正在考虑的功能的关键用例之间没有明确的界限时。本周,我们来看看一个这样的...
继续阅读 »

使Swift成为如此强大且通用的语言的主要原因在于,当我们选择在为特定问题形成解决方案时选择使用哪种语言功能时,我们通常可以使用多种选项。然而,这种多样性也可能引起混淆和争论,特别是当我们正在考虑的功能的关键用例之间没有明确的界限时。

本周,我们来看看一个这样的语言特性 - 计算属性 - 以及它们如何让我们构建非常优雅的便利API,如何避免在部署它们时意外隐藏性能问题,以及在计算属性之间进行选择的一些不同策略和方法。

属性用于数据

理想情况下,属性是计算还是存储应该只是一个实现细节 - 特别是因为只要查看它所使用的代码就无法确切地知道属性是如何存储的。因此,就像存储的属性如何构成类型存储的数据一样,计算属性可以被视为在需要时计算类型数据的方法。

假设我们正在制作一个用于收听播客的应用程序,并且使用如下所示的State枚举来模拟给定播客剧集所处的状态(是否已经下载,收听等)。

extension Episode {
enum State {
case awaitingDownload
case downloaded
case listening(progress: Double)
case finished
}
}

然后,我们为我们的Episode模型提供一个存储的state属性,我们可以根据给定的剧集状态来制作决策 - 例如,能够向用户显示是否已经下载了一集。但是,由于该特定用例在我们的代码库中非常常见,我们不希望必须state在许多不同的地方手动打开- 所以我们还提供Episode了一个isDownloaded我们可以在需要的地方重用的计算属性:

extension Episode {
var isDownloaded: Bool {
switch state {
case .awaitingDownload:
return false
case .downloaded, .listening, .finished:
return true
}
}
}

我们在state上面开启而不是使用if或guard声明的原因是,如果我们在我们的State枚举中添加一个新案例,那么“强迫”我们自己更新这个代码- 否则我们可能会以不正确的方式处理这个新案例了解它。

上面的实现可以说是计算属性的一个很好的用例 - 它消除了样板,增加了便利性,并且就像它是一个只读存储属性一样 - 它的全部意义在于让我们访问模型数据的特定部分。

意外瓶颈

现在让我们来看看硬币的另一面 - 如果我们不小心,计算属性虽然非常方便,但有时最终会导致意外的性能瓶颈。继续上面的播客应用程序示例,假设我们为用户的播客订阅库建模的方式是通过Library结构,该结构还包含类似上次服务器同步发生时的元数据:

struct Library {
var lastSyncDate: Date
var downloadNewEpisodes: Bool
var podcasts: [Podcast]
}

虽然Podcast我们需要在我们的应用程序中呈现上述大多数视图的所有模型,但我们确实有一些地方可以将所有用户的播客显示为平面列表。就像我们之前Episode使用isDownloaded属性扩展一样,最初的想法可能是在这里做同样的事情 - 添加一个计算allEpisodes属性,收集用户库中每个播客的所有剧集 - 如下所示:

extension Library {
var allEpisodes: [Episode] {
return podcasts.flatMap { $0.episodes }
}
}

要了解更多信息flatMap,请查看“Map,FlatMap和CompactMap”基础知识文章。

上面的API可能看起来非常简单 - 但它有一个相当大的缺陷 - 它的时间复杂度是线性的(或O(N)),因为为了计算我们的allEpisodes属性,我们需要一次遍历所有播客。一开始这似乎不是什么大不了的事 - 但是在我们每次我们在一个单元格中出列单元格时访问上述属性时,在这种情况下可能会出现问题UITableView:

class AllEpisodesViewController: UITableViewController {
...

override func tableView(
_ tableView: UITableView,
cellForRowAt indexPath: IndexPath
) -> UITableViewCell {
let cell = tableView.dequeueReusableCell(
withIdentifier: reuseIdentifier,
for: indexPath
)

// Here we're accessing allEpisodes just as if it was a
// stored property, and there's no way of telling that this
// will actually cause an O(N) evaluation under the hood:
let episode = library.allEpisodes[indexPath.row]
cell.textLabel?.text = episode.title
cell.detailTextLabel?.text = episode.duration

return cell
}
}

由于表格视图单元格可以以非常快的速度出列 - 当用户滚动时 - 上述代码迟早会成为性能瓶颈,因为我们当前的allEpisodes实现将在每次访问时不断迭代所有播客。不是很好。

虽然收集每个播客的所有剧集本身就是O(N)我们当前模型结构的一个操作,但我们可以改进我们通过API 发出复杂信号的方式。我们不是将它allEpisodes看作另一个属性,而是让它成为一种方法。这样一来,它看起来更像是一个行动正在执行(这是),而不是访问一个数据块的只是一个快速的方法:

extension Library {
func allEpisodes() -> [Episode] {
return podcasts.flatMap { $0.episodes }
}
}

如果我们还更新我们AllEpisodesViewController接受一组剧集作为其初始化程序的一部分,而不是Library直接访问我们的模型,那么我们得到以下调用站点 - 它看起来比我们之前的实现更清晰:

let vc = AllEpisodesViewController(episodes: library.allEpisodes())

在我们的视图控制器中,我们仍然可以像以前一样继续访问所有剧集 - 只是现在该阵列只构建一次,而不是每次单元格出列时都是如此,这是一个很大的胜利。

方便懒惰

将任何无法在常规时间内执行的计算属性转换为方法通常会提高API的整体清晰度 - 因为我们现在强烈表示存在与访问它们相关的某种形式的成本。但在这样做的过程中,我们也失去了一些使用属性给我们带来的“优雅”。

然而,在许多这样的情况下,实际上有一种方法可以实现清晰,优雅和性能 - 所有这些都在同一时间。为了能够继续使用属性,而不必通过使用延迟评估来预先完成所有处理工作。

就像我们在“Swift序列:懒惰的艺术”和“Swift中的字符串解析”中看到的那样,推迟迭代序列直到它实际需要可以给我们带来显着的性能提升 - 所以让我们来看看如何我们可以使用该技术将其allEpisodes转变为属性。

我们将首先Library使用两种新类型扩展我们的模型 - 一种用于我们的剧集序列,另一种用于迭代该序列中的元素:

extension Library {
struct AllEpisodesSequence {
fileprivate let library: Library
}

struct AllEpisodesIterator {
private let library: Library
private var podcastIndex = 0
private var episodeIndex = 0

fileprivate init(library: Library) {
self.library = library
}
}
}

要变成AllEpisodesSequence第一类Swift序列,我们所要做的就是Sequence通过实现makeIterator工厂方法使其符合:

extension Library.AllEpisodesSequence: Sequence {
func makeIterator() -> Library.AllEpisodesIterator {
return Library.AllEpisodesIterator(library: library)
}
}

接下来,让我们的迭代器符合要求IteratorProtocol,并实现我们的实际迭代代码。我们将通过阅读播客中的每一集来做到这一点,当没有更多的剧集可以找到时,我们将继续播放下一个播客 - 直到所有剧集都被退回,如下所示:

extension Library.AllEpisodesIterator: IteratorProtocol {
mutating func next() -> Episode? {
guard podcastIndex < library.podcasts.count else {
return nil
}

let podcast = library.podcasts[podcastIndex]

guard episodeIndex < podcast.episodes.count else {
episodeIndex = 0
podcastIndex += 1
return next()
}

let episode = podcast.episodes[episodeIndex]
episodeIndex += 1
return episode
}
}

有了上述内容,我们现在可以自由地allEpisodes转回计算属性 - 因为它不再需要任何前期评估,只需AllEpisodesSequence在常量时间内返回一个新实例:

extension Library {
var allEpisodes: AllEpisodesSequence {
return AllEpisodesSequence(library: self)
}
}

虽然上述方法需要的代码多于我们之前的代码,但它有一些关键的好处。第一个是现在完全不可能简单地下标到allEpisodes返回的序列,因为Sequence这并不意味着随机访问任何底层元素:

// Compiler error: Library.AllEpisodesSequence has no subscripts
let episode = library.allEpisodes[indexPath.row]

这看起来似乎不是一个好处,但它阻止我们意外地造成我们之前遇到的那种性能瓶颈 - 迫使我们将我们的allEpisodes序列复制到一个Array之前我们将能够随机访问其中的剧集它:

let episodes = Array(library.allEpisodes)
let vc = AllEpisodesViewController(episodes: episodes)

虽然每次我们想要阅读一集时都没有什么能阻止我们执行上面的数组转换 - 但是当我们意外地订阅一个看起来像是存储的数组时,这是一个更加慎重的选择。比计算的。

另一个好处是,如果我们所寻找的只是一小部分,我们不再需要从每个播客中不必要地收集所有剧集。例如,如果我们只想向用户展示他们下一个即将到来的剧集 - 我们现在可以简单地这样做:

let nextEpisode = library.allEpisodes.first

使用延迟评估的好处在于,即使allEpisodes返回序列,上述操作也具有恒定的时间复杂度 - 就像您期望访问first任何其他序列一样。太棒了!

这都是关于语义的
既然我们能够将复杂的操作转换为计算属性,而无需任何前期评估,那么最大的问题是 - 无参数方法的剩余用例是什么?

答案很大程度上取决于我们希望给定API具有哪种语义。属性非常意味着某种形式的访问值或对象的当前状态 - 而不更改它。所以修改状态的任何东西,例如通过返回一个新值,很可能更好地用一个方法表示 - 比如这个,它更新了state我们Episode之前的一个模型:

extension Episode {
func finished() -> Episode {
var episode = self
episode.state = .finished
return episode
}
}

将上述API与使用属性的情况进行比较 - 很明显,一种方法为这种情况提供了恰当的语义:

// Looks like we're performing an action to finish the episode:
let finishedEpisode = episode.finished()
// Looks like we're accessing some form of "finished" data:
let finishedEpisode = episode.finished

许多相同的逻辑也可以应用于静态API,但我们可能会选择做出某些例外,特别是如果我们要优化使用点语法调用的API 。有关设计此类静态API的一些示例,请参阅“Swift中的静态工厂方法”和Swift中基于规则的逻辑”。

结论

计算属性非常有用 - 并且可以使我们能够设计更简单,更轻量级的API。但是,重要的是要确保这种简单性不仅被感知,而且还反映在底层实现中。否则,我们冒着隐藏性能瓶颈的风险,在这种情况下,通常更好的选择方法 - 或者在适当时部署延迟评估。

链接:https://www.jianshu.com/p/315e4522c7c8

收起阅读 »

HashMap原理底层剖析

注意以下文章可能有描述和理解上的错误,如果出现错误请到评论区指出,我会第一时间修改问题。也希望文章能解决你的疑惑。 HashMap结构图 HashMap底层数据结构:Entry数组+链表+红黑树(JDK1.8版本) Entry+链表(JDK1.7版本)...
继续阅读 »



注意以下文章可能有描述和理解上的错误,如果出现错误请到评论区指出,我会第一时间修改问题。也希望文章能解决你的疑惑。



HashMap结构图


HashMap底层数据结构:Entry数组+链表+红黑树(JDK1.8版本) Entry+链表(JDK1.7版本)
在这里插入图片描述




代码分析


常见的参数及意义


	//默认的Hash表的长度
static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // aka 16
//Hash表的最大长度
static final int MAXIMUM_CAPACITY = 1 << 30;
//默认加载因子
static final float DEFAULT_LOAD_FACTOR = 0.75f;
//当链表的长度为8的时候转化为红黑树
static final int TREEIFY_THRESHOLD = 8;
//桶中元素个数小于6的时候红黑树转换为链表
static final int UNTREEIFY_THRESHOLD = 6;
//只有当数组的长度大于等于64并且链表个数大于8才会转换为红黑树
static final int MIN_TREEIFY_CAPACITY = 64;
//Hash表
transient Node<K,V>[] table;
//遍历的时候使用返回一个K-V集合
transient Set<Map.Entry<K,V>> entrySet;
//表中K-V的个数
transient int size;
//对集合的修改次数,主要是后面出现的集合校验
transient int modCount;
//阈值当size大于threshold时就会进行resize
int threshold;
//加载因子
final float loadFactor;

源码解释


构造方法


//传入初始化容量,和指定的加载因子
public HashMap(int initialCapacity, float loadFactor) {
//参数校验
if (initialCapacity < 0)
throw new IllegalArgumentException("Illegal initial capacity: " +
initialCapacity);
//如果传入的值大于最大容量,就将最大的值赋给他
if (initialCapacity > MAXIMUM_CAPACITY)
initialCapacity = MAXIMUM_CAPACITY;
//参数校验
if (loadFactor <= 0 || Float.isNaN(loadFactor))
throw new IllegalArgumentException("Illegal load factor: " +
loadFactor);
this.loadFactor = loadFactor;
//返回的是2的整数次幂
this.threshold = tableSizeFor(initialCapacity);
}

//指定HashMap的容量
public HashMap(int initialCapacity) {
//调用如上的双参构造函数
this(initialCapacity, DEFAULT_LOAD_FACTOR);
}

//无参构造函数
public HashMap() {
//初始化加载因子为默认的加载因子
this.loadFactor = DEFAULT_LOAD_FACTOR; // all other fields defaulted
}

//构造一个映射关系与指定 Map 相同的新 HashMap。
public HashMap(Map<? extends K, ? extends V> m) {
//初始化加载因子为默认的加载因子
this.loadFactor = DEFAULT_LOAD_FACTOR;
//构造的过程函数
putMapEntries(m, false);
}

final void putMapEntries(Map<? extends K, ? extends V> m, boolean evict) {
//获取m集合中元素个数
int s = m.size();
//如果m集合元素个数是0个那么下面这些操作也就没有必要了
if (s > 0) {
if (table == null) { //表示的拷贝构造函数调用putMapEntries函数,或者是构造了HashMap但是还没有存放元素
//计算的值存在小数所以+1.0F向上取整
float ft = ((float)s / loadFactor) + 1.0F;
//将ft强制转换为整形
int t = ((ft < (float)MAXIMUM_CAPACITY) ?
(int)ft : MAXIMUM_CAPACITY);
//如果计算出来的值大于当前HashMap的阈值更新新的阈值为2次方
if (t > threshold)
threshold = tableSizeFor(t);
}
else if (s > threshold)//如果Map集合元素大于当前集合HashMap的阈值则进行扩容
resize();
//将Map集合中元素存放到当前集合中
for (Map.Entry<? extends K, ? extends V> e : m.entrySet()) {
K key = e.getKey();
V value = e.getValue();
putVal(hash(key), key, value, false, evict);
}
}
}

size函数


 //返回key-val的数量
public int size() {
return size;
}

isEmpty函数


   //当前的集合是否为null
public boolean isEmpty() {
return size == 0;
}

get具体过程函数


//根据key获取对应的val
public V get(Object key) {
Node<K,V> e;
//通过hash值,key找到目标节点再返回对应的val
return (e = getNode(hash(key), key)) == null ? null : e.value;
}

//获取key对应的节点
final Node<K,V> getNode(int hash, Object key) {
Node<K,V>[] tab; Node<K,V> first, e; int n; K k;
//如果集合为空和对应的下标数组中的值为空直接返回null
//first = tab[(n - 1) & hash]数组的长度是2n次方减1后对应位全部变为1,这样为与操作永远都会在数组下标范围内不会越界
if ((tab = table) != null && (n = tab.length) > 0 &&
(first = tab[(n - 1) & hash]) != null) {
if (first.hash == hash && // 如果第一个节点hash与对应hash相等,并且key也相等则返回当前节点
((k = first.key) == key || (key != null && key.equals(k))))
return first;
//第一个节点的下一个节点不为null
if ((e = first.next) != null) {
//判断节点是否为树形
if (first instanceof TreeNode)
//在树形结构中查找节点并返回
return ((TreeNode<K,V>)first).getTreeNode(hash, key);
do {//通过do...while结构遍历找对应key的节点
if (e.hash == hash &&
((k = e.key) == key || (key != null && key.equals(k))))
//找到节点并返回
return e;
} while ((e = e.next) != null);
}
}
//未找到对应的节点
return null;
}

containsKey函数


	//查看是否包含指定key    
public boolean containsKey(Object key) {
//通过getNode返回是否为null判断是否存在key
return getNode(hash(key), key) != null;
}

put函数


在此之前先看一下put的过程
在这里插入图片描述


//调用putVal向当前集合中存放元素并返回对应的val
public V put(K key, V value) {
return putVal(hash(key), key, value, false, true);
}

//存放对应的key-val
final V putVal(int hash, K key, V value, boolean onlyIfAbsent,
boolean evict) {
Node<K,V>[] tab; Node<K,V> p; int n, i;
//如果当前集合为null则将集合扩容并且将新的存放结构赋值给tab
if ((tab = table) == null || (n = tab.length) == 0)
n = (tab = resize()).length;
//找到key存放的链表,如果为空直接将当前节点存放链表在第一个位置
if ((p = tab[i = (n - 1) & hash]) == null)
tab[i] = newNode(hash, key, value, null);
else { //当前为链表不为null
Node<K,V> e; K k;
//表示当前链表第一个位置key已经存在,将当前节点赋值给e
if (p.hash == hash &&
((k = p.key) == key || (key != null && key.equals(k))))
e = p;
//查看当前的节点是否属于树形结构如果是则在TreeNode中查找并将赋值给e
else if (p instanceof TreeNode)
e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);
else {
for (int binCount = 0; ; ++binCount) {
//找到当前存放位置节点的最后一个节点的next并将当前要插入的节点插入
if ((e = p.next) == null) {
p.next = newNode(hash, key, value, null);
if (binCount >= TREEIFY_THRESHOLD - 1) // 链表的长度为8的时候转化为红黑树减一是因为元素从0开始
treeifyBin(tab, hash);
//跳出死循环
break;
}
//表示的是当前链表已经存在当前要插入的key,HashMap不存在重复的key
if (e.hash == hash &&
((k = e.key) == key || (key != null && key.equals(k))))
break;
//将节点后移
p = e;
}
}
if (e != null) { // 当前节点不为null将e.val存放在oldValue
V oldValue = e.value;
if (!onlyIfAbsent || oldValue == null)//不管oldValue是否为null都会发生value赋值给e.value
//当出现重复的key之后上面会将节点保存给e并未修改新的val值,在此更新
e.value = value;
//将结点向后调整到最后面
afterNodeAccess(e);
//如果为null返回null,不为null返回对应的val
return oldValue;
}
}
//++modCount对其集合操作的次数+1
++modCount;
if (++size > threshold)//如果在放入元素以后大于阈值则进行2倍扩容
resize();
afterNodeInsertion(evict);
return null;
}


resize函数


 //将集合扩容
final Node<K,V>[] resize() {
Node<K,V>[] oldTab = table;
//旧表的容量
int oldCap = (oldTab == null) ? 0 : oldTab.length;
//之前的阈值
int oldThr = threshold;
int newCap, newThr = 0;
//这里也可以说集合不为空
if (oldCap > 0) {
if (oldCap >= MAXIMUM_CAPACITY) {//如果集合现在数组的长度大于等于最大容量
threshold = Integer.MAX_VALUE;//将整型最大的值赋值给threshold
return oldTab;
}
//当前集合数组长度扩大二倍赋值给newCap小于MAXIMUM_CAPACITY
//并且集合的容量大于等于默认容量将当前阈值扩大二倍赋值给新的阈值
else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY &&
oldCap >= DEFAULT_INITIAL_CAPACITY)
newThr = oldThr << 1; // double threshold
}
//若没有经历过初始化,通过构造函数指定了initialCapcity,将当前容量设置为大于它最小的2的n次方
else if (oldThr > 0)
newCap = oldThr;
else { // 初始的时候长度和阈值都使用默认值
newCap = DEFAULT_INITIAL_CAPACITY;
newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY);
}
//重新计算threshold
if (newThr == 0) {
float ft = (float)newCap * loadFactor;
newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ?
(int)ft : Integer.MAX_VALUE);
}
//更新当前集合阈值
threshold = newThr;
//从这里开始便是将oldTab数据重新hash放入扩容后的newTab
@SuppressWarnings({"rawtypes","unchecked"})
Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap];
//将table指向的oldTab指向newTab
table = newTab;
if (oldTab != null) {
//遍历哈希表
for (int j = 0; j < oldCap; ++j) {
Node<K,V> e;
//当前链表是否为null、并且将就链表赋值给e
if ((e = oldTab[j]) != null) {
oldTab[j] = null;//将原来位置的链表置为null方便垃圾回收
if (e.next == null)//链表的长度为1直接将链表中的一个节点重新hash存放到相应的位置
newTab[e.hash & (newCap - 1)] = e;
else if (e instanceof TreeNode) //表示节点类型为树形结构
((TreeNode<K,V>)e).split(this, newTab, j, oldCap);
else { //链表是非树形结构,并且节点数量是大于1
//将链表拆分为两个子链表
Node<K,V> loHead = null, loTail = null;
Node<K,V> hiHead = null, hiTail = null;
Node<K,V> next;
do { //通过do...while遍历链表
next = e.next;
if ((e.hash & oldCap) == 0) {
if (loTail == null) //设置头节点
loHead = e;
else //设置尾结点
loTail.next = e;
loTail = e;//将尾结点变为最后一个节点
}
else {
if (hiTail == null)//同上都是设置头节点下面也一样是设置尾结点
hiHead = e;
else
hiTail.next = e;
hiTail = e;
}
} while ((e = next) != null);
if (loTail != null) {//在新表的j位置存放链表
loTail.next = null;
newTab[j] = loHead;
}
if (hiTail != null) {//在新表的j+oldCap位置存放链表
hiTail.next = null;
newTab[j + oldCap] = hiHead;
}
}
}
}
}
return newTab;
}

remove函数


 	// 移除指向key返回对应的val          
public V remove(Object key) {
Node<K,V> e;
//返回如果为空返回null否则返回e.val
return (e = removeNode(hash(key), key, null, false, true)) == null ?
null : e.value;
}

final Node<K,V> removeNode(int hash, Object key, Object value,
boolean matchValue, boolean movable) {
Node<K,V>[] tab; Node<K,V> p; int n, index;
//常规的判断表不为null,key有对应的存储位置
if ((tab = table) != null && (n = tab.length) > 0 &&
(p = tab[index = (n - 1) & hash]) != null) {
Node<K,V> node = null, e; K k; V v;
if (p.hash == hash &&
((k = p.key) == key || (key != null && key.equals(k))))
//表示的是key存储在当前链表的第一个位置
node = p;
else if ((e = p.next) != null) {//表示的是链表的长度大于1
if (p instanceof TreeNode)//判断是否是树的实列
//返回对应key在红黑树存储的位置
node = ((TreeNode<K,V>)p).getTreeNode(hash, key);
else {//当前结构为链表
do {//遍历链表
if (e.hash == hash &&
((k = e.key) == key ||
(key != null && key.equals(k)))) {//找到对应的节点保存并跳出循环
node = e;
break;
}
//将节点后移
p = e;
} while ((e = e.next) != null);
}
}
//表示要删除的key存在并且找到
if (node != null && (!matchValue || (v = node.value) == value ||
(value != null && value.equals(v)))) {
if (node instanceof TreeNode)//如果是树形在树型结构中移除当前节点
((TreeNode<K,V>)node).removeTreeNode(this, tab, movable);
else if (node == p)//表示的链表中的第一个节点
tab[index] = node.next;
else
p.next = node.next;//移除节点
++modCount;//操作+1
--size;//长度-1
afterNodeRemoval(node);
//返回节点
return node;
}
}
return null;
}

clear函数


//清除集合中的所有key-value      
public void clear() {
Node<K,V>[] tab;
//集合操作+1
modCount++;
if ((tab = table) != null && size > 0) {//表不为null才进行遍历
size = 0;
for (int i = 0; i < tab.length; ++i)//遍历集合所有元素都置为null,方便垃圾回收
tab[i] = null;
}
}

containsValue函数


 	//查看集合是否包含指定value
public boolean containsValue(Object value) {
Node<K,V>[] tab; V v;
if ((tab = table) != null && size > 0) {//表不为null
for (int i = 0; i < tab.length; ++i) {//遍历数组
for (Node<K,V> e = tab[i]; e != null; e = e.next) {//遍历链表
if ((v = e.value) == value ||
(value != null && value.equals(v)))
//存在指定的value直接返回true
return true;
}
}
}
//集合中不存在指定value返回false
return false;
}

keySet函数


	//返回key的所有集合set
public Set<K> keySet() {
Set<K> ks = keySet;
if (ks == null) {
ks = new KeySet();
keySet = ks;
}
return ks;
}

values函数


	//返回所有的value集合    
public Collection<V> values() {
Collection<V> vs = values;
if (vs == null) {
vs = new Values();
values = vs;
}
return vs;
}

entrySet函数


   // 返回所有的key-value集合
public Set<Map.Entry<K,V>> entrySet() {
Set<Map.Entry<K,V>> es;
return (es = entrySet) == null ? (entrySet = new EntrySet()) : es;
}

面试常见的问题



  1. 为什么HashMap默认的长度为2的整数次幂?



    就是因为获取索引h&(length-1)可以保证散列的均匀,避免不必要的hash冲突。



  2. 为什么加载因子是0.75?大了会怎么样?小了会怎么样?



    首先加载因子是表示hash表的填满程度,当为0.75的时候是在对提高空间利用率和减少查询成本的折中,当大于0.75的时候填满的元素越多,空间利用率越高,但是冲突的概率变大;当小于0.75的时候填满的元素越少,空间利用率越低,但是冲突的概率变小。



  3. 什么是哈希冲突?如何解决?



    哈希冲突是指hash出来的地址被其他元素所占用;
    解决的方法
    1.链地址法
    解决的思路就是当出现冲突的时候将冲突的元素加入当前的链表之中
    在这里插入图片描述
    2.开放地址法
    开放地址法也称之为再散列。
    思路:如果映射的地址被占用了,在哈希函数值的基础上加上指定数值,这样就可以把冲突的地址给错开,然后重新开辟新的地址用来存储。根据增量值的不同,分为线性探测再散列和二次探测再散列
    在这里插入图片描述
    3.再哈希法
    这种方法就是构造多个不同的哈希函数,当哈希地址Hi=RH1(Key)发生冲突时,再计算Hi=RH2(Key)…直到哈希不冲突,这样的方法增加了计算的时间。
    4.建立公共溢区
    就是哈希表分成了两个表:一个是基础表,另外一个则是溢出表,凡是与基础表发生冲突的数据都会被添加到溢出表。



  4. 什么是扰动函数?怎么设计的?为什么这个设计?



    扰动函数是hash函数拿到k的hashcode值,这个值是一个32位的int,让高16位与低16位进行异或。
    理论上来说字符串的hashCode是一个int类型值,那可以直接作为数组下标了,且不会出现碰撞。但是这个hashCode的取值范围是[-2147483648, 2147483647],有将近40亿的长度,谁也不能把数组初始化的这么大,内存也是放不下的。
    混合原始哈希码的高位和低位,以此来加大低位的随机性,这样设计在一定的程度上减少了hash碰撞,优化了散列的效果 。



  5. JDK1.8在对HashMap较1.7有什么优化?



    1.首先是最重要的就是底层的数据结构,1.7的时候底层数据结构是数组+链表;而在1.8的时候变成了数组+链表+红黑树
    2.在哈希上1.7扰动四次,1.8做了一次扰动,可以提高效率
    3.1.7在进行resize扩容的时候是重新哈希,1.8的时候采用的是索引位置不变或者就是就哈希表的容量+当前索引。
    4.1.7采用插入方式是头插法,1.8采用的是尾插法。



  6. 为什么1.8扩容不用重新哈希?
    在这里插入图片描述


  7. HashMap线程安全吗?为什么不安全?怎么解决不安全?



    首先HashMap是线程不安全的。JDK1.7的时候采用头插法,多线程同时插入的时候,A线程在插入节点B,B线程也在插入,遇到容量不够开始扩容,重新hash,放置元素,采用头插法,后遍历到的B节点放入了头部,这样形成了环。JDK1.8采用尾插法,会造成两种情况两个线程同时插入只有一个成功插入,还有就是可能会造成两次resize(++size > threshold) 。解决的方案:一、使用HashTable效率比较差。二、使用ConcurrentHashMap比较常用的。三、使用Collections.synchronizedMap() 以上三种线程安全。



  8. HashMap内部节点是有序的吗?



    不是有序的。有序的Map集合有LinkedHashMap、TreeMap



  9. HashMap一般采用什么作为key?



    HashMap一般采用String、Integer 等类作为key、因为这些类底层已经重写了hashcode、equals方法,用的是final修饰类在多线程情况下相对安全。



  10. 为什么重写equals还要重写hashcode?



    比如HashMap中不允许存在相同的key,当重写了equals方法没有重写hashcode方法,当两个对象中的值相同,但是他们hashcode不同会造成比如
    class newInstance1 = new class(1);
    class newInstabce2 = new class(2);
    以上的比较对象的时候hashcode不同,equal方法比较返回false;但是重写Hashcode后,可以达到返回true。





如果看完觉得得到帮助就留下你的一键三连,谢谢 注意如果有错误的地方评论区提出来我立即更正谢谢大佬的指正。


收起阅读 »

自学编程的人,90%以上都会掉进这些坑,避开这些误区能提高N倍学习效率

前言 几乎每一个程序员都会走上那么一段自学的道路,尤其是在校生或进入工作岗位之后,技术的提升基本都靠自学,有的虽然是网上报班学习,但更多时候还是自己在学习,师傅引进门,修行靠个人。 有的人自学很快,几乎一个多月就能掌握一门技术,而有的人苦苦坚持,最后还是半...
继续阅读 »


前言


几乎每一个程序员都会走上那么一段自学的道路,尤其是在校生或进入工作岗位之后,技术的提升基本都靠自学,有的虽然是网上报班学习,但更多时候还是自己在学习,师傅引进门,修行靠个人。


有的人自学很快,几乎一个多月就能掌握一门技术,而有的人苦苦坚持,最后还是半途而废,很大的原因就在于在学习的时候掉进了一些误区没能走出来。


今天我们就来讲讲自学编程常见的十大误区,避开这些误区我们定能在自学之路上一往无前!


呕心沥血所写8000字文章,希望对你们有所帮助。
在这里插入图片描述


误区一:不重基础,什么火我就学什么


我们经常碰到一些爱学习的小伙伴,他们热衷于学习各种潮流技术,而且是跳着过去学的,因为基础知识往往是比较枯燥无味且成就感比较低的,于是就跳跃式性学习,什么技术火就去学习什么技术。


比如你的java se基础不牢,比如说你连最基本的oop、网络操作系统、基本的数据结构和算法,还有常用的设计模式,最基本的多线程高并发这些概念都没有搞懂,那么你就一味的去追求这些所谓的火的、时髦的技术,你可能会陷入一个迷茫。


建议:我们不反对学习新技术,但在学习新技术之前,应该先把基础知识牢牢掌握,切勿心急吃热豆腐最后烫嘴,初学编程的小伙伴儿一定要扎扎实实、老老实实地把基础知识弄懂。
Python建议掌握的计算机基础


误区二:总纠结于学最好的编程语言


编程语言本身没有好与坏之分,只有什么语言适合什么样的应用场景。


我举几个例子,比如说PHP这个语言,它比较适合做外部开发,java它适合做安卓、大数据,或者是我们的java EE,C和C++它比较适合做底层开发,比如说像游戏引擎、系统软件,你再比如说汇编语言适合做驱动开发,比如python它比较适合做人工智能,go语言它是区块链的主力开发语言,适合做也可以适合做外部后台等等。


所以说从上面我所讲的,你有没有发现就没有最好的编程语言这种说法。


那么你究竟学什么样的编程语言,主要是要依据你学习的目标和兴趣。你学完这个编程语言你想干什么,然后你再决定我学什么编程语言,用倒推法来看问题你就会发现你的出发点是否正确,同一个目标,路可以有很多条,但如果你一来就开始选定出发点(编程语言),你可以能就错过了一条更省时省力的路线。
在这里插入图片描述


忠告大家两点:


第一点,编程语言它从逻辑语法上其实都是非常相似的。你比如说java、C、C++或者其他编程语言,其实逻辑语法和结构其实都大同小异。你只要学会了或者精通了一门语言,你再去学别的编程语言,可以这么说,触类旁通,比较轻松,而且学习成本会大大降低,但前提是你要先学精通一门。


第二点,如果你学编程就是为了进入到IT行业或者进入到互联网,就是为了找一份工作。而你们自己目前并不知道学什么语言,如果是这种诉求的话,我建议可以考虑Python,原因特别简单,一是Python容易上手,很多人自学的时候因为入门困难就半途而废了,别想那么多,先把你自己想做的东西用编程思维呈现出来;二是Python的发展趋势很迅猛,已经连续四年在所有编程语言中增长率第一,成为最受欢迎的编程语言,未来很长,我们要有前瞻性地进行学习。


误区三:喜欢看不喜欢动手,听懂了但不会用


喜欢看但不喜欢动手,这几乎是绝大多数初学者的通病,我依稀记得我初学编程的时候也是这样,学着学着也学了蛮久的,可一上手代码就不知所措,感觉很难驾驭。


听懂和能使用是两码事,初学者看书或者听视频,他很容易感觉这个老师讲的我听懂了。但是一旦独立让他去做一个项目或者去完成一道题,他立马就没有思路了,马上蒙圈,结果都不明白了,我不知道大家有没有这种感受。


有的同学就说“老师我在学的时候我就不知道写什么”,那么我可以建议大家,你就把你看的书或者是教程什么的,你把看过的项目案例给我敲一遍并且理解了,然后你根据你想做什么项目,实现一个什么功能,再具体地去写相应的代码。


我举个例子,比如你想去这个健身,练一身迷人的肌肉或腹肌,我问大家一个问题,**如果你只是看教练健身的视频,你能否长出健壮的肌肉?**其实你是长不出来的,你光看怎么可能长肌肉呢?你必须要自己去天天这个举哑铃或者是运动,各种运动按照教练的要求,对不对?你的饮食上还要注意,才能长出迷人的肌肉。


其实我们学编程也是一样的道理,你光看视频是不行的,你听懂了并不代表你会用。
在这里插入图片描述


忠告:


编程它是一门做中学的学科,什么叫做中学?是在做的过程中学会的,而不是说我已经知道了我理解了我再去做,因为我们的计算机学科它是一门工科性质的,特别强调是动手能力。过程出错不要紧,多做几遍,多调试几遍,再不懂就去查资料或者找人问问,一点点地融会贯通。


纸上得来终觉浅,绝知此事要躬行。出现错误不可怕,出现错误就是你提高的关键点了。


误区四:学习时很少做笔记或思维导图


这基本等于说没有将学到的知识转成自己的知识。很多自学者都出现这种情况,学编程时非常努力和勤奋,但是技术提升其实很慢。你让他说今天学了什么东西?他一脸茫然,他只知道我好像看了一些书、看一些视频。
在这里插入图片描述
那么为什么会出现这个情况?我给大家分析一下。因为有些小伙伴儿他在学技术的时候只是听,知识就像流水一样,从书本或者视频流出来,然后知识并没有沉淀在他的大脑,整个人就变成了一个知识的一个传输器。


因此当把这个书本一合上,就跟没有学过这个一样,毫无印象,全部忘了这个我们把它称之为无效学习


学知识不管你是听视频还是看书,一定要明白一个道理,这些知识不是你的,是作者的,那么你应该怎么办呢?你最好是学完一个知识或者学完一个技术以后,你要用自己的语言把它总结下来,用自己的语言描述一下你是怎么理解这个技术的,这样你才能真正地把这个知识点拿下来,甚至最好能够学完一个知识体系的。


比如说把java的面向对象学完了,或者把java的多线程学完了,你最好画一个思维导图,把这些知识点精华浓缩一下,把这个知识体系建立在你的大脑里面。


自己总结和建立知识体系的方法,你学一年,甚至比别人学两年、三年效果都好。
在这里插入图片描述


误区五:喜欢死记硬背而不是理解原理


我们在学编程的时候,的确有很多东西是需要死记硬背的,比如说语法规则和规范,比如说像java变量的命名,还有这个程序的主体结构,包括它语法的一些规范,怎么用才是一个高效的用法,而这些呢你没有办法,你只能把它背一背,因为是规则,这是规定好的。


但是涉及到功能的实现、算法、设计模式、底层机制、优化效率等等,你就不要死记硬背了,一定要去理解了。


还有一点就是不要去纠结编程的时候我记不住代码,小伙伴们只需要掌握某一个功能,用什么、用怎样一个方式或者使用代码去实现就可以了,你要知道在哪儿去找这段代码就行。
在这里插入图片描述


误区六:出错时选择逃避


程序出错了,没有积极的去调错,而是逃避,这个现象我相信很多小伙伴,尤其是初学者都遇到过,新手写代码的时候只要看到报错信念就发慌了。


其实告诉大家,大可不必,因为程序一旦出错了,正是我们提高自己技术的时候。你想一想,对一个初学者他怎么可能写代码一行都不出错呢?这是不可能的,对吧?你比如说一些基本语法出错了,或者是字母大小写写错了,这是很容易出现的。


其实这些错误它本身并不难,你只要把每一个错误都排除了,其实这个时候你的能力就越来越强。正是因为这些错误你看得多了,你下次就不会犯,慢慢你就感觉到编程其实挺快乐的,以后你就会达到这样一个水平。累了困了不是喝红牛,而是写两段代码放松放松,达到这个水平就很好了。
在这里插入图片描述
借用电影《头文字D》里面的一句话“神其实也是人,只是他做了人做不到的事情,所以成为了神。”


那么什么是编程大神、调试大神?就是因为他们犯了足够多的错误,什么地方会犯错,什么错误他都见过了,别人看起来是错误的东西,在他手里就不会出现,或者出现了解决起来也是轻而易举,这就是大神了。


你如果犯了一万个错误,你也会成为编程大神。


误区七:孤军奋战,闭门造车


在程序员这条路上总有那么一些人喜欢孤军奋战、闭门造车,不愿意,也不敢分享。包括有些已经学过一两年甚至更久的人都会出现这个问题。


在学习编程的道路上,你一定要给自己营造一个学习的氛围,你需要同伴或者是高手跟你一同成长。反之,如果你脱离了交流,往往会让学习的问题越积越多,最后你可能就放弃了。


因为问题太多了嘛,你又没解决,那肯定慢慢就放弃了,孤军奋战很容易让新手成为井底之蛙。在迷茫的时候,大家知道有时候一个朋友或者一个高手的一句话、一个插件、一本书或者一个提示,它就会让你有一种豁然开朗的感觉。你会说“诶原来还有这样的一种操作”,那么这就可能让你的学习效率大大提升。
在这里插入图片描述
忠告


初学编程的小友千万不要孤军奋战、闭门造车,要敢于分享,敢于去总结,敢于把自己所学到的东西给别人说出来,说错了又能咋滴?人家又不会顺着网线来打你;说错了别人会不会笑我?其实你只要是第一次犯,别人不会笑话,如果你提出来,别人反而会觉得你很勤奋,反而更愿意帮助你,你下次不要犯就好了。


误区八:学的很杂,不精通一门语言


很多小友在网上去搜这个资料,什么技术火,我就学什么技术,不分重点,也没有目标,很容易迷失自己,什么都想学,什么都没学精通,天天疲于奔命学各种技术,最后整个知识体系没有建立起来。


比如有些小友学java EE,但javaEE的整个体系没有建立起来;比如有些小友学大数据,整个体系也没有建立出来,它只是学了其中某一小块。如果这样的话,你会发现你在真正的工作中,当别人问你精通什么的时候,你答不上来。


那自然你的薪资肯定上不去,因为你没有没有真正能够吃饭的家伙,没有真正能拿得出手的东西,没有什么东西可以去跟别人竞争,所以说西瓜、芝麻什么都捡,肯定是要吃亏的。
在这里插入图片描述


忠告


不管你是聪明还是迟钝,不管你是勤奋还是懒惰,每个人的时间其实都是有限的,好钢要用在刀刃上,把自己有限的时间高效地利用起来,千万不要什么都去学,没有必要。


我建议小友们专注于一门技术或者语言,比如说我们就专注于Java或者专注于Python,那都无所谓,你就专注于这一门语言,你精通这一门语言以后,你再去学别的编程语言或者别的技术,你会发现一马平川,学习成本大大降低,触类旁通,学期会会非常的快。


学习编程技术的时候应该有一个明确的方向和目标。不管你是学java、Python、PHP、.net还是区块链,你要有一个学习目标。


比如说如果是为了工作,那么我2个月内要学完什么内容,半年后学到什么水平,一年后我要开始找工作,我希望我的薪资是多少,一年到两年后我要达到什么技术水平,三年后我的薪资要达到几万…给自己制定一个清晰的规划,不要自己给自己打马虎眼,你才会看清自己的成长。如果你自己无法制定,那么可以找一些人帮你参考,这都可以。


误区九:专业不对口,不适合编程?


这个误区其实我也经常遇到过,很多小友说:“龙叔,我以前是学管理的、学金融的、学建筑的、学化学的,我以后找工作是不是会吃亏呀?或者说我是不是就学不好编程了?”


我告诉大家,IT行业里面的程序员是非科班出身的人太多太多,各个行业的都有,太多都转行了,而且做得很成功,所以说这跟学专业也没有关系,为什么呢?


编程本身其实就是一个技能,跟你以前的专业有什么关系呢?没关系,你只要你的逻辑思维正常,然后你比较勤奋,那这个学编程就没问题,就是学一个技能而已,别想得太复杂。
在这里插入图片描述


而且我认为有些时候你跨专业进入到这个程序员这个圈,在某些时候还是有优势的。为什么这么说?


举个例子,公司给了你一个任务,让你去做一个项目是关于财务的一个项目,如果你以前是金融相关专业的,那你理解这个项目的业务逻辑和业务流程肯定要比以前没有学过金融的要快。这就是为什么像用友这样的软件公司每一年都会在什么财经大学里面招一帮学生去做程序员,为什么?做业务逻辑的。


所以我们写软件或者做项目不单是技术本身,还有业务逻辑、业务流程在里边,所以不用担心这个事儿。如果你确实还担心,那怎么办?也很简单,你大不了就把大学计算机专业的课本内容学一遍嘛,这有什么大不了的,它是ok的。


误区十:数学不好,不适合编程?


很多小伙伴没有搞清楚数学和编程之间的关系,他们往往把数学和编程化等号,他们认为我数学好,我编程就学得好,我数学不好那么我编程就学不好。


如果真的是这样子的话,那我们大学里面就不需要再分两个专业了,一个是数学专业,一个是计算机专业,对吧?数学专业和计算机专业是分开的,这说明这两个学科它肯定是不一样的。


那么为什么会造成这样一个认识?因为有些小伙伴认为我们在处理这个业务逻辑的时候,可能会去用到数学。这个是不假的,可能会用到一些关于数学的公式、数学的推断,这些可能会用到,但是对于我们绝大部分的程序员来讲,我们是站在应用层面来编程的,换言之,我们是用别人已经学好的一个算法,然后应用到我们的一个业务模块里面去解决这个问题。我们很少让一个程序员,尤其是应用层面的程序员去自己独立开发一个算法、解决一个问题。


当然话也说回来了,假如你从事的这个岗位是算法工程师或者是高级数据分析师,那么对数学会要求高一些,往往要求这个人既懂计算机又是数学专业的。但对我们绝大部分的程序员来说,数学要求其实没有那么高,所以大家不要去恐惧这个事情。
在这里插入图片描述


在这里插入图片描述
文章到这里就结束了,感谢你的阅读,只是有些话想对读者们说说。


我退休后一直在学习如何写文章,说实在的,每次在后台看到一些读者的回应都觉得很欣慰,对于自媒体我是个刚入门的人,还是个迟钝的大叔…为了感谢读者们,我想把我收藏的一些编程干货贡献给大家,回馈每一个读者,希望能帮到你们。


干货主要有:


 2000多本Python电子书(主流和经典的书籍应该都有了)


 Python标准库资料(最全中文版)


 项目源码(四五十个有趣且经典的练手项目及源码)


 Python基础入门、爬虫、web开发、大数据分析方面的视频(适合小白学习)


⑤Python学习路线图(可以弄清楚Python的所有方向和技术)


*如果你用得到的话可以直接拿走,在我的QQ技术交流群里(纯技术交流和资源共享,广告勿入)可以自助拿走,群号是980758007。*
在这里插入图片描述

收起阅读 »

Tomcat源码学习第4篇-Servlet请求分析

前段时间家里有事忙,停更了好长一段时间,这里跟等待更新的小伙伴们说一声抱歉,没能提前说明一下,让小伙伴们等了这么久,真的不好意思! 前面说完了Tomcat的初始化和启动步骤,那么接下来就要进入重头戏了!在本篇文章中,我会跟前面一样,通过图文的方式来带着小...
继续阅读 »



前段时间家里有事忙,停更了好长一段时间,这里跟等待更新的小伙伴们说一声抱歉,没能提前说明一下,让小伙伴们等了这么久,真的不好意思!



前面说完了Tomcat的初始化和启动步骤,那么接下来就要进入重头戏了!在本篇文章中,我会跟前面一样,通过图文的方式来带着小伙伴们了解一个 Servlet是如何被tomcat处理的,具体的处理链路都有哪些。


一、请求分析


在《Tomcat源码学习第2篇》中备注了各个组件的说明。


当一个servlet请求到来的时候,首先经过的是connector组件,它是用来接收请求的。


该组件接收到请求之后,会把相关请求进行封装,然后传递到engine组件中。


紧跟着,engine组件会锁定对应的hostcontext以及wrapper,一层层的传递下去,找到最终处理请求的servlet实例。


请求链路


二、深入探索


不知道大家还有没有印象,在前面的文章中,我们在NioEndpoint类中,启动Accepter线程的入口处上方还有着一个线程组在启动运行,然而却没有讲解该线程是用来干嘛的~


NioEndpoint.startInternal()


NioEndpoint.startInternal()


点击跳转到该类过来,我们可以看到他实现了Runnable接口,那么我们直接查看他的run()方法,看看它的运行逻辑。


Poller.run()


Poller


通过注释我们可以知道,该线程主要用于轮询已连接的套接字,检查是否触发了事件,并在事件发生时将关联的套接字移交给对应的处理器。在源码中我们可以看到keyCount变量记录着待处理请求数,提供给后面做相应判断。


Poller.run()


继续往下走,通过keyCount判断是否有请求需要进行处理,需要的话则通过selector.selectedKeys()拿到需要被处理的channel集合,进行循环处理。在while循环中我们看到,所有就绪的通道都调用的是processKey(sk, socketWrapper)方法进行处理。


image-20210503200131828


点击跳转过来该方法,在这里可以看到他对该sk做了读写判断,既然是请求进来,那肯定是做读操作,我们先进读相关的方法看一下。


NioEndpoint.processKey()


NioEndpoint.processKey()


进来之后我们可以看到它首先在缓存池中尝试去获取一个处理线程,当缓存池中没有线程时,就创建一个新的线程,如果有的话就直接使用。


AbstractEndpoint.processSocket()


AbstractEndpoint.processSocket()


既然是线程了,那么我们就关心线程的核心方法即可。点击SocketProcessorBase跳转查看run()方法。


SocketProcessorBase.run()


SocketProcessorBase.run()


doRun()处打上断点,单击下一步,跳转到NioEndpoint.doRun()方法中。Poller线程移交到这边的线程进行处理,在该线程中需要得到当前的socket,做进一步的处理。


NioEndpoint.doRun()


image-20210503212817648


进入该方法之后,我们可以看到它首先对wrapper进行判断,不为空再取出socket,然后尝试着在connections中去获取对应的processor,如果获取不到,再尝试获取已经处理过连接,但是尚未销毁的processor中去获取,还获取不到才进行创建。这样可以避免频繁的创建和销毁对象。


AbstractProtocol.process()


AbstractProtocol.process()


AbstractProtocol.process()


得到processor之后,调用process方法对报文进行解析。


AbstractProtocol.process()


进入该方法之后,我们可以看到这里面是对socketEvent的状态进行判断,我们当前请求主要是读状态,在此处打上断点,跳到该方法进来看一下。


AbstractProcessorLight.process()


AbstractProcessorLight.process()


这里我们可以看到是进入到了 http11类中,在该类里面对报文进行解析,封装原生的requestresponse对象。这里的response因为我们还没有到返回的步骤,所以只是做个初步的参数设置。后续要传入Adapter进行下一步操作。


Http11Processor.service()


Http11Processor.service()


Http11Processor.service()


Http11Processor.service()


在这里对原生的requestresponse进行转换,得到HttpServletRequestHttpServletResponse。然后根据请求信息找到能够处理当前请求的hostcontextwrapper


CoyoteAdapter.service()


CoyoteAdapter.service()


在这方法可以看到它会通过getMapper()方法去匹配能够处理当前请求的 host,context,wrapper。到这里可能有的小伙伴会奇怪,为什么是从mapper中去匹配呢?这个问题留给你们去探索一下,等下篇再给你们解答。


CoyoteAdapter.postParseRequest()


CoyoteAdapter.postParseRequest()


上一方法中,通过connector获取service之后再取得对应的mapper,可是进来之后却没有看到对该mapper对象的构建,那该对象是哪里来的呢?


Mapper.map()


Mapper.map()


不知道大家还记不记得在第二篇中,在StandardService类中initInternal()startInternal()方法中有mapperListener方法的初始化和启动。


StandardService.initInternal()


StandardService.startInternal()


在该方法中查找到对应的host, context, wrapper


Mapper.internalMap()


Mapper.internalMap()


Mapper.internalMap()


回到CoyoteAdapter.postParseRequest(),通过Evaluste我们可以看到当前请求对应的host, context, wrapper以及实例的映射均已找到。


CoyoteAdapter.postParseRequest()


接下来要做的就是根据链路组件进行一级级的调用,直至最后取出servlet执行。


CoyoteAdapter.service()


CoyoteAdapter.service()


先得到host,在通过host继续调用下一级组件


StandardEngineValve.invoke()


StandardEngineValve.invoke()


AbstractAccessLogValve.invoke()


AbstractAccessLogValve.invoke()


ErrorReportValve.invoke()


ErrorReportValve.invoke()


这里拿到context,继续invoke()


StandardHostValve.invoke()


StandardHostValve.invoke()


AuthenticatorBase.invoke()


AuthenticatorBase.invoke()


StandardContextValve.invoke()


StandardContextValve.invoke()


拿到wrapper之后,继续向下执行,从wrapper容器中得到servlet对象。


StandardWrapperValve.invoke()


StandardWrapperValve.invoke()


紧接着,把得到的servlet加入过滤器链中(可能有其它的处理,这里不直接进行处理),留待下面调用过滤器链再统一进行处理。


StandardWrapperValve.invoke()


StandardWrapperValve.invoke()


ApplicationFilterChain.doFilter()


ApplicationFilterChain.doFilter()


终于找到具体的实例了,太不容易了!!!


ApplicationFilterChain.internalDoFilter()


ApplicationFilterChain.internalDoFilter()


三、总结


Servlet请求链路



我收集有众多的 计算机电子书籍,有需要的小伙伴自提哦~


收起阅读 »

iOS 类簇(class clusters)

类簇(class clusters)类簇是Foundation framework框架下广泛使用的一种设计模式。它管理了一组隐藏在公共抽象父类下的具体私有子类。没有使用类簇(Simple Concept but Complex Interface)为了说明类簇...
继续阅读 »

类簇(class clusters)

类簇是Foundation framework框架下广泛使用的一种设计模式。它管理了一组隐藏在公共抽象父类下的具体私有子类。

没有使用类簇(Simple Concept but Complex Interface)

为了说明类簇的结构体系和好处,我们先思考一个问题:如何构建一个类的结构体系用它来定义一个对象存储不同数据类型的数字(char,intfloatdouble)。因为不同数据类型的数字有很多共同点(例如:它们都能从一种类型转换成另一种类型,都能用字符串表示),所以可以用一个类来表示它们。然而,不同的数据类型的数字的存储空间是不同的,所以用一个类来表示它们是很低效的。考虑到这个问题,我们设计了如下图1-1的结构解决这个问题。


Number是一个抽象父类,在其方法声明中声明了子类的共有操作。但是,Number不会声明一个实例变量存储不同类型的数据,而是由其子类创建对应类型的实例变量并将调用接口共享给抽象父类Number到目前为止,这个类结构的设计十分简单。然而,如果C语言的基本数据类型被修改了(例如:加入了些新的数据类型),那么我们Number类结构如下图1-2所示:


这种创建一个类保存一种类型数据的概念很容易扩展成十几个类。类簇的体系结构展示了一种概念简洁性的设计。

使用类簇(Simple Concept and Simple Interface)

使用类簇的设计模式来解决这个问题,类结构设计如图1-3所示:


使用类簇我们只能看到一个公共父类Number,它是如何创建正确子类的实例的呢?解决方式是利用抽象父类来处理实例化。

创建实例(Creating Instances)

在类簇中的抽象父类必须声明创建私有子类变量的方法。抽象父类的主要职责是当调用创建实例对象的方法时,根据调用的方法去分配合适的子类对象(不能选择创建实例对象的类)。

在Foundation framework中,你可能调用类方法或者allocinit创建对象。以Foundation framework的NSNumber创建数字对象为例:

NSNumber *aChar = [NSNumber numberWithChar:’a’];
NSNumber *anInt = [NSNumber numberWithInt:1];
NSNumber *aFloat = [NSNumber numberWithFloat:1.0];
NSNumber *aDouble = [NSNumber numberWithDouble:1.0];

使用上面方法返回的对象aCharanIntaFloat,  aDouble是由不同的私有字类创建的。尽管每个对象的从属关系(class membership)被隐藏了,但是它的接口是公开的,能够通过抽象父类NSNumber声明的接口来访问。当然这种做法是及其不严谨的,某种意义上是不正确的,因为用NSNumber方法创建的对象并不是一个NSNumber的对象,而是返回了一个被隐藏了的私有子类的对象。但是我们可以很方便的使用抽象类NSNumber接口中声明的方法来实例化对象和操作它们。

拥有多个公共抽象父类的类簇(Class Clusters with Multiple Public Superclasses)

在上面的例子中,使用一个公共抽象父类声明多个私有子类的接口。但是在Foundation framework框架中也有很多使用两个或两个以上的公共抽象父类声明私有子类接口的例子,如表1-1所示:


还存在这种类型的类簇,但这些清楚说明了两个公共抽象父类是如何协同工作来声明类簇的编程接口的。一个公共抽象父类声明了所有类簇对象都能相应的方法,而另一个公共抽象父类声明的方法只适合允许修改内容的类簇对象。

创建子类(Creating Subclasses Within a Class Cluster)

类蔟的体系结构是在易用性和可扩展性之间均衡的结果:类簇的应用使得学习和使用框架中的类十分简单,但是在类簇中创建子类是困难的。但是很少情况下需要在类簇中创建子类,因为类簇的好处是显而易见的。

如果你发现类簇提供的功能不能满足你的变成需要,那么在类簇创建子类是一种选择。例如:假如你想在NSArray的类簇中创建一个基于文件存储而不是基于内存存储的数组。因为改变了类的底层存储机制,就不得不在类簇中创建子类。

另一方面,在某些情况下我们创建一个类内嵌类簇对象就足够了。例如:如果你的程序需要被提醒,当某些数据没被修改的时候。在这种情况下,创建一个包装Foundation framework框架定义的数据对象的类可能是最好的方法。这个类的对象能干预修改数据的消息,拦截这个消息,对这个消息采取相应的行动,然后重定向给内嵌的数据对象。

综上所述,如果你想管理对象的存储空间,就在类簇中创建子类。否则,创建一个复合对象(composite object),复合对象:你自己设计的类对象内嵌一个标准Foundation framework框架的对象。

真正子类(A True Subclass)

在类簇中创建一个子类,你必须:

  • 创建类簇中抽象超类的子类
  • 声明自己的存储空间
  • 重写父类的所有初始化方法
  • 重写父类的所有原始方法(primitive methods)

第一点:因为在类簇的体系结构中只有类簇中的抽象父类是公开可见的节点。第二点:子类会继承类簇的接口但没有实例变量,因为抽象父类没有声明,所以子类必须声明它所需要的任意实例变量。最后:子类必须重写继承的所有方法。

一个类的原始方法(primitive methods)是构成其接口的基础。NSArray为例,它声明类管理数组对象的接口。在概念上,一个数据保存了很多数据项,它们都能通过下标(index)访问。NSArray通过这两个原始方法表达了这一抽象概念,countobjectAtIndex:,以这些方法为基础可以实现其它派生方法。


原始方法(primitive methods)和派生方法(derived methods)的接口区分使创建子类更简单。子类必须重写所有继承的原始方法(primitive methods),这样做可以确保所有继承的派生方法(derived methods)都能正常运行。

原始和派生的区别同样适用于完全初始化对象接口。子类中需要解决如何处理init…方法的问题。

通常,一个类簇的抽象父类方法声明了一系列init…方法和+ className类方法。基于你选择的init…方法或+ className类方法,抽象类决定用哪个具体的子类来实例化。你可以认为抽象类是为子类服务的,因为抽象类没有实例变量,它也不需要初始化方法。

自定义的子类应该声明自己的init…+ className方法,不应该依赖继承的方法。为了保持初始化链,它应该在自己的指定初始化函数里调用父类的指定初始化函数(designated initializers)。在类簇中它也应该以合理方式重写继承的所有初始化方法,抽象父类的指定初始化函数总是init

复合对象(A Composite Object)

在你自定义的对象中内嵌一个私有的类簇对象称为复合对象。复合对象可以利用类簇对象来实现基本的功能,只拦截复合对象想要特殊处理的消息。这种结构减少了代码量,利用了Foundation framework的测试代码。如图1-4所示:


复合对象必须声明它自己是类簇抽象父类的子类,必须重写父类的所有原始方法,也可以重写派生方法但不是必须的。

总结

在Cocoa中,实际上许多类都是以类簇的方式实现的,即它们是一群隐藏在通用接口之下与实现相关的类。例如创建数组时可能是__NSArray0,__NSSingleObjectArray__NSArrayI,所以请不要轻易尝试创建NSStringNSArray,NSDictionary的子类。对类簇使用isKindOfClassisMemberOfClass的结果可能是不正确的。因为类簇是由公共抽象类管理的一组私有类,公共抽象类并不是实例对应的真正的类,类簇中真正的类的从属关系被隐藏了。


转自链接:https://www.jianshu.com/p/86ef3ca9810d

收起阅读 »

iOS -开发SDK的技巧

本文目标:掌握封装及开发SDK的全部技巧内容提要:不同场景下如何封装及开发SDK.a静态库创建直接创建Framework库在已有工程中创建创建Framework工程进行封装创建Bundle资源库文件含界面SDK如何进行依赖开发使用脚本创建Framework库,...
继续阅读 »

本文目标:掌握封装及开发SDK的全部技巧

内容提要:不同场景下如何封装及开发SDK

  • .a静态库创建
  • 直接创建Framework库
  • 在已有工程中创建
  • 创建Framework工程进行封装
  • 创建Bundle资源库文件
  • 含界面SDK如何进行依赖开发
  • 使用脚本创建Framework库,解决合并的烦恼
  • Swift 如何创建Framework库

知识准备

  • 终端命令
真机和模拟器上的库文件合并 
Framework库合并的是Framework内包含的二进制文件,合并后替换库中的文件,没有.a后缀
lipo -create xxx.a(真机) xxx.a(模拟器) -output 新名字.a
查看SDK支持的架构
lipo -info XXX.a 输出: i386 armv7 x86_64 arm64
arm7: 在最老的支持iOS7的设备上使用
arm7s: 在iPhone5和5C上使用
arm64: 运行于iPhone5S的64位 ARM 处理器 上
i386: 32位模拟器上使用
x86_64: 64为模拟器上使用
注意: 高位兼容地位(32位兼容16位),arm7版本可以在arm7s上运行
需要在对应架构设备上运行,才能生成对应架构的包
  • category的处理
category是项目开发中经常用到的,把category打包成静态库是没有问题的,但是在使用这个静态库时,
调用category中的方法时会发生找不到该方法的运行时错误(selector not recognized),
解决的办法是在使用静态库的工程中配置other linker flags的值为 -ObjC -all_load
  • 对图片资源和UI界面xib或nib文件的处理
.a和.framework两种静态库,通常都是把需要用的到图片或者xib文件存放在一个bundle文件中,而该bundle文件的名字和.a或.framework的名字相同。
.a文件中无法存放图片或xib文件,很容易理解,但是.framework从本质上说也是一个bundle文件,为什么不把图片或者xib文件直接放在.framework中而单独再创建个bundle文件呢?
那是因为iOS系统不会去扫描.framework下的图片等资源文件,也不会在项目中显示,也就是说即使放在 .framework目录下,系统根本就不会去扫描,因此也无法发现使用
  • Debug和Release
Debug和Release,在我看来主要是针对其面向的目标不同的而进行区分的。
Debug通常称为调试版本,通过一系列编译选项的配合,编译的结果通常包含调试信息,而且不做任何优化,以为开发人员提供强大的应用程序调试能力。
Release通常称为发布版本,是为用户使用的,一般客户不允许在发布版本上进行调试。所以不保存调试信息,同时,它往往进行了各种优化,以期达到代码最小和速度最优。为用户的使用提供便利

开发指南

网上找了一个动画工程,作为我们开刀的对象
下载原始工程
如果你有耐性,可以和我一起走完整个流程。当然每个模块都是独立的,你可以进行针对性的阅读

一、.a静态库创建

  • 创建静态库工程 >> 删除自动创建的.m文件 >> 清空头文件里的信息 >> 导入你要封装的系统库文件




  • 点击目标工程 >> Build Phases >> Editor >> add build Phases(是否公开头文件选项) >> 设置公开访问的头文件(或在Target Membership中直接设置)

    目标工程 > Build Phases > 点击左侧加号 > add build Phases(是否公开头文件选项) > 设置公开访问的头文件(或在Target Membership中直接设置)







  • 在设备 和 模拟器 下分别按下command + B进行编译 >> 查看Product目录 >> Show in Finder 查看编译成功的静态库
  • debug模式下运行生成 Debug-iphoneos 和 Debug-iphonesimulator两个文件夹
  • release模式下运行生成 Release-iphoneos 和 Release-iphonesimulator文件夹


    • 合并Debug模式下的真机和模拟器下的静态库文件
    使用终端进行合并
    cd 文件保存目录
    lipo -create 模拟器.a(路径) 真机.a(路径) -output 重命名.a
    查看架构模式
    lipo -info XXX.a 查看是否满足运行要求
    • 使用.a库文件
      创建文件夹libAdvanced用于保存静态库信息 >> 替换刚刚合并的.a文件 >> 添加用到的图片等资源文件 >> 导入工程验证

    • 创建新工程验证
    • 如果架构报错 Build Settings >> BuildActiveArchitecture Only Debug改为NO

    二、直接创建Framework库

    Framework是资源的集合,将静态库和其头文件包含到一个结构中,让Xcode可以方便地把它纳入到你的项目中。本质也是一个bundle文件
    在已有工程中创建
    • 创建Framework
      点击目标工程 >> 点击下面左下角加号 >> 创建


    • 参数配置
    点击目标工程 >> 选择你创建的Framework >> 点击工程设置 >> 做出如下修改

    Build Settings >> Dead Code Stripping >> 设置为NO

    Build Settings >> Strip Debug Symbol During Copy >> 全部设置为NO

    Build Settings >> Strip Style >> 设置为Non-Global Symbols

    Build Settings >> Base SDK >> Latest iOS(iOS 选择最新的)

    Build Settings >> Link With Standard Libraries >> 设置为 NO

    Build Settings >> Mach-O Type >> Static Library

    对于Mach-O Type有两种情况:(1)选择 Static Library 打出来的是静态库;(2)选择 Relocatable Object File 打出来是动态库。


    • 选择framework支持的系统版本

    • 将需要打包的文件拖入到Framework中


    设置需要公开的文件

    • 选择运行模式(debug 或 Release)分别在真机和模拟器下common + B 编译生成对应的Framework库

    • 合并二进制文件并替换

    cd 到保存文件目录下
    lipo -create xxx/Debug-iphoneos/LibLoaderFramework.framework/LibLoaderFramework xxx/Debug-iphonesimulator/LibLoaderFramework.framework/LibLoaderFramework -output LibLoaderFramework
    lipo -info LibLoaderFramework
    输出
    Architectures in the fat file: LibLoaderFramework are: i386 arm64
    然后替换二进制文件


    删除Framework


    • 如果没有用到info.plist文件可以删除,避免在工程中发生冲突
    • 验证
      导入完整Framework到工程,移除打包前的代码,对库进行验证
    • 建立Framework工程进行创建
      • 使用xcode直接创建Framework工程

      • 把需要编译的文件导入到工程中

      • 设置需要公开的头文件

    • 选择Framework支持的系统版本
    • 配置参数

    参数配置基本都一样
    点击目标工程 >> 选择你创建的Framework >> 点击工程设置 >> 做出如下修改
    Build Settings >> Dead Code Stripping >> 设置为NO
    Build Settings >> Strip Debug Symbol During Copy >> 全部设置为NO
    Build Settings >> Strip Style >> 设置为Non-Global Symbols
    Build Settings >> Base SDK >> Latest iOS(iOS 选择最新的)
    Build Settings >> Link With Standard Libraries >> 设置为 NO
    Build Settings >> Mach-O Type >> Static Library
    对于Mach-O Type有两种情况:(1)选择 Static Library 打出来的是静态库;(2)选择 Relocatable Object File 打出来是动态库。
    -  选择Debug(或Release)模式分别在模拟器和真机上 command + B 编译

    - 合并真机和模拟器下编译的二进制文件
    cd到你想要保存合并后文件的目录下
    lipo -create xxx.framework/xxx ooo.framework/ooo -output ooo。
    查看文件支持的架构
    lipo -info LibLoaderFramework
    将合并成功的二进制文件替换为framework中的二进制文件,如果没有用到info.plist文件,可以删除,避免在工程中发生冲突
    • 创建新的工程,导入Framework进行验证
    如果工程无法联想出Framework头文件,导入路径形式如下:
    #import <LibLoaderFramework/PublicHeader.h>

    三、创建Bundle资源库文件

    创建Bundle工程



    • 配置几个编译设置

    因为你正在创建一个在iOS上使用的bundle,这与默认的OS X不同。
    Build Settings >> Base SDK >> Latest iOS (iOS 10.2选择最新)
    Build Settings >> Product Name >> ${TARGET_NAME}替换为你的工程名XXXX(直接写工程名就好)
    ################注意事项######################
    默认情况下,有两种resolutions(分辨率)的图片可以产生一些有趣的现象。
    例如,当你导入一个retina@2x版本的图片时,普通版的和Retina版的将会合并成一个多resolution的TIFF(标签图像文件格式,Tagged Image File Format)。
    Build Settings > COMBINE_HIDPI_IMAGES设置为NO
    • 如何添加资源文件

      • 直接拖入
      • 选择图片或其他资源文件 > Target Membership > 选择bundle目标
    • 编译工程并查看


    • Bundle文件使用时需要真实路径

    NSBundle *bundle = [NSBundle bundleWithURL:[[NSBundle mainBundle] URLForResource:@"LoaderBundle" withExtension:@"bundle"]];
    NSString *resourceStr = [bundle pathForResource:@"IMG_0017" ofType:@"JPG"];
    我们可以创建NSBundle分类避免重复书写
    • 创建工程验证

    四、含界面SDK如何进行依赖开发

    在无法看到真实效果的情况下为iOS开发一个UI控件库是极其困难的,所以我们需要掌握依赖开发的知识

  • 创建Framework工程
  • 参数设置:参考如上第二章节
  • 创建验证工程
  • 关闭Framework工程
  • 添加Framework工程的xxxx.xcodeproj到验证工程并连接到静态库如图操作:若未找到库,对库进行编译


    • 导入库的公开头文件,对验证工程进行编译
    如果工程无法联想出Framework头文件,导入路径形式如下:
    #import <LibLoaderFramework/PublicHeader.h>
    像这样使用嵌套工程的好处是你可以对库本身做出修改,而不用离开示例工程,即使你同时改变两个地方的代码也一样。每次你编译工程,你都要检查是否将头文件的public/project关系设置正确。如果实例工程中缺失了任何需要的头文件,它都不能被编译。

    五、使用脚本创建Framework库

  • 创建.a的静态库工程
    (创建方式与参数配置参照第一节不再赘述)
  • 使用脚本创建Framework目录结构,此时不包含二进制文件
  • 添加 New Run Script Phases
  • 双击面板标题栏Run Script,重命名为Build Framework。
    • 这个面板允许你在构建时运行一个Bash脚本
    • 你希望让脚本在build的过程中何时执行,就把这个面板拖动到列表中相对应的那一位置。
    • 对于该framework工程来说,脚本最后执行,因此你可以让它保留在默认的位置即可。


  • #set –e确保脚本的任何地方执行失败,则整个脚本都执行失败。
    set -e

    #导出framework路径
    export FRAMEWORK_LOCN="${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.framework"

    # 创建当前版本真实头文件夹
    mkdir -p "${FRAMEWORK_LOCN}/Versions/A/Headers"

    # 创建引用路径
    /bin/ln -sfh A "${FRAMEWORK_LOCN}/Versions/Current"

    /bin/ln -sfh Versions/Current/Headers "${FRAMEWORK_LOCN}/Headers"

    /bin/ln -sfh "Versions/Current/${PRODUCT_NAME}" \
    "${FRAMEWORK_LOCN}/${PRODUCT_NAME}"

    # 拷贝公共头文件到framework中
    /bin/cp -a "${TARGET_BUILD_DIR}/${PUBLIC_HEADERS_FOLDER_PATH}/" \
    "${FRAMEWORK_LOCN}/Versions/A/Headers"

    #######################简化目录也可用使用如下脚本#######################

    #set –e确保脚本的任何地方执行失败,则整个脚本都执行失败。
    set -e

    #导出的文件路径
    export FRAMEWORK_LOCN="${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.framework"

    # 创建真是文件路径
    mkdir -p "${FRAMEWORK_LOCN}/Headers"

    # 拷贝公共头文件到framework中
    /bin/cp -a "${TARGET_BUILD_DIR}/${PUBLIC_HEADERS_FOLDER_PATH}/" \
    "${FRAMEWORK_LOCN}/Headers"
    这个脚本做了如下三个操作:
    1.创建了libLoader.framework/Versions/A/Headers目录
    2.创建了一个framework所需要的三个连接符号([symbolic links](http://en.wikipedia.org/wiki/Symbolic_link))

    当前版本文件夹
    Versions/Current => A
    头文件夹
    Headers => Versions/Current/Headers
    二进制文件
    libLoader => Versions/Current/libLoader

    3.将公共头文件从你之前定义的公共头文件路径拷贝到Versions/A/Headers目录下,-a参数确保修饰次数作为拷贝的一部分不会改变,防止不必要的重新编译。


    • 多架构(Multi-Architecture)编译
      解决Framework或.a库合并的烦恼,此处用的是.a工程,使用Framework工程类似
    • iOS app需要在许多不同的CPU架构下运行:
    arm7: 在最老的支持iOS7的设备上使用
    arm7s: 在iPhone5和5C上使用
    arm64: 运行于iPhone5S的64位 ARM 处理器 上
    i386: 32位模拟器上使用
    x86_64: 64为模拟器上使用


    每个CPU架构都需要不同的二进制数据,当你编译一个应用时,无论你目前正在使用那种架构,Xcode都会正确地依照对应的架构编译。例如,如果你想跑在虚拟机上,Xcode只会编译i386版本(或者是64位机的x86_64版本)。
    这意味着编译会尽可能快地进行,当你归档一款app或者构建app的发布版本(release mode)时,Xcode会构建上述三个用于真机的ARM架构。因此这样app就可以跑在所有设备上了。不过,其他的编译架构又如何呢?让我们一起往下走
    创建 Aggregate 集合
    点击目标工程 > 添加新目标 > Cross-Platform > Aggregate > next > 命名为Framework'

    为什么使用集合(Aggregate)目标来创建一个framework呢?为什么这么不直接?因为OS X对库的支持更好一些,事实上,Xcode直接为每一个OS X工程提供一个Cocoa Framework编译目标。基于此,你将使用集合编译目标,作为Bash脚本的连接串来创建神奇的framework目录结构。
    你是不是开始觉得这个方法有些懵逼了?

    添加依赖库
    为了确保每当这个新的framework目标被创建时,静态链接库都会被编译,你需要往静态库目标中添加依赖(Dependency)。在库工程中选择Framework目标,在Build Phases中添加一个依赖。展开Target Dependencies面板,添加依赖库

    添加多平台编译脚本
    这个目标的主要编译部分是多平台编译,你将使用一个脚本来做到这一点。和你之前做的一样
    选择Framework目标 >> Build Phases >> 左侧 “+” 按钮 >> New Run Script Phases >> 命名MultiPlatform Build
    ![MultiPlatform Build

    • 写入编译framewo编译脚本

    #set –e确保脚本的任何地方执行失败,则整个脚本都执行失败。
    set -e

    #标示 如果已经插入脚本 退出
    if [ -n "$IYQ_MULTIPLATFORM_BUILD_IN_PROGRESS" ]; then
    exit 0
    fi
    export IYQ_MULTIPLATFORM_BUILD_IN_PROGRESS=1

    # 自定义变量
    IYQ_FRAMEWORK_NAME=${PROJECT_NAME}
    IYQ_INPUT_STATIC_LIB="lib${PROJECT_NAME}.a"
    IYQ_FRAMEWORK_LOCATION="${BUILT_PRODUCTS_DIR}/${IYQ_FRAMEWORK_NAME}.framework"

    #构建静态库 传参 "${1}"
    function build_static_library {
    # 重新构建库
    xcrun xcodebuild -project "${PROJECT_FILE_PATH}" \
    -target "${TARGET_NAME}" \
    -configuration "${CONFIGURATION}" \
    -sdk "${1}" \
    ONLY_ACTIVE_ARCH=NO \
    BUILD_DIR="${BUILD_DIR}" \
    OBJROOT="${OBJROOT}" \
    BUILD_ROOT="${BUILD_ROOT}" \
    SYMROOT="${SYMROOT}" $ACTION
    }

    #合并
    function make_fat_library {

    xcrun lipo -create "${1}" "${2}" -output "${3}"
    }

    # 1 正则判断 真机还是模拟器 (iphoneos/iphonesimulator)
    if [[ "$SDK_NAME" =~ ([A-Za-z]+) ]]; then
    IYQ_SDK_PLATFORM=${BASH_REMATCH[1]}
    else
    echo "Could not find platform name from SDK_NAME: $SDK_NAME"
    exit 1
    fi

    # 2 SDK版本
    if [[ "$SDK_NAME" =~ ([0-9]+.*$) ]]; then
    IYQ_SDK_VERSION=${BASH_REMATCH[1]}
    else
    echo "Could not find sdk version from SDK_NAME: $SDK_NAME"
    exit 1
    fi

    # 3 其他平台判断 如果 则 否则
    if [ "$IYQ_SDK_PLATFORM" == "iphoneos" ]; then
    IYQ_OTHER_PLATFORM=iphonesimulator
    else
    IYQ_OTHER_PLATFORM=iphoneos
    fi

    # 4 其他平台路径
    if [[ "$BUILT_PRODUCTS_DIR" =~ (.*)$IYQ_SDK_PLATFORM$ ]]; then
    IYQ_OTHER_BUILT_PRODUCTS_DIR="${BASH_REMATCH[1]}${IYQ_OTHER_PLATFORM}"
    else
    echo "Could not find other platform build directory."
    exit 1
    fi

    #调用上面构建函数 如果当前运行的是真机则构建模拟器
    build_static_library "${IYQ_OTHER_PLATFORM}${IYQ_SDK_VERSION}"

    # 如果你现在正在为模拟器编译,那么Xcode会默认只在该系统对应的结构下编译,例如i386 或 x86_64。为了在这两个结构下都进行编译,这里调用了build_static_library,基于iphonesimulator SDK重新编译,确保这两个结构都进行了编译。
    if [ "$RW_SDK_PLATFORM" == "iphonesimulator" ]; then
    build_static_library "${SDK_NAME}"
    fi

    # 合并库
    make_fat_library "${BUILT_PRODUCTS_DIR}/${IYQ_INPUT_STATIC_LIB}" \
    "${IYQ_OTHER_BUILT_PRODUCTS_DIR}/${IYQ_INPUT_STATIC_LIB}" \
    "${IYQ_FRAMEWORK_LOCATION}/${IYQ_FRAMEWORK_NAME}"

    # 确保文件存在 相当于-dpR,保持文件的连接(d),保持原文件的属性(p)并作递归处理(R)
    cp -a "${IYQ_FRAMEWORK_LOCATION}/${IYQ_FRAMEWORK_NAME}" \
    "${IYQ_OTHER_BUILT_PRODUCTS_DIR}/${IYQ_FRAMEWORK_NAME}.framework/${IYQ_FRAMEWORK_NAME}"

    # 拷贝到指定目录下
    ditto "${IYQ_FRAMEWORK_LOCATION}" "${SRCROOT}/BuildFramework/${IYQ_FRAMEWORK_NAME}.framework"

    在工程目录下的BuildFramework文件下查看,并导入工程验证
    #import <libLoader/LoaderProgressView.h>


    • SDK存在图片,xib等资源文件的情况

    • 添加bundle目标工程

    • bundle创建详细操作参考第三节内容

    • bundle目标工程进行编译

    • 添加bundle资源库依赖


    • 如果想把你的编译包copy到指定位置,在脚本后面加入如下代码

    # 拷贝bundle到指定目录下
    ditto "${BUILT_PRODUCTS_DIR}/${IYQ_FRAMEWORK_NAME}.bundle" \
    "${SRCROOT}/BuildFramework/${IYQ_FRAMEWORK_NAME}.bundle"



    原贴链接:https://www.jianshu.com/p/cbb1f54b89d2
    收起阅读 »

    7大程序设计原则

    编程的工作既是技术活,也是体力活,而编写优秀的软件,更是一件比较难的事情。 初级程序员只希望代码不出错,顶级程序员却把写代码当成艺术,当年雷军以过人的能力成为求伯君的左膀右臂,其早年的代码被说成“像诗一样优美”。 很多大牛,在着手写代码时并不是直接上手...
    继续阅读 »

    编程的工作既是技术活,也是体力活,而编写优秀的软件,更是一件比较难的事情。


    初级程序员只希望代码不出错,顶级程序员却把写代码当成艺术,当年雷军以过人的能力成为求伯君的左膀右臂,其早年的代码被说成“像诗一样优美”。


    很多大牛,在着手写代码时并不是直接上手编写,而是根据需求进行设计,不但将代码中 Bug 出现的机率降到最低,还让代码具有高可读性,高安全性等等。


    那大牛们都遵循怎样的原则呢,我们能不能学习一下?


    将大牛们的经验总结到一起,可以得到以下「7 大程序设计原则」 。这些设计原理源于对实际软件开发现场的分析,是提高代码质量的经验结晶。


    让我们一起一探究竟吧!


    01 简单性原则


    Simplicity Principle


    What:追求简单
    简单性原则就是追求简单。


    说得极端一点,就是自始至终都以最简单的逻辑编写代码,让编程初学者一眼就能看懂。


    因此,在编程时我们要重视的是局部的完整性,而不是复杂的整体关联性。


    Why:Bug 喜欢出现在复杂的地方
    软件故障常集中在某一个区域,而这些区域都有一个共同的特点,那就是复杂。编写代码时如果追求简单易懂,代码就很难出现问题。


    不过,简单易懂的代码往往给人一种不够专业的感觉。这也是经验老到的程序员喜欢写老练高深的代码的原因。所以我们要有足够的定力来抵挡这种诱惑。


    Do:编写自然的代码
    努力写出自然的代码。放下高超的技巧,坚持用简单的逻辑编写代码。


    既然故障集中在代码复杂的区域,那我们只要让代码简单到让故障无处可藏即可。不要盲目地让代码复杂化、臃肿化,要保证代码简洁。


    02 同构原则


    Isomorphism Principle


    What:力求规范
    同构原则就是力求规范。


    同等对待相同的东西,坚持不搞特殊。同等对待,举例来说就 是同一个模块管理的数值全部采用同一单位、公有函数的参数个数统一等。


    Why:不同的东西会更显眼
    相同的东西用相同的形式表现能够使不同的东西更加突出。不同的 东西往往容易产生 bug。遵循同构原则能让我们更容易嗅出代码的异样, 从而找出问题所在。


    图表和工业制品在设计上追求平衡之美,在这一点上,同构原则也 有着相似之处。统一的代码颇具美感,而美的东西一般更容易让人接 受,因此统一的代码有较高的可读性。


    Do:编写符合规范的代码
    我们要让代码符合一定的规范。不过,这会与程序员的自我表现欲相冲突。


    为了展现自己的实力,有些程序员会无视编程规范,编写独特的代码。可靠与简单是代码不可或缺的性质,但这些程序员常常在无意间让代码变得复杂。


    这就把智慧与个性用错了地方。小小的自我满足远不及代码质量重要。所以在编写代码时,务必克制住自己的表现欲,以规范为先。


    03 对称原则


    Symmetry Principle


    What:讲究形式上的对称
    讲究形式上的对称。


    对称原则就是讲究形式上的对称,比如有上就有下,有左就有右, 有主动就有被动。


    也就是说,我们在思考一个处理时,也要想到与之成对的处理。比 如有给标志位置 1 的处理,就要有给标志位置 0 的处理。


    Why:帮助读代码的人推测后面的代码
    具有对称性的代码能够帮助读代码的人推测后面的代码,提高其理解代码的速度。同时,对称性会给代码带来美感,这同样有助于他人理解代码。


    此外,设计代码时将对称性纳入考虑的范围能防止我们在思考问题时出现遗漏。如果说代码的条件分支是故障的温床,那么对称性就是思考的框架,能有效阻止条件遗漏。


    Do:编写有对称性的代码
    在出现“条件”的时候,我们要注意它的“反条件”。每个控制条件都存在与之成对的反条件(与指示条件相反的条件)。要注意条件与反条件的统一,保证控制条件具有统一性。


    我们还要考虑到例外情况并极力避免其发生。例外情况的特殊性会破坏对称性,成为故障的温床。特殊情况过多意味着需求没有得到整理。此时应重新审视需求,尽量从代码中剔除例外情况。


    命名也要讲究对称性。命名时建议使用 set/get、start/stop、begin/ end 和 push/pop 等成对的词语。


    04 层次原则


    Hierarchy Principle


    What:讲究层次
    注意事物的主从关系、前后关系和本末关系等层次关系,整理事物的关联性。


    不同层次各司其职,同种处理不跨越多个层次,这一点非常重要。比如执行了获取资源的处理,那么释放资源的处理就要在相同的层次进行。又比如互斥控制的标志位置 1 和置 0 的处理要在同一层次进行。


    Why:层次结构有助于提高代码的可读性
    有明确层次结构的代码能帮助读代码的人抽象理解代码的整体结构。读代码的人可以根据自身需要阅读下一层次的代码,掌握更加详细的信息。


    这样一来就可以提高代码的可读性,帮助程序员表达编码意图,降低 bug 发生的概率。


    Do:编写有抽象层次结构的代码
    在编写代码时设计各部分的抽象程度,构建层次结构。保证同一个层次中的所有代码抽象程度相同。另外,高层次的代码要通过外部视角描述低层次的代码。这样做能让调用低层次代码的高层次代码更加简单易懂。


    05 线性原则


    Linearity Principle


    What:处理流程尽量走直线
    线性原则就是让处理流程尽量走直线。


    一个功能如果可以通过多个功能的线性结合来实现,那它的结构就会非常简单。


    反过来,用条件分支控制代码、毫无章法地增加状态数等行为会让代码变得难以理解。我们要避免做出这些行为,提高代码的可读性。


    Why:直线处理可提高代码的可读性
    复杂的处理流程是故障的温床。


    故障多出现在复杂的条件语句和循环语句中。另外,goto 等让流程出现跳跃的语句也是故障的多发地。


    如果能让处理由高层次流向低层次,一气呵成,代码的可读性就会大幅提高。与此同时,可维护性也将提高,添加功能等改良工作将变得更加容易。


    一般来说,自上而下的处理流程简单明快,易于理解。我们应避开复杂反复的处理流程。


    Do:尽量不在代码中使用条件分支
    尽量减少条件分支的数量,编写能让代码阅读者线性地看完整个处理流程的代码。


    为此,我们需要把一些特殊的处理拿到主处理之外。保证处理的统一性,注意处理的流程。记得时不时俯瞰代码整体,检查代码是否存在过于复杂的部分。


    另外,对于经过长期维护而变得过于复杂的部分,我们可以考虑对其进行重构。明确且可靠的设计不仅对我们自身有益,还可以给负责维护的人带来方便。


    06 清晰原则


    Clarity Principle


    What:注意逻辑的清晰性
    清晰原则就是注意逻辑的清晰性。


    逻辑具有清晰性就代表逻辑能清楚证明自身的正确性。也就是说,我们编写的代码要让人一眼就能判断出没有问题。任何不明确的部分都 要附有说明。


    保证逻辑的清晰性要“不择手段”。在无法用代码证明逻辑正确性的情况下,我们也可以通过写注释、附文档或画图等方法来证明。不过,证明逻辑的正确性是一件麻烦的事,时间一长,人们就会懒得用辅助手段去证明,转而编写逻辑清晰的代码了。


    Why:消除不确定性
    代码免不了被人一遍又一遍地阅读,所以代码必须保持较高的可读性。编写代码时如果追求高可读性,我们就不会采用取巧的方式编写代码,编写出的代码会非常自然。


    采用取巧的方式编写的代码除了能让计算机运行以外没有任何意义。代码是给人看的,也是由人来修改的,所以我们必须以人为对象来编写代码。


    消除代码的不确定性是对自己的作品负责,这么做也可以为后续负责维护的人提供方便。


    Do:编写逻辑清晰的代码
    我们要编写逻辑清晰的代码。


    为此,我们应选用直观易懂的逻辑。会给读代码的人带来疑问的部分要么消除,要么加以注释。


    另外,我们应使用任何人都能立刻理解且不存在歧义的术语。要特别注意变量名等一定不能没有意义。


    07 安全原则


    Safty Principle


    What:注意安全性
    安全原则就是注意安全性,采用相对安全的方法来对具有不确定性的、模糊的部分进行设计和编程。


    说得具体一点,就是在编写代码时刻意将不可能的条件考虑进去。比如即便某个 i f 语句一定成立,我们也要考虑 else 语句的情况;即便某个 case 语句一定成立,我们也要考虑 default 语句的情况;即便某个变量不可能为空,我们也要检查该变量是否为 NULL。


    Why:防止故障发展成重大事故
    硬件提供的服务必须保证安全,软件也一样。


    硬件方面,比如取暖器,为防止倾倒起火,取暖器一般会配有倾倒自动断电装置。同样,设计软件时也需要考虑各种情况,保证软件在各种情况下都能安全地运行。这一做法在持续运营服务和防止数据损坏等方面有着积极的意义。


    Do:编写安全的代码
    选择相对安全的方法对具有不确定性的部分进行设计。列出所有可能的运行情况,确保软件在每种情况下都能安全运行。理解需求和功能,将各种情况正确分解到代码中,这样能有效提高软件安全运行的概率。


    为此,我们也要将不可能的条件视为考察对象,对其进行设计和编程。不过,为了统一标准,我们在编写代码前最好规定哪些条件需要写,哪些条件不需要写。


    摘自:《编程的原则:程序员改善代码质量的 101 个方法》
    作者:[日]上田勋


    收起阅读 »

    Android界面左右滑动切换

    Android 界面左右滑动切换 1.界面布局 <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" xmlns:tools="http://...
    继续阅读 »


    Android 界面左右滑动切换


    1.界面布局


    <LinearLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical"
    tools:context=".MainActivity">


    <androidx.viewpager.widget.ViewPager
    android:id="@+id/viewPager"
    android:layout_weight="13"
    android:layout_width="match_parent"
    android:layout_height="0dp"
    android:layout_below="@id/scrollbar">
    </androidx.viewpager.widget.ViewPager>

    <LinearLayout
    android:layout_weight="1"
    android:layout_width="match_parent"
    android:layout_height="0dp"
    android:orientation="horizontal"
    android:background="#FFFFFF">
    <LinearLayout
    android:layout_weight="1"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:gravity="center"
    android:orientation="vertical">
    <ImageView
    android:id="@+id/i1"
    android:layout_weight="1"
    android:layout_width="wrap_content"
    android:layout_height="0dp"
    android:layout_gravity="center"
    android:src="@mipmap/photo2" />
    <TextView
    android:id="@+id/t1"
    android:layout_weight="1"
    android:layout_width="wrap_content"
    android:layout_height="0dp"
    android:gravity="center"
    android:text="主页"
    android:textSize="20sp"
    android:textColor="#000" />
    </LinearLayout>
    <LinearLayout
    android:layout_weight="1"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:gravity="center"
    android:orientation="vertical">
    <ImageView
    android:id="@+id/i2"
    android:layout_weight="1"
    android:layout_width="wrap_content"
    android:layout_height="0dp"
    android:layout_gravity="center"
    android:src="@mipmap/photo3" />
    <TextView
    android:id="@+id/t2"
    android:layout_weight="1"
    android:layout_width="wrap_content"
    android:layout_height="0dp"
    android:gravity="center"
    android:text="活动"
    android:textSize="20sp"/>
    </LinearLayout>

    </LinearLayout>
    <ImageView
    android:layout_width="match_parent"
    android:layout_height="10dp"
    android:id="@+id/scrollbar"
    android:scaleType="matrix"
    android:layout_marginTop="5dp"
    android:src="@mipmap/scrollbar"/>

    </LinearLayout>


    界面展示
    在这里插入图片描述
    2.功能实现
    绑定ID
    在这里插入图片描述
    在onCreate函数中初始化滑块位置


    		bmpW = BitmapFactory.decodeResource(getResources(), R.mipmap.scrollbar).getWidth();
    //为了获取屏幕宽度,新建一个DisplayMetrics对象
    DisplayMetrics displayMetrics = new DisplayMetrics();
    //将当前窗口的一些信息放在DisplayMetrics类中
    getWindowManager().getDefaultDisplay().getMetrics(displayMetrics);
    //得到屏幕的宽度
    int screenW = displayMetrics.widthPixels;
    //计算出滚动条初始的偏移量
    offset = (screenW / 2 - bmpW) / 2;
    //计算出切换一个界面时,滚动条的位移量
    one = offset * 2 + bmpW;
    Matrix matrix = new Matrix();
    matrix.postTranslate(offset, 0);
    //将滚动条的初始位置设置成与左边界间隔一个offset
    scrollbar.setImageMatrix(matrix);

    在onCreate函数中,ViewPage添加两个Fragment界面


    		FragmentManager fragmentManager=getSupportFragmentManager();
    fragments=new ArrayList<Fragment>();
    fragments.add(new BlankFragment1());
    fragments.add(new BlankFragment2());

    定义MyPagerAdapter类


     public class MyPagerAdapter extends FragmentPagerAdapter
    {

    public MyPagerAdapter(@NonNull FragmentManager fm) {
    super(fm);
    }

    @NonNull
    @Override
    public Fragment getItem(int position) {
    return fragments.get(position);
    }

    @Override
    public int getCount() {
    return fragments.size();
    }
    }

    定义MyOnPageChangeListener类


    public class MyOnPageChangeListener implements ViewPager.OnPageChangeListener {

    @Override
    public void onPageSelected(int arg0) {
    Animation animation = null;
    switch (arg0) {
    case 0:
    /**
    * TranslateAnimation的四个属性分别为
    * float fromXDelta 动画开始的点离当前View X坐标上的差值
    * float toXDelta 动画结束的点离当前View X坐标上的差值
    * float fromYDelta 动画开始的点离当前View Y坐标上的差值
    * float toYDelta 动画开始的点离当前View Y坐标上的差值
    **/

    animation = new TranslateAnimation(one, 0, 0, 0);
    t1.setTextColor(Color.rgb(0,0,0));
    t2.setTextColor(Color.rgb(117,117,117));
    i1.setImageResource(R.mipmap.photo2);
    i2.setImageResource(R.mipmap.photo3);
    break;
    case 1:
    animation = new TranslateAnimation(offset, one, 0, 0);
    t1.setTextColor(Color.rgb(117,117,117));
    t2.setTextColor(Color.rgb(0,0,0));
    i1.setImageResource(R.mipmap.photo1);
    i2.setImageResource(R.mipmap.photo4);
    break;
    }
    //arg0为切换到的页的编码
    currIndex = arg0;
    // 将此属性设置为true可以使得图片停在动画结束时的位置
    animation.setFillAfter(true);
    //动画持续时间,单位为毫秒
    animation.setDuration(200);
    //滚动条开始动画
    scrollbar.startAnimation(animation);
    }

    @Override
    public void onPageScrolled(int arg0, float arg1, int arg2) {
    }

    @Override
    public void onPageScrollStateChanged(int arg0) {
    }
    }

    使用方法


    		MyPagerAdapter myPagerAdapter=new MyPagerAdapter(fragmentManager);
    viewPager.setAdapter(myPagerAdapter);
    viewPager.addOnPageChangeListener(new MyOnPageChangeListener());

    3.源代码


    点击下载


    4.有的软件开发不需要左右滑动屏幕切换界面,只需要点击按钮切换,这时候我们只需要定义一个类,禁止滑动即可。


    (1) 新建命名为CustomViewPager的类
    在这里插入图片描述


    package com.example.day_05;

    import android.content.Context;
    import android.util.AttributeSet;
    import android.view.MotionEvent;

    import androidx.viewpager.widget.ViewPager;

    /**
    * Created by Administrator on 2017/5/19.
    */


    public class CustomViewPager extends ViewPager {

    private boolean isCanScroll = true;

    public CustomViewPager(Context context) {
    super(context);
    }

    public CustomViewPager(Context context, AttributeSet attrs) {
    super(context, attrs);
    }

    /**
    * 设置其是否能滑动换页
    * @param isCanScroll false 不能换页, true 可以滑动换页
    */

    public void setScanScroll(boolean isCanScroll) {
    this.isCanScroll = isCanScroll;
    }

    @Override
    public boolean onInterceptTouchEvent(MotionEvent ev) {
    return isCanScroll && super.onInterceptTouchEvent(ev);
    }

    @Override
    public boolean onTouchEvent(MotionEvent ev) {
    return isCanScroll && super.onTouchEvent(ev);

    }
    }


    这时候ViewPage全部替换成我们定义这个类的名称
    在这里插入图片描述
    替换
    在这里插入图片描述
    在这里插入图片描述
    调用方法


     viewPager.setScanScroll(false);

    这时候屏幕就禁止滑动了,可以点击按钮进行切换


    源代码
    点击下载

    收起阅读 »

    乐观锁VS悲观锁

    乐观锁 VS 悲观锁 悲观锁:总是假设最坏的情况,每次取数据时都认为其他线程会修改,所以都会加锁(读锁、写锁、行锁等),当其他线程想要访问数据时,都需要阻塞挂起。 乐观锁:总是认为不会产生并发问题,每次去取数据的时候总认为不会有其他线程对数据进行修改,因此...
    继续阅读 »


    乐观锁 VS 悲观锁


    悲观锁:总是假设最坏的情况,每次取数据时都认为其他线程会修改,所以都会加锁(读锁、写锁、行锁等),当其他线程想要访问数据时,都需要阻塞挂起。


    乐观锁:总是认为不会产生并发问题,每次去取数据的时候总认为不会有其他线程对数据进行修改,因此不会上锁,但是在更新时会判断其他线程在这之前有没有对数据进行修改。
    乐观锁在Java中通过使用无锁来实现,常用的是CAS,Java中原子类的递增就是通过CAS自旋实现。
    在这里插入图片描述


    CAS


    CAS全称 Compare And Swap(比较与交换),是一种无锁算法。在不使用锁(没有线程被阻塞)的情况下实现多线程之间的变量同步。java.util.concurrent包中的原子类就是通过CAS来实现了乐观锁。


    一个 CAS 涉及到以下操作:
    我们假设内存中的原数据V,旧的预期值A,需要修改的新值B,



    1. 比较 A 与 V 是否相等。(比较)

    2. 如果比较相等,将 B 写入 V。(交换)

    3. 返回操作是否成功。


    CAS的底层原理



    • 调用 Unsafe 类中的 CAS 方法,JVM 会帮我们实现出 CAS 汇编指令

    • 这是一种完全依赖于硬件的功能,通过它实现原子操作

    • 原语的执行必须是连续的,在执行过程中不允许被中断,CAS 是 CUP 的一条原子指令


    CAS的三大问题



    • 如果 CAS 长时间一直不成功,会给 CPU 带来很大的开销,在Java的实现中是一只通过while循环自旋CAS获取锁。

    • 只能保证一个共享变量的原子操作

    • 引出了 ABA 问题


    ABA问题


    CAS需要在操作值的时候检查内存值是否发生变化,没有发生变化才会更新内存值。但是如果内存值原来是A,后来变成了B,然后又变成了A,那么CAS进行检查时会发现值没有发生变化,但是实际上是有变化的。


    如何解决ABA问题
    加入版本信息,例如携带 AtomicStampedReference 之类的时间戳作为版本信息,保证不会出现老的值。


    UnSafe


    Unsafe类是在sun.misc包下,不属于Java标准。但是很多Java的基础类库,包括一些被广泛使用的高性能开发库都是基于Unsafe类开发的,比如Netty、Cassandra、Hadoop、Kafka等。Unsafe类在提升Java运行效率,增强Java语言底层操作能力方面起了很大的作用。


    使用Unsafe可用来直接访问系统内存资源并进行自主管理,Unsafe类在提升Java运行效率,增强Java语言底层操作能力方面起了很大的作用。


    Unsafe可认为是Java中留下的后门,提供了一些低层次操作,如直接内存访问、线程调度等。


    这个类的提供了一些绕开JVM的更底层功能,基于它的实现可以提高效率。但是,它是一把双刃剑:正如它的名字所预示的那样,它是Unsafe的,它所分配的内存需要手动free(不被GC回收)。如果对Unsafe类理解的不够透彻,就进行使用的话,就等于给自己挖了无形之坑,最为致命。

    收起阅读 »

    面试官:说说什么是Java内存模型(JMM)?

    1. 为什么要有内存模型? 1.1. 硬件内存架构 1.2. 缓存一致性问题 1.3. 处理器优化和指令重排序 2. 并发编程的问题 3. Java 内存模型 3.1. Java 运行时内存区域与硬件内存的关...
    继续阅读 »







    在面试中,面试官经常喜欢问:『说说什么是Java内存模型(JMM)?』


    面试者内心狂喜,这题刚背过:『Java内存主要分为五大块:堆、方法区、虚拟机栈、本地方法栈、PC寄存器,balabala……』


    面试官会心一笑,露出一道光芒:『好了,今天的面试先到这里了,回去等通知吧』


    一般听到等通知这句话,这场面试大概率就是凉凉了。为什么呢?因为面试者弄错了概念,面试官是想考察JMM,但是面试者一听到Java内存这几个关键字就开始背诵八股文了。Java内存模型(JMM)和Java运行时内存区域区别可大了呢,不要走开接着往下看,答应我要看完。


    1. 为什么要有内存模型?


    要想回答这个问题,我们需要先弄懂传统计算机硬件内存架构。好了,我要开始画图了。


    1.1. 硬件内存架构


    在这里插入图片描述
    (1)CPU


    去过机房的同学都知道,一般在大型服务器上会配置多个CPU,每个CPU还会有多个,这就意味着多个CPU或者多个核可以同时(并发)工作。如果使用Java 起了一个多线程的任务,很有可能每个 CPU 都会跑一个线程,那么你的任务在某一刻就是真正并发执行了。


    (2)CPU Register


    CPU Register也就是 CPU 寄存器。CPU 寄存器是 CPU 内部集成的,在寄存器上执行操作的效率要比在主存上高出几个数量级。


    (3)CPU Cache Memory


    CPU Cache Memory也就是 CPU 高速缓存,相对于寄存器来说,通常也可以成为 L2 二级缓存。相对于硬盘读取速度来说内存读取的效率非常高,但是与 CPU 还是相差数量级,所以在 CPU 和主存间引入了多级缓存,目的是为了做一下缓冲。


    (4)Main Memory


    Main Memory 就是主存,主存比 L1、L2 缓存要大很多。


    注意:部分高端机器还有 L3 三级缓存。


    1.2. 缓存一致性问题


    由于主存与 CPU 处理器的运算能力之间有数量级的差距,所以在传统计算机内存架构中会引入高速缓存来作为主存和处理器之间的缓冲,CPU 将常用的数据放在高速缓存中,运算结束后 CPU 再讲运算结果同步到主存中。


    使用高速缓存解决了 CPU 和主存速率不匹配的问题,但同时又引入另外一个新问题:缓存一致性问题。
    在这里插入图片描述
    在多CPU的系统中(或者单CPU多核的系统),每个CPU内核都有自己的高速缓存,它们共享同一主内存(Main Memory)。当多个CPU的运算任务都涉及同一块主内存区域时,CPU 会将数据读取到缓存中进行运算,这可能会导致各自的缓存数据不一致。


    因此需要每个 CPU 访问缓存时遵循一定的协议,在读写数据时根据协议进行操作,共同来维护缓存的一致性。这类协议有 MSI、MESI、MOSI、和 Dragon Protocol 等。


    1.3. 处理器优化和指令重排序


    为了提升性能在 CPU 和主内存之间增加了高速缓存,但在多线程并发场景可能会遇到缓存一致性问题。那还有没有办法进一步提升 CPU 的执行效率呢?答案是:处理器优化。



    为了使处理器内部的运算单元能够最大化被充分利用,处理器会对输入代码进行乱序执行处理,这就是处理器优化。



    除了处理器会对代码进行优化处理,很多现代编程语言的编译器也会做类似的优化,比如像 Java 的即时编译器(JIT)会做指令重排序。
    在这里插入图片描述



    处理器优化其实也是重排序的一种类型,这里总结一下,重排序可以分为三种类型:



    • 编译器优化的重排序。编译器在不改变单线程程序语义放入前提下,可以重新安排语句的执行顺序。

    • 指令级并行的重排序。现代处理器采用了指令级并行技术来将多条指令重叠执行。如果不存在数据依赖性,处理器可以改变语句对应机器指令的执行顺序。

    • 内存系统的重排序。由于处理器使用缓存和读写缓冲区,这使得加载和存储操作看上去可能是在乱序执行。



    2. 并发编程的问题


    上面讲了一堆硬件相关的东西,有些同学可能会有点懵,绕了这么大圈,这些东西跟 Java 内存模型有啥关系吗?不要急咱们慢慢往下看。


    熟悉 Java 并发的同学肯定对这三个问题很熟悉:『可见性问题』、『原子性问题』、『有序性问题』。如果从更深层次看这三个问题,其实就是上面讲的『缓存一致性』、『处理器优化』、『指令重排序』造成的。


    在这里插入图片描述
    缓存一致性问题其实就是可见性问题,处理器优化可能会造成原子性问题,指令重排序会造成有序性问题,你看是不是都联系上了。


    出了问题总是要解决的,那有什么办法呢?首先想到简单粗暴的办法,干掉缓存让 CPU 直接与主内存交互就解决了可见性问题,禁止处理器优化和指令重排序就解决了原子性和有序性问题,但这样一夜回到解放前了,显然不可取。


    所以技术前辈们想到了在物理机器上定义出一套内存模型, 规范内存的读写操作。内存模型解决并发问题主要采用两种方式:限制处理器优化使用内存屏障


    3. Java 内存模型


    同一套内存模型规范,不同语言在实现上可能会有些差别。接下来着重讲一下 Java 内存模型实现原理。


    3.1. Java 运行时内存区域与硬件内存的关系


    了解过 JVM 的同学都知道,JVM 运行时内存区域是分片的,分为栈、堆等,其实这些都是 JVM 定义的逻辑概念。在传统的硬件内存架构中是没有栈和堆这种概念。
    在这里插入图片描述
    从图中可以看出栈和堆既存在于高速缓存中又存在于主内存中,所以两者并没有很直接的关系。


    3.2. Java 线程与主内存的关系


    Java 内存模型是一种规范,定义了很多东西:



    • 所有的变量都存储在主内存(Main Memory)中。

    • 每个线程都有一个私有的本地内存(Local Memory),本地内存中存储了该线程以读/写共享变量的拷贝副本。

    • 线程对变量的所有操作都必须在本地内存中进行,而不能直接读写主内存。

    • 不同的线程之间无法直接访问对方本地内存中的变量。


    看文字太枯燥了,我又画了一张图:
    在这里插入图片描述


    3.3. 线程间通信


    如果两个线程都对一个共享变量进行操作,共享变量初始值为 1,每个线程都变量进行加 1,预期共享变量的值为 3。在 JMM 规范下会有一系列的操作。
    在这里插入图片描述
    为了更好的控制主内存和本地内存的交互,Java 内存模型定义了八种操作来实现:



    • lock:锁定。作用于主内存的变量,把一个变量标识为一条线程独占状态。

    • unlock:解锁。作用于主内存变量,把一个处于锁定状态的变量释放出来,释放后的变量才可以被其他线程锁定。

    • read:读取。作用于主内存变量,把一个变量值从主内存传输到线程的工作内存中,以便随后的load动作使用

    • load:载入。作用于工作内存的变量,它把read操作从主内存中得到的变量值放入工作内存的变量副本中。

    • use:使用。作用于工作内存的变量,把工作内存中的一个变量值传递给执行引擎,每当虚拟机遇到一个需要使用变量的值的字节码指令时将会执行这个操作。

    • assign:赋值。作用于工作内存的变量,它把一个从执行引擎接收到的值赋值给工作内存的变量,每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。

    • store:存储。作用于工作内存的变量,把工作内存中的一个变量的值传送到主内存中,以便随后的write的操作。

    • write:写入。作用于主内存的变量,它把store操作从工作内存中一个变量的值传送到主内存的变量中。



    注意:工作内存也就是本地内存的意思。



    4. 有态度的总结


    由于CPU 和主内存间存在数量级的速率差,想到了引入了多级高速缓存的传统硬件内存架构来解决,多级高速缓存作为 CPU 和主内间的缓冲提升了整体性能。解决了速率差的问题,却又带来了缓存一致性问题。


    数据同时存在于高速缓存和主内存中,如果不加以规范势必造成灾难,因此在传统机器上又抽象出了内存模型。


    Java 语言在遵循内存模型的基础上推出了 JMM 规范,目的是解决由于多线程通过共享内存进行通信时,存在的本地内存数据不一致、编译器会对代码指令重排序、处理器会对代码乱序执行等带来的问题。


    为了更精准控制工作内存和主内存间的交互,JMM 还定义了八种操作:lock, unlock, read, load,use,assign, store, write


    – End –


    关于Java 内存模型还有很多东西没有展开讲,比如说:内存屏障happens-before锁机制CAS等等。要肝一个系列了,加油!



    作者:雷小帅


    推荐一个Github 开源项目,『Java八股文』Java面试套路,Java进阶学习,打破内卷拿大厂Offer,升职加薪!https://github.com/CoderLeixiaoshuai/java-eight-part


    作者简介: ?读过几年书:华中科技大学硕士毕业;
    ?浪过几个大厂:华为、网易、百度……
    ?一直坚信技术能改变世界,愿保持初心,加油技术人!


    微信搜索公众号【爱笑的架构师】,关注这个对技术有追求且有趣的打工人。


    收起阅读 »

    TIOBE5月编程语言榜单:Python超越Java重回第二,Rust崛起

    作者 | 苏宓 出品 | CSDN(ID:CSDNnews) TIOBE 官方最新发布了 5 月的编程语言榜单,不妨一起来看一下本月榜单中又有哪些最新的变化呢? Python 重回第二 和 4 月相比,本月榜单的 TOP 10 ...
    继续阅读 »

    作者 | 苏宓


    出品 | CSDN(ID:CSDNnews)


    TIOBE 官方最新发布了 5 月的编程语言榜单,不妨一起来看一下本月榜单中又有哪些最新的变化呢?



    Python 重回第二


    和 4 月相比,本月榜单的 TOP 10 中变化最大的非 Python 与 Java 莫属。


    现实来看,曾经的铁三角 Java、C、C++ 如今已被彻底瓦解,犹记得 2020 年 5 月,Java 被 C 超越后,于 11 月份再次被 Python 短暂碾压,一路跌到了第三位,虽然后来 Java 再次追上 Python,可还是无法拯救其下滑的趋势。


    据最新的榜单显示,Python 以 0.13% 的差异再次领先 Java,位居第二,Java 排名第三。



    面对市场份额一直在缩减的 Java,轻芒联合创始人、前豌豆荚技术负责人范怀宇在《2020-2021开发者大调查》中剖析道,“Kotlin 虽然在统计中总的比例不高,但在 Android 开发上进一步在取代 Java。Kotlin 作为另一个基于 JVM 的编程语言,一方面可以保持 Java 使用 JVM 稳定和高性能的好处,享用 JVM 已有的生态;另一方面,通过其更为灵活的语法特性,越来越广泛地被 Android 开发者使用,已然成为 Android 的首选编程语言,对于新参与 Android 的开发者而言,Kotlin 是更好的学习对象。”


    因此,Java 一直处于下滑的趋势,也在情理之中。


    与之形成鲜明对比且处于蒸蒸日上的 Python,TIOBE CEO Paul Jansen 评估道,“去年 11 月,Python 短暂地超越了 Java,位居 TIOBE 榜单的第二位。本月中,Python 再次成功上位,有理由相信它将在这一位置上待得更久。在未来半年内,Python 或许能成为 TIOBE 榜单上的第一名,因为 C(宛如 Java 一样)的流行度正在下降。”



    被大厂拥抱的 Rust,属于它的时代已至!


    至于 C 语言为何会不再受到重用?我们也从另一种编程语言 Rust 身上找到了答案。


    在本月榜单中,Rust 从上个月的第 29 名上升到了本月的 24 名,其生态在各个科技大厂的支持下,也大有进入 TOP 20 的潜力。


    不久前,Facebook 正式宣布加入 Rust 基金会,与其他成员共同负责 Rust 开源生态以及社区的运作和发展,与此同时,其承诺将进一步加大对 Rust 语言的采用。事实上,Facebook 是继 AWS、Google、华为、微软、Mozilla 后最新加入 Rust 基金会的成员,此前,很多科技公司早已深度地拥抱了 Rust。


    凭借安全、高性能、可靠性和高生产率等特性,AWS 在众多产品中应用 Rust 的同时,不惜花重金聘用 Rust 编译器联合创始人 Felix Klock 来加码 Rust 的应用;Google 将其应用到了 Android 系统中以及基于此重新实现一些重要的安全组件;微软在寻求替代 C、C++ 语言之际,不仅将 Rust 整合到了 Azure 服务中,也正在用 Rust 来实现一种新的编程语言;就连 Linux 内核开发者也开始在 Linux 内核中添加 Rust 支持的 RFC......


    Rust 下一步,未来可期。



    其他编程语言排名


    下面列出了完整的 21-50 名,因为是非官方发布的,所以可能存在遗漏:



    第 51-100 名如下,由于它们之间的数值差异较小,仅以文本形式列出(按字母排序):



    • ActionScript, Arc, B4X, bc, Boo, C shell, CFML, Clojure, Common Lisp, Eiffel, Erlang, F#, Hack, Icon, IDL, Inform, Io, J, JScript.NET, Korn shell, Lasso, Maple, MEL, ML, MQL4, MUMPS, NATURAL, OCaml, OpenCL, OpenEdge ABL, Oz, PL/I, PostScript, Pure Data, Q, Racket, Ring, RPG, Scheme, Simulink, Smalltalk, SPARK, SPSS, Stata, Tcl, Vala/Genie, Verilog, XC, Xojo, Zig




    Top 10 编程语言 TIOBE 指数走势(2002-2020)




    历史排名(1986-2021)


    注:以下排名位次取决于12个月的平均值。




    编程语言“名人榜”(2003-2020)



    【说明】:


    TIOBE 编程语言社区排行榜是编程语言流行趋势的一个指标,每月更新,这份排行榜排名基于全球技术工程师、课程和第三方供应商的数量,其中包括了流行的搜索引擎以及技术社区,如 Google、百度、维基百科、CSDN、必应、Hao 123 等等。具体的计算方式详见:https://www.tiobe.com/tiobe-index/programming-languages-definition/。请注意这个排行榜只是反映某个编程语言的热门程度,并不能说明一门编程语言好不好,或者一门语言所编写的代码数量多少。


    这个排行榜可以用来考察你的编程技能是否与时俱进,也可以在开发新系统时作为一个语言选择依据。


    详细榜单信息可参考 TIOBE 官网:https://www.tiobe.com/tiobe-index



    60+专家,13个技术领域,CSDN 《IT 人才成长路线图》重磅来袭!


    直接扫码或微信搜索「CSDN」公众号,后台回复关键词「路线图」,即可获取完整路线图!



    收起阅读 »

    Android应用架构之MVVM模式

    前言 早期的Android应用开发中,Activity/Fragment承担了过多的职责,它们不仅负责了应用界面的显示,而且负责了业务逻辑的处理。这样一来,Activity/Fragment很容易就变得臃肿、复杂,造成应用难以测试、维护和扩展。随着Andro...
    继续阅读 »


    前言


    早期的Android应用开发中,Activity/Fragment承担了过多的职责,它们不仅负责了应用界面的显示,而且负责了业务逻辑的处理。这样一来,Activity/Fragment很容易就变得臃肿、复杂,造成应用难以测试、维护和扩展。随着Android应用开发技术的不断发展和成熟,Android应用架构的设计得到了越来越多开发人员的关注和重视。目前,Android的应用架构主要有MVC、MVP和MVVM模式,本文将介绍一下MVVM模式。


    相关知识



    学习项目



    MVP模式


    MVVM模式可以说是MVP模式的进一步发展,所以先来了解一下MVP模式。


    MVP (Model-View-Presenter) 模式的结构如下图所示:


    MVP模式.png


    MVP模式将应用分为三层:Model层主要负责数据的提供,View层主要负责界面的显示,Presenter层主要负责业务逻辑的处理。


    在MVP模式中,Model层和View层不能直接通信,Presenter层负责充当中间人,实现Model层和View层之间的间接通信。View层和Presenter层互相持有对方的引用,实现View层和Presenter层之间的通信。


    MVP模式的主要优点是:分离了Model层和View层,分离了视图操作和业务逻辑,降低了耦合。


    MVVM模式


    MVVM (Model-View-ViewModel) 模式的结构如下图所示:


    MVVM模式.png


    MVVM模式与MVP模式一样,也将应用分为三层,并且各个对应的层的职责相似:



    • Model层,主要负责数据的提供。Model层提供业务逻辑的数据结构(比如,实体类),提供数据的获取(比如,从本地数据库或者远程网络获取数据),提供数据的存储。

    • View层,主要负责界面的显示。View层不涉及任何的业务逻辑处理,它持有ViewModel层的引用,当需要进行业务逻辑处理时通知ViewModel层。

    • ViewModel层,主要负责业务逻辑的处理。ViewModel层不涉及任何的视图操作。通过官方提供的Data Binding库,View层和ViewModel层中的数据可以实现绑定,ViewModel层中数据的变化可以自动通知View层进行更新,因此ViewModel层不需要持有View层的引用。ViewModel层可以看作是View层的数据模型和Presenter层的结合。


    MVVM模式与MVP模式最大的区别在于:ViewModel层不持有View层的引用。这样进一步降低了耦合,View层代码的改变不会影响到ViewModel层。


    MVVM模式相对于MVP模式主要有如下优点:



    • 进一步降低了耦合。ViewModel层不持有View层的引用,当View层发生改变时,只要View层绑定的数据不变,那么ViewModel层就不需要改变。而在MVP模式下,当View层发生改变时,操作视图的接口就要进行相应的改变,那么Presenter层就需要修改了。

    • 不用再编写很多样板代码。通过官方的Data Binding库,UI和数据之间可以实现绑定,不用再编写大量的findViewById()和操作视图的代码了。总之,Activity/Fragment的代码可以做到相当简洁。


    例子


    下面举一个简单的例子来实践MVVM模式。完整的项目代码可以去GitHub上查看:



    https://github.com/chongyucaiyan/MVVMDemo



    例子实现的主要功能是:点击按钮网络查询天气,查询成功后在界面上显示天气信息。主界面如下图所示:


    MVVMDemo界面.png


    MVVM模式的代码组织结构建议按照 业务功能 进行划分,具体操作是:每个业务功能独立一个包存放,每个业务功能包下面再按Model、View、ViewModel分包存放。所有的Model存放在model包下面,所有的Activity和Fragment存放在activity包下面,所有的ViewModel存放在viewmodel包下面。该例子比较简单,只有一个weather业务功能模块,最终的代码组织结构如下图所示:


    MVVMDemo代码组织结构.png


    编写Model


    查询杭州天气的URL为:



    http://www.weather.com.cn/data/cityinfo/101210101.html



    访问该URL将返回一串JSON字符串,如下所示:


    {"weatherinfo":{"city":"杭州","cityid":"101210101","temp1":"5℃","temp2":"20℃","weather":"晴转多云","img1":"n0.gif","img2":"d1.gif","ptime":"18:00"}}

    按照此JSON字符串,可以编写相应的实体类。WeatherData类的代码如下所示:


    public class WeatherData {

    private WeatherInfo weatherinfo;

    public WeatherInfo getWeatherinfo() {
    return weatherinfo;
    }

    public void setWeatherinfo(WeatherInfo weatherinfo) {
    this.weatherinfo = weatherinfo;
    }
    }

    WeatherInfo类的代码如下所示:


    public class WeatherInfo {

    private String city;

    private String cityid;

    private String temp1;

    private String temp2;

    private String weather;

    private String img1;

    private String img2;

    private String ptime;

    public String getCity() {
    return city;
    }

    public void setCity(String city) {
    this.city = city;
    }

    public String getCityid() {
    return cityid;
    }

    public void setCityid(String cityid) {
    this.cityid = cityid;
    }

    public String getTemp1() {
    return temp1;
    }

    public void setTemp1(String temp1) {
    this.temp1 = temp1;
    }

    public String getTemp2() {
    return temp2;
    }

    public void setTemp2(String temp2) {
    this.temp2 = temp2;
    }

    public String getWeather() {
    return weather;
    }

    public void setWeather(String weather) {
    this.weather = weather;
    }

    public String getImg1() {
    return img1;
    }

    public void setImg1(String img1) {
    this.img1 = img1;
    }

    public String getImg2() {
    return img2;
    }

    public void setImg2(String img2) {
    this.img2 = img2;
    }

    public String getPtime() {
    return ptime;
    }

    public void setPtime(String ptime) {
    this.ptime = ptime;
    }
    }

    编写ViewModel


    ViewModel不涉及任何的视图操作,只进行业务逻辑的处理。通过官方提供的Data Binding库,当ViewModel中的数据发生变化时,UI将自动更新。QueryWeatherViewModel的代码如下所示:


    public class QueryWeatherViewModel {

    private static final String TAG = "QueryWeatherViewModel";

    public final ObservableBoolean loading = new ObservableBoolean(false);

    public final ObservableBoolean loadingSuccess = new ObservableBoolean(false);

    public final ObservableBoolean loadingFailure = new ObservableBoolean(false);

    public final ObservableField<String> city = new ObservableField<>();

    public final ObservableField<String> cityId = new ObservableField<>();

    public final ObservableField<String> temp1 = new ObservableField<>();

    public final ObservableField<String> temp2 = new ObservableField<>();

    public final ObservableField<String> weather = new ObservableField<>();

    public final ObservableField<String> time = new ObservableField<>();

    private Call<WeatherData> mCall;

    public QueryWeatherViewModel() {

    }

    public void queryWeather() {
    loading.set(true);
    loadingSuccess.set(false);
    loadingFailure.set(false);

    mCall = RetrofitManager.get()
    .create(QueryWeatherRequest.class)
    .queryWeather();
    mCall.enqueue(new Callback<WeatherData>() {

    @Override
    public void onResponse(Call<WeatherData> call, Response<WeatherData> response) {
    WeatherInfo weatherInfo = response.body().getWeatherinfo();
    city.set(weatherInfo.getCity());
    cityId.set(weatherInfo.getCityid());
    temp1.set(weatherInfo.getTemp1());
    temp2.set(weatherInfo.getTemp2());
    weather.set(weatherInfo.getWeather());
    time.set(weatherInfo.getPtime());

    loading.set(false);
    loadingSuccess.set(true);
    }

    @Override
    public void onFailure(Call<WeatherData> call, Throwable t) {
    if (call.isCanceled()) {
    Log.i(TAG, "call is canceled.");
    } else {
    loading.set(false);
    loadingFailure.set(true);
    }
    }
    });
    }

    public void cancelRequest() {
    if (mCall != null) {
    mCall.cancel();
    }
    }
    }

    编写View


    View不涉及任何的业务逻辑处理,只进行界面的显示。在xml布局文件中,通过官方提供的Data Binding库,将UI与ViewModel中的数据进行绑定,当ViewModel中的数据发生变化时,UI将自动更新。xml布局文件的代码如下所示:


    <?xml version="1.0" encoding="utf-8"?>
    <layout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools">


    <data>

    <import type="android.view.View" />

    <variable
    name="viewModel"
    type="com.github.cyc.mvvmdemo.weather.viewmodel.QueryWeatherViewModel" />

    </data>

    <RelativeLayout
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:padding="@dimen/default_content_padding"
    tools:context="com.github.cyc.mvvmdemo.weather.activity.QueryWeatherActivity">


    <Button
    android:id="@+id/btn_query_weather"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_centerHorizontal="true"
    android:text="@string/query_weather"
    android:enabled="@{viewModel.loading ? false : true}"
    android:onClick="@{() -> viewModel.queryWeather()}" />


    <RelativeLayout
    android:id="@+id/vg_weather_info"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:layout_below="@id/btn_query_weather"
    android:layout_marginTop="@dimen/query_weather_margin"
    android:visibility="@{viewModel.loadingSuccess ? View.VISIBLE : View.GONE}">


    <TextView
    android:id="@+id/tv_city"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:textStyle="bold"
    android:text="@string/city" />


    <TextView
    android:id="@+id/tv_city_value"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_toRightOf="@id/tv_city"
    android:layout_alignBottom="@id/tv_city"
    android:text="@{viewModel.city}"
    tools:text="杭州" />


    <TextView
    android:id="@+id/tv_city_id"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_below="@id/tv_city"
    android:layout_marginTop="@dimen/query_weather_margin"
    android:textStyle="bold"
    android:text="@string/city_id" />


    <TextView
    android:id="@+id/tv_city_id_value"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_toRightOf="@id/tv_city_id"
    android:layout_alignBottom="@id/tv_city_id"
    android:text="@{viewModel.cityId}"
    tools:text="101210101" />


    <TextView
    android:id="@+id/tv_temp"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_below="@id/tv_city_id"
    android:layout_marginTop="@dimen/query_weather_margin"
    android:textStyle="bold"
    android:text="@string/temperature" />


    <TextView
    android:id="@+id/tv_temp1_value"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_toRightOf="@id/tv_temp"
    android:layout_alignBottom="@id/tv_temp"
    android:text="@{viewModel.temp1}"
    tools:text="5℃" />


    <TextView
    android:id="@+id/tv_tilde"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_toRightOf="@id/tv_temp1_value"
    android:layout_alignBottom="@id/tv_temp"
    android:text="@string/tilde" />


    <TextView
    android:id="@+id/tv_temp2_value"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_toRightOf="@id/tv_tilde"
    android:layout_alignBottom="@id/tv_temp"
    android:text="@{viewModel.temp2}"
    tools:text="10℃" />


    <TextView
    android:id="@+id/tv_weather"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_below="@id/tv_temp"
    android:layout_marginTop="@dimen/query_weather_margin"
    android:textStyle="bold"
    android:text="@string/weather" />


    <TextView
    android:id="@+id/tv_weather_value"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_toRightOf="@id/tv_weather"
    android:layout_alignBottom="@id/tv_weather"
    android:text="@{viewModel.weather}"
    tools:text="" />


    <TextView
    android:id="@+id/tv_time"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_below="@id/tv_weather"
    android:layout_marginTop="@dimen/query_weather_margin"
    android:textStyle="bold"
    android:text="@string/release_time" />


    <TextView
    android:id="@+id/tv_time_value"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_toRightOf="@id/tv_time"
    android:layout_alignBottom="@id/tv_time"
    android:text="@{viewModel.time}"
    tools:text="10:00" />

    </RelativeLayout>

    <ProgressBar
    android:id="@+id/pb_progress"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_centerInParent="true"
    android:visibility="@{viewModel.loading ? View.VISIBLE : View.GONE}" />


    <TextView
    android:id="@+id/tv_query_failure"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_centerInParent="true"
    android:text="@string/query_failure"
    android:visibility="@{viewModel.loadingFailure ? View.VISIBLE : View.GONE}" />

    </RelativeLayout>
    </layout>

    在Activity中,通过官方提供的Data Binding库加载布局文件,创建ViewModel,并绑定View和ViewModel。QueryWeatherActivity的代码如下所示:


    public class QueryWeatherActivity extends AppCompatActivity {

    // ViewModel
    private QueryWeatherViewModel mViewModel;

    // DataBinding
    private ActivityQueryWeatherBinding mDataBinding;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    mDataBinding = DataBindingUtil.setContentView(this, R.layout.activity_query_weather);
    // 创建ViewModel
    mViewModel = new QueryWeatherViewModel();
    // 绑定View和ViewModel
    mDataBinding.setViewModel(mViewModel);
    }

    @Override
    protected void onDestroy() {
    super.onDestroy();
    // 取消请求
    mViewModel.cancelRequest();
    }
    }

    总结


    MVVM模式将应用分为三层:Model层主要负责数据的提供,View层主要负责界面的显示,ViewModel层主要负责业务逻辑的处理。各个层职责单一,结构清晰,应用可以很方便地进行测试、维护和扩展。


    参考


    收起阅读 »

    Android仿微信红包动画平移动画

    Android 仿微信红包动画 平移动画先看效果图:简单思路:先找好素材,一张红包封面和 “开”这个图片,先用ps将红包图片P成两部分,两个椭圆的样子。“开”要有不同角度的,因为要由帧动画完成。开完之后背景设个随机数。红包封面可以用ps软件p出来,用椭圆选框工...
    继续阅读 »

    Android 仿微信红包动画 平移动画

    先看效果图:

    在这里插入图片描述

    简单思路:

    先找好素材,一张红包封面和 “开”这个图片,先用ps将红包图片P成两部分,两个椭圆的样子。“开”要有不同角度的,因为要由帧动画完成。开完之后背景设个随机数。红包封面可以用ps软件p出来,用椭圆选框工具即可。

    素材:

    在这里插入图片描述

    目录图:

    在这里插入图片描述

    详细完全代码:
    1. xml开动画——用帧动画完成。

    这节课有详细讲解 mooc讲解的视频教程保证能听懂,简单易学

    <?xml version="1.0" encoding="utf-8"?>

    <animation-list xmlns:android="http://schemas.android.com/apk/res/android"
    android:oneshot="true">

    <item android:drawable="@drawable/open1" android:duration="150"></item>
    <item android:drawable="@drawable/open2" android:duration="150"></item>
    <item android:drawable="@drawable/open3" android:duration="150"></item>
    <item android:drawable="@drawable/open5" android:duration="150"></item>
    <item android:drawable="@drawable/open6" android:duration="150"></item>
    <item android:drawable="@drawable/open1" android:duration="150"></item>
    <item android:drawable="@drawable/open2" android:duration="150"></item>
    <item android:drawable="@drawable/open3" android:duration="150"></item>
    <item android:drawable="@drawable/open5" android:duration="150"></item>
    <item android:drawable="@drawable/open6" android:duration="150"></item>
    <item android:drawable="@drawable/open1" android:duration="150"></item>
    </animation-list>`
    2. 布局代码:
    <?xml version="1.0" encoding="utf-8"?>
    <RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    xmlns:tools="http://schemas.android.com/tools"
    tools:context=".MainActivity">


    <TextView
    android:id="@+id/textView"
    android:layout_width="wrap_content"
    android:layout_height="50dp"
    android:layout_alignParentStart="true"
    android:layout_alignParentLeft="true"
    android:layout_alignParentTop="true"
    android:layout_alignParentEnd="true"
    android:layout_alignParentRight="true"
    android:layout_alignParentBottom="true"
    android:layout_marginStart="59dp"
    android:layout_marginLeft="59dp"
    android:layout_marginTop="193dp"
    android:layout_marginEnd="55dp"
    android:layout_marginRight="55dp"
    android:layout_marginBottom="268dp"
    android:gravity="center"
    android:text="恭喜同学,获得随机红包:"
    android:textSize="20dp" />


    <TextView
    android:id="@+id/text"
    android:layout_width="130dp"
    android:layout_height="50dp"
    android:layout_alignParentStart="true"
    android:layout_alignParentLeft="true"
    android:layout_alignParentEnd="true"
    android:layout_alignParentRight="true"
    android:layout_alignParentBottom="true"
    android:layout_marginStart="130dp"
    android:layout_marginLeft="130dp"
    android:layout_marginEnd="124dp"
    android:layout_marginRight="124dp"
    android:layout_marginBottom="231dp"
    android:gravity="center"
    android:text="TextView"
    android:textColor="@color/colorAccent"
    android:textSize="25dp" />


    <ImageView
    android:id="@+id/bg1"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_alignParentStart="true"
    android:layout_alignParentTop="true"
    android:layout_marginTop="0dp"
    android:scaleType="fitXY"
    app:srcCompat="@drawable/start55" />


    <ImageView
    android:id="@+id/bg2"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_alignParentStart="true"
    android:layout_alignParentBottom="true"
    android:layout_marginStart="0dp"
    android:layout_marginBottom="0dp"
    android:background="@drawable/start66"
    android:scaleType="fitXY" />


    <ImageView
    android:id="@+id/open"
    android:layout_width="wrap_content"
    android:layout_height="43dp"
    android:layout_alignTop="@+id/bg2"
    android:layout_alignParentStart="true"
    android:layout_alignParentLeft="true"
    android:layout_alignParentEnd="true"
    android:layout_alignParentRight="true"
    android:layout_alignParentBottom="true"
    android:layout_marginStart="133dp"
    android:layout_marginLeft="133dp"
    android:layout_marginTop="323dp"
    android:layout_marginEnd="134dp"
    android:layout_marginRight="134dp"
    android:layout_marginBottom="145dp"
    android:background="@drawable/open_rotate" />



    </RelativeLayout>

    3.最后Maintivity详细代码:
    import android.graphics.Bitmap;
    import android.graphics.BitmapFactory;
    import android.graphics.drawable.AnimationDrawable;
    import android.os.Handler;
    import android.support.v7.app.AppCompatActivity;
    import android.os.Bundle;
    import android.view.View;
    import android.view.animation.Animation;
    import android.view.animation.TranslateAnimation;
    import android.widget.ImageView;
    import android.widget.TextView;
    import java.util.Random;

    public class MainActivity extends AppCompatActivity implements View.OnClickListener {
    private ImageView open,bg1,bg2;
    private AnimationDrawable animationDrawable;
    private Animation animation = null;
    private Bitmap bitmap;
    private TextView text;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);
    open=(ImageView)findViewById(R.id.open);
    bg1 =(ImageView)findViewById(R.id.bg1);
    bg2 =(ImageView)findViewById(R.id.bg2);

    //设置随机数---用作金额
    text=(TextView) (findViewById(R.id.text));
    Random ra =new Random();
    int bb= ra.nextInt(88889+1);
    text.setText(String.valueOf(bb));
    text.setTextSize(40);

    //"开"——帧动画
    animationDrawable =(AnimationDrawable) open.getBackground();
    open.setOnClickListener(this);
    }
    public void onClick(View v) {
    // TODO Auto-generated method stub
    switch (v.getId()) {
    case R.id.open:
    animationDrawable.start();//开——帧动画
    //线程延时运行
    Handler handler = new Handler();
    handler.postDelayed(new Runnable() {
    @Override
    public void run() {
    //上+开 背景动画
    final TranslateAnimation openAnimation = new TranslateAnimation(
    TranslateAnimation.RELATIVE_TO_SELF, 0, TranslateAnimation.RELATIVE_TO_SELF, 0,
    TranslateAnimation.RELATIVE_TO_SELF, 0, TranslateAnimation.RELATIVE_TO_SELF, -0.5f);
    openAnimation.setDuration(1000); //设置动画的时间
    bg1.postDelayed(new Runnable() {
    @Override
    public void run() {
    bg1.setVisibility(View.VISIBLE);
    openAnimation.setFillAfter(true);//设置动画结束后位置保持不东
    bg1.startAnimation(openAnimation);
    }
    }, 0);//设置开始动画的准备时间
    open.postDelayed(new Runnable() {
    @Override
    public void run() {
    open.setVisibility(View.VISIBLE);
    openAnimation.setFillAfter(true);//设置动画结束后位置保持不东
    open.startAnimation(openAnimation);
    }
    }, 0);//设置开始动画的准备时间

    //下 背景动画
    final TranslateAnimation ctrlAnimation = new TranslateAnimation(
    TranslateAnimation.RELATIVE_TO_SELF, 0, TranslateAnimation.RELATIVE_TO_SELF, 0,
    TranslateAnimation.RELATIVE_TO_SELF, 0, TranslateAnimation.RELATIVE_TO_SELF, 0.4f);
    ctrlAnimation.setDuration(1000); //设置动画的时间
    bg2.postDelayed(new Runnable() {
    @Override
    public void run() {
    bg2.setVisibility(View.VISIBLE);
    ctrlAnimation.setFillAfter(true);//设置动画结束后位置保持不东
    bg2.startAnimation(ctrlAnimation);

    }
    }, 0);//设置开始动画的准备时间
    }
    }, 1500);//3秒后执行Runnable中的run方法
    break;
    }
    }
    }

    复制到Android studio 里面应该是可以直接运行的,关键部分代码有备注,不懂的代码可以复制问du娘。其中有用到线程作用是延时运行代码,是为了先让“开”动画运行完,然后“开”和上背景同时上移,代码很简单,祝各位能get到知识。

    收起阅读 »

    炫酷动画统计图表库:CurveGraphView

    CurveGraphView 是一个带有炫酷动画统计图表库,除了性能出色并具有许多样式选项之外,该库还支持单个平面内的多个线图。多个折线图对于比较不同股票,共同基金,加密货币等的价格非常有用。10.1 如何使用?1、在build.gradle 中添加如下依赖:...
    继续阅读 »

    CurveGraphView 是一个带有炫酷动画统计图表库,除了性能出色并具有许多样式选项之外,该库还支持单个平面内的多个线图。

    多个折线图对于比较不同股票,共同基金,加密货币等的价格非常有用。

    10.1 如何使用?

    1、在build.gradle 中添加如下依赖:

    dependencies {
    implementation 'com.github.swapnil1104:CurveGraphView:{current_lib_ver}'
    }

    2、在xml文件中添加布局:

     

    然后在代码中添加各种配置项

    curveGraphView = findViewById(R.id.cgv);

    curveGraphView.configure(
    new CurveGraphConfig.Builder(this)
    .setAxisColor(R.color.Blue) // Set X and Y axis line color stroke.
    .setIntervalDisplayCount(7) // Set number of values to be displayed in X ax
    .setGuidelineCount(2) // Set number of background guidelines to be shown.
    .setGuidelineColor(R.color.GreenYellow) // Set color of the visible guidelines.
    .setNoDataMsg(" No Data ") // Message when no data is provided to the view.
    .setxAxisScaleTextColor(R.color.Black) // Set X axis scale text color.
    .setyAxisScaleTextColor(R.color.Black) // Set Y axis scale text color
    .build()
    ););

    3、 提供数据集

    PointMap pointMap = new PointMap();
    pointMap.addPoint(0, 100);
    pointMap.addPoint(1, 500);
    pointMap.addPoint(5, 800);
    pointMap.addPoint(4, 600);
    10.2 效果图
    效果1效果2

    更多详细使用方式请看Github: https://github.com/swapnil1104/CurveGraphView

    下载地址:CurveGraphView-master.zip

    收起阅读 »