本文只谈关于 Android 上面几个 “加速器” 适配器架构方案的方面得问题，目前 Android 上面实现加速器，主要有两个流派：

1、MPA架构（多进程架构）

2、MTA架构（多线程架构）

两个方案各有优缺点，基本适用MTA架构得基本是通过 Golang 实现的，没错就是 Google 那个 Go 语言来实现整个 “网络游戏加速器” 核心底层。

多数人为了轻松实现 “网络游戏加速器” 核心底层部分：tun2socks，除开这部分都没太大技术可言，当然服务器还是要一定技术的，一般会有一些优化算法，比如负载平衡、最佳路径算法

人们不要把现代大多数的 “网络游戏加速器” 真的想的太那么的高端，思想首先就不怎么对，“网络游戏加速器” 现在的技术门槛不像以前那么高了，早前，大家都的被迫研究XX万行CXX代码，才接触看到跟个天书视的，现在把，可能，平淡如水，大概是这种感觉？。

1、借鉴来自 “某蓝蓝绿绿的灯” 一定开源代码

2、依赖 Google 于 Github 上面开源的 go-netstack 网络协议栈来处理

FlowerWrong/tun2socks: Redirect tun flow to socks 5 in golang, support tcp and udp. (github.com)

3、依赖 Google 于 Github 上面开源的 go-gvisor 内实现的协议栈来处理

     xjasonlyu/tun2socks: tun2socks - powered by gVisor TCP/IP stack (github.com)

它们都是 go-tun2socks 协议栈的路子，类似的开源代码在 github 上面实在太多了，真的没有太大必要在过多的累赘。

但，我摸着良心，做这种东西建议直接 C/C++，其它的尽量都不要去过多考虑了，路子太野，而且也存在一定潜在代码泄露方面的安全问题，用 C/C++ 来做多好，主程编个/MT静态库让其它人那头文件自己调用，笑~！

以下所示的开源项目是个被各种XXX用的很多的东西，它是个关于某几个DL工具底层 go-tun2socks 程序编译的开源仓库。 

xxf098/go-tun2socks-build: tun2socks with v2ray & xray support for Android (github.com)

其依赖具体的实现 go-tun2socks 的仓库在这里：eycorsican/go-tun2socks: A tun2socks implementation written in Go. (github.com)

这个东西的路子其实就是把 C/C++ 层封装一次 LwIP TCP/IP Stack for Golang，来实现 go-tun2socks 程式，但这种实现，好处是从内存安全角度上面看，比在 C/C++ 层直接实现要好控制的多，另外相对更容易解决异步链接 SOCKS5 主机的问题，毕竟在 C/C++ 语言上面做异步很多时候是个很痛苦的事情，但是嘛，具体还是看技术人员的个人一个选择。

MTA多线程架构，都是编译成DLL动态链接库（Linux/Android为SO库）Android 上面直接通过JNI链接调用，整个程序都在相同的进程空间，好处就是处理上面比较方便，坏处就是容易整个程序挂，如果底层写的有BUG，稳定性是个很大的问题，另外就是句柄、内存资源回收可能会成为一个潜在的挑战，举个例子：关闭了网络游戏加速器链接，需要释放连接关联的各种资源，如果操作不当可能存在泄露的风险，所以除了团队人很多，不然不太建议用C/C++，因为 Android 上面找 native 层的问题真的不是那么便捷的。

MPA多进程架构，这类型的可能算是主流把？目前大多数工具、开源的基本都是这个路子，核心依赖于 sendfd/recvfd 内核文件描述句柄资源共享来实现，但缺点也比较明显，处理上会麻烦很多，而且介于 IPC 机制的问题，会存在大量突发 “端口分配”、“连接分配” 导致IPC访问阻塞时间过长，因为这需要同步模型来处理，可以异步处理嘛？答案是可以的，但是处理上会变得有些麻烦，所以目前基本都是按照同步阻塞模型来处理共享句柄的。

这类似的架构一般就分为多个进程，主进程为 Android JAR DEX应用层（JAVA/Kotlin 编程语言编写部分）子进程为 native，可以由 Golang、C/C++ 语言实现。

但 native 部分并不是一个真的DLL文件，而是一个EXE可执行文件，但把它们放到APP工程的 libs 文件夹里面改成 .so 的后缀名，这样子 Android 系统在安装 APP 的时候会自动给 .so 后缀名文件 +rx 访问执行权限，在不 ROOT 的情况下，Android 应用程序是无法给文件增加X执行权限得，有些 Android 系统环境上面，如果APP打包的时候这些 native 程序不把后缀名搞成 .so 打包进入APK要出问题，安装时它们不会给 native 程序文件加X执行权限或者不复制到应用的 native_lib_dir 目录，算是个 Android 兼容坑点，想要搞这种路子实现的童靴务必需要注意这点。

然后就是运行 native 程序的路子，这个就是用 JAVA 语言框架默认提供的 Runtime.getRuntime().exec(cmd...) 来执行运行 native 程序的命令行，它运行是以子进程的方式运行，这个很重要，如果不是子进程在非ROOT环境上面是 senfd/recvfd 模型是不会工作的，因为访问权限不足，哈哈！（一点都不智能，真是太不方便！）

Android 上面，PING某个主机，大多数实现就是通过 Runtime.getRuntime().exec("ping ...") 调用来实现的，但是呢，这个东西其实有个更好的解决办法那就是在 C/C++ 层通过创建 “ socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP)” 来实现哦，这可以免ROOT权限问题，ROOT权限目前只是限制不能使用 SOCK_RAW，可没说不能用DGRAM 类型的ICMP，实在不行不还是有TCP/UDP协议，控制TTL来测PING的路子嘛，总之方法还是有一些的，童靴们不要只认为就只有这么一种，能不调用别人程序的情况就尽量别调用，谁知道那个2B Android 发行版本系统就不给普通APP程序调用PING程序的执行权限呢？或者PING不能直接类似这样去调用 /usr/bin/ping，是吧！Android 的东西真的太烫了。

MPA架构的实现由于目前相对来说比较主流，开源实现也比较多，但是大多数基本都是从某个开源项目（算这个套路的祖宗？）上抄抄改改，换了个协议，底层逻辑基本没有变化，所以我个人还是推荐感兴趣的童靴们可以看看这个开源项目，算是个基础入门把，这个东西实现也不复杂，那就是 S*S-Android 工具开源项目的实现，XX协议什么的就不用去管了，人们只需要关注底层那部分就可以，对于游戏加速器，是不太可能走什么 socks 协议路子的，不然这...也...太坑玩家了把。

不过呢，第一篇文章我也提到这种 tun2socks 类型的网络游戏加速器，其实并不能尽量做到最好的延迟表现，如果想要真正的做到尽量最好的延迟表现，XX万行代码的C/C++ FULL NAT类型的工具开源项目，值得人们深入去研究与理解。