Our team transformed an old project with 100,000 lines of Android code (E-COMMERCE system Management Console App) by using Small framework as a plug-in. The project was divided into more than 10 plug-in modules, which freed the code coupling between business modules and laid a good foundation for rapid iteration of business functions and multi-team parallel development. There were some problems during the migration, but they were basically solved with everyone’s efforts. I also want to thank The author Guangliang of Small for his quick response to the issue we proposed.

Application scenarios of Small

Compile time: Automated to help you separate the various common libraries, business module plug-ins (plug-ins only keep their own code and resources, to minimize) runtime: The minimum number of hooks can be used to seamlessly integrate each plug-in into the host, so that the code and resources can be fully integrated and called freely. Therefore, the purpose of Small is to ensure the “smooth development” experience of developers and the “smooth use” experience of App users, regardless of (2) that developers do not need to pay attention to.

There are many plug-in schemes, it is difficult to have a unified form, each has its own application scenarios. If you need to distribute your plugin for others to use, Small won’t suffice. If you want to use plug-ins to split and reorganize your apps, I think Small has been ahead of the game and will continue to do so.

Plug-in engineering (development) structures

1. Dependency management: Small uses the same ClassLoader to load different plug-ins. Therefore, dependencies in different plug-ins are visible to other plug-ins and hosts during runtime. 2. Communication between plug-ins: Plug-in development is generally multi-team parallel, and direct calls between plug-ins should be avoided to reduce coupling 3. Resource usage: Due to the feature of Small, the resources of the Runtime plug-ins can be accessed by each other, but the development needs to be organized and managed in a unified way, including naming and using resources safely.

The official recommendation for integrating the Small plug-in for older projects

The basic principle of

Do not put business logic in the host. Just load the plug-in and call the main plug-in.

Refactoring steps

  1. Lib.– Public module plug-ins

    Rip out each third-party library and make it into a ‘lib’.    Plug-in module, including statistics, maps, networks, pictures and other libraries.

    Separate the business common code (utils) accumulated in the old project and encapsulate it into a lib.utils plug-in

    Separate the basic styles and themes into a lib.style plug-in
  2. Open the app.– Service module plug-in

    Disassemble the business module into app.    Modules, they can rely onlib.Module to display the calllib.Each API in ‘

    The relatively independent business modules should be removed first, such as “details page” and “About us”. If the remaining businesses are not easy to be removed, they should be put into a plug-in first

    If they are not easy to dismantle, first put all business into a main plug-in app. Main

Communication between plug-ins

Communication/intermodulation between plug-ins Currently communication between plug-ins is limited to small.openuri (), which is used to call up pages from other plug-ins.

Sometimes, however, we need to manipulate other plug-ins. For example, before jumping to another plugin’s page, you need to check the status of that plugin. I think we should use LocalBroadcastManager for v4 package

Potholes encountered in the old project integration of Small plug-ins

  1. There is no problem getting data from startActivityForResult in the plug-in. This problem occurs if the Activity is launched in SingleTask startup mode.

  2. App1, which relies on both lib1 and lib2, cannot find classes when compiling.

  3. One lib is dependent on the other lib, but the Duplicate package error occurs at buildLib. BuildLib is dependent on the other lib, but the following error occurs at buildLib. Had to get rid of the dependence. The reason is unknown

  4. If the plug-in uses Baidu Map, etc., you need to put the relevant functions under a plug-in, note that the large. So is placed inside the plug-in

  5. Aar references are supported in the Small plug-in, which is actually used

  6. The Small 0.9 version of the plug-in limits package names, so existing code can be copied and changed. Pay special attention to the layout file custom ban package name changes, can be compiled but will not find the class at runtime. Custom package names are now supported in version 1.1

  7. Error This error occurs when you compile a single plug-in using assembleRelease. However, some computers can compile the plug-in separately.

    11:30:54 PM: Executing External Task 'assembleRelease'... Configuration on demand is an incubating feature. Incremental java compilation is an incubating feature. FAILURE: Build failed with an exception. * What went wrong: A problem occurred configuring project ':app.me'. > Could not find property 'android' on project ':app'. * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. BUILD FAILEDCopy the code
  8. The meta and Service of the third-party SDK need to be declared in the manifest of the host App, such as the positioning Service of baidu Map SDK.
  9. Public. TXT was deleted and lib and bundle were recompiled
  10. Some pages with tight coupling in the old code are not easy to disassemble, but can be used as a module. We finally disassembled 6 large modules.

  11. Gradle. Parallel =true in gradle.properties does not support gradle parallel compilation

      gradle  buildLib -q
[Small] [Small] building library 1 of 2 - app (0x7f)
[Small] [Small] building library 1 of 2 - app (0x7f)
building library 2 of 2 - lib.utils (0x73)

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':lib.utils:preBuild'.
 ./build-small/intermediates/small-pre-link/aar/app-D.txt (No such file or directory)Copy the code

    Refer to gradle documentation. This is not a Bug. Dependent projects cannot be compiled in parallel

We will continue to update when we encounter problems

Refer to the article

Github.com/wequick/Sma…