Android移动开发中通用技术整理
代码很简单
import android.content.Context; import android.net.ConnectivityManager; import android.net.NetworkInfo; /** * 网络监测工具 * * @author Nono * */ public class NetUtil { public static boolean checkNet(Context context) { try { //获取连接管理对象 ConnectivityManager connectivity = (ConnectivityManager) context .getSystemService(Context.CONNECTIVITY_SERVICE); if (connectivity != null) { //获取活动的网络连接 NetworkInfo info = connectivity.getActiveNetworkInfo(); if (info != null && info.isConnected()) { if (info.getState() == NetworkInfo.State.CONNECTED) { return true; } } } } catch (Exception e) { } return false; }网络上有更详细的check方式，就是list出所有的连接。个人感觉一般没什么大的意义。就这样的简版就行了。
通用技术二：版本检测。
这也是个常用的功能，基本目前所见的应用都带。
基本流程图
通用技术三：数据缓存
数据缓存也是常用的技术。
对于资讯类应用尤为重要。
进入显示区，获取填充数据：
Step 1：根据网络请求参数生成的唯一文件名（一般使用MD5，因为以该文件名命名的文件会存入到本地），进行本地检索。
文件存在，执行Step 4，否则执行Step 2；
Step 2：正常的网络请求操作；
Step 3：根据指定参数生成唯一文件名对数据做本地存储；
Step 4：数据获取和显示；
基本步骤如上。
图片类资源缓存的扩展。
特别提到所谓的图片资源是我们常说的面试中比较常提及到的一个词汇：内存溢出。
简单举例：比如国内市场上的应用Market.
应用商店中最多的资源就是图片，一个ListView下拉，那图片是刷刷的。但是无论我们怎么拉，应用时不报错的，然后当我们拉到很下面时，在往上拉时，发现图片执行了异步加载，先显示默认图片，然后过会会显示图标。
此处设计到两个方面：1，是图片数据缓存，因为我们每次去刷新界面不可能都再次网络请求获取。 2.防内存溢出
第一点很简单，就如上面提到的图片最本地缓存。
第二点其实又是也不太明白，上回有哥们说关于到C层释放问题。我一直以为用常规的对显示view对象的重用就可以解决的，这样每次图片资源就一个屏幕显示的图片size。
后来看到一篇文章说：
尽量不要使用setImageBitmap或setImageResource
或BitmapFactory.decodeResource来设置一张大图，
因为这些函数在完成decode后，最终都是通过java层的createBitmap来完成的，
需要消耗更多内存.
因此，改用先通过BitmapFactory.decodeStream方法
。。。。。。。。。。。。。。。。。。。。。。。。。
不懂底层真心无力。无论是是否有用，至少也是种未雨绸缪的态度。了解的可以去研究下。文章具体什么名忘了，百度下估计就有了。
以上两点其实都不是问题，因为都解决了。
但是为了考虑到性能问题，IO读取操作的速度大家都懂。
然后就有人考虑到图片的内存存取。为了防溢出，可以用软引用（outMemory前自动释放内存）或是引用队列（内存中暂存最近使用资源，又可人为控制溢出）。
对于软应用 有某个开源代码 ImageManager类，（本人也不知道到底是不是开源的，上上一个项目中发现此类，开注释代码是 * Copyright (C) 2009 Google Inc.，我猜是开源的吧，有需要的朋友可以搜索下code）。
内存暂存的改进是让view刷新图片加载时更加流畅和完美，但完美也是有代价。
如此设计，数据获取就多了内存检索一步。
通用技术四：网络请求
一般公司都是封装了自己的HttpClient类或是jar
一般Android上的网络请求分3种。
一种是apache的jar，第二种是java 中HttpURLConnection.第三种忘了
本人更喜欢apache提供的，因为它基本把每个实体都分化成类。用的比较清爽。当然也是个人爱好。
通用技术五：网络请求协议
常用XML,Json。两种都用过。但都没用到Android中提供的原生Api。
一条网络请求的步骤：
1.一般使用一个javaBean，setter所有需要的参数
2.bean转json或是xml格式的string。
3.请求和返回。
4.json或是xml格式的String转成bean
其实一开始我天真的这么假设过，传来传去最后都是要转bean。为何不序列化bean文件直接传。
后来了解到：序列化的话就存在序列id，那么服务器和客户端就需要同一套序列化代码。这样对于一对多的服务器和客户端就有所问题了。
第二点是这样的效率是非常低下的。
对于Android中提供的解析Api，貌似没有直接 bean2JsonObject这一实现，就是直接new JsonObject（ beanobject）？貌似没有 = =没注意。
然后自己写的话，无非用反射，遍历bean中的setter或是getter方法对字符窜的拼接。
XML因为有个哥们写完了。json的话可以参考一个 JSON.org包，具体我也忘了我从哪边下载的。然后稍微修改了一下对于其中的getXXX反射的判断，
因为LZ的把Bean做成了单例，单例中存在了一个getInstance（）方式，当时郁闷了半天，一解析就stackxxxxx，就是内存泄露啦什么的。因为对于刚提到的这个get方法没做判断，无穷获取对象解析，就挂了。
后来听说请求协议还可以用goggle的protobuf协议，据说速度更快，好几倍,非死book就用放入这个（听说）。
但是对于Google自己的开发分操作系统为什么不直接提供该api，不是太清楚。
过段时间有空去看下文档。谢谢老大的提起。
通用技术六：通信加密
这块就太繁琐了，想必不同公司用的都自己的一套加密。
我用过RSA的非对称加密，简单流程就是客户端和服务端在应用开启网络正常下，交换公钥。然后就是客户端数据传输前
用ClientPrivateKey加密，服务端获取后用一开始交换过去的ClientPublicKey解密数据。反过来同理。
但是个人觉得这样的加密，攻击者只需一开始截取了公钥。。。。就。。。
鄙人对加密真心未涉足。不了解。
还有是用过常用的放篡改的MD5以及MD5前的3des加密。但是安全性不敢恭维。
一般人只要反编译了该应用就获取了加密类下的keycode。。然后又是悲剧了。。
通信加密我觉得是未来互联网中最重要的一部分，基本所有的应用都慢慢设计到用户名和密码管理这一块。
小到移动支付，大到智能住宅。我想谁都不希望被他人动了自己的钱包或是房子。
而在这个密码爆炸的年代。。谁没十几二十个密码啊！！
通用技术七：消息推送
这绝对是个让人恶心却又让人喜欢的技术。
如以前的恶意短信。
还好现在的应用基本都有提供给用户开启以及定制的选项。
走的是按用户需求推送信息。
在Android这个技术相对于Ios上比较落后,就说Apple上提供了这么一个统一的框架，而对于Android上虽然也有了，但是一会被墙，一会又不统一的形式。
引发出了形形色色的推送。
第一种：常驻后台服务，定时去服务端pull。说白了，这真是一种伪推送。理念上完全违规了。
第二种：长连接。其实我也不太明白。因为我们的应用时给电信的某个定制，电信苛刻的要求是不可以有常驻后台服务和进程。
其他的基本都是以第二种发展而来额框架。
类似于即时聊天应用，走哪个什么XMPP协议啊。。功能大家都懂。现在的即时聊天工具都用这个。
这边提下是google自己的C2DM框架。资料很多，但是针砭不一。
还有就是比较出名的 Androidpn框架。鄙人打算过段时间试试这个，因为现在应用也用不上。
个人觉得这个技术算是挺好的，我比较喜欢按自己需求的定制阅读，资讯，团购信息什么的哈哈。
通用技术八：Log日志
这个其实没什么用，在开发时可能会用到。
可以按自己需求，安全level设计自己的日志log类或是包
转自：http://blog.csdn.net/nono_love_lilith/article/details/7229342
jopen 
openkk