1 Reply Latest reply on Nov 8, 2014 1:59 PM by jbante

    FMGo ISO battery usage


      I notice that some of aps (iRadar, TomTom, etc) on my phone use way more battery than others.

      I have read that ISO8 now includes battery usage per ap.



      Has anyone looked at FMGo and DB design elements as they regard battery usage ?

        • 1. Re: FMGo ISO battery usage

          I haven't done specific testing, but my intuition is that the biggest power draws (that we have some control over as developers) are (in this order):


          1. Anything that uses a radio — communicating with a FileMaker Server, pulling data from other internet sources (web viewers, Insert from URL), geolocation (which uses radios for GPS, GLONASS, cellular protocols, and WiFi).
          2. Anything that asks the CPU to do any work.


          Cellular data connections will use more power than WiFi, so an application could save energy by doing less work (or warning the user) when using cellular data connections (determined by the Get ( NetworkType ) function). The biggest obvious energy use optimization is to use a local file on the iOS device that syncs with a server periodically rather than maintaining an active connection to the server. Such an application could do a more marginal optimization by refusing to sync with the server unless it can connect over WiFi, or prompting the user with a warning that syncing over cellular data will use more energy and asking for confirmation first.


          Applications that have to live on hosted files could do as much data processing as possible with Peform Script on Server, to minimize how much energy has to be used on radio traffic sending data back-and-forth between the device and the server. This also usually reduces how much work the iOS device's CPU has to do, so PSOS ("p-sauce") should improve energy use on two fronts. I imagine this probably holds true for any script that has to access and manipulate record data, but any "function scripts" that only process information from their parameters or work on global fields or never-committed data may be better off running client-side, since these shouldn't have any need to communicate with the host and, if I'm right, minimizing radio use may have a bigger impact on energy performance than CPU use.


          Any use of the Location or LocationValues function should use the worst accuracy (biggest number for the parameter) and/or shortest timeout you're comfortable with for each application. The better the accuracy you ask for, the longer the various radios used will stay on trying to get a better fix, and the more energy those radios will use.


          To achieve energy savings by reducing CPU usage, just do all the same performance optimizations you would do to make a file perform faster, because they're actually the same thing. From the software side, we can think of the CPU clock speed as a physical constant. Almost anything that runs faster does so by achieving the desired effect with fewer CPU cycles (or other resources). Many of the bigger performance optimizations in FileMaker come from minimizing network use, but those performance gains are less consistent because of the relatively temperamental nature of networks. All your optimizations for speed will also improve energy use. There are plenty of other resources and forum threads on how to achieve that, but the new Design: Performance white paper can get you started.