Android开发过程中的部分经验总结

该文章为Android App 开发过程中遇到的常见问题总结，该总结也会持续不断的优化 完善当中。后续开发中一定会遇到各种各样的问题， 这些问题会酌情不断补充进来。

我将遇到的问题分为两大类，非技术问题和技术问题。

一、 非技术问题。

　　非技术上的问题一般为项目的管理问题，重点是项目开发过程中的协调沟通问题。

　　1. 项目的开展。

　　　　磨刀不误砍柴工。 项目开展前，团队可以抽出一些时间（不宜太长）进行充分的讨论，大家各抒己见，表达自己对项目的观点。讨论的重点当然是技术层面的，这个阶段，项目带头人可以抽出自己认为比较难实现或者可能开发过程中耗时比较长的点，以及面临的比较新的问题，放到屏幕上，大家一起讨论，提出自己的解决该问题的方法，达到集思广益，找到最优的解决方案的目的。另一方面来看，这个过程其实也是团队成员提高的过程，在这个过程当中，大家互相借鉴、互相验证，拿自己的解决方案和别人的思路进行比较，找到不足，提出建议或批评，这都是非常有益的。也避免了，个别成员闭门造车的现象出现。

　　　　讨论的过程，也是一个确定开发任务并进行分配任务的过程。每个人各抒己见的过程中，充分发扬民主，大家达成共识，这样，在项目开发的落实中，因为每个人都积极参与了，所以大家的热情也会比较高涨。

      2. 项目的进展。

　　　

　　3. 项目的跟踪。

　　　可以参考敏捷开发的流程。比如站立会议，进行交流，及时发现并解决问题。

　　4. 项目完成总结与评价。

　　　总结以下几个方面：1） 开发中测试反馈的bug总结： 1）归类总结。2）数量统计。

　　　　　　　　　　　　2） 后续的开发中，应该怎样避免类似的上述问题。 开发前，开发中，开发后 这三个过程中怎样做？提出针对性强、切实可行的措施。

二、 技术层面的问题。

　　1.  代码规范问题。

　　　　该问题曾在公司内部的技术分享群中我曾经提出过，我个人认为代码规范评判的标准就是：让两个人来写一段代码（相同也可不同），让第三者来看，他分辨不出这两段代码是由不同的两个人写的。

      2. 代码的质量的保证。

           从三方面来看：

　　　　（1） 对未来实际生产情况的准确判断和预估。判断大规模使用情况下，能不能抗住高并发或大业务量的压力。

　　　　（2） 程序员在写代码时，自身对代码质量是否有严格的要求和高层次的追求。比如单元测试是否能保证百分百覆盖， 边界条件是否考虑完全等等不一而足。

　　　　（3） 对技术能力是否有不断提高的内在需求，是否是在不断深入研究相关技术，并拓展自身的技术视野。

　　对以上三个方面立刻关注虽然不能取得立杆见影的效果，但长期来看，如果能持之以恒、潜移默化的践行，我相信，对个人技术层面的提升效果还是非常显著的。

 

三、 下面简单举例谈谈一些技术层面的问题:

　　Android 开发过程中遇到的问题都是较为琐碎的，一般通过搜索引擎，参考别人的解决方案，都可以得到较好的解决。

 

因此这里重点谈下Android App 性能优化的问题。

　　1 、降低执行时间
　　这部分包括：缓存、数据存储优化、算法优化、JNI、逻辑优化、需求优化几种优化方式。
　　(1). 缓存
　　缓存主要包括对象缓存、IO缓存、网络缓存、DB缓存，对象缓存能减少内存的分配，IO缓存减少磁盘的读写次数，网络缓存减少网络传输，DB缓存较少Database的访问次数。
　　在内存、文件、数据库、网络的读写速度中，内存都是最优的，且速度数量级差别，所以尽量将需要频繁访问或访问一次消耗较大的数据存储在缓存中。

　　Android中常使用缓存:
　　消息缓存
　　通过handler.obtainMessage复用之前的message，如下：

