@nightwitch mitsuba/pbrt 属于 CPU 离线渲染器，GPU 商用渲染器或多或少都有自己的核心技术优势 不可能开放出来, 目前比较有名的开源 GPU 渲染器有 Cycles 。
@marcTTT 酷家乐的网页渲染图实现应该只是用 webgl 实现的 pbr 光栅化渲染，对于本地来说应该会实现自己的 GPU 离线渲染器保证场景的渲染质量。此外对于 CG 来说新兴的数据交换格式是存在的 glTF2.0，虽然应用不广泛但是许多开源渲染器 /游戏引擎是支持的

我也和楼主遇到了类似的烦恼，找遍了 github 的 fragment 管理库，发现要么只做状态管理，要么状态管理做得半成品的同时动画管理也只做了个半成品，google 的 navigation 更是到处挖坑，只能自己写 fragment 的管理，非常期待有一个比较功能全面的 fragment 管理库
不过对于 标准化架构设计 这个问题，activity 与 fragment 的分工职责更倾向于业务的选择，而不应该算入到架构设计这一层面的问题，纯粹的单 activity 还是会带来非常多的问题，在我自己进行开发的过程中也有考虑过纯粹的单 activity 设计，但这样会带来代码臃肿，数据通信，可维护性差，以及 fragment 多层嵌套后状态难以管理等诸多问题
(PS. 看到作者的 ID 很眼熟，发现竟然是 Rxjava 简明魔法和 Viabus 的作者，太厉害了一直在关注，不过对于 viabus 有一点小小的看法：viabus 比起 flux-like 的架构，还是欠缺了一点简洁性，由于项目经历过少，无法判断 viabus 比起其他框架到底优秀在哪种地方

@no1xsyzy 可能表达有点错误，linux 科学家指:是 linux 教徒科研工作者...虽然目前来说确实就训练模型来说，对代码的抽象性和理论推导要求比实际代码能力来要强一点，所以并不会要求代码写得很漂亮，但这也确实正在成为所诟病的一点，诸如脚本调参侠之类的戏称。个人感觉 cs 最重要的还是对代码如同艺术以及对数学如同神明一样古典美感结合最好

@no1xsyzy 做算法也算程序员啊...只要是 cs 的，代码就应该以规范化来写，传统 linux 科学家哪个不是写得一手好代码，就说最近火热的机器学习这一块，xgboost，lightgdm 也是按照规范在运作...纯粹训练模型算是偏数学科研工作者了