[Feature Request]提议优化OpenWrt-mihomo项目结构以增强模块化和灵活性

[Mikihta]

问题描述

当前，OpenWrt-mihomo项目主要由mihomo（内核）和luci-app-mihomo两个插件组成。然而，mihomo内核插件包含了许多应由luci-app-mihomo处理的高层功能（如DNS劫持和防火墙配置），导致两个插件高度耦合。这种设计模式增加了用户在更新过程中的操作复杂性，并且影响了项目的整体可维护性。

观察到的问题

• mihomo和luci-app-mihomo之间的功能重叠导致必须同时更新两个插件以实现效果。
• 高耦合度使得维护和升级过程复杂且易出错。

建议的改进

1. 核心内核分离：建议将mihomo插件专注于核心网络功能，例如添加到系统路径的内核文件（类似于Adgurad home、SingBox），而将DNS劫持、防火墙设置等高层功能迁移至luci-app-mihomo。
2. 独立项目：考虑将mihomo插件作为一个独立的内核项目维护，这将有助于吸引对核心技术感兴趣的开发者，并鼓励更多基于此内核的创新实现。

预期好处

• 降低耦合度：使插件更专注，简化更新和维护过程。
• 增加灵活性：用户可以根据需要选择安装不同的功能组件。
• 鼓励社区贡献：模块化的设计可能吸引更多开发者参与。
• 提高可维护性：降低维护成本，加快错误修复和功能迭代的速度。
• 促进标准化：标准化的模块化设计促进生态系统的健康发展。

结论

希望这些建议能被考虑，以改善OpenWrt-mihomo项目的结构和用户体验。期待您的反馈和项目的未来发展。

[Mikihta]

将mihomo内核插件作为一个独立的项目后，更有利于实现对alpha版本的mihomo内核更新（作为pre-release版本发布），能为用户提供更多的选择性。

[morytyann]

核心内核分离

我还是坚持我的想法，我想以官方的方式来做这个插件，既service/luci-app/luci-i18n三个包，service用于运行服务，luci-app用于配置服务，luci-i18n用于luci的本地化。

独立项目

如果是在上一条的基础上，那这个包就没有什么意义了，会写Makefile就可以做出来。或者可以按OpenClash的方式，下载二进制文件也可以呀；如果不在上一条的基础上，那就和上一条冲突了，还是说你的两个建议是或者的关系？

[Mikihta]

我的想法是在上条的基础之上
虽然说事实上就是会写Makefile就能实现，但我估计有很大一部分用户（我并没有做过调研，只是感觉）都不会Makefile或者懒（比如我🤣）去实现这个事情。
而且这个情况下我想开发者就不必操心系统架构的问题，直接使用GitHub自动抓取mihomo内核是否有更新并自动编译，或许能减轻一些负担，而且能将插件推广到更多的架构上

[Mikihta]

不得不说我很看好你的这个项目，因为它的简洁性，使得极客能获得更好的使用体验（相较于openclash的臃肿），同时更简洁轻量的插件也十分利于新手上手🙏

[Mikihta]

其次，这样也并不是没有意义，通过插件方式安装内核相较于openclash使用文件的方式，其实对于用户来说操作更简单，也能进一步降低用户使用门槛

[morytyann]

嗯……其实现在就可以呀（直接使用GitHub获取Mihomo内核的包），开发一个luci-app，依赖本仓库Mihomo包，或者说不依赖，按照OpenClash的逻辑，检测并下载安装Mihomo包也可以，只要不修改Mihomo包的配置将其设置为启动就没问题。

至于安装/更新内核，我觉得最优雅的办法是创建一个feed添加到OpenWrt，然后通过软件包菜单来更新。点两下的事，总不至于麻烦了吧~

[Kryo123456]

我个人觉得按openclash那样的方式就挺好，检测到更新直接点击下载然后就完成更新了。不过openclash的更新方式有时候也有不少bug，按照作者目前的更新方式除了有点繁琐倒没有什么其他的问题。

[zutzo]

做成一个脚本就行了
隔壁大佬写的安装脚本

curl https://raw.githubusercontent.com/pmkol/openwrt-mihomo/main/mihomo-pkg-install.sh | bash

终端输入就行了 如果连终端都不会用 那还不如回去用 你的 Clash Meta for Android