How it works
OS Monitor is built with 2 major components, the first compoenet is a native execute binary runs on background in order to collect system informaiton, the second component is an user interface which is responsbility for rendering data on screen.
When UI component sends a request, the background binary will collect and serilized data, the serilzed data will be transfer via IPC and render on screen.
The background binary works at single thread mode, the all requests are queued and processed, OS Monitor also avoid to serialze several times, the data only will be converted with flatBuffers once.
The latest version has been totally rewrote, the whole architecture is changed, 1.x ~ 2.x use JNI to collect data, it causes some problems that like maintenance and root permission, 3.x tries to solve issues and improve performance, it bases on new mechanism which introduces on the following section.
- Communication between Android App and native process via unix socket
- All requests or responses are serialized by Google flatBuffer
- Data could be reused if the request is equal in a short time
- Maximum 8 connections at same time
It bases on unix socket with a randomize name, if anyone knows the randomize name, he can easy hijack it with own app, a security token are used to prevent hijack, any connection need to offer a token for validating, otherwise, the connection will be disconnected.