[Feature] 有时间麻烦更新一下clash meta for android

[qianyiqq]

Verify steps

• 我已经在 Issue Tracker 中找过我要提出的请求 I have searched on the issue tracker for a related feature request.
• 我已经仔细看过 Documentation 并无法找到这个功能 I have read the documentation and was unable to solve the issue.

Description

想体验一下新核心的功能，如果可以的话加入自动更新核心的功能，这样就不用每次都去升级软件，只需要替换核心就可以了

Possible Solution

No response

[sf467]

附议，请求更新clash meta for android

[stevejohnson7]

下周更新☺️这周略忙
内核跟踪的分支已经切到Alpha了，等下周看看改改名字更下submodule就能发

[sf467]

下周更新☺️这周略忙 内核跟踪的分支已经切到Alpha了，等下周看看改改名字更下submodule就能发

感谢开发者，感谢用爱发电

[Magic989]

下周更新☺️这周略忙 内核跟踪的分支已经切到Alpha了，等下周看看改改名字更下submodule就能发

感谢开发者😀，期待 mihomo for android 上线

[qianyiqq]

下周更新☺️这周略忙 内核跟踪的分支已经切到Alpha了，等下周看看改改名字更下submodule就能发

在哪里下载呢

[ainisw99]

能提供keep-alive-interval 时间修改这个功能吗在界面吗？

[sf467]

下周更新☺️这周略忙 内核跟踪的分支已经切到Alpha了，等下周看看改改名字更下submodule就能发

已经周六了。。。。😢

[S-T-eve]

cmfa要打赢复活赛了吗

[sf467]

😢

[Jacky-Bruse]

下周更新☺️这周略忙 内核跟踪的分支已经切到Alpha了，等下周看看改改名字更下submodule就能发

感谢大佬，期待更新

[CXwudi]

估计早把这issue给忘了😂

[qianyiqq]

估计早把这issue给忘了😂

你们再多去提几个新的issue

[CXwudi]

估计早把这issue给忘了😂

你们再多去提几个新的issue

然后@stevejohnson7反手就是duplicate, close😂

[sf467]

这个咱真的只能是慢慢求着，不能摧的太过分，毕竟大佬真的是用爱发电的。

没办法嘛，自己又不会写

[Paulgudring]

@E021ntox @CXwudi @qianyiqq @sf467 stevejohnson7在之前已经提供了锚定alpha branch的修订，fork下来使用action即可，更新不是他的义务。

可以使用我fork下来的仓库 ，内核是现在的alpha。因为不知道原仓库build签名密码，所以我用keytool另签了一份。

内核0.16.0到现在似乎没有非常重大的更新，各位有什么想要用的特性吗？cmfa从半年多前就缺人来开发新的功能了，感觉除非是cfa 3代码泄漏或者新的安卓gui出世，安卓上的clash生态就只会维持现在这个状态了。

[sf467]

@E021ntox @CXwudi @qianyiqq @sf467 stevejohnson7在之前已经提供了锚定alpha branch的修订，fork下来使用action即可，更新不是他的义务。

可以使用我fork下来的仓库 ，内核是现在的alpha。因为不知道原仓库build签名密码，所以我用keytool另签了一份。

内核0.16.0到现在似乎没有非常重大的更新，各位有什么想要用的特性吗？cmfa从半年多前就缺人来开发新的功能了，感觉除非是cfa 3代码泄漏或者新的安卓gui出世，安卓上的clash生态就只会维持现在这个状态了。

感谢你，meta有一项功能没有得到支持，那就是 mate 内核之下的url-test，和fallback类型的策略组是可以点选的，包括在 Windows 上直接跑核，用面板控制内核，可以直接点选。我记得之前有一篇 issue 说过，这是一个特性。但在 cfma 上没有得到支持

[Paulgudring]

感谢你，meta有一项功能没有得到支持，那就是 mate 内核之下的url-test，和fallback类型的策略组是可以点选的，包括在 Windows 上直接跑核，用面板控制内核，可以直接点选。我记得之前有一篇 issue 说过，这是一个特性。但在 cfma 上没有得到支持

@sf467 应该感谢stevejohnson7大佬，我只是把他的action跑起来了。说的特性是这个吗，cfa 3.0实现了vpnservice和root下的原核两种模式，而且可以使用外部控制，可惜没有开源就结束了，否则还有机会改成meta核。

[ForestL18]

@E021ntox @CXwudi @qianyiqq @sf467 stevejohnson7在之前已经提供了锚定alpha branch的修订，fork下来使用action即可，更新不是他的义务。

