浅谈Nya LoCyanFrp!开发

什么是 Nya LoCyanFrp!

Nya LoCyanFrp! (简写 NyaLCF) 是由本人开发的 LoCyanFrp 映射客户端，原为非官方客户端，现由于我加入了 LCT 团队（LoCyanTeam），所以转为官方客户端。
GitHub: https://github.com/Muska-Ami/NyaLCF

开发这款启动器的原因

如果你和我一样是从一代 LCF 开始使用的，那么你应该知道原官方启动器对于新手来说究竟有多不友好。没有图形化的操作，令人堪忧的稳定性，这些都是我创作 NyaLCF 的缘由。
出于对 LCF 自愿贡献的心态，为了帮助广大用户更好的使用 LCF ，我写下了这款启动器。

技术栈的选择

我认为技术栈决定了一个软件的性能。由于当时我从来没有做过桌面端软件开发，所以其实对于 NyaLCF 的技术栈选择上我是没有把握的。
我曾经考虑过用 Electron 来写，但是一想到 Electron 极其夸张的占用，最终打消了这个念头。
考虑到当时浅浅理解了一部分 Vue3 的原理过后，我正在学习 Flutter 框架，在实体书中对 Flutter 优点的极力推荐下，我 最终选择 Flutter 作为 NyaLCF 的核心技术栈。

项目的下一步开发

确定好技术栈后，我便着手开始实践在书上学到的内容。由于 Dart 语言和 Java 无与伦比的相似性，同时兼顾如同 JS 一般语法，我很快就上手熟练了。
项目基本界面的组建并没有花费太多时间，我只花了一周多搞定基本页面的构型。

在此期间，我也积累下了一些在 Flutter 中可能遇到但实体书中不会说明的问题解决方案。比如，组件在 Row 嵌套不指定宽高或设置为最小宽高会导致一个要求有限宽度的组件拥有无限宽度而报错，使用 Container 嵌套来实现类似 Web 开发中的 margin padding 值，处理容器间宽度，使用 ListView 来让整个页面可滚动等。

但开发其实并不顺利，由于学业原因，加上我当时对于 Flutter 框架了解不够，当时推送后足有半个月没有继续进行下一步的开发。

直到某一天，在 LCF 群里吐槽启动器太难用的时候偶然想起我还有这个项目未完工，心血来潮便打算继续完成这个项目。

后续的开发里，我找到了不少 Flutter 开发必备的依赖，最典型的比如相对于 Flutter 原版更好的状态管理器 GetX ，获取各种路径非常好用的 path_provider。这些包方便了后续的开发。我的代码里面有不少造轮子的工具类，这些类大多基于这些依赖实现。

Frpc 分发难题

这个问题属于是从 NyaLCF 诞生起就一直没修改的历史遗留问题。由于 Frpc 是独立于应用程序本身且可更新的，出于我个人习惯，会为其设计动态下发逻辑。这个东西逻辑其实我也想好了，但是一直没落实到实际代码中。现在 NyaLCF 是通过固定版本号分发解决的这个问题。

进程管理与进程交互设计

NyaLCF 在处理进程时，会为每个进程创建一个对应的 Map 并加入进程树。这个 Map 中包含了 Process 对象，以及对应的隧道ID：

pMap['process'] = process;
pMap['proxy_id'] = proxyId;
cctr.addProcess(pMap);

这个对象中的 proxy_id 主要用于查询这个进程对应的是哪个隧道。根据这个隧道 ID ，可以直接在 LCF API 上获得隧道信息，并反馈给用户。

由于 dart:io 先天残废，Process 对象几乎没有可以操作的方法，所以只能通过 kill() 方法关闭进程。
且由于 start() 方法并不会让 Frpc 成为 NyaLCF 的子进程，为了在关闭启动器后不再留下多余进程，需要对每一个进程执行 kill() 。

在进程交互上，NyaLCF 完全不与 Frpc 进行交互，完全被动处理，只根据日志输出判断是否需要执行其他操作。
当用户请求停止进程时，直接执行 kill() ，并从进程树中移除相关进程。

process.kill();
cctr.removeProcess(pMap);

打包

当我写完程序测试完毕后，我才发现 Flutter 并没有带有打包功能。
现在 NyaLCF 的打包是通过使用自行修改过的 flutter_distributor 实现的。

改动主要在 DEB 和 AppImage 的打包逻辑，首先是修复了 DEB 打包部分中没有填写社区贡献者打包会导致 dpkg 无法正常打包为 DEB 包的问题，然后对于 AppImage 部分，主要是修复了项目可执行文件名与项目名称不一致导致无法正常打开应用程序的问题。解决方案是修改源码添加可自定义的 binary_name 参数。具体的改动可以查看 此处

自动化构建输出

NyaLCF 采用的是 GitHub Actions 作为自动化构建和发布的平台。逻辑很简单，先在 GitHub Actions 上构建，然后当推送到 main 分支时，自动执行发布的逻辑，将构建输出发布到 GitHub Releases 。

后记

其实这个项目我也说了是一时的想法开始做的，从当初第一版只有 2000+ 行代码到现在的 7000+ 行代码，可以见得项目的体量变化。
其实出于项目性能考量，也有一直在更新项目中做的并不好的逻辑，目前我个人对软件性能还是满意的，在实测数据中 开启 10 个左右的隧道占用仅 100M 左右（主要是图信化和日志缓存）。
关于代码细节的优化，这里不一一赘述了，这都是实际操作后留下的经验，需要自己去体会。
既然做了大家喜欢，那就一直做下去吧。