如何通过技术优化让 android 程序变得流畅
优化之前性能改善应该作为产品设计时就应该考虑的要素,也是品质控制的重要一环。还是那句老话, 如果做,请趁早。在雏形阶段,就应该对于性能的表现形式定下具体的kpi,比如,需要用多少时间来打开某个页面, 导入/导出多少条数据在多少秒之内, 运行时的内存峰值控制在多少等等。 如果你面对的是一个多个团队维护, 开发维护历史坎坷, 用户众多的产品, 那第一步要做的也是确定kpi, 并经可能准确稳定的得到基线。1、确定kpi kpi不一定非要从最终用户的交付出发, 也可以是像"loop函数的处理时间不超过0.05秒"这样规定.得到基线 根据kpi先得到基线, 如果已经有成型的产品, 则用当前的版本作为输入得到, 如果没有产品, 考察几个市面上的竟品得到. 同时需要注意的是基线的测量不可避免的会遇到样本不足和数据抖动的问题, 使得不稳定性, 所以测量方法也要尽可能的稳定和禁得住推敲.测量方法的设计也是一个涉及面比较广的话题了, 不展开了. 多测试几次,应用方差/平均值这样的统计方法处理. 现在越来越多的应用使用线上收集的方式来收集性能数据, 就是为了增加样本数.识别问题得到基线后, 基本上对于产品的性能就有一个__客观__的认识了。记下来就开始针对用户/产品/开发者不满意的地方进行工作了。不过,先不要急, 首先要识别问题。这里有一个我对于问题的分类, 跟各位分享。资源资源类问题指产品对于资源使用上存在着严重的浪费, 比如频繁的io操作, 过度的线程使用等等。体验大部分影响用户体验的问题,都可能是资源类问题引起的。但是还有相当一部分与资源无关, 比如: 数据从网络端到客户端呈现比较慢,打开任务列表是等到菊花也谢了等分析并解决问题就像性能问题是多种多样的一样, 解决问题的手段也要视不同情况而定。但是,还是有一定的规律可循,同时,也有一些风险需要规避:2、**新技术盲目的认为新技术的引入可以解决性能问题, 往往摁下葫芦起了瓢。3、频繁改设计每当有性能指标表现低下时,就改动设计, 认为设计一定存在不合理的地方。同时, 有一些实践经验分享:4、优化交互对于体验类问题, 其实最好的切入点是优化交互设计。比如: 让页面能马上进入,可以让用户操作一些不需要网络数据的操作; 多张图片展示增加动画效果,虽然总体展示时间不能提高,但是给用户在整个过程中产品很努力不无聊。5、先改bug比较突出的性能问题往往伴随着bug或者代码瑕疵。比如, 在android上内存的泄漏引起频繁gc导致程序卡顿; 逻辑错误导致程序在后台持续请求数据,引起功耗增加等。所以, 请先将bug控制住,我们再来谈性能的改善。6、适合移动设备的设计服务器端接口设计上尽可能的精简,考虑到移动端的设计, 分页, 消息结构精简, 键值短。移动端对于资源类(webview, thread, io类操作)有统一的管理, 无论多少产品由多少个团队维护,都要从统一的资源入口进行请求和处理。队列在这方面一直很受欢迎^o^根据机型和网络情况适配, 避免产生过大,过多的资源对象(比如图片, html5的dom等)考虑数据资源的共用和缓存。 图片和h5的缓存不再话下, 多团队合作时要考虑之前这些数据是否已经有可以借用,图片对象有时可以借用,部分数据可能也会有用。视图层深的优化,可能需要设计的介入 但是很多时候对于视图结构的麻木可能是罪魁祸首。没有太好的建议,因为场景一般都比较复杂。这里呼吁, 请先积攒一些手写ui的经验再来开发工程产品吧。其他。一些细节的把握, 参考各种代码实践经验,微小调整追求卓越。优化之后测量,收集数据,来印证修改效果,一切用数据说话。记得将解决实践记录到checkl**t分享制定相应的代码静态规则/单元用例等放入持续集成中。总结断: 去掉不关注的方面, 专注影响性能的因素 舍: 放弃不切合实际的做法, 专注于问题的实质原因 离: 让性能问题, 慢慢远离你的产品吧^_^ 20210311