Android新项目搭建（持续更新中）

之前项目的框架好久没有更新了，想重新搭建一个，顺便整理一下使用到的技术。

1、设计规范

android.support.design：28

dedign出来好多年了，除了有的项目中偶尔用了一点，还没有真正使用，准备在这个demo中全面使用。

这篇文章收集了很多相关的文档，https://www.jianshu.com/p/040bd4c50eef

十款 Material Design 风格的 Android 开源项目

ps： Material Design 过时了？？

在github上有很多相关的开源项目，不过貌似大部分都2-3年没有维护了，也看到有的文章提出了Material Design 的各种问题，现在推广的不是很好。

问题确实是存在的，但是对于一个测试用的demo来说，相关的设计效果和动画效果还是很好的，所以还是用一下吧。

2、使用的代码阿里的规范

可以在androidStudio中设置规范检查。具体配置方法可以参考这篇文档 https://www.cnblogs.com/whycxb/p/9736414.html

规范的具体内容 https://blog.csdn.net/leeyhcoding/article/details/79413532

其中有几个是我自己容易犯的错

1）使用 new Thread 创建子线程。应该使用线程池

新建线程时，必须通过线程池提供（AsyncTask 或者 ThreadPoolExecutor或者其他形式自定义的线程池），不允许在应用中自行显式创建线程。
使用线程池的好处是减少在创建和销毁线程上所花的时间以及系统资源的开销，解决资源不足的问题。如果不使用线程池，有可能造成系统创建大量同类线程而导致消耗完内存或者“过度切换”的问题。另外创建匿名线程不便于后续的资源使用分析，对性能分析等会造成困扰。
同时，线程池不允许使用 Executors 去创建，而是通过 ThreadPoolExecutor 的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险。

2）使用toask.makeText 弹出吐司，应该定义一个全全局的toask对象。

这样可以避免连续显示Toast 时不能取消上一次 Toast 消息的情况(如果你有连续弹出 Toast 的情况，避免使用 Toast.makeText)

3）不要在 Android 的 Application 对象中缓存数据

虽然在application中缓存数据很方便，但是基础组件之间的数据共享请使用 Intent 等机制，也可使用 SharedPreferences 等数据持久化机制。

4）过度使用LinearLayout

布局中不得不使用 ViewGroup 多重嵌套时，不要使用 LinearLayout 嵌套，改用 RelativeLayout，可以有效降低嵌套数。
说明： Android 应用页面上任何一个 View 都需要经过 measure、layout、draw 三个步骤才能被正确的渲染。从 xml layout 的顶部节点开始进行 measure，每个子节点都需要向自己的父节点提供自己的尺寸来决定展示的位置，在此过程中可能还会重新measure（由此可能导致 measure 的时间消耗为原来的 2-3 倍）。节点所处位置越深，套嵌带来的 measure 越多，计算就会越费时。这就是为什么扁平的 View 结构会性能更好。同时，页面拥上的 View 越多，measure、layout、draw 所花费的时间就越久。要缩短这个时间，关键是保持 View 的树形结构尽量扁平，而且要移除所有不需要渲染的View。理想情况下，总共的 measure，layout，draw 时间应该被很好的控制在 16ms以内，以保证滑动屏幕时 UI 的流畅。要找到那些多余的 View（增加渲染延迟的 view），可以用 Android Studio Monitor里的 Hierarachy Viewer 工具，可视化的查看所有的 view。

灵活使用布局，推荐 Merge、ViewStub 来优化布局，尽可能多的减少 UI布局层级，推荐使用 FrameLayout，LinearLayout、RelativeLayout 次之。

5） ScrollView 包裹 ListView/GridView

不能使用 ScrollView 包裹 ListView/GridView/ExpandableListVIew;因为这样会把 ListView 的所有 Item 都加载到内存中，要消耗巨大的内存和 cpu 去绘制图面。
ScrollView 中嵌套 List 或 RecyclerView 的做法官方明确禁止。除了开发过程中遇到的各种视觉和交互问题，这种做法对性能也有较大损耗。ListView 等 UI 组件自身有垂直滚动功能，也没有必要在嵌套一层 ScrollView。目前为了较好的 UI 体验，更贴近 Material Design 的设计，推荐使用 NestedScrollView。

6）SharedPreference 提交数据时，尽量使用 Editor#apply()

SharedPreference 提交数据时，尽量使用 Editor#apply() ，而非Editor#commit()。一般来讲，仅当需要确定提交结果，并据此有后续操作时，才使用 Editor#commit()。
说明：
SharedPreference 相关修改使用 apply 方法进行提交会先写入内存，然后异步写入磁盘，commit 方法是直接写入磁盘。如果频繁操作的话 apply 的性能会优于 commit，apply 会将最后修改内容写入磁盘。但是如果希望立刻获取存储操作的结果，并据此做相应的其他操作，应当使用 commit。

这篇文章对SharedPreference 进行了详细的分析，也提出了一些使用方面的建议 https://www.jianshu.com/p/8eb2147c328b

7）在 Activity 中显示对话框或弹出浮层时，尽量使用 DialogFragment，而非Dialog/AlertDialog，这样便于随Activity生命周期管理对话框/弹出浮层的生命周期。

其实还有很多其他的问题，尤其是在安全这一块，但是在实际项目中涉及的比较少，也不是很好处理，所以不再这里体现了