Android App high cpu usage and battery drain












0















I've been working on an android game for awhile now. I have the basic game implemented so now I'm going back and trying to optimize. It seems like the battery drain and CPU usage are too high for what I'm doing. I really only have my main thread and then all the drawing and updating is done on a separate thread.



Below is the code for the actual game thread that does updating and all the drawing. All of the actual code has been removed, what's left is what I've been experimenting with to figure out the abnormal CPU usage/battery drain.



So basically if I start the below thread with only an infinite while loop the app uses about 315mAh or about 9% of my phones battery in 30 minutes of use. If I start the thread with no code inside the run method so that it expires after one run through it uses roughly 70mAh or 2% of the phone battery in the same amount of time. The CPU usage also jumps from 2%-3% without the thread running to about 14%-15% when the thread running and just running the infinite loop.



To summarize it seems like running the thread with only an infinite while loop, that does nothing, increases the battery usage by 7% over 30 minutes. I don't see how this is possible and think I must be missing something. I'll keep working to figure this out but there's no more code to take out. If anyone has any suggestions or can provide some insight as to why this is happening I'd greatly appreciate it. Thanks in advance.



class InnerThread extends Thread
{
public InnerThread()
{
super();
}

public void run()
{
while(true){}
}
}









share|improve this question



























    0















    I've been working on an android game for awhile now. I have the basic game implemented so now I'm going back and trying to optimize. It seems like the battery drain and CPU usage are too high for what I'm doing. I really only have my main thread and then all the drawing and updating is done on a separate thread.



    Below is the code for the actual game thread that does updating and all the drawing. All of the actual code has been removed, what's left is what I've been experimenting with to figure out the abnormal CPU usage/battery drain.



    So basically if I start the below thread with only an infinite while loop the app uses about 315mAh or about 9% of my phones battery in 30 minutes of use. If I start the thread with no code inside the run method so that it expires after one run through it uses roughly 70mAh or 2% of the phone battery in the same amount of time. The CPU usage also jumps from 2%-3% without the thread running to about 14%-15% when the thread running and just running the infinite loop.



    To summarize it seems like running the thread with only an infinite while loop, that does nothing, increases the battery usage by 7% over 30 minutes. I don't see how this is possible and think I must be missing something. I'll keep working to figure this out but there's no more code to take out. If anyone has any suggestions or can provide some insight as to why this is happening I'd greatly appreciate it. Thanks in advance.



    class InnerThread extends Thread
    {
    public InnerThread()
    {
    super();
    }

    public void run()
    {
    while(true){}
    }
    }









    share|improve this question

























      0












      0








      0








      I've been working on an android game for awhile now. I have the basic game implemented so now I'm going back and trying to optimize. It seems like the battery drain and CPU usage are too high for what I'm doing. I really only have my main thread and then all the drawing and updating is done on a separate thread.



      Below is the code for the actual game thread that does updating and all the drawing. All of the actual code has been removed, what's left is what I've been experimenting with to figure out the abnormal CPU usage/battery drain.



      So basically if I start the below thread with only an infinite while loop the app uses about 315mAh or about 9% of my phones battery in 30 minutes of use. If I start the thread with no code inside the run method so that it expires after one run through it uses roughly 70mAh or 2% of the phone battery in the same amount of time. The CPU usage also jumps from 2%-3% without the thread running to about 14%-15% when the thread running and just running the infinite loop.



      To summarize it seems like running the thread with only an infinite while loop, that does nothing, increases the battery usage by 7% over 30 minutes. I don't see how this is possible and think I must be missing something. I'll keep working to figure this out but there's no more code to take out. If anyone has any suggestions or can provide some insight as to why this is happening I'd greatly appreciate it. Thanks in advance.



      class InnerThread extends Thread
      {
      public InnerThread()
      {
      super();
      }

      public void run()
      {
      while(true){}
      }
      }









      share|improve this question














      I've been working on an android game for awhile now. I have the basic game implemented so now I'm going back and trying to optimize. It seems like the battery drain and CPU usage are too high for what I'm doing. I really only have my main thread and then all the drawing and updating is done on a separate thread.



      Below is the code for the actual game thread that does updating and all the drawing. All of the actual code has been removed, what's left is what I've been experimenting with to figure out the abnormal CPU usage/battery drain.



      So basically if I start the below thread with only an infinite while loop the app uses about 315mAh or about 9% of my phones battery in 30 minutes of use. If I start the thread with no code inside the run method so that it expires after one run through it uses roughly 70mAh or 2% of the phone battery in the same amount of time. The CPU usage also jumps from 2%-3% without the thread running to about 14%-15% when the thread running and just running the infinite loop.



      To summarize it seems like running the thread with only an infinite while loop, that does nothing, increases the battery usage by 7% over 30 minutes. I don't see how this is possible and think I must be missing something. I'll keep working to figure this out but there's no more code to take out. If anyone has any suggestions or can provide some insight as to why this is happening I'd greatly appreciate it. Thanks in advance.



      class InnerThread extends Thread
      {
      public InnerThread()
      {
      super();
      }

      public void run()
      {
      while(true){}
      }
      }






      android cpu battery






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 18 '18 at 23:39









      EnvengeEnvenge

      315




      315
























          3 Answers
          3






          active

          oldest

          votes


















          1














          Loops with no delay or pacing are notorious for hogging CPU and battery. Think carefully about whether you really need to be processing continuously, or if once per frame, once per arbitrary time interval, or once each time some external event occurs would be sufficient. Try adding a small arbitrary delay in the loop, and you'll probably see an immediate improvement.



          Many games use a main game loop. That's a searchable term. Basically, an endless loop performs some computations, draws a frame, then usually sleeps for some time. (See SystemClock.sleep() vs. Thread.sleep().) Your main loop could pass a frame number and timestamp to the rest of your code. You might compute the positions of moving objects every frame, but you could do more complex things like update the AI of your enemies only at certain intervals of time or frames. If you use a game engine like Unity, the main loop is still there, but you don't write it yourself. You just write the code that it calls every frame.






          share|improve this answer


























          • So I thought this may be the issue. I tested and it is running at about 13,000 frames per second which is obviously way too high for what I need. The ideal is to get it going at 60 FPS. I've tried using System.nanotime to maintain the framerate but in that case the majority of the game code is running at 60 FPS but the code to keep the framerate maintained is still runnning at 13,000+ FPS. I can try maintaining the framerate in a different way, what is the preferred way to do a delay? SystemClock.sleep?

            – Envenge
            Nov 18 '18 at 23:57











          • @Envenge Edited.

            – Kevin Krumwiede
            Nov 19 '18 at 0:36











          • Really appreciate your help. I have experience with game loops and have one implemented I just removed the actual code to try to get the least possible code in my loop to make sure I wasn't having a memory leak or something, somewhere inside, that was causing the spike in cpu usage and battery drain. Multi-threading is a fairly new concept to me which I'm still trying to fully utilize. There's definitely a lot to learn I again appreciate your time and patience to explain things that may seem fairly obvious.

            – Envenge
            Nov 19 '18 at 4:12





















          0














          while(true) is a classical endless loop and probably not required in Java.



          it does not even matter on which thread it runs, it's most likely draining the juice.



          see Are "while(true)" loops so bad?






          share|improve this answer
























          • Hi, the while(true) loop is meant to be endless so it keeps the thread running to test battery drain of the thread by doing only a small amount of work. I wanted to minimize the amount of work the thread is doing to see how low I can get the battery drain and still have the thread running.

            – Envenge
            Nov 18 '18 at 23:49






          • 2





            @Envenge You're not minimizing the work. Spinning in while(true) is just as much work as performing some useful calculation.

            – Kevin Krumwiede
            Nov 18 '18 at 23:52








          • 1





            @Envenge as the other answer suggests, unless adding some easing... it will run at the maximum iteration speed and drain the battery rigorously. this is something which one possibly can do on an AC powered machine, but not a mobile device. there it's better to perform processing only when required.

            – Martin Zeitler
            Nov 18 '18 at 23:52













          • eg. when adding Thread.sleep(500) it would still iterate twice per second. but this is a workaround. reconsidering the fundamental business logic suggested.

            – Martin Zeitler
            Nov 18 '18 at 23:57













          • I've played with this a bit already but haven't quite found the best way to do it without slightly interfering with the gaming performance. I'll look into reorganizing the code and try putting the thread to sleep periodically. Thanks for your quick responses!

            – Envenge
            Nov 19 '18 at 0:00



















          0














          I went through and edited my code. Utilizing thread.sleep to limit the overall drawing and updating code to 60 frames per second. Also I made use of the Object.wait() and Object.notify() methods to reduce the unnecessary processing of the thread. I've seen huge improvements, thanks for the help, I really appreciate it. My problem was most definitely that I was wasting battery and CPU power processing nothing.






          share|improve this answer























            Your Answer






            StackExchange.ifUsing("editor", function () {
            StackExchange.using("externalEditor", function () {
            StackExchange.using("snippets", function () {
            StackExchange.snippets.init();
            });
            });
            }, "code-snippets");

            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "1"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53366550%2fandroid-app-high-cpu-usage-and-battery-drain%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            3 Answers
            3






            active

            oldest

            votes








            3 Answers
            3






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            1














            Loops with no delay or pacing are notorious for hogging CPU and battery. Think carefully about whether you really need to be processing continuously, or if once per frame, once per arbitrary time interval, or once each time some external event occurs would be sufficient. Try adding a small arbitrary delay in the loop, and you'll probably see an immediate improvement.



            Many games use a main game loop. That's a searchable term. Basically, an endless loop performs some computations, draws a frame, then usually sleeps for some time. (See SystemClock.sleep() vs. Thread.sleep().) Your main loop could pass a frame number and timestamp to the rest of your code. You might compute the positions of moving objects every frame, but you could do more complex things like update the AI of your enemies only at certain intervals of time or frames. If you use a game engine like Unity, the main loop is still there, but you don't write it yourself. You just write the code that it calls every frame.






            share|improve this answer


























            • So I thought this may be the issue. I tested and it is running at about 13,000 frames per second which is obviously way too high for what I need. The ideal is to get it going at 60 FPS. I've tried using System.nanotime to maintain the framerate but in that case the majority of the game code is running at 60 FPS but the code to keep the framerate maintained is still runnning at 13,000+ FPS. I can try maintaining the framerate in a different way, what is the preferred way to do a delay? SystemClock.sleep?

              – Envenge
              Nov 18 '18 at 23:57











            • @Envenge Edited.

              – Kevin Krumwiede
              Nov 19 '18 at 0:36











            • Really appreciate your help. I have experience with game loops and have one implemented I just removed the actual code to try to get the least possible code in my loop to make sure I wasn't having a memory leak or something, somewhere inside, that was causing the spike in cpu usage and battery drain. Multi-threading is a fairly new concept to me which I'm still trying to fully utilize. There's definitely a lot to learn I again appreciate your time and patience to explain things that may seem fairly obvious.

              – Envenge
              Nov 19 '18 at 4:12


















            1














            Loops with no delay or pacing are notorious for hogging CPU and battery. Think carefully about whether you really need to be processing continuously, or if once per frame, once per arbitrary time interval, or once each time some external event occurs would be sufficient. Try adding a small arbitrary delay in the loop, and you'll probably see an immediate improvement.



            Many games use a main game loop. That's a searchable term. Basically, an endless loop performs some computations, draws a frame, then usually sleeps for some time. (See SystemClock.sleep() vs. Thread.sleep().) Your main loop could pass a frame number and timestamp to the rest of your code. You might compute the positions of moving objects every frame, but you could do more complex things like update the AI of your enemies only at certain intervals of time or frames. If you use a game engine like Unity, the main loop is still there, but you don't write it yourself. You just write the code that it calls every frame.






            share|improve this answer


























            • So I thought this may be the issue. I tested and it is running at about 13,000 frames per second which is obviously way too high for what I need. The ideal is to get it going at 60 FPS. I've tried using System.nanotime to maintain the framerate but in that case the majority of the game code is running at 60 FPS but the code to keep the framerate maintained is still runnning at 13,000+ FPS. I can try maintaining the framerate in a different way, what is the preferred way to do a delay? SystemClock.sleep?

              – Envenge
              Nov 18 '18 at 23:57











            • @Envenge Edited.

              – Kevin Krumwiede
              Nov 19 '18 at 0:36











            • Really appreciate your help. I have experience with game loops and have one implemented I just removed the actual code to try to get the least possible code in my loop to make sure I wasn't having a memory leak or something, somewhere inside, that was causing the spike in cpu usage and battery drain. Multi-threading is a fairly new concept to me which I'm still trying to fully utilize. There's definitely a lot to learn I again appreciate your time and patience to explain things that may seem fairly obvious.

              – Envenge
              Nov 19 '18 at 4:12
















            1












            1








            1







            Loops with no delay or pacing are notorious for hogging CPU and battery. Think carefully about whether you really need to be processing continuously, or if once per frame, once per arbitrary time interval, or once each time some external event occurs would be sufficient. Try adding a small arbitrary delay in the loop, and you'll probably see an immediate improvement.



            Many games use a main game loop. That's a searchable term. Basically, an endless loop performs some computations, draws a frame, then usually sleeps for some time. (See SystemClock.sleep() vs. Thread.sleep().) Your main loop could pass a frame number and timestamp to the rest of your code. You might compute the positions of moving objects every frame, but you could do more complex things like update the AI of your enemies only at certain intervals of time or frames. If you use a game engine like Unity, the main loop is still there, but you don't write it yourself. You just write the code that it calls every frame.






            share|improve this answer















            Loops with no delay or pacing are notorious for hogging CPU and battery. Think carefully about whether you really need to be processing continuously, or if once per frame, once per arbitrary time interval, or once each time some external event occurs would be sufficient. Try adding a small arbitrary delay in the loop, and you'll probably see an immediate improvement.



            Many games use a main game loop. That's a searchable term. Basically, an endless loop performs some computations, draws a frame, then usually sleeps for some time. (See SystemClock.sleep() vs. Thread.sleep().) Your main loop could pass a frame number and timestamp to the rest of your code. You might compute the positions of moving objects every frame, but you could do more complex things like update the AI of your enemies only at certain intervals of time or frames. If you use a game engine like Unity, the main loop is still there, but you don't write it yourself. You just write the code that it calls every frame.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Nov 19 '18 at 0:36

























            answered Nov 18 '18 at 23:49









            Kevin KrumwiedeKevin Krumwiede

            6,43131952




            6,43131952













            • So I thought this may be the issue. I tested and it is running at about 13,000 frames per second which is obviously way too high for what I need. The ideal is to get it going at 60 FPS. I've tried using System.nanotime to maintain the framerate but in that case the majority of the game code is running at 60 FPS but the code to keep the framerate maintained is still runnning at 13,000+ FPS. I can try maintaining the framerate in a different way, what is the preferred way to do a delay? SystemClock.sleep?

              – Envenge
              Nov 18 '18 at 23:57











            • @Envenge Edited.

              – Kevin Krumwiede
              Nov 19 '18 at 0:36











            • Really appreciate your help. I have experience with game loops and have one implemented I just removed the actual code to try to get the least possible code in my loop to make sure I wasn't having a memory leak or something, somewhere inside, that was causing the spike in cpu usage and battery drain. Multi-threading is a fairly new concept to me which I'm still trying to fully utilize. There's definitely a lot to learn I again appreciate your time and patience to explain things that may seem fairly obvious.

              – Envenge
              Nov 19 '18 at 4:12





















            • So I thought this may be the issue. I tested and it is running at about 13,000 frames per second which is obviously way too high for what I need. The ideal is to get it going at 60 FPS. I've tried using System.nanotime to maintain the framerate but in that case the majority of the game code is running at 60 FPS but the code to keep the framerate maintained is still runnning at 13,000+ FPS. I can try maintaining the framerate in a different way, what is the preferred way to do a delay? SystemClock.sleep?

              – Envenge
              Nov 18 '18 at 23:57











            • @Envenge Edited.

              – Kevin Krumwiede
              Nov 19 '18 at 0:36











            • Really appreciate your help. I have experience with game loops and have one implemented I just removed the actual code to try to get the least possible code in my loop to make sure I wasn't having a memory leak or something, somewhere inside, that was causing the spike in cpu usage and battery drain. Multi-threading is a fairly new concept to me which I'm still trying to fully utilize. There's definitely a lot to learn I again appreciate your time and patience to explain things that may seem fairly obvious.

              – Envenge
              Nov 19 '18 at 4:12



















            So I thought this may be the issue. I tested and it is running at about 13,000 frames per second which is obviously way too high for what I need. The ideal is to get it going at 60 FPS. I've tried using System.nanotime to maintain the framerate but in that case the majority of the game code is running at 60 FPS but the code to keep the framerate maintained is still runnning at 13,000+ FPS. I can try maintaining the framerate in a different way, what is the preferred way to do a delay? SystemClock.sleep?

            – Envenge
            Nov 18 '18 at 23:57





            So I thought this may be the issue. I tested and it is running at about 13,000 frames per second which is obviously way too high for what I need. The ideal is to get it going at 60 FPS. I've tried using System.nanotime to maintain the framerate but in that case the majority of the game code is running at 60 FPS but the code to keep the framerate maintained is still runnning at 13,000+ FPS. I can try maintaining the framerate in a different way, what is the preferred way to do a delay? SystemClock.sleep?

            – Envenge
            Nov 18 '18 at 23:57













            @Envenge Edited.

            – Kevin Krumwiede
            Nov 19 '18 at 0:36





            @Envenge Edited.

            – Kevin Krumwiede
            Nov 19 '18 at 0:36













            Really appreciate your help. I have experience with game loops and have one implemented I just removed the actual code to try to get the least possible code in my loop to make sure I wasn't having a memory leak or something, somewhere inside, that was causing the spike in cpu usage and battery drain. Multi-threading is a fairly new concept to me which I'm still trying to fully utilize. There's definitely a lot to learn I again appreciate your time and patience to explain things that may seem fairly obvious.

            – Envenge
            Nov 19 '18 at 4:12







            Really appreciate your help. I have experience with game loops and have one implemented I just removed the actual code to try to get the least possible code in my loop to make sure I wasn't having a memory leak or something, somewhere inside, that was causing the spike in cpu usage and battery drain. Multi-threading is a fairly new concept to me which I'm still trying to fully utilize. There's definitely a lot to learn I again appreciate your time and patience to explain things that may seem fairly obvious.

            – Envenge
            Nov 19 '18 at 4:12















            0














            while(true) is a classical endless loop and probably not required in Java.



            it does not even matter on which thread it runs, it's most likely draining the juice.



            see Are "while(true)" loops so bad?






            share|improve this answer
























            • Hi, the while(true) loop is meant to be endless so it keeps the thread running to test battery drain of the thread by doing only a small amount of work. I wanted to minimize the amount of work the thread is doing to see how low I can get the battery drain and still have the thread running.

              – Envenge
              Nov 18 '18 at 23:49






            • 2





              @Envenge You're not minimizing the work. Spinning in while(true) is just as much work as performing some useful calculation.

              – Kevin Krumwiede
              Nov 18 '18 at 23:52








            • 1





              @Envenge as the other answer suggests, unless adding some easing... it will run at the maximum iteration speed and drain the battery rigorously. this is something which one possibly can do on an AC powered machine, but not a mobile device. there it's better to perform processing only when required.

              – Martin Zeitler
              Nov 18 '18 at 23:52













            • eg. when adding Thread.sleep(500) it would still iterate twice per second. but this is a workaround. reconsidering the fundamental business logic suggested.

              – Martin Zeitler
              Nov 18 '18 at 23:57













            • I've played with this a bit already but haven't quite found the best way to do it without slightly interfering with the gaming performance. I'll look into reorganizing the code and try putting the thread to sleep periodically. Thanks for your quick responses!

              – Envenge
              Nov 19 '18 at 0:00
















            0














            while(true) is a classical endless loop and probably not required in Java.



            it does not even matter on which thread it runs, it's most likely draining the juice.



            see Are "while(true)" loops so bad?






            share|improve this answer
























            • Hi, the while(true) loop is meant to be endless so it keeps the thread running to test battery drain of the thread by doing only a small amount of work. I wanted to minimize the amount of work the thread is doing to see how low I can get the battery drain and still have the thread running.

              – Envenge
              Nov 18 '18 at 23:49






            • 2





              @Envenge You're not minimizing the work. Spinning in while(true) is just as much work as performing some useful calculation.

              – Kevin Krumwiede
              Nov 18 '18 at 23:52








            • 1





              @Envenge as the other answer suggests, unless adding some easing... it will run at the maximum iteration speed and drain the battery rigorously. this is something which one possibly can do on an AC powered machine, but not a mobile device. there it's better to perform processing only when required.

              – Martin Zeitler
              Nov 18 '18 at 23:52













            • eg. when adding Thread.sleep(500) it would still iterate twice per second. but this is a workaround. reconsidering the fundamental business logic suggested.

              – Martin Zeitler
              Nov 18 '18 at 23:57













            • I've played with this a bit already but haven't quite found the best way to do it without slightly interfering with the gaming performance. I'll look into reorganizing the code and try putting the thread to sleep periodically. Thanks for your quick responses!

              – Envenge
              Nov 19 '18 at 0:00














            0












            0








            0







            while(true) is a classical endless loop and probably not required in Java.



            it does not even matter on which thread it runs, it's most likely draining the juice.



            see Are "while(true)" loops so bad?






            share|improve this answer













            while(true) is a classical endless loop and probably not required in Java.



            it does not even matter on which thread it runs, it's most likely draining the juice.



            see Are "while(true)" loops so bad?







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Nov 18 '18 at 23:41









            Martin ZeitlerMartin Zeitler

            15.7k33965




            15.7k33965













            • Hi, the while(true) loop is meant to be endless so it keeps the thread running to test battery drain of the thread by doing only a small amount of work. I wanted to minimize the amount of work the thread is doing to see how low I can get the battery drain and still have the thread running.

              – Envenge
              Nov 18 '18 at 23:49






            • 2





              @Envenge You're not minimizing the work. Spinning in while(true) is just as much work as performing some useful calculation.

              – Kevin Krumwiede
              Nov 18 '18 at 23:52








            • 1





              @Envenge as the other answer suggests, unless adding some easing... it will run at the maximum iteration speed and drain the battery rigorously. this is something which one possibly can do on an AC powered machine, but not a mobile device. there it's better to perform processing only when required.

              – Martin Zeitler
              Nov 18 '18 at 23:52













            • eg. when adding Thread.sleep(500) it would still iterate twice per second. but this is a workaround. reconsidering the fundamental business logic suggested.

              – Martin Zeitler
              Nov 18 '18 at 23:57













            • I've played with this a bit already but haven't quite found the best way to do it without slightly interfering with the gaming performance. I'll look into reorganizing the code and try putting the thread to sleep periodically. Thanks for your quick responses!

              – Envenge
              Nov 19 '18 at 0:00



















            • Hi, the while(true) loop is meant to be endless so it keeps the thread running to test battery drain of the thread by doing only a small amount of work. I wanted to minimize the amount of work the thread is doing to see how low I can get the battery drain and still have the thread running.

              – Envenge
              Nov 18 '18 at 23:49






            • 2





              @Envenge You're not minimizing the work. Spinning in while(true) is just as much work as performing some useful calculation.

              – Kevin Krumwiede
              Nov 18 '18 at 23:52








            • 1





              @Envenge as the other answer suggests, unless adding some easing... it will run at the maximum iteration speed and drain the battery rigorously. this is something which one possibly can do on an AC powered machine, but not a mobile device. there it's better to perform processing only when required.

              – Martin Zeitler
              Nov 18 '18 at 23:52













            • eg. when adding Thread.sleep(500) it would still iterate twice per second. but this is a workaround. reconsidering the fundamental business logic suggested.

              – Martin Zeitler
              Nov 18 '18 at 23:57













            • I've played with this a bit already but haven't quite found the best way to do it without slightly interfering with the gaming performance. I'll look into reorganizing the code and try putting the thread to sleep periodically. Thanks for your quick responses!

              – Envenge
              Nov 19 '18 at 0:00

















            Hi, the while(true) loop is meant to be endless so it keeps the thread running to test battery drain of the thread by doing only a small amount of work. I wanted to minimize the amount of work the thread is doing to see how low I can get the battery drain and still have the thread running.

            – Envenge
            Nov 18 '18 at 23:49





            Hi, the while(true) loop is meant to be endless so it keeps the thread running to test battery drain of the thread by doing only a small amount of work. I wanted to minimize the amount of work the thread is doing to see how low I can get the battery drain and still have the thread running.

            – Envenge
            Nov 18 '18 at 23:49




            2




            2





            @Envenge You're not minimizing the work. Spinning in while(true) is just as much work as performing some useful calculation.

            – Kevin Krumwiede
            Nov 18 '18 at 23:52







            @Envenge You're not minimizing the work. Spinning in while(true) is just as much work as performing some useful calculation.

            – Kevin Krumwiede
            Nov 18 '18 at 23:52






            1




            1





            @Envenge as the other answer suggests, unless adding some easing... it will run at the maximum iteration speed and drain the battery rigorously. this is something which one possibly can do on an AC powered machine, but not a mobile device. there it's better to perform processing only when required.

            – Martin Zeitler
            Nov 18 '18 at 23:52







            @Envenge as the other answer suggests, unless adding some easing... it will run at the maximum iteration speed and drain the battery rigorously. this is something which one possibly can do on an AC powered machine, but not a mobile device. there it's better to perform processing only when required.

            – Martin Zeitler
            Nov 18 '18 at 23:52















            eg. when adding Thread.sleep(500) it would still iterate twice per second. but this is a workaround. reconsidering the fundamental business logic suggested.

            – Martin Zeitler
            Nov 18 '18 at 23:57







            eg. when adding Thread.sleep(500) it would still iterate twice per second. but this is a workaround. reconsidering the fundamental business logic suggested.

            – Martin Zeitler
            Nov 18 '18 at 23:57















            I've played with this a bit already but haven't quite found the best way to do it without slightly interfering with the gaming performance. I'll look into reorganizing the code and try putting the thread to sleep periodically. Thanks for your quick responses!

            – Envenge
            Nov 19 '18 at 0:00





            I've played with this a bit already but haven't quite found the best way to do it without slightly interfering with the gaming performance. I'll look into reorganizing the code and try putting the thread to sleep periodically. Thanks for your quick responses!

            – Envenge
            Nov 19 '18 at 0:00











            0














            I went through and edited my code. Utilizing thread.sleep to limit the overall drawing and updating code to 60 frames per second. Also I made use of the Object.wait() and Object.notify() methods to reduce the unnecessary processing of the thread. I've seen huge improvements, thanks for the help, I really appreciate it. My problem was most definitely that I was wasting battery and CPU power processing nothing.






            share|improve this answer




























              0














              I went through and edited my code. Utilizing thread.sleep to limit the overall drawing and updating code to 60 frames per second. Also I made use of the Object.wait() and Object.notify() methods to reduce the unnecessary processing of the thread. I've seen huge improvements, thanks for the help, I really appreciate it. My problem was most definitely that I was wasting battery and CPU power processing nothing.






              share|improve this answer


























                0












                0








                0







                I went through and edited my code. Utilizing thread.sleep to limit the overall drawing and updating code to 60 frames per second. Also I made use of the Object.wait() and Object.notify() methods to reduce the unnecessary processing of the thread. I've seen huge improvements, thanks for the help, I really appreciate it. My problem was most definitely that I was wasting battery and CPU power processing nothing.






                share|improve this answer













                I went through and edited my code. Utilizing thread.sleep to limit the overall drawing and updating code to 60 frames per second. Also I made use of the Object.wait() and Object.notify() methods to reduce the unnecessary processing of the thread. I've seen huge improvements, thanks for the help, I really appreciate it. My problem was most definitely that I was wasting battery and CPU power processing nothing.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Nov 24 '18 at 18:28









                EnvengeEnvenge

                315




                315






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Stack Overflow!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53366550%2fandroid-app-high-cpu-usage-and-battery-drain%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    鏡平學校

                    ꓛꓣだゔៀៅຸ໢ທຮ໕໒ ,ໂ'໥໓າ໼ឨឲ៵៭ៈゎゔit''䖳𥁄卿' ☨₤₨こゎもょの;ꜹꟚꞖꞵꟅꞛေၦေɯ,ɨɡ𛃵𛁹ޝ޳ޠ޾,ޤޒޯ޾𫝒𫠁သ𛅤チョ'サノބޘދ𛁐ᶿᶇᶀᶋᶠ㨑㽹⻮ꧬ꧹؍۩وَؠ㇕㇃㇪ ㇦㇋㇋ṜẰᵡᴠ 軌ᵕ搜۳ٰޗޮ޷ސޯ𫖾𫅀ल, ꙭ꙰ꚅꙁꚊꞻꝔ꟠Ꝭㄤﺟޱސꧨꧼ꧴ꧯꧽ꧲ꧯ'⽹⽭⾁⿞⼳⽋២៩ញណើꩯꩤ꩸ꩮᶻᶺᶧᶂ𫳲𫪭𬸄𫵰𬖩𬫣𬊉ၲ𛅬㕦䬺𫝌𫝼,,𫟖𫞽ហៅ஫㆔ాఆఅꙒꚞꙍ,Ꙟ꙱エ ,ポテ,フࢰࢯ𫟠𫞶 𫝤𫟠ﺕﹱﻜﻣ𪵕𪭸𪻆𪾩𫔷ġ,ŧآꞪ꟥,ꞔꝻ♚☹⛵𛀌ꬷꭞȄƁƪƬșƦǙǗdžƝǯǧⱦⱰꓕꓢႋ神 ဴ၀க௭எ௫ឫោ ' េㇷㇴㇼ神ㇸㇲㇽㇴㇼㇻㇸ'ㇸㇿㇸㇹㇰㆣꓚꓤ₡₧ ㄨㄟ㄂ㄖㄎ໗ツڒذ₶।ऩछएोञयूटक़कयँृी,冬'𛅢𛅥ㇱㇵㇶ𥄥𦒽𠣧𠊓𧢖𥞘𩔋цѰㄠſtʯʭɿʆʗʍʩɷɛ,əʏダヵㄐㄘR{gỚṖḺờṠṫảḙḭᴮᵏᴘᵀᵷᵕᴜᴏᵾq﮲ﲿﴽﭙ軌ﰬﶚﶧ﫲Ҝжюїкӈㇴffצּ﬘﭅﬈軌'ffistfflſtffतभफɳɰʊɲʎ𛁱𛁖𛁮𛀉 𛂯𛀞నఋŀŲ 𫟲𫠖𫞺ຆຆ ໹້໕໗ๆทԊꧢꧠ꧰ꓱ⿝⼑ŎḬẃẖỐẅ ,ờỰỈỗﮊDžȩꭏꭎꬻ꭮ꬿꭖꭥꭅ㇭神 ⾈ꓵꓑ⺄㄄ㄪㄙㄅㄇstA۵䞽ॶ𫞑𫝄㇉㇇゜軌𩜛𩳠Jﻺ‚Üမ႕ႌႊၐၸဓၞၞၡ៸wyvtᶎᶪᶹစဎ꣡꣰꣢꣤ٗ؋لㇳㇾㇻㇱ㆐㆔,,㆟Ⱶヤマފ޼ޝަݿݞݠݷݐ',ݘ,ݪݙݵ𬝉𬜁𫝨𫞘くせぉて¼óû×ó£…𛅑הㄙくԗԀ5606神45,神796'𪤻𫞧ꓐ㄁ㄘɥɺꓵꓲ3''7034׉ⱦⱠˆ“𫝋ȍ,ꩲ軌꩷ꩶꩧꩫఞ۔فڱێظペサ神ナᴦᵑ47 9238їﻂ䐊䔉㠸﬎ffiﬣ,לּᴷᴦᵛᵽ,ᴨᵤ ᵸᵥᴗᵈꚏꚉꚟ⻆rtǟƴ𬎎

                    Why https connections are so slow when debugging (stepping over) in Java?