SwitchyAgain 开发杂谈（七）变化
就 SwitchyAgain 和 SwitchyOmega 的对比来说，在之前已经说过，是全面迁移到了 MV3 + TypeScript + React 这样的架构设计。构建也成功转移到了以 npm 为基础的构建链。在完成这种更现代化的修改后，接下来就还会对日新月异的前端变化来做更多的新功能的开发。
这里就分为两部分。第一部分，是 SwitchyOmega 原来就有的一些新功能的开发需求，也就是历史因素的功能开发。第二部分，是针对自停止开发后的出现的浏览器的新特性来做新功能的开发，这里还要考虑到会更倾向于去针对 Firefox 适配更多的功能，因为 Firefox 本身有更开放的 API 接口可供调用。
那么，还需要特别说下在迁移到了现代化的架构后，对 SwitchyOmega 臃肿的代码结构做优化设计。原来的结构，模块之间是界限很模糊的状态，耦合程度很高。那么为了更好地去维护开发，这里还需要特别抽出一段时间，去理清这种耦合程度是否能够拆出来，优先把简单的又比较重要的先给拆出来。虽然说这里是可以通过 AI 来分析并辅助完成，但也不是很小的工程，整个项目的内部架构就好像一种杂乱的布线，然后装好漂亮的外壳，根本看不出来里面实际的情况。
一开始，只是先拿一个模块的一小部分来做下测试，觉得各方面都没问题，就继续这样去拆。最后就拆出了特别多的模块。而且还发现了有重复的冗余结构，合并到了一起统一被调用，减轻了实际构建后的体积，但对运行耗时应该没有多大的优化程度。这样的拆分对之后的新功能的开发非常有帮助，这样只需要加新模块就好，不需要挤到同一个文件里去继续改，不然面对那么多行代码的文件，哪怕有 AI 都不是很容易的事情。即使现在有了 AI 也依然需要考虑到如何增加 AI 运行的速度，那么修改也会更倾向于能够让 AI 去尽可能快速理解的方向。
不过这个结构还是实在太大了。我认为主要是这个项目真的有非常丰富的功能，虽然现在有非常多的类似功能的扩展程序，但往往都无法做到如此之出色。如果是只是我的一个很小的个人项目，只有我自己一个人使用的话，那我就会选择大刀阔斧，将我不会使用到的功能全都砍掉，保留这种操作逻辑和设计，做一个轻巧的版本出来。
可惜的是，还是觉得，既然来都来了，也没必要做成这样，倒不如就继续下去也好，反正该优化的就优化，应该还不至于把事情给搞砸。问了好多次 AI，是否还有优化的空间，是否还能继续拆分，到最后 AI 回答了很多次没有更多优化空间，继续拆分收益不大，才停止。但其实还是有很多代码挤到了一块的，只是要拆也不好拆了，真要拆又会拆太多出来，本身也没有修改的必要，就暂时这样了。以后恐怕也不会去动了，属于是一种很稳定的状态。
这样之后，就是一些新功能。除了自己有想到的一些，还有去翻 SwitchyOmega 别人提到的。也没有很多是有实现可能的。因为这里很多人都意识不到，这个扩展程序，本质上只是对浏览器的功能做调用而已，浏览器没打算开放给你用，那你也没辙。只不过，Firefox 和 Chrome 相对比，开放了更多的 API 接口出来，所以有些功能，就变成了只有 Firefox 才支持的特性。
最开始，我是先做一个语言切换的功能。这里原本是通过浏览器的语言来同步修改，无法自行切换。我就挺不喜欢这种限制，所以先实现了这个。不过对于我来说，我自用的话我会只考虑只支持英文，做多语言是真的很累。实际分析后发现之前提交了好多语言，但就感觉像是一时兴起的而已，最后真正保留的就六种。还有两种是代码里保留但不会加入到发布的版本里，因为觉得实际上也没什么人会去用。
这里还是很纠结的。如果说，这个扩展程序根本就没那么多人会去使用，那多语言就是多余的设计。后面我去加新功能，只要涉及到文字方面，都要先默认做好英文的，然后再去加其他语言的进来。改动多了就会很烦躁，写出来也不知道是给谁用。就拿波斯文字来说，我是真的对这个很陌生。我知道它是右到左的书写顺序，但要我这个设置界面也这样做就很夸张，我也不懂这个文字怎么知道实际效果该是怎样才是最好。那就只能妥协，在现在的这种以从左到右的设计里仅翻译成波斯文字。毕竟我对会有切换到这种文字的用户，还是持有非常大的怀疑态度。
毕竟这些都也是从 SwitchyOmega 带过来的。如果说统统不要，又显得太激进。那就是做取舍了，现在的这种取舍我感觉就还好，没有太痛苦。不过每次到扩展商店去更新版本，都要针对不同的语言去做本地化的更新，这个就挺痛苦的。Firefox 那边就统一一个入口，没有这种针对不同语言显示不同的内容的设计。Chrome 这边是每一个语言都可以是不同的内容。从产品设计的角度来说，这是很好的设计，但对于个人开发者来说，非常痛苦。当然也可以选择只使用英文覆盖其他语言，但这样的话那还有做多语言的必要了吗？
解决了多语言的切换问题后，就来到了浅色、深色的配色切换。其实我是用不到这个功能的。于是几乎就靠 AI 来完成了，我只是决定下配色方案不要太丑。因为这里仍然在使用 Bootstrap 3.3.7，没有原生的深色匹配方案。AI 打算用最新版的深色配色，但太丑了，于是不断微调，最后就是这种效果了。我个人觉得很好看。不过我并不用，所以很难说效果就真的很好。
接着就是更具体的功能增加和修改，比如说隐藏某个代理，是要在弹出菜单隐藏还是设置页隐藏，然后还新增了一个右键菜单的切换选项，那么这里也可以设置隐藏。导出的时候不要附带从外部下载的规则列表具体的内容，因为太多的话会额外增加备份文件的体积。还有好多杂七杂八的功能，基本也是想到哪就做到哪，没有很具体的规划。
有一个能够看到所有的代理并简单管理的弹出界面。这个挺需要的，也能符合我的需求。不过这是在有很多的代理的情况下才有用。我平时也用不到这么多。只是从产品设计的角度来说，有这么一个功能会很好。还有很多更现代化的操作，比如说鼠标移动过去会右边悬浮三个小点，点击后能够有不同的操作，选择后弹出操作界面。这样的设计，给后面的新加的代理组的功能，就提供了很好的操作设计思路。
还有是对某个具体的网址检测会最终应用到哪个代理。这里对我来说难度挺大。我本身也几乎用不到这个功能。最大的问题就是设置页的设置入口，以及弹出菜单的展示界面。经过几轮的修改尝试，最后确定的就是给左边的导航菜单加一个新的入口，在这个新入口去设置。弹出菜单也是加一个入口，然后会把原来的某些功能合并进来，做成了一种资源检测的展示页。这里卡了有好多天，我都不想去做了。但还是坚持下来了，实际做出来的效果我自己来说很满意。虽然我的确用不到，一直都是关掉的。这个检测对于加载很多资源的网站来说，是很耗时的。
然后就是绕过列表。这里本来的操作就不是很方便，一旦多了起来就不好找。那么就是加了一个分区的功能，可以有不同的分区，并且可以选择是否启用。这样的话就很方便了。并且还做成了一个全局的列表，这种全局的列表对我来说更常用。实际上我会用到特定代理的情况并没有很多。
接着还有一个通过本地去解析域名。这个只能是 Firefox 才能做到，配合设置 DoH。也可以不设置，这样就直接走的本地解析，但如果本地解析存在问题，或者说需要通过 DNS 做额外的解析分流，那采用 DoH 也是很好的方式。这里能玩的花样也特别多，但我的确没那么多时间去研究了。只能是以后有机会再说了。
最让我印象深刻的还是对不同的标签、窗口、网站或页面应用不同的代理。虽然这个在 Chrome 上仅能实现普通窗口和隐私窗口不同代理。所以，反正我的确更常用 Firefox，那么这个功能几乎是我最喜欢的新功能了。具体的开发过程没有很痛苦，基本就按照 Firefox 开放的接口来接入，然后加多一个设置的入口。
这个场景对于只是想要临时使用代理非常有用。原本 SwitchyOmega 有一个临时规则的功能，但这个仅能针对当前的地址栏的网站，或者是加载不了的资源。而且可以看出是针对 Chrome 来设计的。这里还能完善的地方有很多，但基于 Chrome 的限制，我就没有很大的兴趣了。不过换到 Firefox，就可以加入这种更灵活的切换设计了，整体来说就轻松了很多。没有那种被限制住了的束缚感。
本来这个应用了不同标签等的设计，是通过扩展图标的左上角有一个小圆点来标记的。但后来觉得可能也能做成角标的设计。这样会更醒目一点。实际做出来，效果的确很好，直接就没想要那个小圆点了，虽然设计的确简洁，但似乎没那么好看。
就这个扩展程序来说，能加的功能还有很多的。不过核心的功能就很完善了。目前已经远远超出我自身的需求了。所以也很难还有动力去做其他自己用不到的功能，更多的还是现有的代码有漏洞就修补。而且自己也并没有很宽裕的时间去投入到这个扩展程序里，因此也就没有特别想去做宣传。有对此喜欢的，那么安装并使用就好，不喜欢就删了。并不想给自己太多没必要的压力，单纯是一种分享而已，做过多的保证没意义。
（完）