可以使用我fork下来的仓库 ，内核是现在的alpha。因为不知道原仓库build签名密码，所以我用keytool另签了一份。

内核0.16.0到现在似乎没有非常重大的更新，各位有什么想要用的特性吗？cmfa从半年多前就缺人来开发新的功能了，感觉除非是cfa 3代码泄漏或者新的安卓gui出世，安卓上的clash生态就只会维持现在这个状态了。

大佬，下载安装了下你仓库里的pre-release的安装包，发现一些新内核的特性无法使用，比如include-all-providers。
在你仓库里的commit记录看了下，貌似clash内核还是停留在11.3的版本（见上图），并没有更新。
想问下是无法通过anctions来拉取最新源码吗？

[ForestL18]

内核0.16.0到现在似乎没有非常重大的更新，各位有什么想要用的特性吗？cmfa从半年多前就缺人来开发新的功能了，感觉除非是cfa 3代码泄漏或者新的安卓gui出世，安卓上的clash生态就只会维持现在这个状态了。

感谢大佬，include-all这个新功能很重要

问下老哥你的include-all功能能用吗？我这边试了不行

[CXwudi]

@E021ntox @CXwudi @qianyiqq @sf467 stevejohnson7在之前已经提供了锚定alpha branch的修订，fork下来使用action即可，更新不是他的义务。

可以使用我fork下来的仓库 ，内核是现在的alpha。因为不知道原仓库build签名密码，所以我用keytool另签了一份。

内核0.16.0到现在似乎没有非常重大的更新，各位有什么想要用的特性吗？cmfa从半年多前就缺人来开发新的功能了，感觉除非是cfa 3代码泄漏或者新的安卓gui出世，安卓上的clash生态就只会维持现在这个状态了。

websocket的代替，v2ray-http-upgrade是只有0.17.0才有

[Z1298434831]

更新了吗？

[Paulgudring]

@ForestL18 @sf467 @E021ntox @CXwudi 你们好。我去调查了一下这个问题，确实我没有做到合并新的内核。

它对齐的应该是 Alpha merge into android-open 分支后产生的 android-real。好，那么在哪里用到这个呢？ 在 ./core/src/foss /golang/clash调用了Git-submodule。但是因为众所周知的问题呢，clash删库，meta改名mihomo，仓库地址都有变化。如果只是把action跑起来了，那还是原本的内核，自然是没有变化的。

于是我fork出来了仓库(mihomo)，在其中合并了新的android-real，并把submodule的url指向了它。那么现在看这个引用的module就是最新的内核了。

但是问题又出现了，patch的方法有几个是依赖于clash仓库的，所以我又fork了一个clash的备份仓库，把内部的go包指定url改成了自己仓库的。这样算是把依赖能够拉起来了。但是内核还有几个新调用的包和函数是有冲突的，我试着改改吧。

因为查找替换仓库内部的包的地址嘛，再次我觉得应该向Dreamacro、Kr328、MetaCubeX organization以及所有社区成员表示敬意的。我自己是学人文的，实际软件工程开发算是苦手，处理上面这些小问题就弄到今天四点；这也是想说每个人都可以做些调查、解决问题，倒是开发文档应该做起来了。另外，我需要向你们道歉，自己其实还是一知半解的，自以为是回答了很多错误的问题。

[ForestL18]

@ForestL18 @sf467 @E021ntox @CXwudi 你们好。我去调查了一下这个问题，确实我没有做到合并新的内核。

它对齐的应该是 Alpha merge into android-open 分支后产生的 android-real。好，那么在哪里用到这个呢？ 在 ./core/src/foss /golang/clash调用了Git-submodule。但是因为众所周知的问题呢，clash删库，meta改名mihomo，仓库地址都有变化。如果只是把action跑起来了，那还是原本的内核，自然是没有变化的。

于是我fork出来了仓库(mihomo)，在其中合并了新的android-real，并把submodule的url指向了它。那么现在看这个引用的module就是最新的内核了。

但是问题又出现了，patch的方法有几个是依赖于clash仓库的，所以我又fork了一个clash的备份仓库，把内部的go包指定url改成了自己仓库的。这样算是把依赖能够拉起来了。但是内核还有几个新调用的包和函数是有冲突的，我试着改改吧。

因为查找替换仓库内部的包的地址嘛，再次我觉得应该向Dreamacro、Kr328、MetaCubeX organization以及所有社区成员表示敬意的。我自己是学人文的，实际软件工程开发算是苦手，处理上面这些小问题就弄到今天四点；这也是想说每个人都可以做些调查、解决问题，倒是开发文档应该做起来了。另外，我需要向你们道歉，自己其实还是一知半解的，自以为是回答了很多错误的问题。

