Once upon a time, we once thought naively that Android plug-in was intended to add new features or add a complete module.
It took a lot of time and effort. After the project was implemented with the plug-in framework, we discovered that 80% usage of the plug-in is to fix online bugs. At this point, it has the same capabilities as hot fix tools such as Tinker and Robust, and even better than hot fix tools.
The App released a new version every two weeks. Generally, the new feature goes online at this point. On the other hand, the release strategy of many companies' Android App are affected by the new release of the iOS platform. New features need to wait for these two versions to be released. It is only when the Apple Store put the version of the iOS online, then the App of Android can be released. It is really not so busy to do.
In the past without plug-in framework, we did all kinds of development. We were scared to write bugs, if serious bug appeared, we must re-issue the upgraded version. With the plug-in framework, developers have no worries about the quality of the code ——anyway, if wrong, we can send a plug-in package to fix it quickly. After the app released, each plug-in will have one or two new releases every day.
The Android plug-in framework has become to a bug-fixing tool. This is the scene that we do not want to see.
In fact, the plug-in framework is more suitable for the games. For example, the King Glory, there will always be new skins, or a new hero role available every few days, even adjusting the roles attributes, all of these do not need to be released as a new version.
There is another use case for plug-in technology, that is ABTest, but it is not used widely. When the product manager want to determine which one will be selected for two styles of design, there will be two strategies which are made into the two plug-in packages, so that 50% of the users download the strategy A, the other 50% of the users download the strategy B. Checking the result after a week, such as the page conversion rate , it will tell you which strategy is better. That is Data-driven product.
In the previous section, it was mentioned about the componentization of Android. That is, with the independence of the business unit, the Android and iOS teams are split into their own business and have their own organization relationships. Therefore, it is necessary to split the different services of hotel ticket and train tickets into different modules. In componentization of Android, modules are still dependent on AAR, we can use Maven to manage these AAR.
This componentized model of Android is only applicable to the development stage. Once there is a bug in the on-line release or new features are to be released, all modules must be repackaged together to deploy the new release.
If we want to go further, then plug-in technology appeared. At this point, each service module is no longer AAR, but a packaged apk file, placed in the assets directory of the host App. In this way, after a release version, some module is updated, only the code of this module is repackaged, an incremental package is generated, and it is put on the server for the user to download.
It is the value of Android plug-in in enterprise application development. The small company only used the Android componentization and did not go into plug-in technology, such benefit was not acquired because of high development costs and low input-output ratio.