闲话多说
为什么作家应该用 Markdown 保存自己的文稿
献给写作者的 Markdown 新手指南
很久之前就知道markdown写文档很好，现在也学学吧，之前是怕太多语法记不住，实际上还好，常用的就那么几个，比看 FSC（Fucking Source Code）简单多了。
书写过程中产生了一个小疑问： 段前是否需要缩进？ 我个人觉得都差不多，不知各位何解。
发问
相信大家平时肯定经常会用到Activity和Fragment，对应的生命周期也不知道面试问了多少遍了，这些就不多说了。
后来我发现除了少数特殊的情况，大多数Activity都可以换成Fragment。
不禁让我产生疑问，Fragment和Activity各有什么特点，平时开发的时候又该如何的进行选择（我经常可以看到别人Fragment和Activity“乱"用，可能是因为不同的人有不同的习惯吧）
求解
Fragment依赖于Activity，所以我们不可能说不用Fragment，问题只是在于新功能是新建一个Activity还是就在当前Activity中显示一个新的Fragment。
Fragment从性能上来说肯定是优于Activity的。相信喜欢用Fragment的朋友肯定也是因为这个原因，页面打开速度真tm快。其实我一开始也是拒绝使用Fragment的，比较Activity能实现我为什么要多此一举用Fragment呢，毕竟Fragment还要学习成本。
当你真正用起来才会知道Fragment的好，就像我某位高中物理老师的金句”没有知情权，就没有话语权“。但是为什么还是会有很多人用过之后还是不喜欢用Fragment呢，很大程度上是因为Fragment相对于Activity来说更容易产生bug，因为Fragment更加灵活，就像我们的软件给用户1个按钮和30个按钮，哪种方案容易出问题显而易见。但是所谓的出问题不是因为灵活的事物本身有问题，而是使用者的了解程度不够，导致使用出错。
-
平板和手机的界面适配要用到Fragment（最开始学Fragment时的例子）
列表和详情页面在手机、平板上的不同展示方式
2.根据业务层次之间的包含关系
Fragment性能的确比Activity好，但是从性能方面比较Fragment和Activity无意义，因为它们的应用场景不同。Activity更倾向于一个整体模块容器，而Fragment是其中的子模块。可以理解成一个工厂（App)有N个生产不同产品的产房（Activity），每个厂房（Activity）里面有生产N类子产品的机器（Fragment）。所以，Activity的存在可以对应用更好的结构化和模块化的划分，让应用有更健壮和清晰的层次，而Fragment可以让将应用的功能细化和具象化。两者没有好坏之分，根据功能划分粒度来选取合适的载体才是正确的架构方式。
作者：张老狗
链接：https://www.zhihu.com/question/39662488/answer/82769071
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
我目前的理解水平比较倾向这种观点，各位有何见解，欢迎留言补充。
总结
总而言之，Fragment较Activity而言，更有性能优势，但如果使用不当也容易产生bug，但是我们作为一个开发人员，骨头再硬还不是得啃，就如同生活不易，依旧要过。
至于选择建议根据业务模块和层级进行划分。
先就这么点吧，本来标题是准备写”Fragment和Activity的特点与选择“，后来发现好像没写什么特点就改成了”Fragment和Activity的选择“，才疏学浅，望请见谅。
