之前分享的文章是对yasio特性和用法的描述：https://blog.csdn.net/xseekerj/article/details/51891362本文将阐述核心设计思路和原则。当一个框架或库的诞生，必然有其原由，一个库带来的好处越大于使用代价，越容易被人接受，以下是本人对框架库设计的重要原则总结：
易用性，只需要简单的调用，便能正常工作
鲁棒性，简而言之就是不能闪退
适用性，核心功能适合绝对大多数使用场景
易集成，例如boost等，作为C++程序库header only概念
复用性，库整体功能或者核心模块，应该尽量做到放之四海皆可用，例如yasio的object_pool
而一个异步网络库还有一个原则： 尽力而为的设计模式。简单来讲，这种模式就是，有任务的时候，我卖力干，但也有间歇，因为有多个任务，我也不能在一个任务上卡太久，没任务的时候我就休眠，让出CPU时间片。其实联系到实际人类生活工作，其实也是这样，张弛有度才能高效工作生活。这种设计方式yasio网络库经历月流水过亿手游项目的实践证明，对于SLG手游的通信需求，网络独立线程，基本不占CPU，使游戏核心渲染线程能发挥最大性能。boost.asio以精巧的设计，解决了网络线程服务处理数据发送请求唤醒的难题，即模拟中断器，当有数据发送请求时主动发送信号，唤醒可能正在休眠的网络服务线程，yasio借鉴了boost.asio也实现了这一原则
那么问题来了， 既生瑜何生亮，既然已经有boost.asio，为什么还要设计yasio。诚然，boost.asio库足够强大，非阻塞io，不仅仅是网络，包括文件等都支持，是各操作系统上非阻塞io的集大成者，但是作为手机游戏的TCP长连接解决方案，boost.asio就像包含各种高品质的材料，需要开发者以一定的方式组装起来，才能很好地工作，这对于移动端的简单需求来讲，显然比较麻烦。因此设计了yasio, yasio带来的最大好处，就是屏蔽传输和拆包细节，业务线程只需要注册事件回调函数，就可以处理网络连接，网络丢失，协议包等网络事件，无需关心底层传输和拆包细节。
网络库的实现中有proactor前置器和reactor反应堆模式boost.asio, yasio都是前置器模式，曾经很有名的ACE库便是reactor模式；打个简单的比喻，例如我们平时在网上购物，懒惰的快递员到了你家楼下，会直接将快递丢在楼下的便利店或者投递箱，通知你“包裹到了，自己下来拿”，这是reactor模式，如果快递员二话不说直接送到你家门口，那么就是proactor模式。
网上有人问为什么要设计独立线程，我让他去看多核设计艺术，首先，如果芯片设计者也怀着这个思想，那么就没有今天的18核心36线程的发烧级CPU的诞生了，另外在这里直白地解释一下原因，首先对于手游，很多人应该知道，IPv6, 为了支持IPv6，基本都需要用域名来配置服务器的连接，域名解析是一件可能会延迟卡顿的事情，那么将域名解析和非阻塞连接的建立过程均放到独立线程，显然，游戏渲染线程就完全没必要浪费时间在这上面了。渲染线程擅长渲染，网络线程擅长网络传输和拆包, 各司其职，才能提高系统整体效率
yasio的核心设计框架:
yasio项目github地址: https://github.com/yasio/yasio
