@narmgalaxy 多谢，我看看

@winterbells 不太明白你遇到的网络请求状况 😂

嗯 Navigation 我再多研究研究。。

@winterbells

replace 的问题在于，每次回退时会重绘 Fragment、重新走一遍数据请求和装载的流程。这大概率地造成转场卡顿，尤其是回退到 ContainerFragment 时。除非不用转场动画。

重新请求数据，或许可以使用 ViewModel 的大作用域状态来恢复，不过数据的装载仍然会和动画造成阻塞，导致卡顿。

@lianyue13 @ssynhtn @maninfog

目前正在推动 标准化架构设计 的确立。

事实上，正因为标准化架构的确立，使得我得以在上上上周 独立承接并完成 29 个页面、34 个 API、涉及 350 余个细节 的中大型电商软件的代工。

纯粹的单 Activity 应用的合理之处在于，让 Fragment 充当页面相比 Activity 要更加轻量、快捷。

Activity 是面向跨进程通信的组件而设计的，是重量级的组件，所以不太适合应用内导航和跨页面的状态管理工作。

并且像 Jetpack 中提供的 ViewModel、LiveData，在 Fragment 而不是 Activity 中能更好地发挥作用域共享的特性。

因为出不起差错，Navigation 在这次代工中没有使用。

Navigation 曾遇到过两个麻烦，一个是转场时的 replace。这个已通过实现自定义 Navigator 解决。
另一个麻烦是，声明式 API 中支持的是 Tween Animation —— 一个早已被淘汰的、转场效果并不好的动画。

打算择日在 Navigator 中用属性动画实现，只是有点复杂，需要在 Fragment 基类中，参照 Fragmentation 的 SupportFragment 实现动画完成等回调。

@ukyoo
图片推荐上传 sm.ms ，github 外链在站外除了本人，无法查看。

Transformations 这个相当于是单例，帮助 LiveData 纵横四海，不过有个缺点就是，它无法限制 LiveData 的作用域。当有多个页面需要共享某个 LiveData，或者当某个页面退出时要求清理 LiveData，Transformations 就不太方便。

ViewModel 对作用域有着良好的封装，所以基本上我是用 ViewModel 去管理 LiveData。

@ukyoo

伪代码传图片了

https://i.loli.net/2019/07/30/5d40467b25b8b95582.png

@ukyoo

我不是这么用的。

LiveData 类似于 Eventbus，它的职责是在 单例的帮助下，从唯一可信源取材完成状态的正确分发。

这里我们将 RxJava 所在的数据源当作唯一可信源，将多个订阅者页面当作分发的目标页面，将 ViewModelProviders 管理的 ViewModel 作为单例。

那么他们的关系是，页面单向依赖于 ViewModel，ViewModel 单向依赖于 数据源。

ViewModel 持有 liveData。ViewModel 通过 数据源的方法来注入 LiveData，在数据源方法处理好数据后，通过 liveData.setValue(数据）来将数据植入到 LiveData，此时 liveData 会在页面的 observe 回调中通知页面做出 UI 响应。

伪代码如下：

class XXXFragment : Fragment{

XXXViewModel = ViewModelProviders.of(this).get(XXXViewModel.class)

XXXViewModel.getXXXLiveData().observe(this,()->{
//4.订阅者页面拿到响应的结果，处理 UI 逻辑
})

//1.通过 ViewModel 去向数据源请求数据
XXXViewModel.requestXXX("id")
}

class XXXViewModel : ViewModel{
MultableLiveData xxxliveData = new MultableLiveData()

public MultableLiveData getXXXLiveData(){
return xxxliveData;
}

public void requestXXX(String id){
//2.ViewModel 中转，去向数据源请求数据
DataRepo.getInstance.requestXXX(getXXXLiveData(),id);
}
}

class DataRepo {

private static DataRepo sInstance;

public void requestXXX(MultableLiveData xxxliveData,String id){
Observable.create(emitter -> {
calculator()...
emitter.onNext(result); }).subscribeOn(Schedulers.newThread())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(o -> {

//3.数据源处理好数据，将纯粹的数据注入到 LiveData
xxxliveData.setValue(result);

});
}
}

如果这样说还是不太清晰的话，请等一等，过段时间我贴个 github 项目，专门介绍 Jetpack 的最佳实践。

会不会是公司给配的显示器不太好啊。

我眼镜防蓝光的一副要 2k，自己买的显示器，护眼的才 1.2k 。

所以显示器还是值得投入的。有些东西千万别将就。

就 android 开发来说，标准化的 Jetpack 架构可以规避至少 30% 的业务代码。

使用 kotlin 还能继续屏蔽 20% 让人欲仙欲死的 !=null。

另有 30% 的诸如 ViewModel、LiveData、DataRepository、POJO 等数据支撑代码，可以全自动生成。

再加上平日里封装好、解耦的组件。

所以哪怕从零搭建一个新项目，标准化的基础设施可以让编码行云流水。在原本架构中看似混乱的业务，也会被化解得烟消云散。

最后，需求决定价值，有需求就有价值。

敲代码的人需求标准化的架构，当然是觉得基建有价值。用户只看得到表面，当然觉得业务有价值。

我作为开发者，我会选择前者，我不喜欢写业务，很烦，我喜欢搞标准化基建，从工程层面上提升开发效率。

2019 年起，新项目全部转 androidX 了。

迁移成本其实很小，主干工程可以通过 as 自动完全迁移。

主要是适配作者已不再维护的第三方控件库需要花费一点时间。

需求决定价值，有需求就有价值。

大众对客观认识事物需求极少，而对转移注意、打发无聊、刷存在感需求多。

我的每篇技术文章都是用心打磨、打磨、再打磨，确认对真正的读者有帮助，才发表的，否则宁缺毋滥。

然而即便如此，也无法确保每篇都能满足大众的口味。

因而，为了保护自己的写作热情，只在公开的平台发表完全无需费脑的文章，而稍稍需要思考的文章则锁在小众圈子中。

最后，商业公司当然是以满足需求为己任了，只不过，社区里的人是什么样的人，那么社区的方向和命名也该改改了。。

@maninfog 感谢你的阅读！

@lastpass 感谢你的补充！

@SuperNovaSonic

有什么依据呢？

@Lucups @ostholz @ice000

那你很棒哦

@ys1992 @mrjiejiejie

感谢你的阅读！

我司目前封装的 SDK，一个功能的状态一般不超过 12 个，所以就算 int 也足够。

64 个状态的话，到底是什么功能才会存在这样的设计呢？

@also24 @whileFalse @WebKit

那你很棒哦

@GetCore 你好，已加

@kile 就算是就职微软，遇到喷子，也要被喷的。

喷子是不讲道理的，为了宣泄情绪，可以找任何借口。

也是事后查了百科词条才确认，确实是遇上了一起典型的被喷事件。有带节奏的、有扣帽子的、有跟在屁股后面乱喷的 …… 前人总结得很清楚了，几个典型全占了。

https://baike.baidu.com/item/%E5%96%B7%E5%AD%90/15088318?fr=aladdin

不过即便如此，我仍然全程冷静地用心码好每一个字。全都是讲给真正的读者听。

所以假若有朝一日，我真正的目标读者，因为这个帖子而找到了大部队，那我的愿望也就达到了。

--go/promotions