我今天也尝试fork了mihomo，并基于alpha创建android-real分支，并把android-open merge into android-real。同时fork了大佬你的cmfa仓库，把.gitmodules修改为了自己fork的mihomo，确实只能编译通过dependencies，无法build出包来。感觉应该是mihomo的新源码和以前针对Android的老patch有冲突。

希望大佬能尝试解决一下。

另外看到了大佬凌晨在跑actions的记录，辛苦了，感谢大佬。

[aylz10]

@ForestL18 @Paulgudring @E021ntox @sf467 @CXwudi
自己fork了一份代码,然后修改了下,已经把核心锚定到fork的mihomo 新建分支android了 ,该分支复制自Alpha
Actions跑了一遍,编译通过并且可以build出安装包,本机稍微测试了下可以正常使用新核心,但是新特性因为没有研究过所以没测试,你可以测试下看看是否支持了新特性.用的是我自己的签名生成的
核心使用Alpha当前最新版本 edf318b， 仓库 ， Pre-Release

[Sakuzy0]

@ForestL18 @Paulgudring @E021ntox @sf467 @CXwudi 自己fork了一份代码,然后修改了下,已经把核心锚定到fork的mihomo 新建分支android了 ,该分支复制自Alpha Actions跑了一遍,编译通过并且可以build出安装包,本机稍微测试了下可以正常使用新核心,但是新特性因为没有研究过所以没测试,你可以测试下看看是否支持了新特性.用的是我自己的签名生成的 核心使用Alpha当前最新版本 edf318b， 仓库 ， Pre-Release

貌似还是不支持新特性include-all-providers 策略组识别不到节点

[ForestL18]

@ForestL18 @Paulgudring @E021ntox @sf467 @CXwudi 自己fork了一份代码,然后修改了下,已经把核心锚定到fork的mihomo 新建分支android了 ,该分支复制自Alpha Actions跑了一遍,编译通过并且可以build出安装包,本机稍微测试了下可以正常使用新核心,但是新特性因为没有研究过所以没测试,你可以测试下看看是否支持了新特性.用的是我自己的签名生成的 核心使用Alpha当前最新版本 edf318b， 仓库 ， Pre-Release

Android分支是直接fork了alpha，并没有合并Android-open分支内容是吗？那alpha分支难道已经默认做了Android patch吗？🤯

[ForestL18]

@ForestL18 @Paulgudring @E021ntox @sf467 @CXwudi 自己fork了一份代码,然后修改了下,已经把核心锚定到fork的mihomo 新建分支android了 ,该分支复制自Alpha Actions跑了一遍,编译通过并且可以build出安装包,本机稍微测试了下可以正常使用新核心,但是新特性因为没有研究过所以没测试,你可以测试下看看是否支持了新特性.用的是我自己的签名生成的 核心使用Alpha当前最新版本 edf318b， 仓库 ， Pre-Release

我这边测试是可以的，include-all-providers，geo-auto-update啥的都能用

[aylz10]

@ForestL18 @Paulgudring @E021ntox @sf467 @CXwudi 自己fork了一份代码,然后修改了下,已经把核心锚定到fork的mihomo 新建分支android了 ,该分支复制自Alpha Actions跑了一遍,编译通过并且可以build出安装包,本机稍微测试了下可以正常使用新核心,但是新特性因为没有研究过所以没测试,你可以测试下看看是否支持了新特性.用的是我自己的签名生成的 核心使用Alpha当前最新版本 edf318b， 仓库 ， Pre-Release

Android分支是直接fork了alpha，并没有合并Android-open分支内容是吗？那alpha分支难道已经默认做了Android patch吗？🤯

你说的没错，alpha分支已经单独做了Android patch，补丁文件名就叫Android_ patch.go 。但是因为meta核心改名成mihomo了，所以有部分依赖指向的不是正确锚点的分支，所以需要改下cmfa里的代码，具体的你可以看我仓库里的提交。还有就是核心里组件变更比较多，而cmfa还是很久之前的代码没有维护，不清楚直接使用新核心会不会造成什么未知的bug，只能当做是新mihomo for Android出来之前的过渡用法了

[Sakuzy0]

@ForestL18 @Paulgudring @E021ntox @sf467 @CXwudi 自己fork了一份代码,然后修改了下,已经把核心锚定到fork的mihomo 新建分支android了 ,该分支复制自Alpha Actions跑了一遍,编译通过并且可以build出安装包,本机稍微测试了下可以正常使用新核心,但是新特性因为没有研究过所以没测试,你可以测试下看看是否支持了新特性.用的是我自己的签名生成的 核心使用Alpha当前最新版本 edf318b， 仓库 ， Pre-Release

