终端端程式设计合作开发现阶段主要就主要就包括了Android与ios三种非主流控制系统，上面他们就透过事例预测来介绍呵呵，零此基础学Android程式设计须要自学什么样规范化。
1.Android的辅助工具规范化
工欲善其事，工欲善其事。
虽然Android基本上都如前所述AndroidStudio展开合作开发，因此辅助工具规范化全数以AndroidStudio为大前提。
要选用捷伊平衡版的AndroidStudio展开合作开发;
代码文档格式要标准化为UTF-8;
删除累赘的import，增加警示再次出现，可借助AS的OptimizeImports(Settings->Keymap->OptimizeImports)机能键，增设他们的偏好。
撰稿完.java、.kt、.xml等文档后要序列化(须要在增设好几点的大前提下)
ReformatCode的迫切性，很大须要确保IDE实用性完全一致为大前提，尽量直白于AndroidStudio预设。
雷西县对较为长的老标识符局部性格式化，不自上而下序列化
2.Android的发包规范化
后面特别强调了辅助工具的标准化实用性，再借助AndroidStudio这类的机能便可把标识符艺术风格显得完全一致。接下去就增添二部份：Android的发包规范化。
对发包，他们需要达成一致完全一致，他们选用PBF形式，不所推荐选用PBL形式。
PBF(按机能发包PackageByFeature)
PBL(按层发包PackageByLayer)
PBF可能不是很好区分在哪个机能中，不过也比PBL要好找很多，且PBF与PBL相较为有如下优势：
package内高内聚，package间低耦合
哪块要添新机能，只改某一个package下的东西，而PBL须要改多个package，非常麻烦。
package有私有作用域(package-privatescope)
原则上一个package下的不允许其他类访问都是不应该加上public的。
很容易删掉机能
统计发现新机能没人用，这个版那块机能得去掉。如果是PBL，得从机能入口到整个业务流程把受到牵连的所有能删的标识符和class都揪出来删掉，一不小心就完蛋。如果是PBF，好说，先删掉对应包，再删掉机能入口(删掉包后入口肯定报错了)，完事。
高度抽象
解决问题的一般方法是从抽象到具体，PBF包名是对机能模块的抽象，包内的class是实现细节，符合从抽象到具体，而PBL弄反了。PBF从确定AppName开始，根据机能模块划分package，再考虑每块的具体实现细节，而PBL从一开始就要考虑要不要dao层，要不要com层等等。
3.Android的命名规范化
标识符中的命名严禁选用拼音与英文混合的形式，更不允许直接选用中文的形式。正确的英文拼写和语法可以让阅读者易于理解，避免歧义。
