淺談一個優秀的 Android SDK 須要具有哪些要點

時間 2021-05-27

標籤 html android git github 網絡 ide 工具性能開發工具測試欄目 Android 简体版

原文原文鏈接

1、前言

從事 Android 研發的工做有五年多的時間了，最近兩年多的時間一直參與開發和維護神策數據 Android SDK[1]。兩年時間，從懵懵懂懂到略有心得，但願經過本文介紹下 SDK 開發過程當中的一些經驗。期待對你們有所幫助，更期待可以獲得你們的指導。html

正式介紹 SDK 開發經驗以前，咱們先來回答兩個問題：android

1. 什麼是 SDK ？

相信作過 Android 研發的同窗，對不少第三方的 SDK 應該不會陌生，例如：極光 SDK、支付寶 SDK、微博 SDK 等。SDK 的全稱是 Software Development Kit，翻譯過來是軟件開發工具包，一般是爲輔助開發某類軟件而編寫的特定軟件包。git

2. App 開發與 SDK 開發有什麼區別呢？

App 開發偏向於用戶層面，從 UI 展現到業務邏輯處理，全程處理用戶的行爲。而 SDK 開發偏向於功能方面，注重功能的開發實現，關於 UI 的設計與開發佔比不多。github

基於上述兩個事實，咱們來看下 SDK 開發中的一些開發原則。網絡

2、開發原則

2.1 基本原則

開發 SDK 中，最重要的一條基本原則是要儘量的穩定，不能影響集成方的功能（例如：不能出現 crash、不能出現性能問題等）。ide

隨着愈來愈多的客戶使用 SDK，對於 SDK 的要求愈來愈高。一旦 SDK 引發了崩潰等問題，會對許多 App 形成災難性的影響。所以，對於 Android SDK 的開發來講，要注意 try...catch 的使用、對象的檢查等。工具

2.2 設計原則

在保證基本原則的前提下，開發 SDK 還存在一些通用的設計原則，下面咱們來詳細介紹下。性能

首先，須要明確 SDK 的做用是爲集成方提供一些功能。所以，要努力下降用戶的上手難度，而且要易於理解。其次，要使 SDK 代碼易於維護。開發工具

具體而言，主要歸納爲下面幾點：測試

2.2.1. 接口易用性

對於接口主要注意兩點：

1. 控制接口數量

相信你們在作 App 開發時，都曾經抱怨過某個 SDK 真難用。一個 SDK 好很差用，關鍵就看接口的設計是否簡單易用。對於集成方來講，並不會關注 SDK 的實現細節，能用一個接口實現的業務，堅定不用兩個。

2. 注意接口命名

一個好的接口命名可以讓調用者見名知意。若是可以作到不須要藉助幫助文檔就能使用的程度，就說明這個接口命名是成功的。例如，對於 Android 中設置點擊事件的接口 setOnClickListener。

2.2.2. 編碼規範

對於 SDK 開發來講，統一編碼規範很重要，最好的狀態是集成方看到代碼就能知道是哪家廠商的 SDK。換句話說就是 SDK 的編碼規範統一，造成本身公司的品牌效應，同時也方便集成方的使用。

對於編碼規範，網上有衆多廠商的規範模板。能夠選擇其中一個或者自定義編碼規範，儘早統一代碼風格。

2.2.3. 跨端一致性

對於同一套 SDK，儘可能保持各端接口命名、實現邏輯的一致。在咱們的開發過程當中，也出現過因爲跨端之間的邏輯有差別，致使客戶在 Android 和 iOS 上體驗不一致的問題，這會帶來額外的支持工做。所以，對於涉及到多個端的需求設計，必定要進行詳細的溝通和確認，防止出現接口命名和實現不一致的狀況。

2.2.4. 避免依賴三方庫

隨着開源的普及，GitHub 上有不少經典的三方庫供開發者使用。對於開發者，會常用到三方庫。例如：網絡請求 OkHttp、圖片加載 Glide 等。可是，在 SDK 的開發中，通常的原則是儘可能避免使用三方庫。主要有如下幾點緣由：

避免與集成方因爲使用相同的三方庫引發的衝突，增長集成方的集成難度；
三方庫會不斷更新。若是引入三方庫，則 SDK 須要及時保持更新，會增長額外的維護工做量；
因爲引入三方庫，出現問題時致使排查困難。

