满心期待的瞄了一眼所谓自主研发 XX 系统的源码，结果，骨子里全是美帝灵魂。

为啥讲 XX 系统呢，因为指名道姓有可能会引来一顿狂喷，对于他们来说，国产、自主研发，是神圣不可冒犯的，也是最核心的目标，哪怕你讲里头怎么是开源代码都是罪大恶极。

Proxy：

Proxy 是一个服务，代理软件提供这个服务，App 要使用这个服务代理过程才能跑起来。代理工具没法约束 App 必须使用它的 Proxy 服务，要不要通过 Proxy 服务来访问网络是 App 做主，代理设置是告诉 App 如何使用代理的，也必须要告诉 App 代理配置才有可能走代理。

操心系统有一个全局 Proxy 设置，默认 1080 端口，打开时系统会把应用层网络流量发到这个端口，这个也是一些代理工具“全局”的原理，调用系统 API 打开这个设置，然后从（ 1080 ）拿流量。但这只是一个“全局变量”，并不意味着应用必须听从一个全局变量的安排。

基于 Proxy 的代理工具，流量规则的意义不大，因为 Proxy 只能服务应用层网络，底层协议（如 ICMP ）没法走 Proxy ，其次，Proxy 是被动方并不能主动的接管流量。

VPN：

首先，VPN 需要操作系统支持，系统不支持就没法跑。因为 VPN 规范涵盖的网络协议比较底层（如 ICMP 也要走 VPN ），操作系统支持的 VPN 接口一般放到 IP 层。也就是说，在流量数据发给网卡之前，还可以通过 VPN 接口进行处理。

这个接口拿到的是网卡的流量，而不是某几个 App 的。不管什么 App 流量总得走网卡出去吧，在总出入口把关啥 App 都跑不了，所以，基于 VPN 接口的代理可以认为是统一设置。它和网络防火墙这类工具比较接近。

以前搞过 USB 驱动，理论上可以，不过得改内核。

USB 标准是 PnP （即插即用），Android 设备接入电脑时会有个“对话”过程，电脑问 Android 是啥 USB 设备啊、有哪些能力啊，这个时候 Android 驱动就会按照 USB 协议规范回复电脑，电脑根据 USB 的回复再设备管理器里动态创建逻辑设备。

如：Android 说我是 U 盘（ USB Mass Storage 设备）那电脑就创建移动磁盘，如 Android 说我是 ADB （自定义设备）那电脑也载入相关驱动。如果需要做个类似“屏蔽” USB 的功能，那 Android Linux 内核需要根据外部设定回应“空设备”（只是个例子），应用层工具是控制不了的。

@laoooo

本来 Azure 很符合，提供免费额度设计又合理，输入格式支持 wav pcm 编码和 ogg opus 编码，这两种都是适合音频处理的格式，不需要在无畏的编解码上耗费太多的计算（没必要费大力气去编码音频，然后在云端又费大力气去解码音频）。

奈何特么 Flutter 的 Package 太拉跨，要么我 app 计划的平台不支持，要么录音格式不支持。只能先看看云服务有没有能支援多格式的，没有的话只能自己折腾音频 package 。

聆听一下 Azure 优美的声音？

https://xinlake.dev/#/app-azure-tts

@iooco
好像要钱。不折腾了，现在基本弃用虚拟机了，上云原生。

Flutter ，对于前端来说 Dart 上手不难。

Flutter 打包平台应用时需要调用平台应用的构建程序，对于 Android 、iOS 端，你还需要搭建 Android 、iOS 的开发环境才能打包出它们的应用。

- 异步解析
- 缓存（避免重复的解析）
- 减少 Json 的体积
- 改进设计，不用 Json 存储巨量数据

被直接拉进群，感觉不被尊重？忽略个人选择？

我觉得一种可能是：大环境造就 App 开发者这种“轻个人、重组织”的主张，以至于 App “不尊重个人”的人机交互设计是“自然”的。

挺正常的，搞嵌入式的关注效率，对于每个 CPU 、内存、IO 都特别敏感。。。

但是这个很难管，原生应用直接和操作系统接触，最自由，各种应用都有自己的玩法，自然会这拉点那拉点。除了文件和数据存储不一样，还有看不见的系统交互（ API 调用）也不一样，有的高效有低效。想要“干净”的系统和应用真的没可能。

基于虚拟机或者应用程序框架（平台）的应用好点，应用只和虚拟机或者平台打交道，这种约束力强一点，不可能到处乱拉也能干净卸载，中间层提供的 API 接口也一样的，比较“干净”，不过这类效率没原生的好能力也会受到平台的限制比如支持串口通讯的 App 就很少甚至没有，因为如果平台不支持 App 就很难搞。

Flutter ，原生桌面应用，编译就可以运行，不用安装，带上运行库和字体等数据只有 30M 。不过 Flutter 桌面官方现在不支持多窗口，适合 UI 简洁的应用

@ykrank

在开发两个（练手的） App （ https://github.com/xinlake/privch-client-flutter ）时我也顺便抽象了一些几个插件发布到 pub.dev ，没什么人用我就把它们都下线了，App 我也暂时把它们从 Google Play 下架了，有空整理好再上架。

现在，我的网站、新开发的应用（如 https://xinlake.dev/#/app-azure-tts ）基本都上 Flutter 了，顺手，Hold 住。前不久好像看到 Google Cloud 的 Function 也支持 Flutter 。

我比较看好 Flutter 这类框架，跨平台、UI 有非常好的表现力。有一个框架把从 Native 实现，到操作系统平台的开发，再到统一跨平台的人机交互，都有效的组织起来，多棒的工具。

应用层： http 、ftp <-----> socks 被动代理应用层协议
传输层：tcp 、udp
网络层：icmp <-------> vpn 主动劫持网络及上层的协议

一个在当地没什么朋友的人又天天跟你唠叨，那估计不是让你给他提建议的

@CodingIran

插件的确是这样，水平参差不起。

我觉得一方面是因为（欠缺原生开发能力的）前端开发人员提供的插件较多，实现的插件 Native 代码还处于“能跑就行”的状态，性能、可靠性、兼容性、可维护等方面都较差。

另外一方面，Google Flutter 的“选用”策略似乎也没了以前 Google 生态建设的智慧，一些高 Like 的 Package 竟然各种问题，很无语。

要驾驭 Flutter 门槛还是蛮高的，前端、原生能力都要具备，虽然前端背景容易入手，但是想驾驭原生跨平台框架还是远远不够。但是 Flutter 对于有经验的开发者还是很不错的选择，毕竟框架本身做的还是很好。

2021 年接触 Flutter 以来从未遇到让人失望的事情，只看官方文档

@xmumiffy

我猜测也是这个原因，不过我这几天数据交互都正常，今天是到了快中午才跟 OpenAI 交互的，应该过了很大个小时了

@xmumiffy

没搞，哈哈，云端 Function 和 OpenAI 交互的，出错时只是转发简短的状态信息，别的详细信息客户端这边不知道，可以确定的只是 429 错误