我这边测试是可以的，include-all-providers，geo-auto-update啥的都能用

我的问题 没仔细看策略组名字

[sf467]

目前2.9.10版本与alpha似乎不能显示测速信息了

是带有 自动测速，故障转移，负载均衡 这三个模式的代理组不显示，其他代理组不影响。原因就是之前暴力替换函数的事，我会提交新的pr修复该bug

实测主动选择的也没显示，无论该策略组内是否包含以上三种策略组

[qqyc]

目前2.9.10版本与alpha似乎不能显示测速信息了

是带有 自动测速，故障转移，负载均衡 这三个模式的代理组不显示，其他代理组不影响。原因就是之前暴力替换函数的事，我会提交新的pr修复该bug

我修改配置文件测试发现所有含有proxy-provider节点的proxy-group或者嵌套含有的group都不显示延迟测试结果，这是同一个bug吗？版本为最新的2.10.0

[CXwudi]

鉴于cmfa已经开始正常更新，我建议关闭这个issue并打开cmfa repo的issue板块来继续讨论cmfa

[Larvan2]

鉴于cmfa已经开始正常更新，我建议关闭这个issue并打开cmfa repo的issue板块来继续讨论cmfa

短期内不会开放cmfa的issue，cmfa仅提供最低限度的内核更新 除非有天兵接着开发

[CXwudi]

鉴于cmfa已经开始正常更新，我建议关闭这个issue并打开cmfa repo的issue板块来继续讨论cmfa

短期内不会开放cmfa的issue，cmfa仅提供最低限度的内核更新 除非有天兵接着开发

那discussion板块也可以

[aylz10]

@sf467 @qqyc @ForestL18 @Larvan2 已经提交新的PR了,修复延迟测试的bug MetaCubeX/ClashMetaForAndroid#176
我发现核心改写的新的 LastDelayForTestUrl(url) 函数
应该是设想的每个分组都可以按照配置文件里自定义的不同的url去测试延迟
但是在修复调试的过程中发现,核心并不是按照刚才猜想的那样工作的
连着测试会发现,已经自定义好的分组或者模式,也会使用默认的https://www.gstatic.com/generate_204 地址测试延迟并且返回数据
例如:我设置的fallback分组地址是http://test
按理说LastDelayForTestUrl(url)里的url我不管是赋值成http://test
还是说默认的地址https://www.gstatic.com/generate_204 都不应该返回延迟数据
测试的结果是函数 LastDelayForTestUrl("https://www.gstatic.com/generate_204") 还是可以返回延迟数据
希望可以解答下我的疑问,我现在修复的方式是从ExtraDelayHistories()提取url的值,然后传入LastDelayForTestUrl(url)

[lxy35326]

目前2.9.10版本与alpha似乎不能显示测速信息了

我的也是

[ForestL18]

@sf467 @qqyc @ForestL18 @Larvan2 已经提交新的PR了,修复延迟测试的bug MetaCubeX/ClashMetaForAndroid#176 我发现核心改写的新的 LastDelayForTestUrl(url) 函数 应该是设想的每个分组都可以按照配置文件里自定义的不同的url去测试延迟 但是在修复调试的过程中发现,核心并不是按照刚才猜想的那样工作的 连着测试会发现,已经自定义好的分组或者模式,也会使用默认的https://www.gstatic.com/generate_204 地址测试延迟并且返回数据 例如:我设置的fallback分组地址是http://test 按理说LastDelayForTestUrl(url)里的url我不管是赋值成http://test 还是说默认的地址https://www.gstatic.com/generate_204 都不应该返回延迟数据 测试的结果是函数 LastDelayForTestUrl("https://www.gstatic.com/generate_204") 还是可以返回延迟数据 希望可以解答下我的疑问,我现在修复的方式是从ExtraDelayHistories()提取url的值,然后传入LastDelayForTestUrl(url)

我也从源代码里发现了这个DefaultTestURL常量，然后找了一圈发现它在这个commit里被修改为默认引用。
所以你观察到的现象就合理了。

不过我对于把一份delay数据分别存history和extra还是感觉到很奇怪，于是我看到了这个issue，原来是为了兼容dashboard。

个人感觉这种处理好乱而且很冗余😖

希望大佬来探讨下这个问题。

[ForestL18]

@Larvan2 感觉这个pr可以合并了

[aylz10]

