关于Activity/Fragment的生命周期
首先说一个题外话，周五测试提了一个bug，跳至下一个Fragment，再回到之前的fragment，之前对一个textview做的操作都没了。
于是我又去看了下View的lifecircle，发现跟Activity还是很不一样的，他从backstack中取出上一个fragment之后会走onCreateView，而inflateview和butterknifer bind view都是在onCreateView中做的（这是对的，onCreateView要返回view的，官方文档也说这个view里要返回这个fragment的root layout。onCreate的话，就是初始化必要组件用的），也就是说view是被重建了的，所以view状态都变成了初始状态。
最终我是这么解决的这个业务问题的：在onCreateView的update当前fragment的view的方法里加了判断，如果uidata中相应的数据有，我就把textview更新。
Activity和Fragment生命周期的区别，我目前感受:
- Fragment多了一对onCreateView/onDestroyView，大概也是因为Fragment相比Activity，更多的是做View展示。
- Fragment多了onAttach和onDetach，用于标识跟Activity连接。
- start/stop(可见)，resume/pause(在前台)这两对是共有的，activity有个特殊的onRestart。
另外，注意到onAttach(Activity activity)在api 23以上已经deprecated了，参数变了：
/*
* onAttach(Context) is not called on pre API 23 versions of Android and onAttach(Activity) is deprecated
* Use onAttachToContext instead
*/
@TargetApi(23)
@Override
public void onAttach(Context context) {
super.onAttach(context);
onAttachToContext(context);
}
那就要注意，如果你覆写这个新的方法，当你的gradle中的target api小于23的时候，onAttach就不会被调用了（上周接入外部SDK的时候由于他们的so不支持targetApi23以上，所以我们的app改成了targetApi22。这就是风险）。正确的做法是升级targetApi，或者同时写两个onAttach。
关于Fragment的状态保存
我们组的App里用的是UIData的方案，我觉得很巧妙；在Fragment的onAttach()方法（另外，onCreate()方法里也把getActivity赋给mActivity）做了mActivity的恢复和mUiData的恢复：
@Override
public void onAttach(Activity activity) {
super.onAttach(activity);
this.mActivity = (CPActivity) activity;
this.mUIData = mActivity.mUIData;
}
这样可以避免getActivity由于onDetach造成的空指针。因为onDetach之后，getActivity就是null了；但是其实Fragment对象并没有被GC回收，所以mActivity并没有被回收。
另外，对于ViewPager+Fragment这样的设计，viewpager默认情况当你滑到第三页的时候，第一页的Fragment就会onDestroyView，这时候再回来第一页，很多东西都会重建了。这种情形要分情况，如果是实时性高的app，这么做无可厚非；如果是实时性低的app，那可以在onCreateView里判断网络数据是否为空，或者rootView是否为空，如果不为空就不请求网络，避免资源消耗。
Activity的状态保存
我们的Activity会有一个public的mUidata，在onCreate()，onRestoreInstanceState()和onRestoreInstanceState()的时候，都会把它从savedInstanceState中存放/取出。
@Override
protected void onCreate(Bundle savedInstanceState) {
// 加载数据
if (savedInstanceState == null) {
//initUIData是抽象方法，子类实现
mUIData = initUIData();
} else {
//记得这里我还问过，为什么要重新set一次classLoader，领导解释了，我大概忆起是classLoader在恢复的时候可能发生错乱
savedInstanceState.setClassLoader(getClass().getClassLoader());
mUIData = (UIData) savedInstanceState.getSerializable(UIDATA);
}
super.onCreate(savedInstanceState);
imm = (InputMethodManager) getSystemService(Context.INPUT_METHOD_SERVICE);
}
Activity的Fragment之间的数据通信
我看了下这个文章，提到了Handler，广播/EventBus，接口，setArgument等方式；其中最后一种的setArgument方式是Fragment的设计师们的初衷，我之前也简单分析过，它的优势是可以在Activity重建的时候恢复数据，也正因为如此，Fragment不推荐使用单例。相比之下我感觉我们组的UIData方案还是蛮好的。
View的状态保存
不光Activity，View这个类也是有onSaveInstanceState和onRestoreInstanceState(android.os.Parcelable)这对保存state的方法的。
对于一个复杂view，比如一个用户填满了的表单，如果用户旋转了下屏幕，数据就都没了肯定不行。
View中有个类，View.BaseSavedState，解释是Base class for derived classes that want to save and restore their own onSaveInstanceState()。我们自定义地去保存View的state。
我们的JDRView中确实继承了它，用于在保存和恢复的时候给uidata赋值，也必须要往parcel里添加和恢复uidata：
public static class SavedState extends BaseSavedState {
/**
* 保存的数据
*/
private UIData mUIData;
public SavedState(Parcelable superState) {
super(superState);
}
private SavedState(Parcel in) {
super(in);
mUIData = (UIData) in.readSerializable();
}
@Override
public void writeToParcel(Parcel out, int flags) {
super.writeToParcel(out, flags);
out.writeSerializable(mUIData);
}
public static final Creator<SavedState> CREATOR = new Creator<SavedState>() {
public SavedState createFromParcel(Parcel in) {
return new SavedState(in);
}
public SavedState[] newArray(int size) {
return new SavedState[size];
}
};
}
我回想了一下JDRView是怎么恢复数据的？
JDRView的构造函数
JDRView()->init(){
mUIData = initUIData();
initUI();}
在onRestoreSavedInstace的时候调用updateUI();
以FinanceView为例，
@Override
public UIData initUIData() {
InvestmentListData investmentListData = mStorageUtil.get(InvestmentListData.class);
if (investmentListData == null || investmentListData.fundCardInfo == null) {
investmentListData = new InvestmentListData();
investmentListData.fundCardInfo = createDefaultData();
}
return investmentListData;
}
我们用的是mStorageUtil，作用是把Serializable的数据转化成Json然后保存的SharedPreferences里去；在构造函数初始化和onRestoreSavedInstance的时候都会给mUidata赋值，然后initUi/updateUi。分别用来从磁盘上恢复缓存数据和View被重建的时候恢复数据。
MainSequenceFragment：
protected void updateCardListUI(CardSequenceList cardSequenceList) {
if (cardSequenceList == null) {
return;
}
List<CardViewInfo> mCardList = cardSequenceList.tabStructureList;
if (needDraw(mCardList)) {
mCardView = CardViewManager.generateCardView(mActivity, mCardList);
addCardViewLayout();
}
for (int i = 0; i < mCardView.size(); i++) {
View cardView = mCardView.get(i);
if (cardView instanceof JDRView) {
//loadData利用cardId去取server数据，onSuccess时updateUI。
((JDRView) cardView).loadData(null);
}
}
}
cardId除了在缓存的时候有用，还有什么用。从前似乎是传页面名称的，现在改成cardId了。
ref:
http://www.jianshu.com/p/662c46cd3b5f
http://blog.csdn.net/u012702547/article/details/47151001
http://www.bubuko.com/infodetail-828889.html
