本文主要从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
