unity控制程序等待_能源效率unity3d - 停止的应用程序等待用户交互

I am looking for a way to make my unity3d app sleep while waiting for user interaction (touch, mouse or keyboard event) or timer (minute-scale).

The app is closer to an e-book reader than a game. The user interaction is best described as reading a non-animated wall of text 99% of the time. Sometimes there is a background sound (max 5% of time), it is enabled by interaction. Target platforms are android, ios, and webplayer.

Rendering even a single texture with normal FPS can drain quite some energy (measured by hand, literally - the device is warm).

My main problem is I don't want to render the camera all the time, but i do need to react to user input with as little lag as possible - so lowering the FPS does not work well here (input waits for the next frame).

So, how can i halt the application waiting for user input in an energy-efficient way? Hints working for just one platform (like integrating a native API) are also welcome.

解决方案

Unity internal architecture is that of a game. There as an infinite loop consisted of Update() and Render() and it's runs as fast as it can. Probably, you can change this behaviour with custom plugin, so there is option №1.

Option №1. Unity is (still) single-threaded. But it is in multi-threaded managed environment. You may call Sleep in your script and application will sleep for a time with no Update() neither Render() invoked. The problem is that Unity run its input in the same thread. But in theory you can create custom plugin and implement input running in another thread. Therefore you will be able to put Unity to conditional sleep using something like WaitFor(customInput). Of course you will need separate implementation of plugin for each platform.

It is not an easy answer, huh? Yet there is another option.

Option №2. You can reduce power consumption if you ease the work (its obviously, I know). First, you don't need 60 frames per second in your app. Look for Application.targetFrameRate and vsync in quality setting (note that vsync overrides targetFrameRate). And second, cache your results. You can pre-render complex scene into render target and then present in on screen instead of source scene until considerably changes will be made.