2.2.5. 「小」而「精」

SDK 儘可能要作到「小」而「精」：

「小」是指 SDK 的體積要儘量的小。避免形成集成方的 App 體積增長較大，否則會引發集成方的不滿，甚至下架 SDK；
「精」是指功能要專一。例如：咱們的 SDK 是用於埋點，若是提供不少常見的工具類顯然是不合適的。

2.2.6. 兼容性

兼容性是每一個開發者都會遇到的問題。在 SDK 開發中更要保證新版本對於舊版本的兼容，常見的兼容性問題分爲兩類：

1. 新老接口兼容性

通常出現接口兼容性的問題主要是因爲最初需求考慮不完善，致使後面進行方案優化時引發接口的變動，使以前的接口成爲歷史的難題，最終形成刪除難度大。所以，功能接口設計要考慮擴展性。

2. 新功能兼容性

這裏的兼容性分爲兩個方面：接入新功能的 App 和未接入新功能的 App。

例如，當初咱們 SDK 適配 OAID 的方案時，因爲須要使用 MSA 提供的集成包才能獲取，可是在 SDK 中通常是不輕易集成一個三方庫的。

所以，在設計這個方案時，就須要讓集成方本身集成三方庫，SDK 中提供獲取的代碼邏輯。最終在肯定開發方案時，就須要考慮到一部分集成方使用了該功能，須要保證該功能正常讀取。一部分集成方沒有使用到該功能，要確保無異常出現。通常這種兼容性問題會決定開發方案的技術實現。

3、完善的文檔說明

3.1 接入指南

對於 SDK 的集成和使用、版本更新和接口介紹，必定要準備比較完善的用戶接入指南。例如，咱們的 SDK 接入指南[2]分爲：

基本使用 (Android)[3]
全埋點 (Android)[4]
SDK API (Android)[5]

儘管根據經驗來看，有些開發者沒有看文檔的習慣。可是一份完整的指導文檔仍是很是有必要，它能夠節省不少集成的成本和時間。

同時，文檔要注意合理的規劃設計。避免一份文檔內容太多，形成閱讀困難。對於使用性的部分，最好有示例代碼進行展現。

3.2 測試報告

在實際的接入過程當中，有不少集成方須要提供相關的性能測試說明，這部分的內容須要及早準備。測試報告能夠經過研發協助測試進行輸出，方便後續的支持工做，下降維護成本。

4、踩過的坑

4.1 不作臆想需求

在最初開發 SDK 時，常常會由客戶的一個簡單需求擴展爲不少需求，致使最終增長了多個接口。儘管看似 SDK 很是靈活，可是多出來的接口增長了不少維護成本。

例如，咱們作過一個開啓 Fragment 名稱採集的需求。客戶提出的需求是經過文件配置，而後 SDK 進行讀取，在實施的過程當中就出現不少臆想需求：

若是有別的客戶不想經過配置文件，想使用接口怎麼辦；
若是用戶想刪除配置文件中已配置項怎麼辦；
若是客戶想恢復忽略的配置怎麼辦。

這些臆想的需求，會增長不少額外的工做和交付成本，而且沒有實際的意義。所以，在 SDK 開發中必定要避免臆想的需求。

4.2 過多的接口

在 SDK 中常常會有不少初始化開關配置接口，這類接口通常是暴露 set 方法讓用戶去設置。一般在初始化時一次性配置，所以這類配置項通常就不須要提供 get 方法，避免接口太多。過多的接口會形成代碼的維護成本增長，包括後期須要兼容的成本都會增長。

4.3 跨端一致性

對於 SDK 研發來講，常會遇到同一個需求須要在 Android、iOS 和 Web 三端同步實現，這就須要三端的研發和測試同窗可以相互溝通，確保三端的邏輯實現一致。在這個過程當中，最難把控的就是細節點的一致性。出現細節不一致的問題，一般是因爲測試 case 很難覆蓋到，研發同窗沒有針對細節流程進行溝通交流而致使的。

所以，爲了不這類問題，對於細節點的方案實現可讓三端的研發同窗相互進行溝通交流，爭取在研發階段把不一致的細節暴露出來，防止出現線上不一致的問題。