工作小结-2018七月(1)

这周主要是完成了盒子2.1的迭代。ui部分进行了大规模的更改，写了较多的控件。

不过这都不重要。这周的主要收获收获在对软件流程的突破。

之前项目里面使用的是一个activity对应一个fragment，但是缺点在于启动模式基本上都是activityA -> fragmentA -> activityB -> fragmentB -> activityC -> fragmentC，这种启动模式，基本上类似于activity启动的时候每次都开启一个栈，每个栈是独立的。

不过这周想到一个比较好的方法，写代码的时候，仍然是一个activity对应一个fragment，不过启动的时候流程进行绑定化。

举个例子，我们有一个页面a用于介绍会员的优点，有一个页面b用于用户进行会员付费，有一个页面c进行付费成功的提示。

一般的情况，一次付费流程，是一个整的，不会出现付费成功，返回仍然是会员付费页面的现状，而应该是付费成功了，点击返回这个流程就会进行关闭。

鉴于上面的流程，衍生出了会员介绍页面：activityA, fragmentA；会员付费页面：activityB, fragmentB; 付费成功页面：activityC, fragmentC

从最基础的会员介绍开始，我们启动activityA,activityA的oncreate只写一个方法，就是启动fragmentA,显示介绍页面。fragmentA中有跳转的接口，跳到会员支付页面fragmentB，这个使用自己写的startFragment方法进行跳转，fragmentB又有支付宝或者微信的回调接口，回调跳转到fragmentC支付成功页面。到了fragmentC支付成功页面，返回按钮触发的就是finish当前的activity，因此此时一旦触发，整个流程就结束了。

那为什么仍然要写成activity -> fragment的模式呢？看上去好像activityB并没有使用。

事实上业务上面有很多地方只有单独的一个接口，该接口是直接进入支付页面，因此此时可以使用start activityB -> start fragmentB -> start fragmentC这种模式，此时如果在fragmentB页面返回，会直接触发activtyB的销毁动作，也能因此成为一个独立的流程。

这套方法的思想来自于activity的任务栈调度模式，模仿的是singletask，不过相对于activity的任务栈，在某些方面还是不足的，例如说重复创建，单一任务多次使用等。这套大概使用情景在于切片化，更多的好处还需要自己体会。

不过称此夸一下，activity的启动，开销比较大，每次启动至少涉及到两次binder，而且activity的启动过于局限。fragment虽然没有完善的任务调度系统，不过好在碎片化开销不算大，哪怕我们知道他比较麻烦，但是起码也能保证一点就是写好了不会太差。

目前对app的拆分大概能拆分成 application -> activitys ,activity -> fragments，感觉比以前的想法更为清晰。