As we know, Android provides a lot of different ways of passing information, such as the four major components AIDL between the local broadcast, processes, memory sharing between anonymous, Intent Bundle transfer, etc., then passed in so many ways, what type is more suitable for assembly components directly pass it.
Local broadcast, which is LoacalBroadcastRecevier. More communication is carried out within the same application of the provisions of the different components of the system, the benefits of that: a broadcast transmission will only spread in their APP, will not leak to other APP, other APP can not send a broadcast to their APP without interference by other APP. Like local broadcast intercom communications, low cost, high efficiency, but there is a drawback is that all communication mechanisms entrusted both with the system, any steps that we can not intervene during the transmission, uncontrollable, commonly used ratio is not a component of the communication process high.
AIDL between processes. The size of that process, and we tend to be components of the communication process in the thread, besides AIDL communication is part of system-level communications, the underlying mechanism to Binder, although Android provides a template for us to achieve, but often difficult to understand user interaction is more complex , often do not apply during the communication of applied components.
Anonymous shared memory. Such as using Sharedpreferences, in a scene in a multi-threaded, often thread-safe, which is a few more changes in store very little information, such as components in the configuration information, and so on.
Intent Bundle delivery. Including the transfer of explicit and implicit, explicit package name transfer needs clear path, components and assemblies often need to rely on each other, this departure from the components of the SOP (separation of concerns), if hidden away, not only would not be the package name path repeat, you need to define a set of rules, there is only one package name wrong path, investigation and it is also somewhat cumbersome, this approach tends to be more appropriate internal transfer between components, the external component dealing with other components use much scene.
The main difficulty is the modular inter-module no direct reference to the question of how to communicate (to replace the module with the module, which is nodule Android in development), we have learned the following main ideas:
- The establishment of a common module, each functional module needs to be exposed interfaces into a common module, implementation class in each module where there is an interface module management class in public in general is a map, at initialization, each module when their interfaces and implementation classes into the map (interface registration), each module requires additional module functions, function call (interface to access) to get through the interface implementation class. It was sort of like "SDK" way, a common module provides an interface and data structure for the function module, this is the easiest way to think of a way to also use a lot of projects early, the interface is of advantage as the structure clear and intuitive, easy to trace the call chain, for more friendly IDE (you can jump directly in the IDE), protocol changes directly reflected in the compilation, maintenance interface is simple. But the drawback is due to the registration of initialization, in strict accordance with the order of call registration, correct design life cycle, interdependent relationship chain design also takes time, and this process is "dangerous", all kinds of excuses is dependent variable .
- Event notification type, such as using EventBus events such as bus or RxBus way, this way although you can complete the corresponding cross-module, decoupling, but it is not the most recommended way, each time a type of communication should be defined, cumbersome, not suitable in essence, EventBus or RxBus more thought should be biased in favor of the notification, one to many, but the return value is not a good deal. The inter-module communication function are more likely to provide, generally one to one, sometimes synchronous return value, so the Event event bus should be the most inappropriate way.
- Using the routing framework, commonly used open source library has ARouter, ActivityRouter, etc., to achieve the jump between pages by Url, reducing the coupling between the pages, while ARouter also provide support services, this model may also be used in a lot of projects now ways, but I think this route may be more emphasis on the framework of the page jump scene, most of the projects can be achieved only interface provides simple page and jump between the module is sufficient, and because the characters are by protocol to represent strings, and form the interface is not as intuitive compared.
- Reflection mode: it can be called APP integrated in one another by the reflection module class or method, properties. Because reflection is hardcoded class path and class name, if another module class name changes, it will lead to reflection can not find the corresponding class, which can not achieve the jump page.
使用AIDL：https://cloud.tencent.com/developer/article/1151076
: AIDL IPC based https://www.ctolib.com/yifei8-ABridge.html
Modular practice summary: https://github.com/LiushuiXiaoxia/AndroidModular
US assembly process frame group: https://tech.meituan.com/2018/12/20/modular-event.html
Dry finishing blog: Android modular / component-based communication framework https://www.ctolib.com/heimashi-module-service-manager.html#articleHeader3
Google's official website examples:
https://developer.android.com/topic/libraries/architecture/index.html
https://developer.android.com/jetpack/docs/guide#best-practices
