Today I wanted to run Hongmeng locally, but found that the IDE only supports Windows, so I gave up. However, the analysis can still be done on paper. Looking at the official documentation , it is relatively simple now. The overall feeling is that it is not much different from the basic concepts of Android, such as the correspondence with Android components and the life cycle of components, which make people feel very familiar. Of course, this is just a form of expression, for example, support for multiple languages is different from Android. Another thing that I find more interesting is the engineering deconstruction of the Hongmeng app :
From the above, I feel that modularity and componentization should be considered by Hongmeng from the beginning. I guess the advantages and disadvantages it may bring:
- Better isolation: engineering isolation to better support business isolation. For example, for a relatively large app (you can refer to my other article- the architecture of the Android app platform ), perhaps each sub-business module can be used as a separate Feature, thereby reducing mutual dependence. For example, you can only compile Entry and your own Feature during local development, thereby reducing compilation time. When testing, the Feature can have better independence.
- More flexible deployment: Hongmeng’s official website describes Feature as a "dynamic feature module of the application". It feels that it should be able to support dynamic deployment and local hot updates. It is useful for improving update speed, reducing update costs (such as bandwidth), and adding new versions to users. Both have advantages. It can also support more flexible assembly, such as configuring different features in the same app for a certain market or certain hardware.
- Of course, flexibility will also bring other problems. For example, maintenance of various versions should be a big challenge. Now there are not only app versions, but also module versions, and explicit differences between module versions ( IDL) and implicit (business) interdependence; in addition, the app may have different flavors (the flexible assembly mentioned above), which should be troublesome to handle.
- Dynamic deployment and hot updates are also easy to bring about regulatory problems, and it is more difficult to review the published content. However, heat is more common in mobile games now, so there are still many precedents to study.
- There is also a more detailed aspect of how the system de-duplicates the same resources between different features without affecting their independence or app performance (such as loading time). For example, both FeatureA and FeatureB depend on one library at the same time. Is it necessary to prevent multiple libraries from being stored in the final project, which affects the app size?