1 Introduction
I have been working in the R & D of the SDK for nearly two years. During this period, I have been maintaining and developing the company ’s Android data collection point SDK. Mainly want to briefly introduce some experience in the SDK development process through this summary.
1.1 What is SDK
I believe that students who do Android development must have used many third-party SDKs, such as the Aurora SDK, Alipay SDK, Weibo SDK, etc. The so-called SDK is a development kit, the full name is Software Development Kit, translated as a software development kit. SDKs are usually specific software packages 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 biased towards the user level, from UI display to business logic processing, handling user behavior throughout. The SDK development is more functional, focusing on functional development and lighter UI.
2. SDK design principles
2.1 Core principles
Core principle: It must be stable and not cause the collapse of the customer's app.
Since our SDK serves the 2B industry, there will be many apps to integrate our SDK, which requires that the core principles of the SDK cannot cause the collapse of customer apps. Once the SDK appears to cause a crash bug, this will have a disastrous impact on many apps. If this happens, it is very fatal. So for Android SDK development, pay attention to the use of try ... catch, object inspection, etc.
2.2 SDK design principles
First of all, it needs to be clear. On the one hand, the value of SDK is to bring value to the caller. Therefore, efforts should be made to reduce the difficulty of getting started and easy to understand. On the other hand, when the SDK code is easy to maintain.
1. Easy to use interface
When doing app development, I also complained that XX SDK is really difficult to use. Whether an SDK is easy to use depends on whether the design of the interface is simple and easy to use. For the access side, he will not pay attention to your implementation details. Businesses that can be done with one API interface will definitely not use 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 about the name, and the degree to which it can be used without the help of documentation shows that the naming of this interface is successful. For example, for the setOnClickListener interface 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 side can see which vendor's SDK it is after seeing the interface naming. In other words, the naming conventions of the SDK are unified to form the brand effect of your company. It is also convenient for the access party to use.
For coding standards, there are standard templates from various manufacturers on the Internet. You can choose one of them or customize the specifications of your own team to unify the coding style as soon as possible.
3. Try to be consistent across interfaces
For the same set of SDKs, try to keep the naming and implementation logic of each end interface consistent. In our development process, there is also a problem that the customers experience inconsistencies on Android and iOS due to the difference in logic between the cross-ends, and it will also bring additional support work. Therefore, for the design of requirements involving multiple terminals, detailed communication and confirmation must be carried out to prevent inconsistencies between 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 OkHttp for network requests, Glide for image loading, etc. However, in the development of the SDK, the general principle is to avoid using open source project libraries as much as possible. There are mainly the following reasons:
-
The reason is to avoid conflicts with the caller due to the use of the same library, increase the workload of caller integration, and reduce the experience of the integration party.
-
The open source library is constantly updated, so the SDK needs to be kept 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. SDK package should be as small as possible
The SDK package must be small and sophisticated.
Small means that the volume of the bag should be as small as possible. Avoid causing the access party's App to increase greatly, otherwise it will cause the access party's dissatisfaction and even get off the shelf.
Fine means that the function should be focused. For example, our SDK is used for buried points, and it is obviously inappropriate to provide many common tools in the design.
6. Compatibility
Compatibility is a problem that every developer will encounter. In the development of the SDK, it is necessary to ensure that the new version is compatible with the old version. Common compatibility issues fall into two categories.
New and old interface compatible
Generally, the problem of interface compatibility is mainly due to the imperfect consideration of the initial requirements, which leads to the change of the interface when the solution is optimized later, which makes the previous interface a historically difficult problem, which eventually makes the deletion difficult.
New feature compatibility
The compatibility issue here is divided into two aspects: App with new function and App without new function. For example, when our SDK was adapted to the OAID solution, because we needed to use the integration package provided by MSA to obtain it, but 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 its own library and provides the obtained code logic 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 this function is normally read. Some access parties do not use this function, to ensure that no abnormality occurs. Generally this kind of compatibility problem will determine the technical realization of the development scheme.
3. Integration and maintenance
3.1 SDK integration
The integration method should be diverse, flexible and convenient. For example, for Android, we provide methods such as maven and gradle dependency introduction, which are also recommended integration methods. However, due to network limitations, some access parties cannot directly rely on maven, so it is necessary to provide aar packages or source code for integration.
3.2 Integration guide
For SDK integration and use, as well as version updates and API interface introduction, you must prepare a relatively complete user access guide. For example, our SDK access guide is divided into:
- Basic use
- common problem
- Advanced applications
- Plugin configuration
- …
Although according to experience, some developers do not have the habit of looking at the documentation, but a complete guidance document is still very necessary, it can save a lot of integration costs and time.
At the same time, the document should pay attention to reasonable planning and design, to avoid too much content in a document, causing reading difficulties. For the usable part, it is best to have sample code to show.
3.3 Complete test report
In the actual access process, there are 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 assisted by R & D and testing together to output, which ultimately facilitates subsequent support work and reduces maintenance costs.
4. Development experience
4.1 Do not think too much demand
In the initial development of the SDK, a lot of requirements were often expanded by a simple requirement of the customer, resulting in the addition of multiple interfaces. Although the SDK seemed to be very flexible, the extra interfaces increased maintenance costs.
We once made a requirement to enable Fragment name collection. The requirement put forward by the customer is through file configuration, and then the SDK reads it. In the process of implementation, a lot of thinking happened.
- What if other customers don't want to use 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?
These too many requirements will add a lot of extra work and delivery costs, so you must avoid thinking too much in SDK development.
4.2 Configuration items do not encourage reading methods
There are often a lot of initialization switch configuration interfaces in the SDK. This type of interface generally exposes the set method for users to set. It is common to initialize the one-time configuration, so this type of configuration item generally does not need to provide a get method to prevent too many interfaces.
to sum up
So far I think of so much content, welcome to exchange, and follow up with better ideas to actively add.
