Android开发心得纪录

嗯，突然觉得有必要记录记录一些东西，一些细微的有时候注意一下就能省力不少的点。

持续跟新中…. 想到了就来更新…

网络层

项目一开始的时候，写网络层的时候，注意一下，请求出去的时候的loading效果，不要持有发出请求的那个Activity或者Fragment,不然到时候空指针会多。
关于全局无网络的处理，建议一开始就在外面套个无网络的布局，就像emptyView一样，然后发请求的时候，check一下网络通不通，不通就显示出来，然后关闭请求。我们现在的版本到了后来优化的时候才有这个需求导致后面动了好多地方。
网络一定要维护请求队列，必须要有停止对列中的请求的方法，当某个页面打开，数据还没有回来的时候，就关闭了，那么一定要去杀掉那个请求。

UI容器

RecyclerView或者老一点的ListView都要写好emptyView，即item数据没有的情况下显示一个友好的提示，点击来个refresh()的操作的。

适配的问题

注意一下老年人字体导致布局爆掉的问题：最近发现部分客户反馈说布局扭曲了，截图过来一看果真是适配来适配去，却没有想到字体用了sp做单位，然后用户可能是老年人，系统设置里面的字体是最大的那种，然后UI爆掉了。原因是sp会读取系统的设置里面的大小。 所以方案有俩：

换掉sp到dp。此法虽说简单，但是，如果一开始没有用，所有布局以及代码里面写出的都得找到然后设置单位为dp，工作量是一个问题，能不能100%全部替换又是一个问题。

这样处理的小tip: 全局替换，Android Studio很强大的重构设计，cmd+shift+R,关键词是sp",替换为dp",加个过滤器（目标文件选择一下*.XML，目标文件夹选择res/）,否则就可能遇到spannable或者sP被正则匹配到，然后就头疼不敢随便doRefactor了。

既然sp做单位的Textview去读了系统设置，那么直接覆盖掉它读取系统设置的就好了。嗯，给BaseActivity里面增加如下方法。

         @Override  public Resources getResources() {
 Resources res = super.getResources();
 Configuration config = new Configuration();
 config.setToDefaults();
 res.updateConfiguration(config, res.getDisplayMetrics());
 return res;  }

我们现在是两种方案都应用了，疗效甚好：）

兼容性的问题

有用户反映之前设置好的手势密码丢失了。然后哼次哼次看代码，请QA复现求出边界条件，可是还是没有找到原因。代码里面倒是有点瑕疵的，之前保存sharedPreference封装的方法有点问题，然后新的版本我们更新了保存sp的工具类，于是遇到了新旧版本的兼容性问题。可能出问题的地方：

保存SP：保存会出现文件路径变了，1）app的文件夹是否换了；2）保存sp的key是否变了，建议写成constants的方式。
读取SP：如果前面保存没有问题了，那么新版本读取旧版本的sp数据的时候，一旦读到了，正确的做法是立即用新的一套保存sp的方式保存一下。那么在迭代几个版本，就可以在一处地方把兼容之前版本的那些代码给清理干净了。还有一个好处就是，你需要用到某个sp的时候不用多处都写冗余写兼容读取的逻辑了，一个入口读取下兼容处理，下面都是新的入口读写操作了，清爽,不易出问题。

关于测试环境，生产环境的切换问题

这个问题，一般都会遇到，还会有一个，测试环境才要打印log信息的问题。之前我们的做法是，在application里面定一个boolean，类似isDebug这样的命名，然后有一些逻辑切换根据这个量来切换API和打印log与否什么的，但是打包的时候可能类似这样需要注意的地方比较多，所以还是可以优化的，嗯，是的。借助Gradle打包，我们可以选择不同的flavor的时候打出相应的配置的包，不用每次费事，还写了几处地方坐判断什么的。参考一下这个就好了。

Android:构建不同环境的APK

StackOverFlow的相关提问

Gradle 多环境配置

关于交互上

按钮至少要给两个状态，normal pressed，点击之后如果有网络逻辑的，务必要给个loading 进度之类的或者点击水波纹，防止用户以为无效果，产生多次点击的事情。点击反馈是务必要给的。
关于资源的管理： app的theme,style,color,textSize的管理。

color)建立2级引用,仿照array的写法，里面引用这样，定义好 titleColor,subTitleColor,hintColor,subTitleHintColor,hignLightTextColor.etc ,然后，titleColor->colorA,hintColor->colorB ,colorAB则是具体颜色值了，你也不用每次纠结这个是什么ABCD哪个颜色了，当然了，前提是，设计有规范（themeColor,titleColor,hintColor 每个页面一致），我们约定好。

插入一下关于团队协作的观点（产品PM，技术Dev，视觉(UI,UX,UE.etc)，测试QA等)。现在遇到一个案例就是：并发的项目有几个，一个productManager负责一个app，但是客户端就有iOS和Android之分，不同的平台不同的特性，然后或许某个需求开发有个workaround的实现说好了，然后。。忘了（事情繁杂，还要不断被打断去确认敲定，确实很有挑战性，／摸头安慰），建议PM好记性不如烂笔头可以试试Evernote印象笔记；设计师在这方面也有痛点，建议负责视觉相关的同学(UI,UE,UX.etc)学习一下Android的MaterialDesign规范, 不要动辄iOS弹框，iOS返回按钮，一点Android的味道没有，要么不伦不类,毕竟现在我朝用户两个平台的量是有明显的比例差距的( AndroidUser可能占了8成以上)。第二点就是，设计稿版本控制的问题，最好的是和产品文档一样，写上一个updateLog之类的东西，这样的话，技术开发看到稿子或者文档，就知道，哦，还有这个地方需要调整，就不用每次打开比如XXX设计稿0926然后仔细找和XXX设计稿0925的改动在哪里，然后再去写实现，如果引入了版本控制团队合作的效率就提高了，而且，以后出了问题什么的可追溯。显然，如果能和开发一样，来个版本控制，每次提交给个commit message，其他人拉取的时候就了然了。这样敏捷多了，项目研发效率和质量肯定提升一个档次（专业带来的好处就是好多沟通的成本就省下来了可以做优化，可以做下一迭代）。