对 Android SDK 开发的一些个人心得

对 Android SDK 开发的一些个人心得

Android小彩虹2021-07-10 19:34:30150A+A-

前言

自从工作以后,大部分时间都是参与 Android SDK 方面的开发工作,满打满算也有两年时间了,多多少少有点心得体会。之前偶然在脉脉上回答了一个“APP 开发和 SDK 开发有什么区别”的问题,前几天又有朋友问到了类似的问题,所以我总结了一下,算是个人心得吧。不过,毕竟我工龄不长,可能理解有不到位的地方,还请谅解!

对 SDK 开发的看法

SDK 开发和 APP 开发的区别还是很大的。APP 更倾向于用户体验、功能更偏于特定业务、讲究的是快速迭代、快速占领市场。而 SDK 是为 APP 服务的,提供的大多是公共基础服务,如网络请求、打点统计、帐号服务等。下面从几个点说说我的看法。

体积和功能

可以用三个字形容:小而精。是指包的体积要尽可能的小,因为业务方接入的时候可能会有这样的抱怨:怎么接了你们的 SDK 后 APP 的包体积涨了好几 M 啊?会降低下载率的...(嘤嘤嘤...)。针对的就是 SDK 的功能了,一定要专注于特定功能,舍弃那些自以为是的需求。要相信多变的业务方一定会反馈新需求的,到时候再对 SDK 的功能进行补充即可。

简短总洁一下:

体积上:小!小!小!

  1. 去除无用资源(主要是图片和 so 库)和代码;
  2. 不要依赖第三方库,至少大体积的库是不可以的,可以考虑移植开源代码(只需移植关键代码,有必要的话根据 SDK 特性做适当修改);
  3. 优化代码结构,去除冗余的代码逻辑(考虑各种设计模式和分包策略);
  4. 打包时进行混淆优化;

功能上:

  1. SDK 讲究功能专一,去除那些花里胡哨的东西;
  2. 基本功能完善,适用于所有的业务线;
  3. 根据业务方的需求反馈,考虑优化或者丰富 SDK 功能;

兼容性

SDK 的兼容性主要考虑几个方面:

  1. 对外接口( API )的兼容性:每次版本更新后,对外接口要尽可能保持不变。对于更改较大的接口,可以使用 @Deprecated 注解对老接口进行标记,并且做新接口调用的兼容,而不是直接删除老接口。
  2. 功能的兼容性:在不影响整体功能和项目结构的基础上提供部分业务的需求定制化,可以形成配置项(相信我,业务方肯定会提一些乱七八糟的需求的,咱惹不起,只好提供配置项了...)。
  3. 如果部分业务较难适配,那只能新开 SDK 分支,做业务的定制化版本(尽量不要这么干,可以和业务商量,因为分支太多后期很难维护)。
  4. SDK 支持的 Android 版本的兼容性:minSdkVersion 的值应该尽可能的小,当然现在市场上基本都是 4.4 以上的手机了。这也从侧面要求不要随便依赖第三方库。

稳定性

SDK 极其注重稳定性,要保证在不同 APP 环境下都能正常工作。如果出现问题就会导致发新版本,一方面要通知所有业务方做版本更新(这是一件很麻烦的事),另一方面会打乱业务方 APP 的版本更新安排(这个锅背定了...)。

所以:

  1. 版本迭代要稳定:一般版本号都采用 x.y.z 模式,对于小功能或者是小的修复,增加 z 值即可,不能影响已经上线的服务。
  2. 对于大版本的改动,增加 y 值甚至 x 值后,需要让 PM 告知业务方下次发版时使用最新版本的 SDK (如果是大 BUG 的修复,那就必须强制要求业务方更新了)。
  3. SDK 上线前必须经过完整的测试流程,保证功能正确、性能达到要求、对不同机型进行适配、对不同 Android 版本进行适配。业务方接入后,可以让业务方也走一遍测试,提供反馈报告。
  4. SDK 的结构设计应该要有好的扩展性,比如接入一个新功能,就不能影响整体的代码框架,否则可能造成一些潜在的威胁,也会增加测试的工作量。

安全性

不光是 APP 需要一些安全措施,SDK 也是有必要保证安全性的。

  1. SDK 混淆、加固、安全审核,这个一般是公司级别的安全管控。针对安全报告做对应修复即可。
  2. 隐私数据的保护,必须进行加密或者掩码处理。比如:本地保存用户的登录态,手机号的掩码显示等。
  3. 网络请求时的数据加密保护,部门一般都有自己的加密机制,大部分都是模仿 ssl 握手协议,采用非对称加密和对称加密结合的方式。更严格的话,可以增加自定义证书校验,不过这个成本较高。
  4. 对于 SDK 中接入的部分第三方功能或者服务需要提供云控机制。因为第三方服务存在不稳定性和弱安全性。

文档规范

这个是被广泛忽视的一点,文档真的很重要!文档真的很重要!文档真的很重要!

  1. SDK 的最终形态中一定要包含接入文档和演示 Demo 。虽然大部分业务方都不看文档,但你一定要写(至少甩锅的时候好甩...)。至于演示 Demo ,一定要考虑尽可能多的场景,把 SDK 的功能都展示出来。
  2. 文档要尽可能详细,但最好不要把所有内容都集中在一个文档里面,这样导致文档过长,业务方更加反感阅读。可以对文档做细划,比如:如何接入(jar、aar?或者是离线包还是 maven 库?)、基本功能如何使用(大部分业务只需要基本功能)、定制化功能如何使用、接入中可能遇到什么问题、怎么解决这些问题等等。
  3. 最好能有个 Web 页面的服务平台(类似开放平台),业务方可以直接在平台上进行应用的注册、管理、文档阅读等。服务平台也可以做一些数据统计的可视化,方便 SDK 的后续发展。

总结

以上就是我目前对 SDK 开发的一些心得体会了,大家有其他想法可以交流交流。至于 APP 开发,本人经验不足就不献丑了。

总的来说,SDK 有自己的生命系统,但它依旧服务于业务、生存于业务、发展于业务,它是业务不可或缺的一部分。

点击这里复制本文地址 以上内容由权冠洲的博客整理呈现,请务必在转载分享时注明本文地址!如对内容有疑问,请联系我们,谢谢!

支持Ctrl+Enter提交

联系我们| 本站介绍| 留言建议 | 交换友链 | 域名展示
本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除

权冠洲的博客 © All Rights Reserved.  Copyright quanguanzhou.top All Rights Reserved
苏公网安备 32030302000848号   苏ICP备20033101号-1

联系我们