之前分享的文章是對yasio特性和用法的描述：https://blog.csdn.net/xseekerj/article/details/51891362
本文將闡述核心設計思路和原則。
當一個框架或庫的誕生，必然有其原由，一個庫帶來的好處越大於使用代價，越容易被人接受，以下是本人對框架庫設計的重要原則總結：
- 易用性，只需要簡單的調用，便能正常工作
- 魯棒性，簡而言之就是不能閃退
- 適用性，核心功能適合絕對大多數使用場景
- 易集成，例如boost等，作爲C++程序庫header only概念
而一個異步網絡庫還有一個原則： 盡力而爲的設計模式。
簡單來講，這種模式就是，有任務的時候，我賣力幹，但也有間歇，因爲有多個任務，我也不能在一個任務上卡太久，沒任務的時候我就休眠，讓出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/simdsoft/yasio