Android开发常见的难题
经过五年的Android开发⽣涯，我总结了Android实际项⽬开发中需要注意的难点如下
耗电.
⼀般在开发阶段, 开发者⾃测阶段都很难准确, 周全的为省电处处做特殊优化. 很多时候要着急出功能, 当项⽬或产品已经落成的时候, 当然更多的时候直到⽤户对⽐后反馈你说, 你的应⽤耗电啦, 你这才会针对这个问题着⼿分析, 可这个时候就更难准确把握是哪⾥耗电了. 有可能是⽹络, 有可能是屏幕常亮, 有可能是后台服务, 有可能是⽆⽤的死循环, 也有可能是在很隐蔽的你没到的地⽅;
流畅.
你可能在做有⼤图⽚处理相关的UI, 或者很多图⽚的列表, ⽹格时遇到过卡顿的问题, 也可能在做复杂绘制, ⽐如实时阴影, 或者复杂动画, 滑动, 渐变效果时发现不流畅. 这个问题有时是因为效果的实现思路不当, ⽐如本该⽤View却使⽤了Window, ⽐如本该直接绘制位图, 却使⽤画图API; ⽽有些是编码不当; 有些是因为频繁的垃圾回收导致; 有时可能需要多线程处理以避免占⽤UI线程; 有时可能需要在fling的时候暂停刷新或加载. 如果你在开发阶段遇到了卡顿, 那是不幸中的万幸, 很多时候在你的测试机器上流畅的效果, 在很多你看不到的⽤户的低端配置机器上卡顿⽆⽐;
⽹络.
移动设备有个特点就是可能⽹络环境不稳定, 举个例⼦, 当你上传或下载到⼀半⽹络断了, 需要怎么处理才更⼈性化, 更使你的应⽤站在⾼可⽤, ⾼健壮的⾏列? 再⽐如你的应⽤被指出很费流量如何解决, 是不是你的同步⽹络布局在架构上存在着不合理的地⽅, 协议没设计好? ⽐如应该使⽤压缩的精简合理的json数据的地⽅, 却⽤了冗余复杂⽽重复的xml还未做压缩? 亦或者你的统计数据收集的太着急, 每次崩溃⽇志都要发送给开发者邮箱?再⽐如怎么实现推送才能准确, 尽可能及时⽽⼜省电. 加载⼀个界⾯慢是否因为⽹络获取数据慢? 能否缓存在本地? 应⽤的服务端是否拖后腿, 服务器⽹络是否存在着CDN? 如果你正在做视频聊天或者在线视频相关的功能, 可能更需要对⽹络特点和⽤户可能的⽹络情况做更多的对策.
内存.
移动设备中供⼀个应⽤使⽤的内存往往很少. 很占内存的⼤图⽚或者众多需要显⽰的图⽚都会导致OOM. 亦或者图⽚显⽰没问题, 但图⽚很占内存,⽤完没有及时释放, 久⽽久之也可能导致OOM. 不当的创建众多实例, 繁多的单例有可能因为存在引⽤⽽不能被回收, 从⽽内存溢出. 如果恰巧不当引⽤了Activity或者相关的, ⽐如View, Drawable, Fragment, Window的实例都有可能导致内存泄露. 这些需要耐⼼分析, 项⽬或产品落成后, 很⿇烦, 很头痛, 甚⾄⽆从下⼿. 另⼀个问题是操作系统说内存不够了, 指
着你的应⽤说你释放点内存吧(onLowMemory& onTrimMemory), 你做了什么处理? 还有的时候逼你做流式过程化编程, ⽐如内存有限, 不能把所有DOM节点都加载进去, ⽽要使⽤SAX或XmlPullParser解析字符串, ⽐如你本可以使⽤写⼀个DAO将数据存⼊JavaBean重复利⽤, 却不得不直接使⽤Cursor, 将它散布在项⽬代码各处;
⼤⼩.
制作android软件流程
指APK的⼤⼩, 显然作为客户端使安装包尽可能⼩是你义不容辞的责任, 从⽽带来的问题是, 你的代码布局, 类设计, 框架设计以及某些细节实现要尽可能合理; 另⼀个是不管你项⽬或产品多着急, 可能不允许你随意使⽤第三⽅类库, 尽管他们很⽅便更健壮, 即你可能要抛弃了⼤轮⼦, 还要打造⼩轮⼦, 重复发明轮⼦. ⽐如你为了做⼀个难度较⼤的动画效果⽽引⼊游戏动画引擎的可能性很低, 只能⾃⼰摸索实现动画的每个细节, 再⽐如你需要放弃使⽤好⽤的FastJson或Gson, ⽽⽤Android⾃带的org.json库, 除⾮有特殊需要或⼗分明确⽽⼜堂⽽皇之的理由, 否则不应该包含⾃⼰编译的sqlite或openssl库, 另外你可能不能直接使⽤Apache Commons或者Guava之类的库, Ioc框架的库等, 要么需要裁切这些库要么⾃⼰封装, 然后你每换⼀份⼯作都重新熟悉他们独有的封装;
安全.
包括sqlite数据库的加解密⽅案, 是加密数据库管理系统呢还是加密关键字段? 包括⽹络通信安全, 你可
能需要使⽤SSL; 包括代码安全, 你可能不希望你的劳动成果, 尤其是门槛很⾼的关键技术, 随意的被任何⼈看到或使⽤; 你可能不希望你的应⽤被加了很多⼴告或瑕疵⼜重新发布到应⽤市场扰乱你的信誉, 剥削你的收益; 如果你的应⽤涉及电⼦商务, 安全⽀付或者虚拟货币, 你需要设计良好的业务流程和逻辑, 并且这些核⼼不容别⼈查看或寻漏洞; 为此, 你可能会做代码混淆, ⽽很多类不允许你混淆, 这样App跑起来后因为NotFound⽽抱怨; 你可能将很多实现移⼊so, 因为是⽤
c/c++写代码, 如果你不熟悉, 很可能错误百出, ⽽且经常引起其他问题, ⽐如因平台相关⽽导致的兼容问题; 即便这些你都花时间学了, 也努⼒做了,
还有⼀个挥之不去的问题, 就是安全领域是对抗性的⼯作. 你的应⽤现在安全不代表以后也安全, 如果应⽤受欢迎, 会有⼤把的⼈来研究破解你的程序; 不仅如此, 你可能还需要谨慎的使⽤四⼤组件, Android设置App, 这些可能⽆形中帮了不法分⼦去损害你⽤户的权益;
⽣存.
这个问题其实可以并⼊其他问题中. 这⾥所谓的⽣存不是指App⽕多久, 这可能不在程序员的考虑之中. 这⾥的⽣存就像⼈的⽣存, ⼈要⽣存离不开社会环境, 应⽤要⽣存离不开操作系统和其他应⽤的配合. ⽐如操作系统或者安全软件可能⽆故, 有意, 有理由杀死⽤户⼿机上你的进程, ⽽不发给你任何邮件. ⽐如你需要输⼊法的某种配合却不到接⼝或⼊⼝, ⽐如输⼊法窗⼝或者其他应⽤因为你的某段代码的执⾏
或者⽤户的操作, ⽆情的遮挡了你需要实时通知给⽤户的信息, 再⽐如你在通知栏上做的信息显⽰, 其效果在某些机型上让你感到费解, 再⽐如⼩⽶不允许未经同意就显⽰悬浮窗;
兼容.
这个问题的范围最⼴, 很多问题都可以归⼊这个问题. 它包括了很多⽅⾯, ⽐如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库或者来个段错误. 上⾯说的输⼊法, 及其他应⽤也会有兼容问题, 搜狗输⼊法和其他输⼊法对某些操作的反应都不⼀样. 最后要提的
兼容问题是升级设置, 即是否允许不同⽼版本在⽤户市场上并存, 此时不同版本的协议变迁如何设计兼容? 亦或者强制升级到最新的⼀个或两个版本上, 是做增量升级还是整体下载升级, 升级失败如何处理?
这么多棘⼿的问题, 隐患和风险, 你是否评估好了, 准备好了, 设计做⾜了, 有好对策了?

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。