1 Introduction

I have been engaged in the development of SDK for nearly two years. During this period, I have been maintaining and developing the company's Android data collection and embedding SDK. I mainly want to briefly introduce some experience in the SDK development process through this summary.

1.1 What is SDK

I believe students who do Android development must have used many third-party SDKs, such as Jiguang SDK, Alipay SDK, Weibo SDK, etc.

The so-called SDK is a development kit, its full name is Software Development Kit, which translates to software development kit. SDK is usually a specific software package written to assist in the development of certain types of software.

What is the difference between App development and SDK development? App development is more inclined to the user level, from UI display to business logic processing, handling user behavior throughout the process. The SDK development is more focused on the function, focusing on the development and realization of the function, and light on the UI.

2. SDK design principles

2.1 Core principles

Core principle: It must be stable and cannot cause the client App to crash.

Since our SDK serves the 2B industry, there will be many apps that integrate our SDK, which requires the core principles of the SDK not to cause the collapse of client apps.

Once the SDK appears to cause a crash bug, it will have a catastrophic impact on many apps. If this happens, it will be very fatal. So for Android SDK development, we must pay attention to the use of try...catch, object inspection, and so on.

2.2 SDK design principles

First, it needs to be clear. On the one hand, the value of SDK is to bring value to the caller. So try to reduce the user's difficulty in getting started and easy to understand. On the other hand, the SDK code is easy to maintain.

1. Interface ease of use

When doing App development, I also complained that the XX SDK is really hard to use. Whether an SDK is good or not, the key depends on whether the interface design is simple and easy to use. For the access party, he will not pay attention to your implementation details. For the business that can be done with one API interface, there is no need for two. Pay attention to the number of control interfaces.

On the other hand, ** pay attention to the naming of the interface. **The naming of a good API interface can make the caller think of it, and the degree to which it can be used without the help of the help document shows that the interface naming is successful. For example, for the interface setOnClickListener for setting click events in Android.

2. The naming convention should be unified

For SDK development, a unified naming convention is very important. The best state is that the ** access party can know which vendor’s SDK is by seeing the interface naming. **In other words, the naming convention of the SDK is unified, forming the brand effect of the company. At the same time, it is convenient for the access party to use.

Regarding coding standards, there are standard templates from various major manufacturers on the Internet. You can choose one of them or customize your own team's specifications to unify the code style as soon as possible.

3. Try to keep the cross-end interface consistent

For the same set of SDK, try to keep the interface naming and implementation logic consistent at each end.

During our development process, the problem of inconsistent customer experience on Android and iOS due to the logic difference between cross-ends also appeared, and it also brought additional support work.

Therefore, for requirements design involving multiple ends, detailed communication and confirmation must be carried out to prevent inconsistencies in interface naming and implementation.

4. Try not to rely on third-party libraries

With the popularity of open source, there are many classic open source projects on GitHub for developers to use. For App developers, open source projects are often used, such as network request OkHttp, image loading Glide, and so on. However, in the development of SDK, the general principle is to avoid using open source project libraries as much as possible. The main reasons are as follows:

The reason is to avoid conflicts caused by using the same library with the caller, increase the workload of the caller's integration, and reduce the experience of the integrator.
The open source library is constantly updated, so the SDK needs to be updated in time, which will increase the workload of additional maintenance.
Due to the introduction of open source libraries, it is difficult to troubleshoot problems.

5. The SDK package should be as small as possible

The SDK package must be small and precise.

Small means that the size of the bag should be as small as possible. Avoid causing the accessing party’s App to increase greatly, otherwise it will cause the accessing party’s dissatisfaction or even removal.

Elaboration means to focus on the function. For example, our SDK is used for burying points, and it is obviously inappropriate to design and provide many common tools in it.

6. Compatibility

Compatibility is a problem that every developer will encounter. In SDK development, it is even more important to ensure that the new version is compatible with the old version. Common compatibility issues fall into two categories.

Compatible with new and old interfaces

Generally, the problem of interface compatibility is mainly due to the imperfect consideration of the initial requirements, which leads to interface changes when the plan is optimized later, making the previous interface a historical problem, and ultimately making it difficult to delete.

New feature compatibility

The compatibility issue here is divided into two aspects: App with access to new functions and App without access to new functions. For example, when our SDK was adapted to the OAID solution, we needed to use the integration package provided by MSA to obtain it. However, it is generally not easy to integrate a third-party library in the SDK, so when designing this solution, we need to let The access party integrates the library itself, and the obtained code logic is provided in the SDK.

Finally, when determining the development plan, it is necessary to consider that some access parties use this function, and it is necessary to ensure that the function is read normally. Some access parties do not use this function, and it is necessary to ensure that there is no abnormality. Generally, this compatibility issue will determine the technical implementation of the development program.

3. Integration and maintenance

3.1 SDK integration

The integration methods should be diverse and flexible at the same time. For example, for Android, we provide methods such as maven and gradle dependency introduction, which are also recommended integration methods. However, for some access parties, due to network restrictions, they cannot directly rely on maven. Here, aar package or source code is needed to integrate.

3.2 Integration Guide

For the integration and use of the SDK, as well as the version update content and API interface introduction, a relatively complete user access guide must be prepared. For example, our SDK access guide is divided into:

Basic usage
FAQ
Advanced application
Plug-in configuration
...

Although based on experience, some developers do not have the habit of reading documents, but a complete guide document is still very necessary, it can save a lot of integration costs and time.

At the same time, you should pay attention to the reasonable planning and design of the document to avoid too much content in a document, which causes difficulty in reading. For the usability part, it is best to have sample code for display.

3.3 Complete test report

In the actual access process, many access parties need to provide relevant performance test instructions. This part of the content needs to be prepared early. The work of the test report can be developed and tested together to assist in the output, which ultimately facilitates the follow-up support work and reduces maintenance costs.

4. Development experience

4.1 Don't think too much demand

In the initial development of the SDK, a simple customer demand often expands many requirements, resulting in the final increase of multiple interfaces. Although the SDK appears to be very flexible, the additional interfaces increase a lot of maintenance costs.

We once did a requirement to enable Fragment name collection. The customer's requirement was to configure it through a file, and then the SDK read it. In the process of implementation, there was a lot of thinking and too much.

What if other customers do not want to pass the configuration file and want to use the interface?
What if the user wants to delete the configured items in the configuration file?
What if the customer wants to restore the ignored configuration?

Too much thinking about these requirements will increase a lot of extra work and delivery costs, so you must avoid thinking too much about requirements in SDK development.

4.2 The configuration item does not advocate providing a reading method

There are often many initialization switch configuration interfaces in the SDK. This type of interface generally exposes the set method for the user to set, and it is common to initialize a one-time configuration. Therefore, this type of configuration item generally does not need to provide a get method to prevent too many interfaces.

to sum up

There are so many things in mind at present, welcome to exchange, and actively supplement with better ideas in the follow-up.

What should I pay attention to when developing Android SDK?