handler.sendMessage(handler.obtainMessage(0, object));

　　(2). 数据存储优化
　　包括数据类型、数据结构的选择。
　　a. 数据类型选择
　　字符串拼接用StringBuilder代替String，在非并发情况下用StringBuilder代替StringBuffer。如果你对字符串的长 度有大致了解，如100字符左右，可以直接new StringBuilder(128)指定初始大小，减少空间不够时的再次分配。
　　64位类型如long double的处理比32位如int慢
　　使用SoftReference、WeakReference相对正常的强应用来说更有利于系统垃圾回收
　　final类型存储在常量区中读取效率更高
　　LocalBroadcastManager代替普通BroadcastReceiver，效率和安全性都更高

　　b. 数据结构选择
　　常见的数据结构选择如：
　　ArrayList和LinkedList的选择，ArrayList根据index取值更快，LinkedList更占内存、随机插入删除更快速、扩容效率更高。一般推荐ArrayList。
　　ArrayList、 HashMap、LinkedHashMap、HashSet的选择，hash系列数据结构查询速度更优，ArrayList存储有序元 素，HashMap为键值对数据结构，LinkedHashMap可以记住加入次序的hashMap，HashSet不允许重复元素。
　　HashMap、WeakHashMap选择，WeakHashMap中元素可在适当时候被系统垃圾回收器自动回收，所以适合在内存紧张型中使用。Collections.synchronizedMap 和ConcurrentHashMap的选择，ConcurrentHashMap为细分锁，锁粒度更小，并发性能更优。 Collections.synchronizedMap为对象锁，自己添加函数进行锁控制更方便。

　　Android也提供了一些性能更优的数据类型，如SparseArray、SparseBooleanArray、SparseIntArray、Pair。
Sparse 系列的数据结构是为key为int情况的特殊处理，采用二分查找及简单的数组存储，加上不需要泛型转换的开销，相对Map来说性能更优。不过我不太明白为 啥默认的容量大小是10，是做过数据统计吗，还是说现在的内存优化不需要考虑这些东西，写16会死吗，还是建议大家根据自己可能的容量设置初始值。

　　(3). 算法优化
　　这个主题比较大，需要具体问题具体分析，尽量不用O(n*n)时间复杂度以上的算法，必要时候可用空间换时间。查询考虑hash和二分，尽量不用递归。

递归使用不当，容易引发栈溢出问题。

　　(4). JNI
　　Android应用程序大都通过Java开发，需要Dalvik的JIT编译器将 Java字节码转换成本地代码运行，而本地代码可以直接由设备管理器直接执行，节省了中间步骤，所以执行速度更快。不过需要注意从Java空间切换到本地 空间需要开销，同时JIT编译器也能生成优化的本地代码，所以糟糕的本地代码不一定性能更优。

　　(5). 逻辑优化
这个不同于算法，主要是理清程序逻辑，减少不必要的操作。

　　(6). 需求优化
这个就不说了，对于sb的需求可能带来的性能问题，只能说做为一个合格的程序员不能只是执行者，要学会说NO。不过不能拿这种接口敷衍产品经理哦。

　　2、异步，利用多线程提高TPS
　　充分利用多核Cpu优势，利用线程解决密集型计算、IO、网络等操作。　　
在Android应用程序中由于系统ANR的限制，将可能造成主线程超时操作放入另外的工作线程中。在工作线程中可以通过handler和主线程交互。　　

　　4、网络优化
　　以下是网络优化中一些客户端和服务器端需要尽量遵守的准则：
　　a. 图片必须缓存，最好根据机型做图片做图片适配
　　b. 所有http请求必须添加httptimeout

　　c. 开启gzip压缩
　　d. api接口数据以json格式返回，而不是xml或html
　　e. 根据http头信息中的Cache-Control及expires域确定是否缓存请求结果。

　　f. 确定网络请求的connection是否keep-alive
　　g. 减少网络请求次数，服务器端适当做请求合并。
　　h. 减少重定向次数
　　i. api接口服务器端响应时间不超过100ms