前言： 很早以前，就听人说过Android以后会火起来，作为一个前瞻性，对它有所了解会是一个转型的好机会。javaweb太成熟饱和了，现在市面上各种Android手机层出不穷，网上各种Android视频连续剧一样跟进，安卓一下子成为了热门话题，刚开始也是出于个人兴趣学的很hi感觉挺容易上手的样子，后来工作中才发现问题很多也很棘手，慢慢的在纠结和痛苦中琢磨出了一些经验和规律！
1. Android作为view层，要实现和服务层低耦合，必须使用webservice接口。目前还没有十分完善的插件，曾经试过axis的Android包(也是一个兴趣者自己做的)，用了之后感觉非常麻烦，特别是复杂数据类型的传递，而且bug也很多，还要改别人源码，无疑增加团队的学习成本和开发难度，无奈之下自己做了。Android端使用Apache的httpclient发送交互请求，定义好xml接口传输数据，接收也是用dom4j解析，经测试在2.2中dom4j支持性很好，2.1少些解析用法不支持，但大部分能用，说到这大家也许懂了。没错，后端用的是servlet机制，再利用java反射根据xml文件描述动态调用指定的spring服务和方法，这些已经足够，而且可以完全按自己的方式做更多灵活的扩展.
2. httpclient确实是个好东西，但作为无状态访问协议，http无法保存用户会话信息。于是翻开了axis的源码发现它原来是把用户的首次访问信息保存至特定文件，而后根据心跳机制，定时做校验，茅塞顿开，于是我把用户首次访问信息保存在数据库会话表中，并且写了一个存储过程，定时把会话中登录时间距离当前时间超过30分钟的记录做删除操作，用户每次登录都与会话表进行匹配，没有记录即刻超时强退。这么一来，方便简单多了，那么用户每次访问系统都得在xml文件里带着系统给它的串号，也就是sessionid，才叫一次完整的会话.
3. Android系统画图是个麻烦的活，初期我们小组找遍了所有画图的插件，都是忧喜过半，没有办法找到特别满意的，要么是使用太麻烦，要么是找不到我们要的效果，研究的很累也没头绪。问了一些原先做过j2me老程序员，他们建议如果不是专业做游戏的话，统计图表这些还是借助服务端来做更合适一点，于是我们抛弃了所有的Android端画图插件，采用jfreechart在服务端画好，图片http流到手机端显示，当然因为2.1系统不支持flash，也就没考虑在做得更漂亮，图表很直观很清晰。
4. UI是个难点，而且为了适应不同分辨率，之前用px单位很有问题，后来改了dip定位，好了许多，之后大面积使用选项卡样式，统一风格，难点很多，比如给tabhost加样式动态改变效果，按钮透明，listview去横线加箭标加动态发亮加下拉翻页，还有手势滑动，各种各样的widget特效和动画切屏。为了省去弯路，我们反编译了QQ，飞信，58，赶集，飞机票，墨迹天气等所有主流的Android布局和美化的用法，吸取不少有用的经验，但是依然感觉布局很难做，美工无法直接介入而且模拟器测试很不给力，没办法只能用真机测ui，速度能快上许多。
5. Android的客户端更新功能，相信只有做过的才知道其中的辛酸，一要做好断点续传，二要做好数据库的初始化工作，三要做好签名，四要做好版本校验的算法并且能显示动态进度条和百分比。断点续传好做，但是数据库初始化麻烦点，我们的做法是把sqlite库文件直接从raw下拷贝至sd卡中，并设置了sqlite的读取库路径指向它，感觉这样好一点。签名一开始不知道，每次覆盖都提示安装未完成，后来才明白为了保证应用的唯一性，它就像是身份证一样，其他没什么作用，和塞班的签名不是一回事，封装apk必须保证在同一签名文件下才可相互覆盖安装！
6. webview中可以调用后端的java代码，类似dwr功能，不过这个功能一直用的很少，很不稳定，兼容性要考量，Android既然提供了那么多的ui控件，就说明webview是无法替代它的，毕竟还需要调用底层服务，webview还是慎用的好。
7. Android也应该遵循mvc的编程规范，activity只负责处理跳转，UI，和简单数据校验工作，业务逻辑放置在service类中，sqlite操作稍加封装下，做个类似jdbcUtil的那种模板类，提供增删改查，分页等方法，这样dao操作就完善许多。我想作为java程序员转做Android开发，最大的障碍不在框架也不在谷歌sdk中的那些api，而是java基础。通过写程序发现，做手机开发的程序员，基本素质要过硬，尤其在集合，线程，异常，io，http这些要非常透彻，不然一个看似很简单的功能，可能就会写的bug百出，甚至效率很低，可读性差，基本上自己回过头都看不懂自己写的是什么，对接口和抽象类，包括匿名内部类的写法也要炉火纯青。