大多数时候，只要有关于更新ActionBar选项的讨论（比如显示/隐藏项目），我看到人们通过调用invalidateOptionsMenu方法（或AppCompat等效方法）来再次强制onCreateOptionsMenu，这实际上是同样的事情之前它再次膨胀菜单，设置所有菜单项等等。所有这些工作，只是为了改变说...一个项目的可见性。
我在谷歌看到的所有样本中都看到了同样的事情。而对于我的生活，我无法弄清楚为什么所有这些无法完成的开销（膨胀菜单等）的原因，如果你只是保持菜单参考localy，并调用自定义方法说... adjustMenu（菜单菜单参考），它不必为菜单充气并再次创建它，而只是对已经创建的菜单进行必要的修改。所以这些东西： https://stackoverflow.com/a/7066901/905938
很可能有理由以谷歌的方式（通过强制onCreateOptionsMenu一次又一次），因为谷歌的样本做同样的事情，但由于我无法自己弄清楚原因，也许有人可以给我在这里，并指出我的原因。
答案 0 :(得分：1)
你应该只是在onCreateOptionsMenu（）中膨胀你的选项菜单。
如果只保留菜单参考localy
，则可以完成所有这些操作
您可以通过onPrepareOptionsMenu（菜单菜单）方法在本地执行此操作。这实际上是设置菜单项可见性的好地方。至于调用的重要性问题invalidateOptionsMenu（）;应该从两个角度来看待它的目的。
在API 11和片段介绍之前，对invalidateOptionsMenu的调用将表示应该再次调用onCreateOptionsMenu（）和onPrepareOptionsMenu（）方法。由于活动通常只有一个选项菜单，因此菜单对象可以保留在内存中，以便后续调用onCreateOptionsMenu（）更具响应性。
自API 11发布以来，选项菜单不再像以前一样存储在内存中，因为片段的引入意味着活动及其每个片段都可以有自己的选项菜单，并且片段可以在活动的生命周期中动态地改变，为每个片段存储一堆选项菜单是低效的，因为这些片段不能保证留在屏幕上。还要记住，在API 11+中，选项菜单项可以显示在操作栏上。将手机的配置从纵向更改为横向意味着可以在操作栏上显示更多选项菜单项，因此溢出菜单中的项目现在可以移动到操作栏本身。一个替代虽然较慢的解决方案是简单地重建所有屏幕上的碎片。从头开始的选项菜单。因此，对于API 11+，对invalidateOptionsMenu（）的调用可以被视为一个信号，表明活动的片段的布局已经改变，并且应该为两者调用onCreateOptionsMenu（）和onPrepareOptionsMenu（）方法。活动和目前正在托管的片段。
查看invalidateOptionsMenu（活动活动）here上的条目，了解有关使用invalidateOptionsMenu的原因的更多信息。