Vewd’s New Service-Based Architecture for Linux: The Dev@Vewd Review

Co-authored by Åsa Karlsson

Vewd Core, our main HTML5 SDK, has quite a descriptive name as it sits at the core of all our products. This week we announced our annual update: Vewd Core 4.22.0. As usual, this update contains many new features, and you can get an overview here. In this article, we’re going to look at one of the most interesting for our customers with Linux-based devices: Vewd Core’s new Service-Based Architecture. 

But Wait, Why Vewd Core 4.22?

If you’re not familiar with our naming, Vewd Core 4.22 is our main version (4) targeting devices to be released in 2022. Why 2022 devices? Because we work to ensure Vewd Core’s compatibility with next year’s requirements from major OTT and video streaming platforms to help our customers pass certification testing. 

What is a Service-Based Architecture

At a high level, a service-based architecture relies on services as the primary functional unit of the architecture rather than having everything in a monolithic binary. In this case, we’ve implemented the browser functionality as a service so that the application connects to it and controls it with a Remote Procedure Call protocol (RPC). 

Vewd Core for Android TV has had a Service-based architecture for years, so we were excited to bring this to TVs running Linux.

Why Build the Browser as a Service?

With tens of millions of Linux shipments each year, Vewd Core is one of the most deployed HTML5 SDKs globally. In most previous implementations of Vewd Core on Linux devices, browser-based applications like an EPG, App Store, or Device UI would link our Core directly into the application as a library. This binary would often have most system applications running in a single process with a shared process space.  

The challenges with this approach are clear:

  • A crash in a third-party application can bring down critical applications running on the system.
  • Measuring and optimizing memory use is challenging as allocations from many components are on the same heap.
  • Tracing where an out-of-memory error or crash occurs becomes trickier.
  • Other components on the same heap limit the effectiveness of Vewd’s memory management tools and optimizations.
  • Different modules inside the same binary may require different versions or variants of libraries or toolchains, which causes many problems.

It was clear that the most robust solution was to decouple the browser engine from the remaining binary. By allowing the main system binary to invoke the browser service on an as-needed basis, we could realize substantial benefits, including:

  1. Memory space separation. Vewd Core now uses its own allocator and its own heap, breaking an old dependency inherent to the previous architecture. Our new architecture allows the main binary to freely use allocators other than Vewd Core’s malloc. It also improves the effectiveness of the Vewd memory allowance system by removing the distraction from external allocations.
  2. Decoupled life cycle. It’s possible to shut down and restart Vewd Core separately from the application, allowing for more dynamic memory and performance management. Crashes do not bring down all components, strengthening stability and security. It’s also easier to pinpoint the source of the crash and improve QA processes and time-to-fix.
  3. Improved performance. Having Vewd Core as a separate service means it can be better tuned and optimized for general applications and OTT streams. Vewd Core can start in the background to be ready when the user starts an application or be silently suspended or terminated to make memory available to other critical applications on the device.
  4. Easier updates. With a stand-alone browser service, updates can be performed on this component only. Customers can upgrade the browser core version more often, thus improving security.
  5. QA and configuration/memory tuning. Now testing Vewd on reference devices is directly applicable on customer production devices as the Browser Service Process runs very much in the same way.
  6. Easier alignment. Coordination of toolchain requirements and dynamic library dependencies between Vewd Core’s components (such as Chromium) and the customer’s software is no longer necessary. Now there’s a separation between Vewd Core dependencies and the main binary dependencies, making everyone’s lives easier.
  7. Increased security. Any crash in any application is a potential opportunity for malicious code to take over. The new architecture isolates Vewd Core in its own process and memory space, and a vulnerability in an application does not make Vewd Core vulnerable (and vice versa).

Application Considerations

Architectural changes can sound significant; we have put in a lot of effort to ensure a smooth transition. By ensuring API compatibility, we substantially decreased the amount of coordination we need with our customers. 

Compiling an application towards Vewd Core 4.22.x version will have no breaking code changes related to the Service Based Architecture in Vewd Core C++ APIs.

Of course, developers will need to update their binary to take full advantage of the new service-based architecture. There are memory, performance, and even security gains available.

  1. Start the browser early. Having the browser service running and initialized allows for faster startup times of apps and windows.
  2. Start and stop OMI windows and apps on demand. Only have the apps running that are in use to preserve memory.
  3. Put the browser service in hibernate mode when not in use to preserve platform resources. It is faster to resume a suspended browser compared to starting it from scratch.

That concludes our review of the Vewd Core’s new Service-Based Architecture on Linux. If you want to dive in more: 

Vewd Core overview

Download an Evaluation SDK 

For customers, more information can be found in the Release Notes and Documentation for Vewd Core 4.22.0