Android应用程序架构 - 基于事件或分层

Question

I'm building an SDK to be used in a hosting app. This SDK is going to be integrated in applications with a lot of users.

We started to build it with a layered architecture - UI, managers interacting with models and networking layer. Three layers total. The UI is getting updates by callbacks.

---

Side note: I was a member in teams that builded some Android applications with a lot of users, in all of them we used the same layered architecture. These applications have active users and there is a good feedbacks until now.

---

We have our beta version and it seems that everything is working as expected.

A week ago one of our team members come and say that he think we need to change our architecture to event driven based. We will have static event handles in the SDK that handle all the listeners and the dispatch will be triggered from some other component.

I think it's a bit risky, I think it will be hard to handle a large SDK with a lot of dependencies and services, in a multithreaded environment in that way. In addition, because we are building an SDK, we want to isolate our main classes form our host application, and I think it will be almost impossible.

My questions :

1. What do you think is the right way to go, is the layered architecture good and we need to stick with it, or the event based is the preferred one?

2. Do you think it's a suitable solution for an SDK that's needs to be as efficient as possible?

3. Do you think that this is a good solution for a multithreaded environment?

Appreciate any feedback, thanks.

some articles I have read:

architecting-android-the-clean-way

architectural-patterns-for-mobile-application-development

event-driven-programming-for-android

Answer 1

Android itself is based on an event-based model. An Android application uses a special thread, named the looper thread, to select events from an event queue one at a time, and processes them sequentially by executing their handlers. There may be additional regular threads that communicate between each other and the looper thread using conventional synchronization operations. The main role of a looper thread is to continuously check its event queue , select and process one event at a time.

To the best of my knowledge, the main motivation for Android to use event based model is that it has to handle alot of events (touch screen, click, sensors, network, internal and external events etc) and choice of event based model make sense.

If your main concern is concurrency and multitasking then Event driven and reactive models happens to be the better choice for multi-threading (or concurrency in general). But layered structure is not bad either, in-fact I think it is better.

At the end of the day, it depends on the nature of job. If you think what your SDK is proving, is similar to Android's job (handling massive events) then go for event based model otherwise layered structure is better.

If concurrency (Multi-threading) is your main issue and you want to exploit multi-core architecture and your jobs are CPU intensive then there are other architectures you should see.

Answer 2

while going through performance tips for android some time ago I came across following advice:

Always Measure

Before you start optimizing, make sure you have a problem that you need to solve . Make sure you can accurately measure your existing performance, or you won't be able to measure the benefit of the alternatives you try.

in short

If it ain't broke, don't fix it