Android 开发最佳实践
持续更新
1摘要
选择一个好用 IDE Andriod Studio
关于包的结构
我建议具体业务相关的包结构是将它们置入在一个包内。而不是在整个应用包的根下
因为我们的业务是不断的增加。就种增加也应当增相应的包名。这样的话包结构的变化就是会明显的变化
不利于稳定。
越是公用的东西则应该放置在明显的地方。如果工具类。
还有一些其他公用的管理类。这些东西可以放置在更高层级的类包下
这种做法使得其他小伙伴可以一眼看到，并且使用它们。
而与你协同开发的小伙伴可能根本不关心你的功能（业务）。
但是包结构的变化使得小伙伴分心。或是误入到其他。引起冲突等
关于依赖关系，尽量做到单向依赖
这个也从包的层次表现出来，
越是靠近根目录的文件，功能，相当于洋葱的内层，他是越是公用的，核心的。需要被依赖的。
越是远离根目录的文件，功能，相当于洋葱的外层，他就越是私用的，他依赖于核心的
关于包的结构
module：业务模块
utils：工具类
widget(视图控件——含自定义view，弹窗，浮窗，通知条。
service：后台服务（）
data：数据
common：常用的管理功能
base：不以业务相关的基本类
log：日志的打印
config：配置
entity：实体类
module：业务模块是放置一个个独立的模块。
network:网络
image:图片
location:地理位置
locale:国际化（含多国语言的配置管理）
permission:权限
manager:
data :
创建线程池管理类，统一管理线程的创建和销毁。减少系统不必要的开销。控制来内存管理
接口化
定义内层的输入，输出接口，是内层自己的职责。（内层通常是最接近数据的，但又不能耦后外层，只是定义输入输出接口，这样方便对接所有关心数据的人）
是不是过度复杂了？
当你习惯了就简单了
我们希望数据流可以从外层流向内层，反之亦然。但是依赖规则不允许。
Log 日志的打印要尽量还原真实场景，不要处理发生的时数据。不需要美化。他当时发生的数据是什么就是什么。
美化后的数据会隐盖有用的信息。可能会使得调查问题发生的原因出现偏差。
在团队协作时，怎么能让代码的单向依赖原则不被破坏，即内层的包，不使用外层的包。
1限制类，方法，参数的访问限制，
2使用依赖原则。将代码分划成为模块后，外层的模块依赖引入内层的模块，不允许内层模块引入外层的模块。
3更不要跨层访问
少写注释，多起一些有意义的名称。有明确的方法名称，类名，属性名等。
公用的静态方法放置在UTIL包下
如使web显示页面的，请使用WebView下的Html5Activity
如果使用自定义，或是你要自己定义一个view.请将他们放置到Widget包里
C。是我们的常量类
Config是配置
service是服务的
entity是实体类。（实体类不要作涉业务的逻辑，不要依赖平台, 保持他的纯java特性）
module功能模块
data数据。
base是基本父类。（作好的，我们以后可以作一个开发框架）
工具类理应能够抽像化，公用化。也理应不涉及具体业务细节。
如果工具类只提供给某个业务使用，那么他的命名上需要下一些工夫，表达出它的使用范
或是的包可以范围应该被控制在包内可以访问，避免外部误用了。
内层定义更抽象的部分，外层定义更具体的部分。
尽可能的作单向依赖，即是外圈使用内圈的类，代码。反之内圈不使用外圈的类，代码。
如查你发现依赖倒置，内层依赖外层的类，代码，尝试把他移动到内圈。
如查你发现跨层依赖，或是新增一个中间件在内层进行处理。不直接依赖使用。
内层的包不要使用外层的包
*定义输入输出接口是内层的职责。
例如 Http协议定义的Content-Length
如果我们也有类似的字符，也作相同的命名的话会与之有冲突。不能正常区分，
这就里需要个可以区分的命名规范。使用小驼峰命名
关于Android布局文件(layout)定义规范要求
关于layout 的命名规范
使用小写字符，字符之间隔使用下横线_
Activity使用的布局文件加上前缀activity_
Fragment使用的布局件加上前缀fragment_
自定义控制件使用的布局加前缀widget_
公用的布局件加上前缀layout_
Adapter使用的布局件加上前缀item_
代码组织方面。Package Diagram对一些大型的项目特别有用。顺便说一句，良好的代码组织，对软件的可维护性至关重要，请认真的规划你的包结构。下文将简单介绍Package Diagram，主要分两块，什么是Package，以及Package之间的关系。
