this usually happens when you are executing huge processes in main thread. it's OK to skip frames less than 200. but if you have more than 200 skipped frames, it can slow down your application UI thread. what you can do is to do these processes in a new thread called worker thread and after that, when you want to access and do something with UI thread(ex: do something with views, findView etc...) you can use handler or runOnUiThread(I like this more) in order to display the processing results. this absolutely solves the problem. using worker threads are very useful or even must be used when it comes to this cases.

https://stacklearn.ir

我的应用程序也有同样的问题。但除了显示卡片列表和文本之外，它并没有做其他事情。没有在后台运行。但随后经过一些调查发现，卡片背景的图像设置导致了这种情况，尽管它很小(350kb)。然后我将图像转换为9patch图像使用 http://romannurik.github.io/AndroidAssetStudio/index.html。 这对我很管用。

我也有同样的问题。当我在另一台计算机上运行这段代码时，它工作得很好。然而，在我的系统上，它显示“应用程序可能在主线程上做了太多的工作”。

我通过重新启动Android工作室解决了我的问题[文件->无效缓存/重新启动->单击“无效并重新启动”]。

我在开发一个在网格布局上使用大量可绘制png文件的应用程序时遇到了同样的问题。我也尽量优化我的代码。但这对我来说行不通。然后我尝试减小这些png的大小。我猜它工作得绝对很好。所以我的建议是减少可绘制资源的大小。

UI线程延迟的另一个常见原因是SharedPreferences访问。当你调用PreferenceManager。getSharedPreferences和其他类似的方法，关联的.xml文件将立即在同一个线程中加载和解析。

解决这个问题的一个好方法是从后台线程触发第一次SharedPreference加载，越早越好(例如从你的Application类的onCreate开始)。这样，在您想要使用首选项对象时，首选项对象可能已经构造好了。

Unfortunately, sometimes reading a preference files is necessary during early phases of startup (e.g. in the initial Activity or even Application itself). In such cases it is still possible to avoid stalling UI by using MessageQueue.IdleHandler. Do everything else you need to perform on the main thread, then install the IdleHandler to execute code once your Activity have been fully drawn. In that Runnable you should be able to access SharedPreferences without delaying too many drawing operations and making Choreographer unhappy.

正如上面其他人回答的那样，“跳过55帧!”意味着应用程序中有一些繁重的处理。

对于我的情况，我的申请过程并不繁琐。我反复检查了所有内容，并删除了那些我认为有点沉重的过程。

我删除了片段、活动、库，直到只剩下骨架。但是问题仍然没有消失。我决定检查一下资源，发现我使用的一些图标和背景相当大，因为我忘记检查这些资源的大小。

因此，我的建议是，如果以上答案都没有帮助，您也可以检查您的资源文件大小。