preface

Since I started working, I have been involved in the development of Android SDK for most of my time, and I have gained some experience more or less. Before, I accidentally answered a question about “what is the difference between APP development and SDK development” on Pulse. A few days ago, another friend asked a similar question, so I summarized it as a personal experience. However, after all, MY working experience is not long, may understand the place is not in place, please understand!

Views on SDK development

There’s a big difference between SDK development and APP development. APP is more inclined to user experience, functions are more oriented to specific business, and what it stresses is fast iteration and rapid market occupation. However, SDK serves for APP, and provides mostly public basic services, such as network request, registration statistics, account services, etc. Here are my views from a few points.

Volume and function

It can be described in three words: small and fine. Small means that the package volume should be as small as possible, because the business side may have such complaints when accessing: why does the package volume of APP increase several meters after connecting with your SDK? Will reduce the download rate… (tehe…) . Focus on the functionality of the SDK, make sure to focus on specific features, and abandon those self-righteous requirements. Trust the fickleness of the business to respond with new requirements, and then add functionality to the SDK.

Brief total cleaning:

In size: small! Small! Small!

  1. Remove useless resources (mainly images and so libraries) and code;
  2. Don’t rely on third-party libraries, or at least large ones, and consider porting open source code (just key code, with appropriate modifications to the SDK features if necessary);
  3. Optimize code structure to remove redundant code logic (consider various design patterns and subcontracting strategies);
  4. Obfuscation optimization during packaging;

Function:

  1. The SDK focuses on feature specificity, eliminating bells and whistles;
  2. Complete basic functions, applicable to all lines of business;
  3. Consider optimizing or enriching SDK functions according to the feedback from business side;

compatibility

There are several main considerations for SDK compatibility:

  1. External interface (API) compatibility: After each version update, the external interface should remain as unchanged as possible. For interfaces that have changed a lot, you can use the @deprecated annotation to mark the old interface and make the new interface call compatible, rather than simply deleting the old interface.
  2. Functional compatibility: Customization of requirements for parts of the business without affecting the overall functionality and project structure can form configuration items (trust me, the business side will come up with some messy requirements, we can’t afford to mess with them, so we have to provide configuration items…) .
  3. If part of the business is difficult to adapt, we can only open a new SDK branch to do the customized version of the business (try not to do this, you can discuss with the business, because too many branches are difficult to maintain later).
  4. Compatibility with Android versions supported by the SDK: The minSdkVersion value should be as small as possible, of course, most phones are above 4.4 on the market now. This also indirectly requires not to rely on third-party libraries.

The stability of

SDKS are extremely stable and need to work well in different APP environments. If there is a problem, a new version will be issued. On the one hand, all the business parties will be notified to update the version (which is a very troublesome thing), and on the other hand, the APP version update arrangement of the business party will be disrupted (this is a fixed problem…). .

So:

  1. Version iteration should be stable: Generally, the version number is X.Y.Z. For minor functions or fixes, the Z value can be increased without affecting services that have been launched.
  2. For the change of large version, after increasing y value or even X value, the PM should inform the business side to use the latest version SDK for the next release (if it is a big BUG fix, it must force the business side to update).
  3. The SDK must go through a complete test process before it goes online to ensure that its functions are correct, its performance meets requirements, and it ADAPTS to different models and Android versions. After the service provider is connected, the service provider can also perform a test and provide a feedback report.
  4. The structure design of SDK should have good expansibility. For example, a new function can not affect the overall code framework, otherwise it may cause some potential threats and increase the workload of testing.

security

It’s not just apps that need some security, SDKS need to be secure as well.

  1. SDK obmuddling, hardening, and security auditing are generally security controls at the company level. Do the corresponding repair for the security report.
  2. The protection of private data must be encrypted or masked. For example, the user’s login status is saved locally, and the mask of the mobile phone number is displayed.
  3. Departments generally have their own encryption mechanisms to encrypt data during network requests. Most of them use asymmetric encryption and symmetric encryption to imitate the SSL handshake protocol. More stringent, custom certificate validation can be added, but this is expensive.
  4. You need to provide a cloud control mechanism for some third-party functions or services connected to the SDK. Because of the instability and weak security of third-party services.

Document specification

This is a widely overlooked point, documentation is really important! Documentation is really important! Documentation is really important!

  1. The final form of the SDK must include access documentation and Demo. Most business people don’t read documentation, but you should write it (at least when it comes to dumping…). . As for demos, be sure to consider as many scenarios as possible and show what the SDK can do.
  2. The document should be as detailed as possible, but it is best not to put everything in one document, which can become too long and unpleasant for the business side to read. You can fine line the document, for example: How to access (JAR, AAR? Or is it an offline package or maven library? , how to use basic functions (most services only need basic functions), how to use customized functions, what problems may be encountered during access, and how to solve these problems, etc.
  3. It is better to have a Web page service platform (similar to an open platform) on which business parties can directly register, manage, read documents, etc. The service platform can also do some visualization of data statistics, which is convenient for the subsequent development of SDK.

conclusion

So that’s what I’ve learned about SDK development so far, and I’d like you to share some other ideas. As for APP development, I don’t have enough experience.

In general, the SDK has a life of its own, but it still serves the business, lives in the business, grows in the business, and is an integral part of the business.