精华内容
下载资源
问答
  • 关于流程优化方面的建议
    千次阅读
    2020-06-09 16:27:23

     

    企业流程的"点线面"三层优化

     

          企业流程优化开展了很长一段时间,也在这方面做了很多积累,但是形成的流程总感觉不系统,不落地,怎么通过流程从宏观到微观,从战略到运营,从点到面,形成企业上下的整体协同运作,实现企业战略落地?”这是某企业高层对流程优化咨询项目提出的需求,也反映出企业实践中对流程产生更高的期望。

    据调查发现,流程管理在企业的实践已经站在了新的起点,由概念引入、孤岛式流程优化向关注与战略和业务的融合、系统性的流程体系优化进行转变。另一方面,随着企业的扩张和地理范围的不断延伸,如何通过流程优化,实现多组织的协同运作和加强一体化管理,使企业能以更有效率的方式进行管控,对流程管理工作也提出新的挑战。

    针对这些需求,通过咨询实践,我们发现流程优化工作将不再仅仅局限于某个具体流程局部的优化,而应该是点、线、面结合,同时综合借鉴战略管理、时钟管理、项目管理、知识管理以及IT等方法工具,推动流程系统级的优化和落地。

     

    一、流程优化的“点”

     

    1、企业在流程建立后发现无法落地,一方面原因可能是流程比较粗

     

    只是规定了流程的活动由谁来做,但如何做不清楚,具体的表单模板、操作标准规范缺乏,从而使流程不具有可操作性;特别是对于快速人员扩张,岗位交替频繁,使流程执行的结果差异化比较大。

    因此,流程“点”的优化主要是通过表单模板实现精细化管理:通过流程配套表单模板,将流程管理思路进行落实和可操作化;同时表单模板制定中应考虑将流程的检查要求、专业知识通过模板固化,直接呈现在使用者面前,以固化最佳实践,实现知识的共享和标准化复制;最后,需要关注的还有表单模板的字段优化,通过标准化字段信息,为后续的数据分析奠定基础,通过数据分析促进流程优化和提供决策支持。

     

    2、流程不能落地的另一个原因是不够简化。

    大的企业管理流程制度文件动辄上百个,和自己相关的不知道有哪几个,流程“点”的优化就是建立基于岗位的索引。如对于企业高层,需要审批的内容很多,不知道哪些该自己签字,优化的方法就列一张管控表,使审批的过程和基于的流程制度文件清晰标识,简单明了化;一般岗位同样也可以建立自己的相关流程制度知识地图索引。

     

    二、流程优化的“线”

    流程“线”的优化,即端到端的流程优化。所谓端到端,起点从市场需求或者企业的战略计划制定,终点到通过执行评估改进,完整地解决客户需求。在以往的流程优化工具中,提到过很多如ASME表、ESEIA等流程优化工具,重点是减少流程中的非增值活动和简化流程。

    然而对于解决多组织协同问题,端到端流程优化的重点:

     

    一是,设置面向整体流程的绩效目标,使端到端流程线上的每个岗位朝着同一目标努力,从而形成系统合力。如新产品上市流程,需建立以新产品上市成功率为导向的统一流程绩效目标,以避免流程环节中的各个部门同向不同力。

    二是,通过分阶段评审决策点设置,实现管理前置,以减少流程返工造成的浪费。

    三是,加强对流程中的信息交流和协同点的识别,在一个跨区域多组织企业中,流程运行的很多问题是由于信息的不对称或者没有及时沟通造成的。因此,明确流程每一个环节的协同点和信息输出点对保障后端流程的顺利进行非常重要。

     

    三、流程优化的“面”

    流程面的优化包括两方面:流程与战略的配称以及流程运行的时钟协同。通过流程面上的优化,使多组织纵向和战略目标对齐,横向执行的步调一致,从而提升企业战略一体化管控能力。

     

    1、流程与战略的配称是指流程运行的目标、流程对应的业务模式、流程运行所需的人财物资源配套都与企业的战略相匹配。

     

    迈克尔.波特在《战略配称》中提到:整体作战比任何一项单独活动都来得重要与有效。竞争优势来自各项活动形成的整体系统。通过建立一个环环相扣、紧密联接的链,使企业各项活动有机组合,将模仿者拒之门外。这里环环相扣、紧密联接的链就是企业整体的流程框架体系。

    该流程框架体系上起始于战略及计划预算制定流程,通过战略及计划预算制定,确定各业务流程领域的流程目标以及需要的资源支持,形成具体的业务运营计划。业务运营流程的构建则需要和企业的战略及流程目标相匹配,如企业战略要求快速响应市场,则供应链流程的设计优化更多考虑如何提高柔性。最后,通过运营流程中的信息反馈,进行战略执行监控,从而形成战略到运营的PDCA闭环管理。

    将该流程框架细化分解到各子流程后,对子流程间的相关衔接或输入输出关系进行连接,形成一张流程关系总图,虽然流程清单分解会是一张树状图,但最终形成的流程关系总图是一张网状图,各流程间都是相互支撑和衔接的。如果一个流程关系总图上,一个流程和其他任何流程都没有输入输出或者链接关系,说明或者是完全独立的一个业务,或者是冗余的职能。

    企业的最高管理层是这张整体的流程框架总图的责任人,其核心任务是确定企业战略,同时在流程间建立配称和相互衔接关系。

     

    2、流程运行的时钟协同,其核心是多组织多领域综合计划体系的管理,通过对流程的运作加上时间,形成一张运营节拍全景图,使所有人员按照统一的时钟运作,从而使企业运作形成稳定的节奏,实现多组织的运作协同。

     

    从宏观上来看,流程运行时钟设置,首先要考虑企业的业务特征和外部的环境影响,如服饰企业生产运营表现出的明显的季节特征;快消品企业的淡旺季特征等,这种运行时钟多半以年为周期,是企业战略流程和重大业务运营活动所遵循的运作时钟。

    如某企业市场策略的制定——执行——绩效评估是围绕着每年三个产品销售季来进行;某企业大型经销商年会时钟的优化,既考虑避免与外部大型事件冲突,同时还要考虑考虑市场启动因素,春运因素等。

    从中观上来看,通过时钟优化,从时间的角度来解决跨组织资源难以统筹协调的问题。如我们经常发现临时召开一个会议难以召集齐需要参加的人员,或者要处理的问题都是零散的,难以提高效率,针对这种情况,则需要对多个流程的时钟和会议进行整合。

    如某营销组织通过流程时钟优化,使得总部的品牌和销售职能管理人员在上半月可以跑市场,收集信息和问题,在每月下旬集中在总部讨论问题和改进;同时对于区域自下而上提报的一些产品、价格、促销等需求审批流程,统一时钟,使总部的审批时间统一放在每月下旬,通过这种改进,推动品牌和销售线上线下的配合,提高了流程的审批效率,同时在总部和区域公司自上而下形成一个稳定的运营节拍。

    从微观上来看,通过逐步将一些运营时钟固化,使例外管理向例行管理转移,使过去随机式管理向计划式管理转移。如某企业高层的重大运营决策会,以前是按需召开,流程优化时我们建议最好固定在每月的20号左右,从而对未来时间有了明确的预期,方便高层统筹安排时间计划。

    四、“点线面”优化的逻辑步骤

    我们在诸多企业发现,企业更多关注“线”的优化,而忽略“面”的优化,究其原因,负责流程管理的部门往往很难站在企业整体的高度进行流程优化,因此只解决了局部的管理规范化,而没有和战略衔接形成整体的规划和管理;而对于“点”的优化落实,由于缺乏对业务操作细节的掌握,也往往是虎头蛇尾。

    企业在开展系统性的流程体系优化时,我们建议循序渐进的进行点线面三层优化的推进,具体如下:

    1、进行流程框架的优化,明确从战略到业务运营各核心流程领域间的逻辑链接,管控模式等,形成流程清单,完成“面”的初步构架;该项工作需由企业高层和流程管理部门共同完成;

    2、进行具体流程的优化,明确流程的输入输出、协同流转和运行时钟,形成流程图,搭出流程的“线”;该项工作主要由流程管理部门推动,各流程责任人负责完成;

    3、基于前两步的输出,进行流程间的时钟整合和协同,实现各流程间的无缝连接,使企业形成一个整体运作;该项工作主要由流程管理部门(或综合运营管理部门)负责整理,并组织各流程责任人共同讨论完成;

    4、在线的优化基础上,进一步进行点的优化,优化细化表单模板,使流程具有可操作性,该项工作主要由流程管理部门推动,各流程责任人负责完成;

    5、最后,在流程体系完善的基础上,由流程管理部门和流程责任人共同推动,形成基于岗位的简化工作索引,推动流程的落地执行。

    更多相关内容
  • 由KBC公司开发的生产过程稳态模拟和优化的大型通用流程模拟软件Petro-SIM软件,目前已在很多炼厂装置工况分析、故障诊断、挖潜增效、加工方案优化、装置生产优化方面发挥了重要的作用。应用Petro-SIM软件,对石家庄...
  • Android 性能优化四个方面总结

    千次阅读 2018-12-17 16:56:49
    目录一、四个方面二、卡顿优化1、Android系统显示原理2、卡顿根本原因3、性能分析工具(1)Profile GPU Rendering(2)TraceView(3)Systrace UI 性能分析4、优化建议(1)布局优化(2)避免过度绘制(3)启动优化...

    一、四个方面

    可以把用户体验的性能问题主要总结为4个类别:

    • 流畅

    • 稳定

    • 省电、省流量

    • 安装包小

    性能问题的主要原因是什么,原因有相同的,也有不同的,但归根到底,不外乎内存使用、代码效率、合适的策略逻辑、代码质量、安装包体积这一类问题,整理归类如下:
    在这里插入图片描述
    从图中可以看到,打造一个高质量的应用应该以4个方向为目标:快、稳、省、小。

    • :使用时避免出现卡顿,响应速度快,减少用户等待的时间,满足用户期望。

    • :减低 crash 率和 ANR 率,不要在用户使用过程中崩溃和无响应。

    • :节省流量和耗电,减少用户使用成本,避免使用时导致手机发烫。

    • :安装包小可以降低用户的安装成本。

    要想达到这4个目标,具体实现是在右边框里的问题:卡顿、内存使用不合理、代码质量差、代码逻辑乱、安装包过大,这些问题也是在开发过程中碰到最多的问题,在实现业务需求同时,也需要考虑到这点,多花时间去思考,如何避免功能完成后再来做优化,不然的话等功能实现后带来的维护成本会增加。


    二、卡顿优化

    Android 应用启动慢,使用时经常卡顿,是非常影响用户体验的,应该尽量避免出现。卡顿的场景有很多,按场景可以分为4类:UI 绘制、应用启动、页面跳转、事件响应,如图:
    在这里插入图片描述

    这4种卡顿场景的根本原因可以分为两大类:

    • 界面绘制:主要原因是绘制的层级深、页面复杂、刷新不合理,由于这些原因导致卡顿的场景更多出现在UI和启动后的初始界面以及跳转到页面的绘制上。

    • 数据处理:导致这种卡顿场景的原因是数据处理量太大,一般分为三种情况,一是数据在处理UI线程,二是数据处理占用CPU高,导致主线程拿不到时间片,三是内存增加导致GC频繁,从而引起卡顿。

    引起卡顿的原因很多,但不管怎么样的原因和场景,最终都是通过设备屏幕上显示来达到用户,归根到底就是显示有问题,所以,要解决卡顿,就要先了解Android系统的显示原理。


    1、Android系统显示原理

    Android显示过程可以简单概括为:Android应用程序把经过测量、布局、绘制后的Surface缓存数据,通过SurfaceFlinger把数据渲染到显示屏幕上, 通过Android的刷新机制来刷新数据。也就是说应用层负责绘制,系统层负责渲染,通过进程间通信把应用层需要绘制的数据传递到系统层服务,系统层服务通过刷新机制把数据更新到屏幕上

    我们都知道在Android的每个View绘制中有三个核心步骤:Measure、Layout、Draw。具体实现是从 ViewRootImp类的performTraversals() 方法开始执行,Measure和Layout都是通过递归来获取View的大小和位置,并且以深度作为优先级,可以看出 层级越深、元素越多、耗时也就越长

    真正把需要显示的数据渲染到屏幕上,是通过系统级进程中的SurfaceFlinger服务来实现的,那么这个SurfaceFlinger服务主要做了哪些工作呢?如下:

    • 响应客户端事件,创建Layer与客户端的Surface建立连接。

    • 接收客户端数据及属性,修改Layer属性,如尺寸、颜色、透明度等。

    • 将创建的Layer内容刷新到屏幕上。

    • 维持Layer的序列,并对Layer最终输出做出裁剪计算。

    既然是两个不同的进程,那么肯定是需要一个跨进程的通信机制来实现数据传递,在Android显示系统中,使用了Android的匿名共享内存:SharedClient,每一个应用和SurfaceFlinger之间都会创建一个SharedClient ,然后在每个SharedClient中,最多可以创建31个 SharedBufferStack,每个Surface都对应一个SharedBufferStack,也就是一个Window。

    一个SharedClient对应一个Android应用程序,而一个Android应用程序可能包含多个窗口,即Surface。也就是说SharedClient包含的是SharedBufferStack的集合,其中在显示刷新机制中用到了双缓冲和三重缓冲技术。最后总结起来显示整体流程分为三个模块:应用层绘制到缓存区,SurfaceFlinger把缓存区数据渲染到屏幕,由于是不同的进程,所以使用Android的匿名共享内存SharedClient缓存需要显示的数据来达到目的。

    除此之外,我们还需要一个名词:FPS。FPS表示每秒传递的帧数在理想情况下,60FPS就感觉不到卡,这意味着每个绘制时长应该在16ms以内。但是 Android系统很有可能无法及时完成那些复杂的页面渲染操作。Android系统每隔16ms发出VSYNC信号,触发对UI进行渲染,如果每次渲染都成功,这样就能够达到流畅的画面所需的60FPS。如果某个操作花费的时间是24ms ,系统在得到VSYNC信号时就无法正常进行正常渲染,这样就发生了丢帧现象。那么用户在32ms内看到的会是同一帧画面,这种现象在执行动画或滑动列表比较常见,还有可能是你的Layout太过复杂,层叠太多的绘制单元,无法在16ms完成渲染,最终引起刷新不及时。


    2、卡顿根本原因

    根据Android系统显示原理可以看到,影响绘制的根本原因有以下两个方面:

    • 绘制任务太重,绘制一帧内容耗时太长

    • 主线程太忙,根据系统传递过来的VSYNC信号来时还没准备好数据导致丢帧

    绘制耗时太长,有一些工具可以帮助我们定位问题。主线程太忙则需要注意了,主线程关键职责是处理用户交互,在屏幕上绘制像素,并进行加载显示相关的数据,所以特别需要避免任何主线程的事情,这样应用程序才能保持对用户操作的即时响应。总结起来,主线程主要做以下几个方面工作:

    • UI生命周期控制

    • 系统事件处理

    • 消息处理

    • 界面布局

    • 界面绘制

    • 界面刷新

    除此之外,应该尽量避免将其他处理放在主线程中,特别复杂的数据计算和网络请求等。


    3、性能分析工具

    性能问题并不容易复现,也不好定位,但是真的碰到问题还是需要去解决的,那么分析问题和确认问题是否解决,就需要借助相应的的调试工具,比如查看Layout层次的Hierarchy View、Android系统上带的GPU Profile工具和静态代码检查工具Lint等,这些工具对性能优化起到非常重要的作用,所以要熟悉,知道在什么场景用什么工具来分析。


    (1)Profile GPU Rendering

    在手机开发者模式下,有一个卡顿检测工具叫做:Profile GPU Rendering,如图:
    在这里插入图片描述

    它的功能特点如下:

    • 一个图形监测工具,能实时反应当前绘制的耗时

    • 横轴表示时间,纵轴表示每一帧的耗时

    • 随着时间推移,从左到右的刷新呈现

    • 提供一个标准的耗时,如果高于标准耗时,就表示当前这一帧丢失


    (2)TraceView

    TraceView是Android SDK自带的工具,用来分析函数调用过程,可以对Android的应用程序以及Framework层的代码进行性能分析。它是一个图形化的工具,最终会产生一个图表,用于对性能分析进行说明,可以分析到每一个方法的执行时间,其中可以统计出该方法调用次数和递归次数,实际时长等参数维度,使用非常直观,分析性能非常方便。


    (3)Systrace UI 性能分析

    Systrace是Android 4.1及以上版本提供的性能数据采样和分析工具,它是通过系统的角度来返回一些信息。它可以帮助开发者收集Android关键子系统,如Surfaceflinger、WindowManagerService等Framework部分关键模块、服务、View系统等运行信息,从而帮助开发者更直观地分析系统瓶颈,改进性能。Systrace的功能包括跟踪系统的I/O操作、内核工作队列、CPU负载等,在UI显示性能分析上提供很好的数据,特别是在动画播放不流畅、渲染卡等问题上。


    4、优化建议

    • 布局优化
    • 避免过度绘制
    • 启动优化
    • 合理的刷新机制
    • 其他

    (1)布局优化

    布局是否合理主要影响的是页面测量时间的多少,我们知道一个页面的显示测量和绘制过程都是通过递归来完成的,多叉树遍历的时间与树的高度h有关,其时间复杂度O(h),如果层级太深,每增加一层则会增加更多的页面显示时间,所以布局的合理性就显得很重要。

    那布局优化有哪些方法呢,主要通过 减少层级、减少测量和绘制时间、提高复用性 三个方面入手。总结如下:

    • 减少层级:合理使用RelativeLayout和LinerLayout,合理使用Merge。

    • 提高显示速度:使用ViewStub,它是一个看不见的、不占布局位置、占用资源非常小的视图对象。

    • 布局复用:可以通过标签(include)来提高复用。

    • 尽可能少用wrap_content:wrap_content 会增加布局measure时计算成本,在已知宽高为固定值时,不用wrap_content。

    • 其他:删除控件中无用的属性。


    (2)避免过度绘制

    过度绘制是指在屏幕上的某个像素在同一帧的时间内被绘制了多次。在多层次重叠的UI结构中,如果不可见的UI也在做绘制的操作,就会导致某些像素区域被绘制了多次,从而浪费了多余的CPU以及GPU源。

    如何避免过度绘制呢,如下:

    • 布局上的优化:移除XML中非必须的背景,移除Window默认的背景、按需显示占位背景图片。

    • 自定义View优化:使用 canvas.clipRect()来帮助系统识别那些可见的区域,只有在这个区域内才会被绘制。


    (3)启动优化

    通过对启动速度的监控,发现影响启动速度的问题所在,优化启动逻辑,提高应用的启动速度。启动主要完成三件事:UI布局、绘制和数据准备。因此启动速度优化就是需要优化这三个过程:

    • UI布局:应用一般都有闪屏页,优化闪屏页的UI布局,可以通过Profile GPU Rendering检测丢帧情况。

    • 启动加载逻辑优化:可以采用分布加载、异步加载、延期加载策略来提高应用启动速度。

    • 数据准备:数据初始化分析,加载数据可以考虑用线程初始化等策略。


    (4)合理的刷新机制

    在应用开发过程中,因为数据的变化,需要刷新页面来展示新的数据,但频繁刷新会增加资源开销,并且可能导致卡顿发生,因此,需要一个合理的刷新机制来提高整体的UI流畅度。合理的刷新需要注意以下几点:

    • 尽量减少刷新次数

    • 尽量避免后台有高的CPU线程运行

    • 缩小刷新区域


    (5)其他

    在实现动画效果时,需要根据不同场景选择合适的动画框架来实现。有些情况下,可以用硬件加速方式来提供流畅度。


    三、内存优化

    在Android系统中有个垃圾内存回收机制,在虚拟机层自动分配和释放内存,因此不需要在代码中分配和释放某一块内存,从应用层面上不容易出现内存泄漏和内存溢出等问题,但是需要内存管理。Android系统在内存管理上有一个Generational Heap Memory模型,内存回收的大部分压力不需要应用层关心,Generational Heap Memory有自己一套管理机制,当内存达到一个阈值时,系统会根据不同的规则自动释放系统认为可以释放的内存,也正是因为Android程序把内存控制的权力交给了Generational Heap Memory,一旦出现内存泄漏和溢出方面的问题,排查错误将会成为一项异常艰难的工作。除此之外,部分Android应用开发人员在开发过程中并没有特别关注内存的合理使用,也没有在内存方面做太多的优化,当应用程序同时运行越来越多的任务,加上越来越复杂的业务需求时,完全依赖Android的内存管理机制就会导致一系列性能问题逐渐呈现,对应用的稳定性和性能带来不可忽视的影响,因此,解决内存问题和合理优化内存是非常有必要的。


    1、Android内存管理机制

    Android应用都是在 Android的虚拟机上运行,应用 程序的内存分配与垃圾回收都是由虚拟机完成的。在Android系统,虚拟机有两种运行模式:Dalvik和ART。

    (1)Java对象生命周期

    在这里插入图片描述
    一般Java对象在虚拟机上有7个运行阶段:

    创建阶段->应用阶段->不可见阶段->不可达阶段->收集阶段->终结阶段->对象空间重新分配阶段


    (2)内存分配

    在Android系统中,内存分配实际上是对堆的分配和释放。当一个Android程序启动,应用进程都是从一个叫做Zygote的进程衍生出来,系统启动 Zygote 进程后,为了启动一个新的应用程序进程,系统会衍生Zygote进程生成一个新的进程,然后在新的进程中加载并运行应用程序的代码。其中,大多数的RAM pages被用来分配给Framework代码,同时促使RAM资源能够在应用所有进程之间共享。

    但是为了整个系统的内存控制需要,Android系统会为每一个应用程序都设置一个硬性的Dalvik Heap Size最大限制阈值,整个阈值在不同设备上会因为RAM大小不同而有所差异。如果应用占用内存空间已经接近整个阈值时,再尝试分配内存的话,就很容易引起内存溢出的错误。


    (3)内存回收机制

    我们需要知道的是,在Java中内存被分为三个区域:Young Generation(新生代)、Old Generation(年老代)、Permanent Generation(持久代)。最近分配的对象会存放在Young Generation区域。对象在某个时机触发GC回收垃圾,而没有回收的就根据不同规则,有可能被移动到Old Generation,最后累积一定时间在移动到Permanent Generation 区域。系统会根据内存中不同的内存数据类型分别执行不同的GC操作。GC通过确定对象是否被活动对象引用来确定是否收集对象,进而动态回收无任何引用的对象占据的内存空间。但需要注意的是频繁的GC会增加应用的卡顿情况,影响应用的流畅性,因此需要尽量减少系统GC行为,以便提高应用的流畅度,减小卡顿发生的概率。


    2、内存分析工具

    做内存优化前,需要了解当前应用的内存使用现状,通过现状去分析哪些数据类型有问题,各种类型的分布情况如何,以及在发现问题后如何发现是哪些具体对象导致的,这就需要相关工具来帮助我们。


    (1)Memory Monitor

    Memory Monitor是一款使用非常简单的图形化工具,可以很好地监控系统或应用的内存使用情况,主要有以下功能:

    • 显示可用和已用内存,并且以时间为维度实时反应内存分配和回收情况。

    • 快速判断应用程序的运行缓慢是否由于过度的内存回收导致。

    • 快速判断应用是否由于内存不足导致程序崩溃。


    (2)Heap Viewer

    Heap Viewer的主要功能是查看不同数据类型在内存中的使用情况,可以看到当前进程中的Heap Size的情况,分别有哪些类型的数据,以及各种类型数据占比情况。通过分析这些数据来找到大的内存对象,再进一步分析这些大对象,进而通过优化减少内存开销,也可以通过数据的变化发现内存泄漏。


    (3)Allocation Tracker

    Memory Monitor和Heap Viewer都可以很直观且实时地监控内存使用情况,还能发现内存问题,但发现内存问题后不能再进一步找到原因,或者发现一块异常内存,但不能区别是否正常,同时在发现问题后,也不能定位到具体的类和方法。这时就需要使用另一个内存分析工具Allocation Tracker,进行更详细的分析,Allocation Tracker可以分配跟踪记录应用程序的内存分配,并列出了它们的调用堆栈,可以查看所有对象内存分配的周期。


    (4)Memory Analyzer Tool(MAT)

    MAT是一个快速,功能丰富的Java Heap分析工具,通过分析Java进程的内存快照HPROF分析,从众多的对象中分析,快速计算出在内存中对象占用的大小,查看哪些对象不能被垃圾收集器回收,并可以通过视图直观地查看可能造成这种结果的对象。


    3、常见内存泄漏场景

    如果在内存泄漏发生后再去找原因并修复会增加开发的成本,最好在编写代码时就能够很好地考虑内存问题,写出更高质量的代码,这里列出一些常见的内存泄漏场景,在以后的开发过程中需要避免这类问题。

    • 资源性对象未关闭:比如Cursor、File文件等,往往都用了一些缓冲,在不使用时,应该及时关闭它们。

    • 注册对象未注销:比如事件注册后未注销,会导致观察者列表中维持着对象的引用。

    • 类的静态变量持有大数据对象

    • 非静态内部类的静态实例

    • Handler临时性内存泄漏:如果Handler是非静态的,容易导致Activity或Service不会被回收。

    • 容器中的对象没清理造成的内存泄漏

    • WebView:WebView存在着内存泄漏的问题,在应用中只要使用一次WebView,内存就不会被释放掉。

    除此之外,内存泄漏可监控,常见的就是用LeakCanary第三方库,这是一个检测内存泄漏的开源库,使用非常简单,可以在发生内存泄漏时告警,并且生成leak tarce分析泄漏位置,同时可以提供Dump文件进行分析。


    4、优化内存空间

    没有内存泄漏,并不意味着内存就不需要优化,在移动设备上,由于物理设备的存储空间有限,Android 系统对每个应用进程也都分配了有限的堆内存,因此使用最小内存对象或者资源可以减小内存开销,同时让GC 能更高效地回收不再需要使用的对象,让应用堆内存保持充足的可用内存,使应用更稳定高效地运行。常见做法如下:

    • 对象引用:强引用、软引用、弱引用、虚引用四种引用类型,根据业务需求合理使用不同,选择不同的引用类型。

    • 减少不必要的内存开销:注意自动装箱,增加内存复用,比如有效利用系统自带的资源、视图复用、对象池、Bitmap对象的复用。

    • 使用最优的数据类型:比如针对数据类容器结构,可以使用ArrayMap数据结构,避免使用枚举类型,使用缓存Lrucache等等。

    • 图片内存优化:可以设置位图规格,根据采样因子做压缩,用一些图片缓存方式对图片进行管理等等。


    四、稳定性优化

    Android应用的稳定性定义很宽泛,影响稳定性的原因很多,比如内存使用不合理、代码异常场景考虑不周全、代码逻辑不合理等,都会对应用的稳定性造成影响。其中最常见的两个场景是:Crash和ANR,这两个错误将会使得程序无法使用,比较常用的解决方式如下:

    • 提高代码质量:比如开发期间的代码审核,看些代码设计逻辑,业务合理性等。

    • 代码静态扫描工具:常见工具有Android Lint、Findbugs、Checkstyle、PMD等等。

    • Crash监控:把一些崩溃的信息,异常信息及时地记录下来,以便后续分析解决。

    • Crash上传机制:在Crash后,尽量先保存日志到本地,然后等下一次网络正常时再上传日志信息。


    五、耗电优化

    在移动设备中,电池的重要性不言而喻,没有电什么都干不成。对于操作系统和设备开发商来说,耗电优化一致没有停止,去追求更长的待机时间,而对于一款应用来说,并不是可以忽略电量使用问题,特别是那些被归为“电池杀手”的应用,最终的结果是被卸载。因此,应用开发者在实现需求的同时,需要尽量减少电量的消耗。

    在Android5.0以前,在应用中测试电量消耗比较麻烦,也不准确,5.0之后专门引入了一个获取设备上电量消耗信息的API:Battery Historian。Battery Historian是一款由Google提供的Android系统电量分析工具,和Systrace一样,是一款图形化数据分析工具,直观地展示出手机的电量消耗过程,通过输入电量分析文件,显示消耗情况,最后提供一些可供参考电量优化的方法。

    除此之外,还有一些常用方案可提供:

    • 计算优化,避开浮点运算等

    • 避免WaleLock使用不当

    • 使用Job Scheduler


    六、安装包大小优化

    应用安装包大小对应用使用没有影响,但应用的安装包越大,用户下载的门槛越高,特别是在移动网络情况下,用户在下载应用时,对安装包大小的要求更高,因此,减小安装包大小可以让更多用户愿意下载和体验产品。

    常用应用安装包的构成,如图所示:
    在这里插入图片描述

    从图中我们可以看到:

    • assets文件夹:存放一些配置文件、资源文件,assets不会自动生成对应的 ID,而是通过AssetManager类的接口获取。

    • res:res是resource的缩写,这个目录存放资源文件,会自动生成对应的ID并映射到 .R文件中,访问直接使用资源ID。

    • META-INF:保存应用的签名信息,签名信息可以验证APK文件的完整性。

    • AndroidManifest.xml:这个文件用来描述Android应用的配置信息,一些组件的注册信息、可使用权限等。

    • classes.dex:Dalvik字节码程序,让Dalvik虚拟机可执行,一般情况下,Android应用在打包时通过Android SDK中的dx工具将Java字节码转换为Dalvik字节码。

    • resources.arsc:记录着资源文件和资源ID之间的映射关系,用来根据资源ID寻找资源。

    减少安装包大小的常用方案:

    • 代码混淆:使用ProGuard代码混淆器工具,它包括压缩、优化、混淆等功能。

    • 资源优化:比如使用Android Lint删除冗余资源,资源文件最少化等。

    • 图片优化:比如利用AAPT工具对PNG格式的图片做压缩处理,降低图片色彩位数等。

    • 避免重复功能的库,使用WebP图片格式

    • 插件化:比如功能模块放在服务器上,按需下载,可以减少安装包大小。

    展开全文
  • 项目实施过程中的优化建议

    千次阅读 2017-02-07 13:44:00
    2015年9月,我在一间上市公司的子公司任职测试组长,参与公司项目群会议时,针对项目的问题提出优化建议如下: 一、公司通用的商城项目: 个人觉得主要从 计划、实施、沟通协作、建设提高 这些方面考虑。 1、是...

    2015年9月,我在一间上市公司的子公司任职测试组长,参与公司项目群会议时,针对项目的问题提出优化建议如下:

    一、公司通用的商城项目:
    个人觉得主要从 计划、实施、沟通协作、建设提高 这些方面考虑。
    1、是希望立项制定整体计划的时候,要多留一些测试的时间,更好的保障项目质量。
    2、是在实施的过程中,主要是对内容变更的管理,制定需求变更流程和指定人员管理好变更内容,降低过程中的沟通成本。
    3、沟通方面:建议遇到开发与需求不一致时,开发人员、需求人员和测试人员三方同时在场确认解决方案。
    4、建议开发组内人员要加强沟通,模块与模块之间要对接好。
    5、提倡在禅道对开发人员任务进行记录,方便跟踪,也方便测试知道哪些人负责哪些模块。
    6、上线部署,没有一个版本管理制度。建议建立版本管理制度。或者是:建议开发人员在二期优化时,把每次修复BUG后提交程序到测试环境,才把BUG状态更新为已解决。这样,我们测试人员一看到BUG是已解决的就去验证。
    7、开发觉得需求不合理的地方没有及时提出,没有跟需求人员反馈,没有沟通就按自己的想法来做。建议若需求有不合理的地方,请开发人员及时反馈给需求人员,不然最终导致,开发的跟需求脱离了。
    8、测试人员不能及时了解到开发进度。每天早上召开半小时以内的例会,汇报昨天的开发进度和今天的开发计划。

    二、为银行定制的商城项目:

    行方频繁存在需求变更(界面、APP的问题)
         建议:1、项目组跟行方整理出需求变更内容。
                    2、进行需求变更分析,评估工作量(要考虑开发时间,还要考虑测试时间)
                    3、要明确解决需求变更的阶段性目标。
                    4、反馈阶段性结果给行方人员验收。

    三、对公司提一意见

    公司应有一个具体的项目实施流程(包括项目启动,需求分析,项目监控,质量管理等涉及到的人员之间的联系以及各个阶段规定的产出物)让所有项目人员都知道。

     

    转载于:https://my.oschina.net/u/2315260/blog/833261

    展开全文
  • 优化很笼统的词汇,这说明它包含的信息量很大,要处理的事情很多。 这次就详细说说,项目优化,都分哪些。 上目录: 目录 代码优化 业务优化 数据库优化 1、缓存 2、SQL优化 3、热点数据分离 4、数据库...

    优化很笼统的词汇,这说明它包含的信息量很大,要处理的事情很多。

    这次就详细说说,项目优化,都分哪些。

    上目录:

    目录

    代码优化

    业务优化

    数据库优化

    1、缓存

    2、SQL优化

    3、热点数据分离

    4、数据库读写分离

    5、页面静态化

    6、合并数据库操作

    7、分布式数据库

    8、NoSQL 和 Hadoop

    项目优化

    1、缓存

    2、数据库连接池应该设多大

    3、高并发方案


    一个一个来,先说

    代码优化

    代码优化主要对代码结构层次的优化,目的就是更加方便代码的可维护性与可读性

    代码结构层次的优化

    例如:

    1. 代码注释(代码规范)
    2. 工具类的封装(方便代码维护,使结构更加清晰,保证团队代码质量一致)
    3. 公共部分的提取
    4. 代码极简化(适度即可)
    5. 遇见多重if else 可以试试“策略模式”

    这些是对代码层次的优化所提出的建议,其他的都不说,只针对最后一项,代码极简化这一问题提出一些方案

    ☞各位太君~里面请~《Java代码-极简之道》☜

    看完之后~继续咱的聊啊~然后就是

    代码性能优化

    列如:

    1. 使用一些性能比较高的类(bufferInputStream)
    2. 缓冲区块的大小(4k或者8k)
    3. 通常要用stringbuffer替代string加号拼接
    4. 解析大文件的xml数据使用sax替代dom4j,使用分段批量提交来完成大数据量的插入。
    5. 根据业务情况使用缓存减少对数据库的访问。
    6. 单线程应尽量使用 HashMap, ArrayList,因为HashTable,Vector使用了同步机制,降低了性能。
    7. 在finally块中关闭流,断开连接,释放资源。
    8. 避免在循环条件中使用复杂表达式 。

    等等等等这些类似的

    然后就是

    业务优化

    我们做项目的时候业务优化这方面最主要是从用户体验度角度进行考虑,减少用户操 作的步骤提高工作效率,通常有以下几种:

    1. 可以通过tabindex属性来改变tab键盘的操作顺序
    2. 可以通过回车键来进行搜索或者提交操作
    3. 对于单选按钮和复选按钮可以通过操作后面的文本来选择前面的单选按钮以及复选按钮
    4. 添加的信息要按照id倒序进行排列
    5. 进行搜索操作时加入js loading操作(不仅告诉用户所进行的请求正在被处理,而且防止用户多次点击提交操作)
    6. 当进行删除操作的时候要弹出提示框,警告用户要进行删除操作,是否确认,如果删除成功则弹出提示框告诉用户。
    7. 根据returnURL在用户登录成功后直接跳到想要访问的资源。
    8. 进行删除操作时通过confirm提示用户是否确认删除操作,操作完后提示操作是否成功。
    9. 减少用户操作的步骤
    10. 使用autocomplete插件快速进行搜索

    等等等等... ...这些都是从业务角度来说的,

    然后就是

    数据库优化

    1、缓存

    首先第一种解决方案就是缓存了。

    缓存,我们可以将数据直接缓存在内从中,例如 Map、也可以使用缓存框架如 Redis 等,将一些需要频繁使用的热点数据保存在缓存中,每当用户来访问的时候,就可以直接将缓存中的数据返回给用户,这样可以有效降低服务器的压力。

    可以缓存起来使用的数据,一般都不能对实时性要求太高。

    2、SQL优化

    很多时候程序跑得慢,不是因为设备落后,而是因为数据库 SQL 写的太差劲。

    要解决海量数据的问题,数据库优化肯定也是不可避免的。一般来说,我们可以从 SQL 优化、表结构优化、以及数据库分区分表等多个方面来对数据库进行优化。

    现在说说最常见的SQL优化的基本常识:

    1. 外键必须加索引。
    2. 避免在 where 子句中对有索引的字段进行运算,这会导致索引失效,从而进行全表扫描。
    3. 在 where 及 order by 涉及的列上建立索引,要尽量避免全表扫描。
    4. 在设计表时要避免表中字段出现null的情况,通常要为其设置默认值。
    5. 避免在查找时放弃使用索引而进行全表扫描。
    6. SELECT语句中避免使用'*’,只查询需要返回的字段 ,这样可以减少oracle解析sql语句的时间。
    7. 用NOT EXISTS 替换 NOT IN 操作符,用 EXISTS  替换 IN

    这些,当然,还有就是其他的

    说其他的之前我先解释一下上面第六条的解释

    链接:《SELECT * 执行效率低的原因在哪里?》

    然后就是另外一个需要考虑优化的地方

    链接:《数据量很大,分页查询很慢的优化方案?》

    3、热点数据分离

    数据库中的数据,虽然是海量数据,但是这些数据并不见得所有数据都是活跃数据,例如用户注册,有的用户注册完就消失的无影无踪了,而有的用户则在不停的登录,因此,对于这两种不同的用户,我们可以将活跃用户分离出来,在主要操作的数据表中只保存活跃用户数据。每次用户登录,先去主表中查看有没有记录,有的话,直接登录,没有的话,再去查看其他表。

    通过判断用户在某一段时间内的登录次数,就可以很快分离出热点数据。

    (我先声明啊~这只是解题思路~)

    4、数据库读写分离

    读写分离之后,一方面可以提高数据库的操作效率,另一方面也算是对数据库的一个备份。

    5、页面静态化

    emmmmm~不知道为啥~很多开发者也好其他架构也好,不是很喜欢页面静态化的写法,但是不得不说,这样确实能一定程度上减轻压力

    而页面静态化其实可以算作是缓存的另外一种形式,相当于直接将相关的页面渲染结果缓存起来。

    在我们的 Web 项目中,资源分为两大类:

    • 静态资源
    • 动态资源

    静态资源就是我们常见的 HTML、CSS、JavaScript、图片等资源,这些资源可以不经过服务端处理,就可以直接返回给前端浏览器,浏览器就可以直接显示出来。

    动态资源则是指我们项目中的 Servlet 接口、Jsp 文件、Freemarker 等,这些需要经过服务端渲染之后,才可以返回前端的资源。

    在实际项目中,静态资源的访问速度要远远高于动态资源,动态资源往往很容易遇到服务器瓶颈、数据库瓶颈,因此,对于一些不经常更新的页面,或者说更新比较缓慢的页面,我们可以通过页面静态化,将一个动态资源保存为静态资源,这样当服务端需要访问的时候,直接将静态资源返回,就可以避免去操作数据库了,降低数据库的压力。

    当然还要考虑到数据的长度已经浏览器的容量问题,总不能都一股脑的都塞浏览器里吧~

    一般来说,Freemarker、Velocity 等都有相关的方法可以帮助我们快速将动态页面生成静态页面。

    这就是页面静态化。

    6、合并数据库操作

    这个方案的宗旨其实是减少数据库操作的次数,例如多次插入操作,我们可以合并成一条 SQL 搞定。多个不同条件的查询,如果条件允许的话,也可以合并成为一个查询,尽量减少数据库的操作,减少在网络上消耗,同时也降低数据库的压力。

    7、分布式数据库

    数据库读写分离之后,无形中增大了代码的复杂度,所以一般还需要借助分布式数据库中间件,这样可以有效提高数据库的弹性,可以方便的随时为数据库扩容,同时也降低代码的耦合度。

    8、NoSQL 和 Hadoop

    另外,引入 NoSQL 和 Hadoop 也是解决方案之一。NoSQL 突破了关系型数据库中对表结构、字段等定义的条条框框,使用户可以非常灵活方便的操作,另外 NoSQL 通过多个存储块存储数据的特点,使得天然具备操作大数据的优势(快)。不过,老实说,NoSQL 目前还是在互联网项目中比较常见,在传统的企业级应用中还是比较少见。

    Hadoop 就不必说了,大数据处理利器。

    项目优化

    1、缓存

    不说,这一块儿的教学太多了,告辞~直接蹦下一个~

    2、数据库连接池应该设多大

    ☞以下内容95%译自这篇文章,各位太君~里面请~☜

    接下来是正文

    数据库连接池的配置是开发者们常常搞出坑的地方,在配置数据库连接池时,有几个可以说是和直觉背道而驰的原则需要明确。

    你有一个网站,压力虽然还没到Facebook那个级别,但也有个1万上下的并发访问——也就是说差不多2万左右的TPS。那么这个网站的数据库连接池应该设置成多大呢?结果可能会让你惊讶,因为这个问题的正确问法是:

    “这个网站的数据库连接池应该设置成多小呢?”

    ☞这个视频是Oracle Real World Performance Group发布的,有兴趣的太君~里面请~☜

    因为这视频是英文解说且没有字幕,我替大家做一下简单的概括:

    视频中对Oracle数据库进行压力测试,9600并发线程进行数据库操作,每两次访问数据库的操作之间sleep 550ms,一开始设置的中间件线程池大小为2048:

    压测跑起来之后是这个样子的:

    每个请求要在连接池队列里等待33ms,获得连接后执行SQL需要77ms

    此时数据库的等待事件是这个熊样的:

    各种buffer busy waits,数据库CPU在95%左右

    接下来,把中间件连接池减到1024(并发什么的都不变),性能数据变成了这样:

    获取链接等待时长没怎么变,但是执行SQL的耗时减少了。下面这张图,上半部分是wait,下半部分是吞吐量

    能看到,中间件连接池从2048减半之后,吐吞量没变,但wait事件减少了一半。

    接下来,把数据库连接池减到96,并发线程数仍然是9600不变。

    96个连接时的性能数据

    队列平均等待1ms,执行SQL平均耗时2ms。

    wait事件几乎没了,吞吐量上升。

    没有调整任何其他东西,仅仅只是缩小了中间件层的数据库连接池,就把请求响应时间从100ms左右缩短到了3ms。

    为什么nginx只用4个线程发挥出的性能就大大超越了100个进程的Apache HTTPD?

    即使是单核CPU的计算机也能“同时”运行数百个线程。但我们都[应该]知道这只不过是操作系统用时间分片玩的一个小把戏。一颗CPU核心同一时刻只能执行一个线程,然后操作系统切换上下文,核心开始执行另一个线程的代码,以此类推。给定一颗CPU核心,其顺序执行A和B永远比通过时间分片“同时”执行A和B要快,这是一条计算机科学的基本法则。一旦线程的数量超过了CPU核心的数量,再增加线程数系统就只会更慢,而不是更快。

    这几乎就是真理了……

    上面的说法只能说是接近真理,但还并没有这么简单,有一些其他的因素需要加入。当我们寻找数据库的性能瓶颈时,总是可以将其归为三类:CPU、磁盘、网络。把内存加进来也没有错,但比起磁盘和网络,内存的带宽要高出好几个数量级,所以就先不加了。

    如果我们无视磁盘和网络,那么结论就非常简单。在一个8核的服务器上,设定连接/线程数为8能够提供最优的性能,再增加连接数就会因上下文切换的损耗导致性能下降。数据库通常把数据存储在磁盘上,磁盘又通常是由一些旋转着的金属碟片和一个装在步进马达上的读写头组成的。读/写头同一时刻只能出现在一个地方,然后它必须“寻址”到另外一个位置来执行另一次读写操作。所以就有了寻址的耗时,此外还有旋回耗时,读写头需要等待碟片上的目标数据“旋转到位”才能进行操作。使用缓存当然是能够提升性能的,但上述原理仍然成立。

    在这一时间段(即"I/O等待")内,线程是在“阻塞”着等待磁盘,此时操作系统可以将那个空闲的CPU核心用于服务其他线程。所以,由于线程总是在I/O上阻塞,我们可以让线程/连接数比CPU核心多一些,这样能够在同样的时间内完成更多的工作。

    那么应该多多少呢?这要取决于磁盘。较新型的SSD不需要寻址,也没有旋转的碟片。可别想当然地认为“SSD速度更快,所以我们应该增加线程数”,恰恰相反,无需寻址和没有旋回耗时意味着更少的阻塞,所以更少的线程[更接近于CPU核心数]会发挥出更高的性能。只有当阻塞创造了更多的执行机会时,更多的线程数才能发挥出更好的性能。

    网络和磁盘类似。通过以太网接口读写数据时也会形成阻塞,10G带宽会比1G带宽的阻塞少一些,1G带宽又会比100M带宽的阻塞少一些。不过网络通常是放在第三位考虑的,有些人会在性能计算中忽略它们。

    上图是PostgreSQL的benchmark数据,可以看到TPS增长率从50个连接数开始变缓。在上面Oracle的视频中,他们把连接数从2048降到了96,实际上96都太高了,除非服务器有16或32颗核心。

    计算公式

    下面的公式是由PostgreSQL提供的,不过我们认为可以广泛地应用于大多数数据库产品。你应该模拟预期的访问量,并从这一公式开始测试你的应用,寻找最合适的连接数值。

    连接数 = ((核心数 * 2) + 有效磁盘数)

    核心数不应包含超线程(hyper thread),即使打开了hyperthreading也是。
    如果活跃数据全部被缓存了,那么有效磁盘数是0,随着缓存命中率的下降,有效磁盘数逐渐趋近于实际的磁盘数。
    这一公式作用于SSD时的效果如何尚未有分析。

    按这个公式,你的4核i7数据库服务器的连接池大小应该为((4 * 2) + 1) = 9。取个整就算是是10吧。是不是觉得太小了?跑个性能测试试一下,我们保证它能轻松搞定3000用户以6000TPS的速率并发执行简单查询的场景。如果连接池大小超过10,你会看到响应时长开始增加,TPS开始下降。

    这一公式其实不仅适用于数据库连接池的计算,大部分涉及计算和I/O的程序,线程数的设置都可以参考这一公式。

    公理:你需要一个小连接池,和一个充满了等待连接的线程的队列

    如果你有10000个并发用户,设置一个10000的连接池基本等于失了智。1000仍然很恐怖。即是100也太多了。你需要一个10来个连接的小连接池,然后让剩下的业务线程都在队列里等待。连接池中的连接数量应该等于你的数据库能够有效同时进行的查询任务数(通常不会高于2*CPU核心数)。

    我们经常见到一些小规模的web应用,应付着大约十来个的并发用户,却使用着一个100连接数的连接池。这会对你的数据库造成极其不必要的负担。

    请注意

    连接池的大小最终与系统特性相关。

    比如一个混合了长事务和短事务的系统,通常是任何连接池都难以进行调优的。最好的办法是创建两个连接池,一个服务于长事务,一个服务于短事务。

    再例如一个系统执行一个任务队列,只允许一定数量的任务同时执行,此时并发任务数应该去适应连接池连接数,而不是反过来。

    3、高并发方案

    (这一块儿我又得单独拉一块儿~先写干货吧~)

    纵向扩展(scale-up)

    它的目标是提升单机的处理能力,方案又包括:

    1. 提升单机的硬件性能:通过增加内存、CPU核数、存储容量、或者将磁盘升级成SSD等堆硬件的方式来提升。
    2. 提升单机的软件性能:使用缓存减少IO次数,使用并发或者异步的方式增加吞吐量。

    横向扩展(scale-out)

    因为单机性能总会存在极限,所以最终还需要引入横向扩展,通过集群部署以进一步提高并发处理能力,又包括以下2个方向: 

    1、做好分层架构:

    这是横向扩展的提前,因为高并发系统往往业务复杂,通过分层处理可以简化复杂问题,更容易做到横向扩展。

    上面这种图是互联网最常见的分层架构,当然真实的高并发系统架构会在此基础上进一步完善。比如会做动静分离并引入CDN,反向代理层可以是LVS+Nginx,Web层可以是统一的API网关,业务服务层可进一步按垂直业务做微服务化,存储层可以是各种异构数据库。

    2、各层进行水平扩展:

    无状态水平扩容,有状态做分片路由。业务集群通常能设计成无状态的,而数据库和缓存往往是有状态的,因此需要设计分区键做好存储分片,当然也可以通过主从同步、读写分离的方案提升读性能。

    高性能的实践方案

    1. 集群部署,通过负载均衡减轻单机压力。
    2. 多级缓存,包括静态数据使用CDN、本地缓存、分布式缓存等,以及对缓存场景中的热点key、缓存穿透、缓存并发、数据一致性等问题的处理。
    3. 分库分表和索引优化,以及借助搜索引擎解决复杂查询问题。
    4. 考虑NoSQL数据库的使用,比如HBase、TiDB等,但是团队必须熟悉这些组件,且有较强的运维能力。
    5. 异步化,将次要流程通过多线程、MQ、甚至延时任务进行异步处理。
    6. 限流,需要先考虑业务是否允许限流(比如秒杀场景是允许的),包括前端限流、Nginx接入层的限流、服务端的限流。
    7. 对流量进行削峰填谷,通过MQ承接流量。
    8. 并发处理,通过多线程将串行逻辑并行化。
    9. 预计算,比如抢红包场景,可以提前计算好红包金额缓存起来,发红包时直接使用即可。
    10. 缓存预热,通过异步任务提前预热数据到本地缓存或者分布式缓存中。
    11. 减少IO次数,比如数据库和缓存的批量读写、RPC的批量接口支持、或者通过冗余数据的方式干掉RPC调用。
    12. 减少IO时的数据包大小,包括采用轻量级的通信协议、合适的数据结构、去掉接口中的多余字段、减少缓存key的大小、压缩缓存value等。
    13. 程序逻辑优化,比如将大概率阻断执行流程的判断逻辑前置、For循环的计算逻辑优化,或者采用更高效的算法。
    14. 各种池化技术的使用和池大小的设置,包括HTTP请求池、线程池(考虑CPU密集型还是IO密集型设置核心参数)、数据库和Redis连接池等。
    15. JVM优化,包括新生代和老年代的大小、GC算法的选择等,尽可能减少GC频率和耗时。
    16. 锁选择,读多写少的场景用乐观锁,或者考虑通过分段锁的方式减少锁冲突。

    上述方案无外乎从计算和 IO 两个维度考虑所有可能的优化点,需要有配套的监控系统实时了解当前的性能表现,并支撑你进行性能瓶颈分析,然后再遵循二八原则,抓主要矛盾进行优化。

    高可用的实践方案

    1. 对等节点的故障转移,Nginx和服务治理框架均支持一个节点失败后访问另一个节点。
    2. 非对等节点的故障转移,通过心跳检测并实施主备切换(比如redis的哨兵模式或者集群模式、MySQL的主从切换等)。
    3. 接口层面的超时设置、重试策略和幂等设计。
    4. 降级处理:保证核心服务,牺牲非核心服务,必要时进行熔断;或者核心链路出问题时,有备选链路。
    5. 限流处理:对超过系统处理能力的请求直接拒绝或者返回错误码。
    6. MQ场景的消息可靠性保证,包括producer端的重试机制、broker侧的持久化、consumer端的ack机制等。
    7. 灰度发布,能支持按机器维度进行小流量部署,观察系统日志和业务指标,等运行平稳后再推全量。
    8. 监控报警:全方位的监控体系,包括最基础的CPU、内存、磁盘、网络的监控,以及Web服务器、JVM、数据库、各类中间件的监控和业务指标的监控。
    9. 灾备演练:类似当前的“混沌工程”,对系统进行一些破坏性手段,观察局部故障是否会引起可用性问题。

    而高可用的方案主要从冗余、取舍、系统运维3个方向考虑,同时需要有配套的值班机制和故障处理流程,当出现线上问题时,可及时跟进处理。

    高扩展的实践方案

    1. 合理的分层架构:比如上面谈到的互联网最常见的分层架构,另外还能进一步按照数据访问层、业务逻辑层对微服务做更细粒度的分层(但是需要评估性能,会存在网络多一跳的情况)。
    2. 存储层的拆分:按照业务维度做垂直拆分、按照数据特征维度进一步做水平拆分(分库分表)。
    3. 业务层的拆分:最常见的是按照业务维度拆(比如电商场景的商品服务、订单服务等),也可以按照核心接口和非核心接口拆,还可以按照请求源拆(比如To C和To B,APP和H5)。

    高并发确实是一个复杂且系统性的问题,由于篇幅有限,诸如分布式Trace、全链路压测、柔性事务都是要考虑的技术点。另外,如果业务场景不同,高并发的落地方案也会存在差异,但是总体的设计思路和可借鉴的方案基本类似。

    高并发设计同样要秉承架构设计的3个原则:简单、合适和演进。“过早的优化是万恶之源”,不能脱离业务的实际情况,更不要过度设计,合适的方案就是最完美的。

    本人才疏学浅,难免犯错,若发现文中有错误遗漏,望不吝赐教。

    展开全文
  • 一个完整的数据分析流程,应该包括以下几个方面建议收藏此图仔细阅读。 (注:图保存下来,查看更清晰) 作为数据分析师,无论最初的职业定位方向是技术还是业务,最终发到一定阶段后都会承担数据管理的角色...
  • Mysql优化方面的面试题

    千次阅读 2018-11-05 12:32:12
    1、MySQL的复制原理以及流程: 基本原理流程,3个线程以及之间的关联; 1. 主:binlog线程——记录下所有改变了数据库数据的语句,放进master上的binlog中; 2. 从:io线程——在使用start slave 之后,负责从...
  • 【IPD流程学习 二】IPD主要流程

    千次阅读 2020-02-13 17:52:26
    上一篇博客详细论述了产品开发过程中遇到的问题,看来不光是我自己感受到了,其实大家都有那种很累但是又没产出的感觉,是整体的流程机制出了问题,所以才要搞流程变革,而其中和我们开发人员最密切相关的就是IPD...
  • unity几种优化建议

    千次阅读 2016-10-14 16:28:20
    最简单的优化建议: 1.PC平台的话保持场景中显示的顶点数少于200K~3M,移动设备的话少于10W,一切取决于你的目标GPU与CPU。 2.如果你用U3D自带的SHADER,在表现不差的情况下选择Mobile或Unlit目录下的。它们更...
  • OA系统流程效率改进方案

    千次阅读 2019-07-11 17:14:46
    工作流程是OA系统中的核心,目的在于以电子化流程规范业务审批环境,打造企业内部信息...通达创新通过多种方式优化流程,提高流程流转和执行效率,真正将OA系统的效率落到实处。 一、OA系统流程效率优化特色 (一...
  • Web前端性能优化的10点建议

    千次阅读 2017-04-06 17:28:24
     一般说来Web前端指网站业务逻辑之前的部分,包括浏览器加载、网站视图模型、图片服务、CDN服务等,主要优化手段有优化浏览器访问、使用反向代理、CDN等。 1. 减少HTTP请求  在浏览器(客户端)和服务器发生通信时,...
  • Android性能优化总结

    万次阅读 多人点赞 2019-06-18 21:45:50
    安卓开发大军浩浩荡荡,经过近十年的发展,Android技术优化日异月新,如今Android 9.0 已经发布,Android系统性能也已经非常流畅,可以在体验上完全媲美iOS。 但是,到了各大厂商手里,改源码、自定义系统,使得...
  • 【Unity优化】关于优化方面的整理

    千次阅读 2016-07-08 18:22:56
    建议在 OC 之前先确定自己的场景是否适合利用 OC 来优化; Texture Packing ,或者叫 Texture Atlasing , 是将同种 shader 的纹理进行拼合,根据 Unity 的 static batching 的特性来减少 draw call 。 建议...
  • Android性能优化之页面优化

    千次阅读 2022-03-03 14:03:32
    通过原理,实战的角度,带读者了解如何进行安卓的界面性能优化
  • 这项任务称为序列标记,因为我们以某种形式的预定义类标记每个输入实体,例如杂货店购物的正常收据,标签可以是 TOTAL_KEY、SUBTOTAL_KEY、COMPANY_NAME、COMPANY_ADDRESS、DATE、 下图描述了这些工作的一般流程
  • 有哪些让程序员受益终生的建议

    万次阅读 多人点赞 2019-10-28 07:11:59
    相比面试流程,我当然更相信处了近十年的同学。 在计算机领域有两个方法提升名气: (1)、Github提交MergeRequest,自造轮子 在所有的技术面试环节,github所提交的开源项目,是一个非常能展示实力的存在...
  • uni app性能优化建议

    千次阅读 2020-03-21 09:22:42
    运行原理 逻辑层和视图层分离,且非H5端通信有折损 uni-app 在非H5端运行时,从架构上分为逻辑层和...逻辑层是运行在一个独立的jscore里的,它不依赖于本机的webview,所以一方面它没有浏览器兼容问题,可以在Andr...
  • WebView优化提升H5加载速度方案

    千次阅读 2020-01-07 11:21:03
    WebView优化提升H5加载速度方案 WebView加载H5经历的过程图示 上图体现的是用户打开一个H5页面,经历的过程与代码内部所做的事情的对应关系。 用户:无感知(WebView进行初始化)->看到白屏(DNS,Connection,...
  • Android性能优化(4):UI渲染机制以及优化

    千次阅读 多人点赞 2019-11-20 09:38:34
    渲染优化方式2.1 过度绘制优化2.1.1 Show GPU overdraw2.1.2 Profile GPU Rendering2.2 卡顿优化2.2.1 SysTrace2.2.2 TraceView 在从Android 6.0源码的角度剖析View的绘制原理一文中,我们了解到View的绘制流程有...
  • rtklib中rtk源码解析及优化建议

    千次阅读 2020-04-28 20:19:49
    选择rtknavi有以下三个方面的考虑: (1)可以实时看到模糊度固定情况; (2)能保证基准站和流动站的数据流观测时段一致性,基准站使用TCP方式采集数据,rtcm3格式;流动站使用端口采集数据,ubx格式。 (3)第(2...
  • Oracle:SQL优化建议

    千次阅读 2018-06-14 13:49:34
    Oracle:SQL优化建议 下述为34条Oracle中SQL的优化建议,仅供参考。 (1)选择最有效率的表名顺序(只在基于规则的优化器中有效): ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名,FROM子句中写在最后的...
  • 【安卓性能优化总结】 【八年工作经验精华积累】 目录 最全的性能优化点总结: 零、 启动优化 1、项目背景 2、 检测启动时间 3、打印启动时间 4、优化理念: 5、启动时透明页优化: 6、MultiDex优化 7、多进程时,...
  • iOS-性能优化的那些事

    千次阅读 多人点赞 2019-05-22 23:18:12
    而且APP性能的优化也不是一朝一夕的事情,在此离别之际,我将详细说明讲解一下我在三年里对APP性能优化方面做过的一些事,大家仁者见仁智者见智,也欢迎大家进群提供宝贵的意见和建议! 这里我...
  • H5性能测试(优化建议

    千次阅读 2018-01-12 10:36:21
    优化建议是对整个测试结果的一个反馈,也需要结合上述测试的结果,并对结果做一个中肯的评估,所以,这里也对三类数据分别作了优化建议: (1)http资源类优化建议:资源数量大、请求数过多、缓存等; ...
  • 文章提供了一种设计良好的蓝牙连接(重连)的流程逻辑,可以极大的提高Android平台上蓝牙设备的连接成功率。
  • 如何优化MySQL千万级大表,我写了6000字的解读

    万次阅读 多人点赞 2019-10-21 20:03:03
    千万级大表如何优化,这是一个很有技术含量的问题,通常我们的直觉思维都会跳转到拆分或者数据分区,在此我想做一些补充和梳理,想和大家做一些这方面的经验总结,也欢迎大家提出建议。 从一开始脑海里开始也是...
  • 在我之前的博文里,从面试官的角度聊聊培训班对程序员的帮助,同时给培训班出身的程序员一些建议,我已经说明了,我对培训班候选人没有偏见,而且我的面试官同事大多也是这样认为的。在这篇文章里,我将直接从筛选...
  • 业务流程监控的几点建议

    千次阅读 2017-11-08 13:17:39
    业务流程成熟的一个重要标志是流程可以被准确的并且合适的检测与控制。当企业完成一个BPM项目后,后续有很多工作。其中一项长期的工作就是流程的监控。企业需要制定监控的范围,监控指标,监控的实施等工作。下面...
  • Elasticsearch:从写入原理谈写入优化

    千次阅读 2021-04-06 00:17:33
    写入优化十三:推荐使用官方客户端 推荐使用官方 Elasticsearch API,因为官方在连接池和保持连接状态方面优化。 高版本 JAVA API 推荐:官方的High-level-Rest API。 其他写入优化 待补充...... 6、写入过程中...
  • 一文搞懂MySQL索引所有知识点(建议收藏)

    万次阅读 多人点赞 2020-10-24 12:19:05
    这一步和前面等值查询流程一样,发生了三次磁盘IO。 查找到15之后,底层的叶子节点是一个有序列表,我们从磁盘块6,键值9开始向后遍历筛选所有符合筛选条件的数据。 第四次磁盘IO:根据磁盘6后继指针到磁盘中寻址...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 119,663
精华内容 47,865
关键字:

关于流程优化方面的建议