@sf467 @qqyc @ForestL18 @Larvan2 已经提交新的PR了,修复延迟测试的bug MetaCubeX/ClashMetaForAndroid#176 我发现核心改写的新的 LastDelayForTestUrl(url) 函数 应该是设想的每个分组都可以按照配置文件里自定义的不同的url去测试延迟 但是在修复调试的过程中发现,核心并不是按照刚才猜想的那样工作的 连着测试会发现,已经自定义好的分组或者模式,也会使用默认的https://www.gstatic.com/generate_204 地址测试延迟并且返回数据 例如:我设置的fallback分组地址是http://test 按理说LastDelayForTestUrl(url)里的url我不管是赋值成http://test 还是说默认的地址https://www.gstatic.com/generate_204 都不应该返回延迟数据 测试的结果是函数 LastDelayForTestUrl("https://www.gstatic.com/generate_204") 还是可以返回延迟数据 希望可以解答下我的疑问,我现在修复的方式是从ExtraDelayHistories()提取url的值,然后传入LastDelayForTestUrl(url)

我也从源代码里发现了这个DefaultTestURL常量，然后找了一圈发现它在这个commit里被修改为默认引用。 所以你观察到的现象就合理了。

不过我对于把一份delay数据分别存history和extra还是感觉到很奇怪，于是我看到了这个issue，原来是为了兼容dashboard。

个人感觉这种处理好乱而且很冗余😖

希望大佬来探讨下这个问题。

这个pr 删除LastDelay函数改换LastDelayForTestUrl函数的操作很是迷惑，按照他的设想，不是应该从extra里取延迟数据吗？并且为了兼容性的话，没必要删除原有的LastDelay函数。如果是为了应对ProxyProvider和ProxyGroup分别使用不同的url，那也应该加判断或者为了兼容性直接设计两个函数分别取用history和extra里的数据，否则没有必要判断url是否在extra里，但是却取用的是不包含url的history。因为如果核心严格按照配置文件里的测速地址去测试延迟的话，history里就不会有ProxyProvider的延迟数据，不需要增加url判断。如果想合并到一个函数里的话，直接设置可选参数，然后判断url是否存在在extra里，是的话就取里面的数据，否的话就提取history。这样兼容性和想实现的功能都有了

[aylz10]

@sf467 @qqyc @ForestL18 @Larvan2 已经提交新的PR了,修复延迟测试的bug MetaCubeX/ClashMetaForAndroid#176 我发现核心改写的新的 LastDelayForTestUrl(url) 函数 应该是设想的每个分组都可以按照配置文件里自定义的不同的url去测试延迟 但是在修复调试的过程中发现,核心并不是按照刚才猜想的那样工作的 连着测试会发现,已经自定义好的分组或者模式,也会使用默认的https://www.gstatic.com/generate_204 地址测试延迟并且返回数据 例如:我设置的fallback分组地址是http://test 按理说LastDelayForTestUrl(url)里的url我不管是赋值成http://test 还是说默认的地址https://www.gstatic.com/generate_204 都不应该返回延迟数据 测试的结果是函数 LastDelayForTestUrl("https://www.gstatic.com/generate_204") 还是可以返回延迟数据 希望可以解答下我的疑问,我现在修复的方式是从ExtraDelayHistories()提取url的值,然后传入LastDelayForTestUrl(url)

我也从源代码里发现了这个DefaultTestURL常量，然后找了一圈发现它在这个commit里被修改为默认引用。 所以你观察到的现象就合理了。

不过我对于把一份delay数据分别存history和extra还是感觉到很奇怪，于是我看到了这个issue，原来是为了兼容dashboard。

个人感觉这种处理好乱而且很冗余😖

希望大佬来探讨下这个问题。

因为本身前端并没有设计直接读取配置文件里的测速url并保存本地的功能，现在设计成这样，我只能愚蠢的到处去核心里找能提取url的函数，否则只能在前端添加读取配置文件里url并保存本地的功能

[ForestL18]

@aylz10 是的，感觉很迷，history感觉完全没有必要，extra就够了。本来就是拿url作为键值取数据，现在history里面没有url，那还取啥？

感觉还是要全部通过url来取数据，history里面存的数据也有可能是不同url的测试结果。

安卓端是否能通过调用这个函数来测试指定url的延迟呢？

[aylz10]

@aylz10 是的，感觉很迷，history感觉完全没有必要，extra就够了。本来就是拿url作为键值取数据，现在history里面没有url，那还取啥？

感觉还是要全部通过url来取数据，history里面存的数据也有可能是不同url的测试结果。

安卓端是否能通过调用这个函数来测试指定url的延迟呢？

