淘宝老P7的Android开发经验非正规总结

    做后台开发不可避免要用到Android，因此基本的调试技能必不可少。入坑Java三个月来跌跌撞撞总算是会在别人搭好的架子上写代码了，这里分享一下老P7冲哥日常给我的一些经验指导。冲哥是个老黄牛，发现我职业生涯里每个公司的初期运气一直比较好，每次都有个低级别默默无闻的老黄牛尽心尽力带我，感恩。也希望冲哥早日升P8，买上第二套房。

1、搞Android开发需要写着Java操着GC的心。Android开发中，不要太过于依赖GC，它没有标准JVM那么强大。自己申请的资源一定要确保自己释放，举几个例子：

1. 1  临时创建的集合对象，用完请clear掉。

2. 2  注册的broadcast，使用完毕后显示注销掉。

3. 3  注册的事件不用时需要注销掉。

4. 4  DB资源使用之后，在合适时期显示释放。

2、谨慎使用WeakReference，并没有你想象的那么美好。要明确使用场景，不然也是会踩坑的。特别需要注意的一个场景就是，假如业务预期已经结束了，业务依赖的其他资源都释放了，这时候还没有发生GC，WeakReference中的对象会不会进入不符合预期的异常情况。

3、拒绝并发操作。Android不管是UI操作还是后台数据处理，串行比并行更易掌控，代码也更容易编写。

4、当切换到后台数据处理时，不建议使用HandThread，而应该自己创建合适的ThreadPoolExecutor。原因是当线程处于idle状态时，HandThread是不会自动释放线程的，导致手淘线程越来越多。而ThreadPoolExecutor就可以指定空闲线程的存货释放。另外根据业务场景还可以使用AsyncTask、AsyncTaskLoader、IntentService、AlarmManager。

5、不建议主线程的使用方法添加syncchronized，特别是在一些系统会掉中，系统本身在很多地方使用了syncchronized，在一个线程中容易造成长时间阻塞。其次主线程中一旦出现syncchronized，所有界面渲染都被阻塞。即使你的Activity被压后台了，别人的Activity还是会被阻塞。

6、在调用Android原生API前建议通读其源代码。关注异常分支处理流程时，该API是通过正常的result返回，还是直接throw exception的方式返回。如果是通过异常返回，那么做好异常处理。日常项目中遇到的一般都是异常返回，这种情况客户端很容易crash。

7、高效使用事件驱动模型来编程，反向依赖更加符合客户端的编程模型。在复杂的交互设计中，无疑会使代码的复杂度成本增加，因此带么各模块尽量做好解耦。事件机制可以让模块之间功能划清界限，各自提供各自的能力和信息。

多说一句，TCP的几乎所有时间操作都是通过ack回包驱动的，操作系统的任务切换是通过tick中断（PENDSV）驱动的，都是事件驱动模型的经典例子。

8、涉及到RPC数据加载时，涉及方案初期需要考虑下面几个点：

8.1 数据大小；

8.2 数据每次加载时间间隔；

8.3 数据加载并发控制；

8.4 数据加载成功要如何处理；

8.5 数据加载失败是否需要重试，重试次数，重试间隔如何确定。

9、客户端与服务端需要约定好RPC返回的结果码，越细越好。主要是：1、避免出现两边处理不一致的逻辑。2、出问题的时候，各方责任能明确（甩锅）。大部分公司做的网络业务resultcode都定义不明确，一旦出现跑流量，RPC请求过量，吃亏的还是客户端开发。

10、重点测试容易出问题的地方，主要指跟外部系统、其他SDK、服务接口依赖的相关API和事件通知。如果涉及到硬件资源、网络资源的请求就要更加注意了，一定要做好幂等处理。之前遇到个Android的坑，就是切后台事件通知和无网事件通知同时来临时，系统不会发送无网通知，因此对于靠事件驱动的一些网络模型就需要补上无网通知。

11、慎用外部伙伴提供的SDK，比如高德地图SDK、扫码SDK等。外部SDK如果有耗电或者流量问题，终端用户只会看到是手淘在消耗手机资源。使用之前需要充分评估。

12、公共模块特别是执行频率非常高的代码，尽量避免使用trycatch去做逻辑处理。某些手机机型（如红米）不会把异常抛到应用层，而是直接在vm层抛出，导致手淘crash。

最后，感谢冲哥三个月来的指点。在哪个公司都能碰见安安心心做事不关心职级不关心公司不公的老员工，生活也很巴适。大部分人到不了P8，但所有人都可以选择自己的生活。