When you first launch Google Chrome, it spawns 8 helper processes in addition to the parent process. If you do nothing, within a minute or two, there are only three helper processes left. It does not reduce these further.
When you observe the Energy impact of Google Chrome in Activity Monitor, you will see that it alternates between a top slot, and the next energy consuming application. When I apply a SIGSTOP from the Terminal to the parent process, the Google Chrome name in Activity monitor changes to red letters as in the following capture, but still fluctuates up and down beneath Safari in Energy usage. Applying the SIGCONT signal does not really change its Activity energy behavior. Again, this paragraph is based on a dormant Google Chrome with the default Google landing page. You will also observe that the SIGSTOP changes the App Nap status to NO, and SIGCONT enables App Nap again.
My thought is that memory used in the Mac is a source of variable battery drain. It takes CPU resources for the scheduler to check, or change the run state of processes, even when they are sleeping. I do not believe that you will be conserving battery power by running a script or launchctl process to check on an application status, or by changing its run state between SIGSTOP, or SIGCONT — when it is likely sleeping anyway if it is not the frontmost process.
Just for fun, the following Bash script syntax will return the run state, and PID for the parent Google Chrome process.
app="Google Chrome"
rstate=$(ps axco comm,state,pid | sed -En "s/^$(echo $app)[ \t]+([a-zA-Z\+]+)[ \t]+([0-9]+)/\1 \2/p")
echo $rstate
S 1317
The best bet would be to quit Google Chrome when not in use, or (personal taste) use another less resource intense browser on a portable Mac.