现在安卓端使用的provider下的HealthCheck()接口。
安卓端本身是不解析配置文件的，都是交由核心去处理，然而核心并没有没有输出url地址的接口，所以如果想直接调用adapter下的URLTest接口的话很麻烦，要重写一套解析读取配置文件各个参数的操作。
但是这种实现方式一是比较冗余，二是如果配置文件格式有太大变动的话，还要去适配新的格式，本身这一系列操作都是核心完成的，前端基本上就是发送指令和接收数据而已
再说HealthCheck()本身就是按照分组url的方式去调用URLTest函数测试延迟的，没必要多此一举

[ForestL18]

@aylz10 是的，感觉很迷，history感觉完全没有必要，extra就够了。本来就是拿url作为键值取数据，现在history里面没有url，那还取啥？
感觉还是要全部通过url来取数据，history里面存的数据也有可能是不同url的测试结果。
安卓端是否能通过调用这个函数来测试指定url的延迟呢？

现在安卓端使用的provider下的HealthCheck()接口。 安卓端本身是不解析配置文件的，都是交由核心去处理，然而核心并没有没有输出url地址的接口，所以如果想直接调用adapter下的URLTest接口的话很麻烦，要重写一套解析读取配置文件各个参数的操作。 但是这种实现方式一是比较冗余，二是如果配置文件格式有太大变动的话，还要去适配新的格式，本身这一系列操作都是核心完成的，前端基本上就是发送指令和接收数据而已 再说HealthCheck()本身就是按照分组url的方式去调用URLTest函数测试延迟的，没必要多此一举

感觉这样做没啥问题，但最新的一个commit去除了select和relay组的默认testurl，那么现在select组测试延迟的时候默认url应该从哪获取呢？希望可以解答下我的疑惑。

[PuerNya]

@ForestL18 测试是前端传入的啊

[ForestL18]

@ForestL18 测试是前端传入的啊

安卓端也是前端传入的吗？可以帮忙指出在哪里吗？🙏

[aylz10]

@aylz10 是的，感觉很迷，history感觉完全没有必要，extra就够了。本来就是拿url作为键值取数据，现在history里面没有url，那还取啥？
感觉还是要全部通过url来取数据，history里面存的数据也有可能是不同url的测试结果。
安卓端是否能通过调用这个函数来测试指定url的延迟呢？

现在安卓端使用的provider下的HealthCheck()接口。 安卓端本身是不解析配置文件的，都是交由核心去处理，然而核心并没有没有输出url地址的接口，所以如果想直接调用adapter下的URLTest接口的话很麻烦，要重写一套解析读取配置文件各个参数的操作。 但是这种实现方式一是比较冗余，二是如果配置文件格式有太大变动的话，还要去适配新的格式，本身这一系列操作都是核心完成的，前端基本上就是发送指令和接收数据而已 再说HealthCheck()本身就是按照分组url的方式去调用URLTest函数测试延迟的，没必要多此一举

感觉这样做没啥问题，但最新的一个commit去除了select和relay组的默认testurl，那么现在select组测试延迟的时候默认url应该从哪获取呢？希望可以解答下我的疑惑。

虽然这个提交在ParseProxyGroup函数里取消了select和relay的默认url设置，但是NewHealthCheck函数里有加url判断，设置默认参数

[Larvan2]

那个PR的设想是可以给不同组设置不同url，但是由于核心和不同ui设置了不同的url，导致与预期表现不符，目前发现的bug有：

1. 导致节点频繁刷新存活状态，具体表现为某些面板上节点一会存活一会不可用
2. 可能会多次触发 hc

@aylz10 cmfa的bug是核心导致的，所以在这基础上也不好说合了这个PR会不会导致未来有更多的问题，不过我觉得可以先设置成和内核一致的内置url（https://www.gstatic.com/generate_204）来暂时规避上诉问题

[aylz10]

那个PR的设想是可以给不同组设置不同url，但是由于核心和不同ui设置了不同的url，导致与预期表现不符，目前发现的bug有：

1. 导致节点频繁刷新存活状态，具体表现为某些面板上节点一会存活一会不可用
2. 可能会多次触发 hc

@aylz10 cmfa的bug是核心导致的，所以在这基础上也不好说合了这个PR会不会导致未来有更多的问题，不过我觉得可以先设置成和内核一致的内置url（https://www.gstatic.com/generate_204）来暂时规避上诉问题

