1.修改一个组合控件使其成为ViewStub的加载形式

项目进入维护期以后，需要对项目中积累的问题就行优化。在当前的项目中，几乎每一个Fragment、Activity。在进行网络访问的时候，都有异常或者边界的情况。所有在对应的Layout中，我们项目中的代码，都放了一个组合控件：NoNetWorkLayout。名字起的是有点问题，大概主要是针对在网络异常或着数据返回错误时展示给用户的界面。相应的代码就是控制这个layout和content_layout之间的Visibility。考虑NoNetWorkLayout并不是必定有展示需求。所以需要用ViewStub的形式进行优化。不过这个NoNetworkLayout已经深入到各个页面。如果去每一个页面做替换。然后ViewStub.inflate。然后在操作inflate的真实View，那要改动的布局和页面很多，而且这代码重复量比较大。不过好在ViewStub这个类比较简单。所以只需要改动它的实现到NoNetWorkLayout中就可以实现占位，延迟填充。

以ViewStub形式的占位控件

一些额外的问题：其实这个形式的修改，也是针对当前已经进展到这个情况的view的修补。在项目中我看到有不同的developer,会因为NoNetWorkLayout的layout不太合适，又重新拷贝代码，然后设置新的layout_id。继续在自己的代码中引用。其实占位View一般都不会有太复杂的逻辑，控制其修改。所以留一个setLayoutResId的方法，就能完成展示不同的占位功能。如果在UI方面也能提供统一的视觉，那么完全不需要去每个layout占位，完全可以在基类中，延迟new这个layout完成全局的异常 边界 误操作的View处理。

2.Background中Activity被回收

有用户反馈bug，在订单Preview页面，进行优惠券选择后，网络提示异常，ProductList为null。根据BI系统的打点采集，看到用户在从选择优惠券页面返回后。preview页面，急速的进行了两次，订单状态的刷新。正常情况下，只会有一次，就是携带优惠券信息的刷新。考虑两次请求间隔大概20ms，不太可能是用户触发两次信息变化，那么就是自然流程。再结合有一个productsList为null。那就是有数据丢失了。定位到在选在优惠券的page，preView的页面被回收。随后进入重建流程后，分别在onCreate的initData和onActivityResult中有两次数据请求。复现此问题可以使用开发者模式中的 不保留后台活动。随后就是一次数据保存与恢复的过程。其实这个只要定位到这个问题后，就没啥难度了。不过后续的修改有丶难。

ps：记录下activity的生命周期流程。按照重建 + onActivityResult

onCreate onStart(onRestart)  onRestore onActivityResult onResume onPause onSaveInstance onPauce onDestory（onCreate和onRestore中的bundle都有save的数据）

首先就是，要规避重建时onCreate和onActivityResult 两个方法同时请求网络。并且不能影响正常进入的流程。大多数时候Activity没有销毁（其实在数据恢复后，这两个接口就算请求两次，问题也不大。不过这完全是有侥幸的成分，毕竟onCreate的请求总是会比onActivityResult的先返回，前者会被覆盖。不过这样很不OK啊。）

其次是这个PreView的activity，可能是前期开发太快，没有分离业务和UI。所以有2300行代码，2300这个不重要，重要的是，这2000行代码在历代版本中已经跑的飞起而且从来没翻车。但是这个preview要承载的东西太多了。比如收货方式(自提/外卖)，是否使用优惠券，以及活动优惠。如果外卖需要选择收货地址，以及各种优惠之间的互斥关系，还有就是备注信息，不排除其他信息。这些数据都是在其他页面进行编辑后返回的，这样要保存太多的数据。数据的恢复又关联到UI的恢复。在这2000行代码里大动干戈的修改一个超低频率的bug，有丶吃力。说归说，当然该还要改的。

问题的总结：1.优化整体代码，降低内存占用。2.关键流程用Activity+fragment的方式，而不是Activity+Activity的方式，一个activity搞定，岂不美哉。3.拆类要趁早。

3.netty

netty的学习，总体来说，有点尬。洋洋洒洒的看了几篇分析博客。回头一看发现，我的sourceCode怎么跟他们的实例都对不上，后来才发现，大神大谈特谈的技术关键，都在server端工作。client端整体上的工作量，以及用到的关键点，比较少。sad。不过看了不亏。鉴于这部分只是都是看Blog。所以也不再啰嗦了。详细的讲解，可以看着个集锦《自顶向下分析netty》自顶向下深入分析Netty - 文集

一些技术点：java中的Future设计模式。netty中的Handle和Pipeline设计。

4.其他

下面是一些我也不知道为啥，反正这么干就行了的问题。

gradle在编译时在如下task时抛出error ---->:app:transformClassesWithAspectTransformForDebug Error:invalid entry CRC 

解决方法是：重装adt（好像是某个编译tool有点问题，损坏？）

JUnit version 3.8 or later expected  运行JUnit 进行单元测试，如上错误,在run选项中，edit configuration中删除所有junit测试的config。然后重新运行。

5.文章

异常代码定位在源码级别时的分析 当log的定位位置是sourceCode的时候，我是不会改的。都是系统的锅。没按我的想法运行。

实践App内存优化：如何有序地做内存分析与优化 - 掘金 大道理听过很多，可是我还没优化。这篇是我看过算是手把手教你怎么做了。

6.最后我想说的一点

丶