全局规则的编写过程分享 #41
Replies: 3 comments
-
大佬有试过使用match数组吗,可以精简规则,但是误触的概率可能比较大 |
Beta Was this translation helpful? Give feedback.
0 replies
-
用 match 数组精简规则确实是个好建议或许可以,但是感觉正如你所说误触的概率可能比较大🤔误触不太好解决。我原来解决误触的方法之一就是用结构来限制一些误触:
确保了 否定 组件离文本位置不会太远。 举个简单的例子就是任何页面都可能存在返回或关闭按钮,这个按钮的id或文本可能也包含对应的触发情况,但实际上它不属于广告的关闭或返回按钮 但这确实是个不错的建议,可以考虑解决🤔 |
Beta Was this translation helpful? Give feedback.
0 replies
-
完成使用 matches 优化精简规则 核心逻辑不变,只是从 由于广告部分大多没有 同时对已验证规则列表更新,详细见每次对应 commit 的评论 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
如何分类
一开始我打算的是在原项目已定义的 11种分类规则 的基础上分别抽取出通用规则作为全局规则
但在实际流程下来,发现其中
分段广告
和功能类
是比较难抽取或者说是没有必要抽取成通用全局规则的,因此最终确定下来了 9 种全局规则如何抽取
我使用了以下规则对原项目的所有 APP 规则进行了简单的爬取与相似度比较:
python代码
最终得到了结构如下的一个字典:
字典示例
这个字典是我总结通用全局规则的基础,我的
提示类
和青少年模式
全局规则都是在此基础上总结出来的。同时这个字典也为我的全局规则校验与误触测试提供了最小验证规则列表(我在每条全局规则合并的PR下都留下的
已验证规则列表整理
的来源)。由此实现了通用性,同时兼顾拥有了防止误触的能力。
而
广告类
的全局规则并不能用这个方式来实现通用全局规则的抽取。因为这些广告通常都五花八门。如果你写的规则过于宽泛十分容易出现误触的情况。所以在编写过程中我一般都是自信满满的写完一条规则,在测试下来最终发现出现了许多误触情况而无法解决最终陷入一筹莫展。
好在天无绝人之路,在总结抽取
提示类
和青少年模式
全局规则过程中,我意外的发现了可以抽取出一段表示拒绝的通用规则,来实现点击取消
,拒绝
等一切否定按钮或按键这让我转变了思路,最终确定了 全局规则 的基本规律是 公共文本 + 否定结构 来实现。
这也是
NEGATION_PART_RULE_TEXT
,NEGATION_PART_RULE_DESC
,NEGATION_PART_RULE_BUTTON
的来源同时由于原项目已经编写了开屏广告的通用规则(实际测试下来已经很完美了,所以这部分我没有修改),我从中获得了可以用来防止误触的
[childCount=0][visibleToUser=true]
用来限制所有全局规则应该点击的是:对用户可见的, 子元素为0 的组件。有了这个可以
表示拒绝的通用规则
,我们就可以通过 广告文本 + 否定结构 来实现广告类
的全局规则编写,同时还可以确保不会出现误触的情况。因为我们通过三点确保了通用性与防止误触的能力。
如何确定文本 + 否定结构之间的链接方式?
这也是我通过大量的规则总结中抽取出来的三条最基本的结构
<n * >
<n * > * >n
<<n * <n * > * >n
它们的泛化性是递增的
使用父子关系来确定元素比使用兄弟关系来确定元素有更好的泛化性,因为有时候一些规则 A组件 和 B组件的位置谁前谁后是不一样的。但是它们都是某个元素的子组件。可以从下面的结构示意来更好的理解这三条结构
<n * >
:我们使用 公共文本 + 否定结构 的结构来看,弹窗 对应的是 公共文本,而 关闭按钮 对应的是 否定结构。使用<n * >
可以确保二者的位置谁在上谁在下都可以匹配而剩下两条也是同理,只是对应的跨度更大而已,本质上也是使用父子关系来代替兄弟关系来达到更好的泛化性
最终实现我们了所有基本全局规则的抽取总结,同时留下了最小验证规则列表。
后话
其实在编写过程中还有存在许多废案,例如一开始我对
广告类
的全局规则编写是打算硬抽组件 id 的规律来实现,但是发现这样编写实在是太容易误触了,比如许多广告组件 id 存在'iv'相关字样,但是实际编写下来许多不是广告组件的 id 也存在'iv'字样,又有许多广告组件甚至没有 id,导致不得不放弃写了半天的规则等等(这也是全屏广告
通用规则只兼容了部分SDK的原因)。这里不得不吐槽一下开发规范的重要性。其实这套思路还有很多的不足,例如规则因为使用了文本导致需要同时考虑 text 和 desc 字段等一些导致全局规则当前还比较臃肿,多语言兼容比较麻烦的原因。
但是这也是这衡量了通用和防误触之间平衡利弊的结果。
对原项目的1K3+规则压缩到现在的百来条已经很不错了。
共勉。
Beta Was this translation helpful? Give feedback.
All reactions