cmfa 原有提取延迟数据是调用的LastDelay接口获取的，该函数不需要传入参数即可获取history里的数据，但是因为核心有次提交把该函数改为了LastDelayForTestUrl有参函数，该函数里有判断url的语句，如果extra里没有该url的key就不从history里返回数据，所以cmfa才会有不显示延迟的bug，才有了这个pr，去适配新的LastDelayForTestUrl接口
我的建议是核心添加一个返回各个节点或者各个组 的 testurl地址数据的接口，这样就很容易去适配
或者可以加回LastDelay接口，这样cmfa还是使用原来LastDelay接口去获取数据，暂时规避了这个不显示延迟的bug，等核心处理好bug后再考虑是否弃用原有接口

[aylz10]

@Larvan2 cmfa的前端测试按钮设计的很简单，就是当前组里每个节点调用核心的HealthCheck()接口去测试延迟，测试完成后再刷新页面更新数据，取延迟数据是调用LastDelay()接口取当前组节点的最后一条延迟数据
所以前端并没有设置任何url，一切都是核心自己处理的
所以没有LastDelay()接口后，之前为了适配新的LastDelayForTestUrl(url)接口，暴力的直接设置了与核心内置url一样的url地址。这才导致有了因为配置文件里url与内置url不一致，测速完成后无法获取到延迟数据的bug

[h0cheung]

那个PR的设想是可以给不同组设置不同url，但是由于核心和不同ui设置了不同的url，导致与预期表现不符，目前发现的bug有：

1. 导致节点频繁刷新存活状态，具体表现为某些面板上节点一会存活一会不可用

2. 可能会多次触发 hc

@aylz10 cmfa的bug是核心导致的，所以在这基础上也不好说合了这个PR会不会导致未来有更多的问题，不过我觉得可以先设置成和内核一致的内置url（https://www.gstatic.com/generate_204）来暂时规避上诉问题

我自己试过的一个做法是调 DelayHistory() 接口，然后取返回值（切片）里最后一个对象的 Delay。没仔细阅读 url test 部分的逻辑，不是很确定，估计这样应该会得到（无论任何原因触发的）最后一次测速结果。

[aylz10]

那个PR的设想是可以给不同组设置不同url，但是由于核心和不同ui设置了不同的url，导致与预期表现不符，目前发现的bug有：

1. 导致节点频繁刷新存活状态，具体表现为某些面板上节点一会存活一会不可用

2. 可能会多次触发 hc

@aylz10 cmfa的bug是核心导致的，所以在这基础上也不好说合了这个PR会不会导致未来有更多的问题，不过我觉得可以先设置成和内核一致的内置url（https://www.gstatic.com/generate_204）来暂时规避上诉问题

我自己试过的一个做法是调 DelayHistory() 接口，然后取返回值（切片）里最后一个对象的 Delay。没仔细阅读 url test 部分的逻辑，不是很确定，估计这样应该会得到（无论任何原因触发的）最后一次测速结果。

嗯，跟原来LastDelay()接口的逻辑是一样的，都是该节点最后一次的测速结果
我迷惑的也就是新接口LastDelayForTestUrl(url)里取特定url的延迟数据这条判断语句。因为既然是最后一条延迟数据，那么不管他用什么url去测速的，那都是该节点最后一次测速的结果，根本没必要去判断这条数据的测速url来源，因为前端正常逻辑下要取用该数据的场景，肯定是先执行了测速指令或者是健康检查的

[ghost]

那个PR的设想是可以给不同组设置不同url，但是由于核心和不同ui设置了不同的url，导致与预期表现不符，目前发现的bug有：

1. 导致节点频繁刷新存活状态，具体表现为某些面板上节点一会存活一会不可用
2. 可能会多次触发 hc

@aylz10 cmfa的bug是核心导致的，所以在这基础上也不好说合了这个PR会不会导致未来有更多的问题，不过我觉得可以先设置成和内核一致的内置url（https://www.gstatic.com/generate_204）来暂时规避上诉问题

cmfa 原有提取延迟数据是调用的LastDelay接口获取的，该函数不需要传入参数即可获取history里的数据，但是因为核心有次提交把该函数改为了LastDelayForTestUrl有参函数，该函数里有判断url的语句，如果extra里没有该url的key就不从history里返回数据，所以cmfa才会有不显示延迟的bug，才有了这个pr，去适配新的LastDelayForTestUrl接口 我的建议是核心添加一个返回各个节点或者各个组 的 testurl地址数据的接口，这样就很容易去适配 或者可以加回LastDelay接口，这样cmfa还是使用原来LastDelay接口去获取数据，暂时规避了这个不显示延迟的bug，等核心处理好bug后再考虑是否弃用原有接口

我看代码，接口会返回 testUrl，应该是这个

