本文主要从App-Android的视角来看,后学末进初来乍到欢迎打脸。
个人觉得要确保一个程序的稳定应该从这几个方面来分析。
- 代码
- 程序框架和设计模式
- 内存管理
- 线程管理
- 静态代码分析工具
- 容错处理-主动捕捉敏感数据异常
- 日志收集
- 测试
- 单元测试
- 压力测试
- 流程测试
- 异常修复制度
- 根据收集到的日志修复bug
- 生成补丁,发布更新
代码层面
程序框架和设计模式
这个不太敢说太多,看具体场景和自己能力做到尽量封装复用代码,解耦各个类之间的关系。下面简单说一下几种框架:
- MVC:简单易用,复用率不高,在android中:controller和view划分不明显全部放在activity里面,造成巨大无比的类,代码的可阅读性降低,维护难,急需拆分。
- MVP:在android上实现了更清晰的三层划分,不再是View和Control傻傻分不清了,虽然在activity里面还是会有部分逻辑,不过也不打紧。缺点也有,复用多了容易造成大面积的case。
- MVVM:mvvm借鉴于web前端的思路,每个html配套js能够实现更方便的组装。然而在Android里面xml的存在感和功能太弱了,直到DataBinding的出现。
内存管理
常见的内存问题是: 内存泄漏和 内存溢出,网上有非常丰富的教程,这里就不再赘述。
这些年技术更新的有点快,避免大家走弯路,建议这么三个工具给大家学习:
- strictMode 严苛模式。
- 应用场景:通常在开发完成之后,用严苛模式跑压测。
- leakCanary 金丝雀,
- 开发过程中配置,开发中就能查看到内存泄漏的引用链。
- Profile Android studio自带的工具。
- 应用场景:程序在某个界面变得卡顿退出后又回复顺畅,常见现象是是内存抖动。
- 这种现象不常见,而这个工具太过于手动了,对能力要求高,解决问题能力效率低,新手不建议去玩。
线程的管理
线程处理不当通常会造成如下问题:内存泄漏,多线程数据重复,脏数据...
- 内存泄漏:
- 常见场景有:自定义线程,Task队列,handler队列,广播队列,自定义动画...
- 解决方式:使用严苛模式排查,跟随创建的根结点销毁而销毁。
- 多线程数据同步问题
- 略过,能力限制,一两句说不清,而前端也很难碰到这种情况。能时机成熟再立新贴。
静态代码分析工具
静态代码分析工具能有效的寻找Java代码中Bug,下面例举两个工具,有时间我会补充两个工具的用法。
- lint
- FindBugs
容错处理
怎么说呢,经常碰到我们开发测试的时候运行正常,但是到了测试或者客户手上的时候问题不断。究其原因:一方面是数据源出了问题,另外一方面是我们对这些部分没有主动进行容错处理。通常需要我们对这些地方进行异常捕捉,也许某个功能无法正常使用,但是终究不会引发崩溃。
下面例举一些常见场景:
- 字符串操作:
- 字符串变换,截取...常见异常有空指针,长度越界,碰到这类操作的时候,我们最好是封装一个工具类,对整个方法进行异常捕捉
- 数组操作:
- 同字符串的处理一样,很容易出现空指针和数组越界
- 网路数据获取,这里情况就有点多了
- 空数据
- 对象转换
- 错误数据初始化UI,导致crush
日志收集
首先明确一点:发布到客户手里的程序必须是不稳定的。在这种情况下日志收集就十分重要了,下面例举两种日志收集的方式。
- 三方平台,比如说:友盟,bugly...
- 自己封装UncaughtException,然后上传到自己的服务器
测试层面
因为不是专业测试,欢迎指点。
单元测试
单元测试是指对软件中的最小可测试单元进行检查和验证。
场景:在现实开发过程中,绝大多数公司都把这部分工作丢给测试去做,除非初次上线,后面都会省略这个步骤,或者不会覆盖所有场景。
我觉得最好还是程序员自己编写单元测试代码,至少数据的入口都写一下测试代码。
压力测试
场景:我们开发的程序可能运行在各种复杂的环境,经历着不可预知的操作。
为了预防和模拟这类情况,还有什么比用Monkey做个压力测试更好的呢?
一条指令,多台测试机,几个小时之后去接收结果。强烈推荐这个测试,再懒的人也不应该忽略这个测试。
流程测试
场景:经历过很多项目组,很多时候开发完一个需求,只对新功能做测试,然后火急火燎的上线,覆盖率严重不足,说实在的上线后经常有睡不着的时候。
为了让上线前各个流程都能正常使用,下面例举两个工具,个人觉得是最容易上手的:
- Espresso :Android studio的插件,可以录制用户的操作生成一段java代码,后续执行这段代码就可以重复流程
- 优点:要求低不需要写代码,搭建好环境就能开始录制
- 缺点:录制过程极其卡顿
- Monkey Runner:官方出了比较久的一个工具,使用python来写测试脚本,初级功能只有十个左右的指令,
- 优点:功能强大,容易学习
- 缺点:全套流程下来,代码量有点大
异常修复制度
根据收集到的日志修复bug
定期或者邮件通知到开发,随时维护线上的bug,最好做到发现后即时修复。
生成补丁,发布更新
发现了异常最好是做到在小部分人受到影响的时候,已经将补丁包无感知的发送到所有客户手上修复了bug。
现在网上有不少开源的热修复代码,但是自己搭建框架难度有点大。大公司有要求的话自己去折腾一下,小公司建议直接用第三方的。部分平台上装机量少的app是可以免费使用他们的热修复的。
下面例举两个平台:
- 阿里的hotfix
- 腾讯的Tinker