androidsdk

When developing Android applications, we need to use the SDK provided by Google. When a certain module developed by us is universal enough, it can be packaged into SDK for other business parties to use. What is a good SDK class product? From the perspective of developers and access parties, I think the following points should be met:

For developers

  • Good maintainability
  • Reasonable design and strong expansibility
  • The code logic is clear and reasonable
  • Monitoring and data are well organized

For access party

  • Integration is simple, best done in one line of code
  • Access documents, access instance details
  • Low crash rate, small memory footprint, SDK as small as possible
  • Timely response to solve problems

The above sums up to be friendly to developers and friendly to access parties. When someone takes over the code they don’t have the urge to hit the keyboard or even drink you a ’82 Sprite. The business side feels refreshed when they plug into your SDK. Sum up a few points that I sum up in the development process below, throw off a brick to attract jade, discuss together.

Pay attention to the point

1. Know your code

The first one is that everyone is responsible for their own code logic.

2. Reasonable interface design

Keep interface design as simple as possible, especially on the business side, where there is less time to study your approach. The simpler the access, the lower the cost to the business.

3. Memory allocation and reclamation

Ask for appropriate memory, if the array only holds 10 data, there is no need to ask for 20 space sizes. Recycle unused resources in time. For applications with multiple processes, consider whether it is necessary to initialize the SDK in each process.

4. Choose third-party libraries carefully

What we want to do is an SDK class product, try not to use third-party libraries. Because it will increase the size of our SDK package. If you must use it, choose a stable third-party library and be aware of conflicts between third-party libraries. Your access party may also rely on this third-party library, even if your version is different. There are two options, depending on provided in your SDK. Second, change the package name of the third-party library to resolve conflicts (which can increase the size of the final application). You can use jarjar.jar to change the package name. Refer to this article

5, The app cannot be installed due to a conflict with ContentProvider authorities

<provider
    android:name="com.democome.SPContentProvider"
    android:authorities="com.democome.sdk.sp"
    android:exported="false"
    android:process=":push" />
Copy the code

In the event that multiple applications have access to the SDK, the second installation will not be able to install either. The name of the application component conflicts with that of the installed application.

<provider
    android:name="com.democome.SPContentProvider"
    android:authorities="${applicationId}.sdk.sp"
    android:exported="false"
    android:process=":push" />
Copy the code

6. Exception handling and logging

What exceptions are handled by the business side and what exceptions are thrown to the business side. I believe that if the exception is caused by the service party’s access problem, you can throw an exception to the service party. Some key processes print logs, which can be turned on or off.

7, Multi-process operation SharedPreferences

Using SharedPreferences for multiple processes is problematic. Although SharedPreferences have a MODE_MULTI_PROCESS model, it is also unreliable. The other process does not synchronize updates. The solution is to synchronize the processes using a ContentProvider.

8. Safety issues

A local denial-of-service vulnerability, in which the intent of getIntent() comes with empty, abnormal, or malformed data, causes the application to crash. The solution is to add a try catch.

9. Packaging management

Standard package management system, version management, release management and so on.

10. Aar resource name

The name of the resource in the AAR is prefixed to avoid referencing errors.

11, confusion

Depending on who you are, some of the big name SDKS are not confused.

12. Memory leaks

Use leakCanary to detect that there are no memory leaks.

13. Make statistics

SDK has a good runtime monitoring mechanism, which can be reported in some key places and crashes to obtain the RUNNING status of SDK in time and ensure the stability of runtime. However, the dot should not be too frequent to avoid the impact on the business side.

14, specific model adaptation

This point nothing to say, in fact, is also the most pit, all kinds of messy pit need to fill.

The above is some summary in the SDK development process, there will be updates to continue to supplement, if you have any experience or lessons in the development process, welcome to leave a message to exchange!

This article was created by Snow under a Creative Commons Attribution 4.0 international license. All articles are original or translated from Www.snow