尝试使用以下策略来提高应用程序的性能:

尽可能使用多线程编程。即使你的智能手机只有一个核(如果处理器有两个或更多核，线程可以在不同的核上运行)，性能上的好处也是巨大的。让你的应用逻辑与UI分离是很有用的。使用Java线程，AsyncTask或IntentService。检查这个。 阅读并遵循Android开发网站的各种性能提示。检查在这里。

Android UI:修复跳过的帧

任何开始开发android应用程序的人都会看到这条消息 “编舞(abc):跳过xx帧!申请可以是 在主线上做了太多工作。”那么它实际上是什么 意思是，你为什么要担心以及如何解决它。

这意味着您的代码需要很长时间来处理和帧 都因为它而被跳过，这可能是因为一些沉重的 您在应用程序或数据库的核心所做的处理 访问或任何其他事情，导致线程停止一段时间。

Here is a more detailed explanation: Choreographer lets apps to connect themselves to the vsync, and properly time things to improve performance. Android view animations internally uses Choreographer for the same purpose: to properly time the animations and possibly improve performance. Since Choreographer is told about every vsync events, I can tell if one of the Runnables passed along by the Choreographer.post* apis doesnt finish in one frame’s time, causing frames to be skipped. In my understanding Choreographer can only detect the frame skipping. It has no way of telling why this happens. The message “The application may be doing too much work on its main thread.” could be misleading. source : Meaning of Choreographer messages in Logcat Why you should be concerned When this message pops up on android emulator and the number of frames skipped are fairly small (<100) then you can take a safe bet of the emulator being slow – which happens almost all the times. But if the number of frames skipped and large and in the order of 300+ then there can be some serious trouble with your code. Android devices come in a vast array of hardware unlike ios and windows devices. The RAM and CPU varies and if you want a reasonable performance and user experience on all the devices then you need to fix this thing. When frames are skipped the UI is slow and laggy, which is not a desirable user experience. How to fix it Fixing this requires identifying nodes where there is or possibly can happen long duration of processing. The best way is to do all the processing no matter how small or big in a thread separate from main UI thread. So be it accessing data form SQLite Database or doing some hardcore maths or simply sorting an array – Do it in a different thread Now there is a catch here, You will create a new Thread for doing these operations and when you run your application, it will crash saying “Only the original thread that created a view hierarchy can touch its views“. You need to know this fact that UI in android can be changed by the main thread or the UI thread only. Any other thread which attempts to do so, fails and crashes with this error. What you need to do is create a new Runnable inside runOnUiThread and inside this runnable you should do all the operations involving the UI. Find an example here. So we have Thread and Runnable for processing data out of main Thread, what else? There is AsyncTask in android which enables doing long time processes on the UI thread. This is the most useful when you applications are data driven or web api driven or use complex UI’s like those build using Canvas. The power of AsyncTask is that is allows doing things in background and once you are done doing the processing, you can simply do the required actions on UI without causing any lagging effect. This is possible because the AsyncTask derives itself from Activity’s UI thread – all the operations you do on UI via AsyncTask are done is a different thread from the main UI thread, No hindrance to user interaction. So this is what you need to know for making smooth android applications and as far I know every beginner gets this message on his console.

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

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

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

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

我不是专家，但当我想从我的android应用程序发送数据到web服务器时，我得到了这个调试消息。虽然我使用AsyncTask类并在后台进行数据传输，但为了从服务器获取结果数据，我使用了AsyncTask类的get()方法，这使得UI同步，这意味着你的UI将等待太长时间。所以我的建议是让你的应用程序在一个单独的线程上执行每个面向网络的任务。

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

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.

我也有同样的问题。 我的是一个案例，我使用的背景图像是在绘图。这个特殊的图像大约有130kB，在我的android应用程序的启动画面和主页上使用。

解决方案-我只是把特定的图像从drawables转移到drawables-xxx文件夹，并且能够释放大量的内存占用在背景和跳绳帧不再跳绳。

更新使用“nodp”可绘制资源文件夹来存储背景可绘制图 文件。 密度限定的可绘制文件夹还是drawable-nodpi优先?

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

我也有同样的问题。在我的情况下，我有2个嵌套的相对布局。RelativeLayout总是要做两个措施通过。如果你嵌套RelativeLayouts，你会得到一个指数测量算法。

优化你的图片…不要使用大于100KB的图片…图像加载占用太多CPU，导致你的应用程序挂起。

在这个问题上做了很多研究之后，我得到了解决方案，

在我的情况下，我使用的服务将运行每2秒和runonUIThread，我想知道问题是在那里，但根本没有。 我发现的下一个问题是我在五月的应用程序中使用大图像，这就是问题所在。

我删除了图像，并设置了新的图像。

结论:-检查你的代码是否有任何你正在使用的原始文件是大的。

我也有同样的问题。Android模拟器在Android < 6.0上运行良好。当我使用模拟器Nexus 5 (Android 6.0)时，应用程序在I/Choreographer:在日志中跳过帧时运行非常慢。

所以，我解决了这个问题，在Manifest文件hardwareAccelerated选项更改为true，像这样:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.myapplication">

    <application android:hardwareAccelerated="true">
        ...
    </application>
</manifest>

2022年1月更新。根据@M的评论。Ed:如果您的目标api为>= 14，则默认启用硬件加速。

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

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

首先阅读警告。它表示在主线程上有更多的负载。所以你要做的就是在线程中运行有更多工作的函数。

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

在我的例子中，这是因为我不小心在一个方法上设置了一个断点。一旦我清除了它，消息就消失了，性能提高了很多。

如果在应用程序中使用async/await功能，这是正常的。

因为我首先最好使用SVG图像而不是所有其他类型的图像，如果不可能，使用一些图像处理工具(如Adobe Photoshop或Fotosizer)压缩所有PNG和JPG资源。最简单的方法之一是在线图像压缩工具，像这样，它帮助我把所有的图像文件减少到初始大小的50%。

还没有解决，但会解决的。对于我的小项目，有一个可组合的功能(按钮)和逻辑来检查是否“com. com”。在启动模拟器时，我在相同的日志中有以下内容:

I/Choreographer: Skipped 34 frames!  The application may be doing too much work on its main thread.

这其实不是问题。当调试器运行了很长时间时，就会发生这种情况。取下制动点并再次检查。

对我来说，这是RoundedBackgroundColorSpan !在textview中，我删除了它(燃烧我的大脑来找到它，因为它没有出现在像Pixel 4 Xl或三星note 10+这样的真实智能手机中，也没有出现在模拟器中，但在芯片设备中如此缓慢的视图)。