引：
周末去电影院看了我等了小半年的<君の名は>，感触良多，总结来说有三点：
1、因为我本是新海诚的忠实粉丝。
2、公司是日企，公司不管是滚键盘的还是忽悠人的，都要会日语。
3、嘿嘿，内心蠢蠢欲动，年少轻狂的我难免喜欢这些文艺爱情片，嘿嘿。
以我对电影的评价，这部电影质量还是很不错的，不知道不考虑情怀问题，国产的什么时候能达到这水平。迷茫脸。
不多说，开始正文。
为什么总结？
不可否认的是，日本人的行事风格是极其死板的，至少日本那边来的同事都是这样。总结来说，无论什么情况，都按规定来，这和我们大部分国人的“随遇而安”的风格格格不入。但正是这种死板，使得一切都变的井然有序，所以我开始渐渐的接受了这些死板的文化，甚至爱上了这种死板。其中，“总结”，就是死板中的一条。公司每天早上上班都有小组会议，总结昨天的情况和今天的安排；项目开始准备阶段，需要总结项目的工数、人员、开发文档；项目结束，无论是开发完成还是客观原因终止开发，都必须总结出对应文档，详细到每一个class中方法的作用。作为后续进来的维护人员，都是一件多幸福的事情，但对我这种作文档，分分钟有点想跳槽走人的冲动。当然，其实还有非常多的总结，我就不一一列举了。总结来说，因为重要，所以总结，因为总结，所以一切都变的井然有序。
总结哪些？
主要是在开发Android 时，一些小经验而已。其实没什么的，哈哈哈哈哈哈。
总结开始咯？
嗯！
一、抽基类
特别是Activity及Fragment等，一定要在项目初期创建类似"BaseActivity.class"的基类。这是为何呢？这还要从我进公司接触的第一个项目说起。当时那个项目需求时，在App退出到后台或者锁屏，再回到App时要到解锁页面，验证通过后才可以使用App，同时，在网络请求时，还需要验证登陆Token失效问题，如果失效，要删除登陆信息，自动跳转到登陆Activity。当时项目分工已经明确，各自负责各自的Activity等，等需要解决这需求的时候，很自然的想到解决方法，通过将Activity的引用放到放到Application中，通过这个引用来跳转Activity（还有另外就是Application中另开一个Activity的栈，但后来总是会出莫名其妙的问题，就放弃了）。恩，没毛病。但真的要做的时候，发现了，十几二十个Activity需要修改（在onResume()把引用设置到Application中，在onStop()中取消引用），这一点都不符合我们码农的风格，效率太低！我们一群小年轻没人愿意干这中无聊的Ctrl+C&&Ctrl+V，所以当时就悔啊，为什么当初没有抽个Activity的基类，在基类中实现这方法，我只要继承它，就什么都不管不问了。可能这一点你还觉得没什么，但我想说，凡事看远点。
二、谨慎选择开源的库
我接手项目的时候，项目已经开发了大概，已经上线给客户使用了。当时用“Afinal”解决网络请求、数据库操作等功能。这个库不可谓不强大，集成了很多，很全面，但是已经至少2年没有更新维护了，效率和其它新的库的相比，从测试数据上对比，差距还是挺远的了。另外，我想换okHttp作为请求的底层，这和“Afinal”的网络请求模块又重复了，我……所以总结来说，对开源库的选择，注意这几点：
1、选择开源库时，要选择会持续维护。因为库的问题导致App突然在某天无法正常运行，难道你打算自己哭着看源码，自己解决？
2、选择集成功能单一的。我还是比较提倡一个库解决一个需求的，如果像“Afinal“一般，我想换个网络请求同时不想提升耦合度，那工作量有点大。
3、注意库的更新日志。很多人都和我一样是版本帝，有更新就更，没有原因，就是想更，不管是修复Bug还是删除方法。删除方法什么都倒是还好，编译时会报错提示。但是方法逻辑变了，那就不好玩了，你懂的。
4、注意库的体积。在图片加载的库中，有Glide，Picasso，Fresco三个选项。Google自己推荐Glide，但Glide的方法数实在的有那么一点点的偏多，同时，Picasso完全可以完美支撑我们的项目，毫无疑问，选择Picasso！就算我是Google脑残粉，但是！在理性面前，还是要学会低头的。
三、多动笔
我讲真，不要太自我崇拜，自己就是一个敲键盘的而已。公司主要是Web端，今年才新成立移动开发部门所以测试时的一些case，基本和Web端一样，只有业务逻辑测试。但Android端不同，一个App的运行，除了业务逻辑问题，还有非常多意想不到的异常情况，什么锁屏、退后台、崩溃等等一系列的case都需要考虑。如果这些case你一人通过脑补就能想到正确的逻辑及解决方法，那我服。但是不能，那还是乖乖的拿出纸笔，用流程图什么的，画画吧。这带来的另一个好处就是，在出现异常case的时候，你看你当时画的流程图，能更快的想起当时的解决思路，更快的定位到问题代码块，这比注释效率更高。
四、规范命名
我们都知道注释的重要性，但光有注释是远远不够的。我认为变量的命名更加重要，一个正确规范的命名，能使阅读代码的效率以几何倍数增长。又说回接手的那个项目。之前是一个新手负责的，所以命名简直是不可描述，’mList,view,textview……"这些变量名就问你怕不怕，这还不关键，关键是，名字叫“mList”，再看对象，居然特么的是一个Json的解析实体，当时的我整个人都斯巴达了。如果换成"mTaskList,mListView,mLoginTV"，有点经验的人都知道表示什么了。除了这个命名，还有常量。将业务中的一些标识等，定义为常量，更直观，更高效（为何高效，这就是基础问题了，这里不说）。举个例子吧，我们规定，字段'type'的值，用'0'代表苹果，'1'代表梨。如果你了解这业务，你当然能明白'0'代表什么，但是，如果你不懂业务，你看到这代码，你能看懂？所以我们定义为常量'public static final int TYPE_APPLE = 0;'，你如果还不懂，那就是你的问题了，嗨！！！
五、多总结
为什么呢？从头看本文章吧。
总结：
扯了这么多有的没得，总结来说就是，要学会死板点，但不能真的死。公司的死板我都不想再吐槽了，码代码时，注释的格式，代码缩进，空格数量，都有明文规定，不合规定，算是Bug，记到你的头上，开会集体批斗。这样带来的好处就是，看代码时，好像就是自己写的一样，坏处就是，写个代码，感觉比写《三体》都难。所以，死板要学，但不能真的这么死，要灵活。