Kivy 如何正确绑定Dropdown打开事件解决多实例失效问题

Kivy事件回调的基础传参规则 #

• 所有通过bind方法注册的事件回调，触发时的固定调用格式为：回调(触发事件的控件实例, 事件附带参数)。
• 如果你传入的是类实例的绑定方法（比如drpdn.open），方法本身已经隐式绑定了所属Dropdown实例作为第一个参数（即Python的self），理论上事件触发时传入的选择按钮实例，正好对应open方法要求的锚定控件参数，逻辑上是通顺的——这也是为什么单实例场景下，和官方示例一致的写法可以正常运行的原因。

随机失效的根本诱因 #

Kivy为了避免循环引用造成的内存泄漏，对所有注册的事件回调优先采用弱引用存储。

• 当你写selection_button.bind(on_release=drpdn.open)时，drpdn.open并不是Dropdown实例的永久内置属性，而是Python运行时临时生成的方法对象：每次访问这个属性时，解释器都会动态创建一个新的方法实例，这个临时对象本身没有任何强引用持有它。
• 这行绑定代码执行完成后，这个临时方法对象就失去了所有强引用，会被Python垃圾回收机制随时清理。Kivy存储的弱引用在原对象被回收后会自动失效，触发事件时自然找不到可调用的回调。
• 这个机制完全匹配观察到的所有异常表现：
  • 为什么效果随机：垃圾回收的时机是不确定的，部分临时方法对象可能在被回收前刚好赶上按钮的点击事件，就表现为“能正常打开”；大部分对象被回收后，点击按钮就没有任何反应。
  • 为什么只有最后创建的Dropdown能正常工作：最后一次循环生成的临时方法对象位于函数调用栈的最末端，通常会比前面的对象晚一点被回收，很多时候甚至会在程序运行初期一直保留在内存中，表现为只有最后一个按钮能触发下拉打开。
  • 为什么和官方示例写法一致却出问题：官方示例通常只创建1个Dropdown实例，生成的临时方法对象不会被立刻回收，所以看起来运行正常；一旦在循环里批量创建多个实例，临时对象增多、垃圾回收压力变大，就会出现回调被提前回收的随机失效问题。

你目前采用的functools.partial方案本身就是正确解法，本质是通过partial生成强引用的独立回调对象，避免了临时方法被GC回收的问题。
如果不想额外写open_dropdown中转函数，也可以直接绑定partial生成的简洁回调，不需要额外的中间函数：

selection_button.bind(on_release=partial(drpdn.open, selection_button))

这种写法的传参逻辑是：partial会预先把selection_button作为固定参数传给drpdn.open，事件触发时Kivy额外传入的控件实例、事件参数会作为最后一个位置参数追加到参数表末尾，完全不会出现参数错位，也不会有临时对象被回收的问题。

避坑提醒：不要在bind时直接传无强引用持有的临时可调用对象，包括直接绑定的实例方法、行内定义的lambda表达式。这类对象随时可能被垃圾回收清理，最终会出现绑定随机失效的问题。

内容的提问来源于stack exchange，提问作者Moje babicka