Android开发常见的八大难题

说八大难题有些牵强, 而且这八个问题也不是孤立的, 而是互相影响互相联系的, 但从程序员开发的角度, 以下的这八个问题至少会有一个, 你会承认, 啊, 这个问题曾令我捉急, 头痛! 本文没有给出任何解决办法, 尽管有些有最佳实践, 有些目前我没有特别好的对策.

1. 耗电. 一般在开发阶段, 开发者自测阶段都很难准确, 周全的为省电处处做特殊优化. 很多时候要着急出功能, 当项目或产品已经落成的时候, 当然更多的时候直到用户对比后反馈你说, 你的应用耗电啦, 你这才会针对这个问题着手分析, 可这个时候就更难准确把握是哪里耗电了. 有可能是网络, 有可能是屏幕常亮, 有可能是后台服务, 有可能是无用的死循环, 也有可能是在很隐蔽的你没找到的地方;
2. 流畅. 你可能在做有大图片处理相关的UI, 或者很多图片的列表, 网格时遇到过卡顿的问题, 也可能在做复杂绘制, 比如实时阴影, 或者复杂动画, 滑动, 渐变效果时发现不流畅. 这个问题有时是因为效果的实现思路不当, 比如本该用View却使用了Window, 比如本该直接绘制位图, 却使用画图API; 而有些是编码不当; 有些是因为频繁的垃圾回收导致; 有时可能需要多线程处理以避免占用UI线程; 有时可能需要在fling的时候暂停刷新或加载. 如果你在开发阶段遇到了卡顿, 那是不幸中的万幸, 很多时候在你的测试机器上流畅的效果, 在很多你看不到的用户的低端配置机器上卡顿无比;
3. 网络. 移动设备有个特点就是可能网络环境不稳定, 举个例子, 当你上传或下载到一半网络断了, 需要怎么处理才更人性化, 更使你的应用站在高可用, 高健壮的行列? 再比如你的应用被指出很费流量如何解决, 是不是你的同步网络布局在架构上存在着不合理的地方, 协议没设计好? 比如应该使用压缩的精简合理的json数据的地方, 却用了冗余复杂而重复的xml还未做压缩? 亦或者你的统计数据收集的太着急, 每次崩溃日志都要发送给开发者邮箱? 再比如怎么实现推送才能准确, 尽可能及时而又省电. 加载一个界面慢是否因为网络获取数据慢? 能否缓存在本地? 应用的服务端是否拖后腿, 服务器网络是否存在着CDN? 如果你正在做视频聊天或者在线视频相关的功能, 可能更需要对网络特点和用户可能的网络情况做更多的对策.
4. 内存. 移动设备中供一个应用使用的内存往往很少. 很占内存的大图片或者众多需要显示的图片都会导致OOM. 亦或者图片显示没问题, 但图片很占内存, 用完没有及时释放, 久而久之也可能导致OOM. 不当的创建众多实例, 繁多的单例有可能因为存在引用而不能被回收, 从而内存溢出. 如果恰巧不当引用了Activity或者相关的, 比如View, Drawable, Fragment, Window的实例都有可能导致内存泄露. 这些需要耐心分析, 项目或产品落成后, 很麻烦, 很头痛, 甚至无从下手. 另一个问题是操作系统说内存不够了, 指着你的应用说你释放点内存吧(onLowMemory& onTrimMemory), 你做了什么处理? 还有的时候逼你做流式过程化编程, 比如内存有限, 不能把所有DOM节点都加载进去, 而要使用SAX或XmlPullParser解析字符串, 比如你本可以使用写一个DAO将数据存入JavaBean重复利用, 却不得不直接使用Cursor, 将它散布在项目代码各处;
5. 大小. 指APK的大小, 显然作为客户端使安装包尽可能小是你义不容辞的责任, 从而带来的问题是, 你的代码布局, 类设计, 框架设计以及某些细节实现要尽可能合理; 另一个是不管你项目或产品多着急, 可能不允许你随意使用第三方类库, 尽管他们很方便更健壮, 即你可能要抛弃了大轮子, 还要打造小轮子, 重复发明轮子. 比如你为了做一个难度较大的动画效果而引入游戏动画引擎的可能性很低, 只能自己摸索实现动画的每个细节, 再比如你需要放弃使用好用的FastJson或Gson, 而用Android自带的org.json库, 除非有特殊需要或十分明确而又堂而皇之的理由, 否则不应该包含自己编译的sqlite或openssl库, 另外你可能不能直接使用Apache Commons或者Guava之类的库, Ioc框架的库等, 要么需要裁切这些库要么自己封装, 然后你每换一份工作都重新熟悉他们独有的封装;
6. 安全. 包括sqlite数据库的加解密方案, 是加密数据库管理系统呢还是加密关键字段? 包括网络通信安全, 你可能需要使用SSL; 包括代码安全, 你可能不希望你的劳动成果, 尤其是门槛很高的关键技术, 随意的被任何人看到或使用; 你可能不希望你的应用被加了很多广告或瑕疵又重新发布到应用市场扰乱你的信誉, 剥削你的收益; 如果你的应用涉及电子商务, 安全支付或者虚拟货币, 你需要设计良好的业务流程和逻辑, 并且这些核心不容别人查看或寻找漏洞; 为此, 你可能会做代码混淆, 而很多类不允许你混淆, 这样App跑起来后因为NotFound而抱怨; 你可能将很多实现移入so, 因为是用c/c++写代码, 如果你不熟悉, 很可能错误百出, 而且经常引起其他问题, 比如因平台相关而导致的兼容问题; 即便这些你都花时间学了, 也努力做了, 还有一个挥之不去的问题, 就是安全领域是对抗性的工作. 你的应用现在安全不代表以后也安全, 如果应用受欢迎, 会有大把的人来研究破解你的程序; 不仅如此, 你可能还需要谨慎的使用四大组件, Android设置App, 这些可能无形中帮了不法分子去损害你用户的权益;
7. 生存. 这个问题其实可以并入其他问题中. 这里所谓的生存不是指App火多久, 这可能不在程序员的考虑之中. 这里的生存就像人的生存, 人要生存离不开社会环境, 应用要生存离不开操作系统和其他应用的配合. 比如操作系统或者安全软件可能无故, 有意, 有理由杀死用户手机上你的进程, 而不发给你任何邮件. 比如你需要输入法的某种配合却找不到接口或入口, 比如输入法窗口或者其他应用因为你的某段代码的执行或者用户的操作, 无情的遮挡了你需要实时通知给用户的信息, 再比如你在通知栏上做的信息显示, 其效果在某些机型上让你感到费解, 再比如小米不允许未经同意就显示悬浮窗;
8. 兼容. 这个问题的范围最广, 很多问题都可以归入这个问题. 它包括了很多方面, 比如Android手机厂商众多, 有些开发者可能还要面对平板, PC, 手表, 电视等. 而且几乎所有厂商都是拿Android源码改造加上自己的硬件方案, 导致屏幕大小不同, 硬件配置不同, 操作系统实现水平参差不齐, 这带来了屏幕适配问题, 还有如果你的App需要NFC, 用户的机型没有相关设施, 不能就弱弱的崩溃了结吧? 另外, 如果你需要在native app和unify app(web app和ndk app)中做出选择, 都会有兼容问题(手机中native app的特点是Android实现一套, IOS实现一套, 而unify app是借助html4/html5或者c/c++仅实现一套, 然后在Android和IOS上做个壳子, 如此也就意味着开发者受众不同). 如果是native app需要面对Android API的变化, 比如是否兼容2.3还是兼容4.0以上, 因为Android API版本的迁移过程中有些实现改了, 有些废弃方法删了, 有些好方法添加了, 还有是否使用android-support库; 如果是web app, 可能需要在不同手机浏览器上做兼容, 也可能加载在自己的webview上, 但你是否知道不同机型webview的实现都不一样? 有些操作实现无效果或受限, 有些机型加载网页慢, 这些你遇到过吗? ndk app的问题经常是so引起的崩溃和少的可怜的崩溃信息, 而且很多测试时跑的好好的程序, 在某些机器上说找不到so库或者来个段错误. 上面说的输入法, 及其他应用也会有兼容问题, 搜狗输入法和其他输入法对某些操作的反应都不一样. 最后要提的兼容问题是升级设置, 即是否允许不同老版本在用户市场上并存, 此时不同版本的协议变迁如何设计兼容? 亦或者强制升级到最新的一个或两个版本上, 是做增量升级还是整体下载升级, 升级失败如何处理?

这么多棘手的问题, 隐患和风险, 你是否评估好了, 准备好了, 设计做足了, 有好对策了?