[ForestL18]

@Larvan2 cmfa的前端测试按钮设计的很简单，就是当前组里每个节点调用核心的HealthCheck()接口去测试延迟，测试完成后再刷新页面更新数据，取延迟数据是调用LastDelay()接口取当前组节点的最后一条延迟数据 所以前端并没有设置任何url，一切都是核心自己处理的 所以没有LastDelay()接口后，之前为了适配新的LastDelayForTestUrl(url)接口，暴力的直接设置了与核心内置url一样的url地址。这才导致有了因为配置文件里url与内置url不一致，测速完成后无法获取到延迟数据的bug

感觉这个地方直接调用接口太粗暴了，导致在给含有include-all-providers参数的proxy group测速时，会默认把providers里面所有节点都测一遍，速度慢且没必要。

是否可以用一个parser来重新解析一下各个组含有哪些节点，这样就可以只测试proxy group里面的节点而不是providers的所有节点了。

[aylz10]

@Larvan2 cmfa的前端测试按钮设计的很简单，就是当前组里每个节点调用核心的HealthCheck()接口去测试延迟，测试完成后再刷新页面更新数据，取延迟数据是调用LastDelay()接口取当前组节点的最后一条延迟数据 所以前端并没有设置任何url，一切都是核心自己处理的 所以没有LastDelay()接口后，之前为了适配新的LastDelayForTestUrl(url)接口，暴力的直接设置了与核心内置url一样的url地址。这才导致有了因为配置文件里url与内置url不一致，测速完成后无法获取到延迟数据的bug

感觉这个地方直接调用接口太粗暴了，导致在给含有include-all-providers参数的proxy group测速时，会默认把providers里面所有节点都测一遍，速度慢且没必要。

是否可以用一个parser来重新解析一下各个组含有哪些节点，这样就可以只测试proxy group里面的节点而不是providers的所有节点了。

没用过provider这个配置，因为怕ip乱我日常使用最多的还是select，所以不太清楚provider相关的东西
你可以过滤掉providers，或者在设置里加个开关去判断是否需要测试providers里的节点
我更倾向于后者

[ForestL18]

@Larvan2 cmfa的前端测试按钮设计的很简单，就是当前组里每个节点调用核心的HealthCheck()接口去测试延迟，测试完成后再刷新页面更新数据，取延迟数据是调用LastDelay()接口取当前组节点的最后一条延迟数据 所以前端并没有设置任何url，一切都是核心自己处理的 所以没有LastDelay()接口后，之前为了适配新的LastDelayForTestUrl(url)接口，暴力的直接设置了与核心内置url一样的url地址。这才导致有了因为配置文件里url与内置url不一致，测速完成后无法获取到延迟数据的bug

感觉这个地方直接调用接口太粗暴了，导致在给含有include-all-providers参数的proxy group测速时，会默认把providers里面所有节点都测一遍，速度慢且没必要。
是否可以用一个parser来重新解析一下各个组含有哪些节点，这样就可以只测试proxy group里面的节点而不是providers的所有节点了。

没用过provider这个配置，因为怕ip乱我日常使用最多的还是select，所以不太清楚provider相关的东西 你可以过滤掉providers，或者在设置里加个开关去判断是否需要测试providers里的节点 我更倾向于后者

从源码看，不管是否使用include-all-providers参数，proxygroup里的节点都会被看作是一个provider中的参数。

但是cmfa直接调用ProxyProvider接口来进行测速的话，那就是把proxy group中所使用的provider里的所有节点一股脑全测了。

不知道我的分析对不对，希望大家一起讨论。

[FunnyShadow]

https://github.com/MetaCubeX/ClashMetaForAndroid/releases

不是，你们都看不见那个 Pre-Release 吗？？？
那玩意是自动同步最新版 mihomo 代码然后自动构建的啊？？？
真不行 Actions 里面也有构建好的安装包的
这个 Issue 的存在的意义是什么？？？

[FunnyShadow]

甚至这玩意 Jan 18 和 Feb 8 还更新了两次

[Paulgudring]

https://github.com/MetaCubeX/ClashMetaForAndroid/releases

不是，你们都看不见那个 Pre-Release 吗？？？
那玩意是自动同步最新版 mihomo 代码然后自动构建的啊？？？
真不行 Actions 里面也有构建好的安装包的
这个 Issue 的存在的意义是什么？？？

不是的，之前构建工作流、app内部都有bug，后来还有测速问题。

理解你的心情，不应该催开发者维护。

这个issue本来在恢复构建后应该关闭，但是cmfa没有维护者，所以保留用作讨论。