自从Android SDK更新到22.6.3，发现新建Activity的时候，会自动生成一个Fragment，这个Fragment是activity的静态内部类，同时生成了一个xml叫fragment_main.xml。打开activity_main.xml发现，只剩一个容器。很明显，谷歌希望大伙把UI写在fragment中。
从Fragment出来后，我和朋友讨论过，说谷歌这样子造成了一种混乱。一个APP，可以只用activity来实现，也即一个APP是同多个Activity构成。也可以只有一个activity，由多个fragment来实现，也可以多个activity和多个fragment混合来实现。到底怎么用，没有人给出答案。不知是不是我信息不畅，谷歌推出了什么新功能，几乎没有找到文章说，为什么要这样？这样的优缺点是什么？谷歌官方也没有给出什么答案。
现在这个新的SDK，算是谷歌用实际行动给出答案了。也就是希望人们多用fragment，少用activity。但是对这样的一种转变，尚缺少最佳实践之类的指导。比如说fragment之间的跳转，replace还是show/hide，都没有什么指导。现在大伙都很忙，如果有人能给出最佳实践，就不需要自己去摸索，因为摸索下去其结果也大同小异，好的东西好的想法，大家最终都殊途同归。所以如果有人能给出最佳实践，显然能节约很多时间。而做这个工作的人最适合的就是谷歌，为什么要加这个，为什么要加这样，显然是谷歌最先思考的，他们应该把优缺点想得很透，才选择这样做。那么把他们的想法公布出来，无疑是最直接最彻底的最佳实践。我并没有找到谷歌公司官方发布的说明文档，可能是我信息不灵通，如果有人知道谷歌做这个，还麻烦告知一下。
不过，因为历史包袱问题，现在谷歌也没有彻底变过来。比如说，虽然生成了一个PlaceholderFragment，界面要写在fragment中，但是在xml中写中简便方法android:onClick，却是调用acitvity中的。如果一个activity要给多个fragment用，那么这种简便写法几乎就不可用，算是废掉了。这个PlaceholderFragment也没什么实际用途，象征大于实际，真要独立，Fragment就没必要搞成内部类。
如果习惯用activity来处理事情，那么显示对SDK自作主张生成fragment很不满，所以网上很多人都直接把fragment给删了。如果不删，一个activity就平白无故多出一个文件，搞得项目中文件太多。
如果觉得烦，这只能说明大伙要拥抱变化了。Fragment出来之初，想用来解决手机和平板适配的问题。但结果显然不尽如人意，从我个人的实际体验来说，我宁愿平板上跑的手机的放大版。自动适配，确实太难了。
把Fragment视为可复用的带逻辑的组件，反倒更适合。我觉得这是Fragment最大的用途。只从界面来讲，Fragment和View没什么区别，但View的代码和View不是一个整体，而Fragment则是一个整体，无论嵌入到哪个activity中，都能独立执行相应的功能。
这样就需要我们在设计之初，进行比activity更加细致的思考。
新版SDK自动添加PlaceholderFragment的思考,布布扣,bubuko.com
新版SDK自动添加PlaceholderFragment的思考
原文地址：http://blog.csdn.net/ctcwri/article/details/36473333
