Android性能优化OOM内存管理ADJ

　　前言
　　OOMADJ（OutofMemoryAdjustment）是android系统在内存不足情况下进行内存调整的重要参数。在处理app启动速度的时候，可以设置主线程的优先级，保证主线程占用的cpu足够久。进程的oomadj，决定了当内存不够的时候，lmk会根据oomadj的大小依次释放内存。在前面介绍Activity页面启动路程过程中见到了更新adj的相关方法，但是没有深入介绍，这里分析一些相关实现。更新adjfinalbooleanrealStartActivityLocked（ActivityRecordr，ProcessRecordapp，booleanandResume，booleancheckConfig）throwsRemoteException｛r。startFreezingScreenLocked（app，0）；更新LurmService。updateLruProcessLocked（app，true，null）；更新ADJmService。updateOomAdjLocked（）；xxxx通过Binder远程调用Activity的onCreateonResume等生命周期app。thread。scheduleLaunchActivity（newIntent（r。intent），r。appToken，System。identityHashCode（r），r。info，newConfiguration（mService。mConfiguration），r。compat，r。task。voiceInteractor，app。repProcState，r。icicle，r。persistentState，results，newIntents，！andResume，mService。isNextTransitionForward（），profilerInfo）；returntrue；｝
　　在启动页面的流程中存在一个名为realStartActivityLocked的方法，这个方法会通过Binder远程调用Activity的onCreate，onResume等生命周期方法，在回调生命周期之前调用了updateLruProcessLocked以及updateOomAdjLocked这两个方法。这两个方法都与进程的优先级有关系。updateLruProcessLockedfinalvoidupdateLruProcessLocked（ProcessRecordapp，booleanactivityChange，ProcessRecordclient）｛hasActivity用来表示某个app中是否包含activity组件1。app本身确实包含activity组件；2。app本身有service，并且有另外一个含有activity的app链接到此app的service上；3。该app启动serivce的时候带有标记BINDTREATLIKEACTIVITY。finalbooleanhasActivityapp。activities。size（）0app。hasClientActivitiesapp。treatLikeActivity；目前，并没有考虑进程中是否含有Service因此，虽然理论上定义了Service相关的进程分类，但并没有实现对应的管理策略在以下代码中，hasService一直为falsefinalbooleanhasServicefalse；notimplyet。app。services。size（）0；if（！activityChangehasActivity）｛Theprocesshasactivities，soweareonlyallowingactivitybasedadjustmentstomoveit。Itshouldbekeptinthefrontofthelistwithotherprocessesthathaveactivities，andwedontwantthosetochangetheirorderexceptduetoactivityoperations。return；｝计数器，记录该函数被调用了多少次，也就是LRU被更新了多少次。mLruSeq；finallongnowSystemClock。uptimeMillis（）；app。lastActivityTimenow；Firstaquickreject：iftheappisalreadyatthepositionwewillputit，thenthereisnothingtodo。if（hasActivity）｛finalintNmLruProcesses。size（）；如果要插入的app已经在mLruProcesses顶端了，就不用插入了if（N0mLruProcesses。get（N1）app）｛if（DEBUGLRU）Slog。d（TAG，Notmoving，alreadytopactivity：app）；return；｝｝else｛将其插入到Service的开头if（mLruProcessServiceStart0mLruProcesses。get（mLruProcessServiceStart1）app）｛if（DEBUGLRU）Slog。d（TAG，Notmoving，alreadytopother：app）；return；｝｝intlruimLruProcesses。lastIndexOf（app）；persistentapp，这部分app不会被杀死，永远在运行，if（app。persistentlrui0）｛如果persistentapp已经在列表里面了那么不作处理。Wedontcareaboutthepositionofpersistentprocesses，aslongastheyareinthelist。if（DEBUGLRU）Slog。d（TAG，Notmoving，persistent：app）；return；｝lrui0，说明LRU中之前记录过当前进程的信息即该进程不是新创建的那么在调整之前，需要先将之前的记录删除if（lrui0）｛if（lruimLruProcessActivityStart）｛此进程没有包含ActivitymLruProcessActivityStart；｝if（lruimLruProcessServiceStart）｛此进程没有服务，是个其他类型的进程mLruProcessServiceStart；｝移除进程，后面会再次添加mLruProcesses。remove（lrui）；｝nextIndex主要用于记录当前进程绑定的Service或ContentProvider对应的进程，应该插入的位置（对应进程中仅含有Service和Provider时才需要处理）后文将看到该值的使用情况intnextIndex；if（hasActivity）｛finalintNmLruProcesses。size（）；if（app。activities。size（）0mLruProcessActivityStart（N1））｛该App没有Activity，但是有一个有Activity的app启动了该App的一个Service。mLruProcessActivityStart（N1）表示App不是当前在显示的页面。mLruProcesses。add（N1，app）；举一个具体的例子，当前显示的AppA打开属于另一个AppB的Service，此时当前显示的AppA就在N这个位置，被打开的Service所在的AppB在N1这个位置。TokeepitfromspammingtheLRUlist（bymakingabunchofclients），wewillpushdownanyotherentriesownedbytheapp。下面的代码，是为了调整不同用户之间的公平性；当前用户新启动了一个进程，将该用户对应的其它进程，适当往前挪动一下（优先被kill）finalintuidapp。info。uid；为了防止某个app中的service绑定了一群client从而导致LRU中顶部大部分都是这些client，这里需要将这些client往下移动，以防止某些app通过和某个app的service绑定从而提升自己在LRU中位置。for（intiN2；imLruProcessActivityStart；i）｛ProcessRecordsubProcmLruProcesses。get（i）；遍历找到第一个与app的uidif（subProc。info。uiduid）｛if（mLruProcesses。get（i1）。info。uid！uid）｛交换i与i1位置的进程，ProcessRecordtmpmLruProcesses。get（i）；mLruProcesses。set（i，mLruProcesses。get（i1））；mLruProcesses。set（i1，tmp）；i；｝还是以上面那个例子为例。A在打开B之后有打开另一个AppC的Service。此时A，B，C的位置是N，N1，N2，由于BC的uid一样，此时B也就是先打开的服务可能会一直向后移动直到mLruProcessActivityStart这个位置，｝else｛Agap，wecanstophere。break；｝｝｝else｛Processhasactivities，putitattheverytipsytop。if（DEBUGLRU）Slog。d（TAG，AddingtotopofLRUactivitylist：app）；进程具有activity，在N位置添加，也就是在栈顶添加，此时app一般就是要显示的app。mLruProcesses。add（app）；｝nextIndexmLruProcessServiceStart；｝elseif（hasService）｛Processhasservices，putitatthetopoftheservicelist。不走这个分支，hasService总是false，if（DEBUGLRU）Slog。d（TAG，AddingtotopofLRUservicelist：app）；mLruProcesses。add（mLruProcessActivityStart，app）；nextIndexmLruProcessServiceStart；mLruProcessActivityStart；｝else｛Processnototherwiseofinterest，itgoestothetopofthenonservicearea。一般走这里，intindexmLruProcessServiceStart；一般情况下clientnull，这个分支不走if（client！null）｛client表示一个另一个进程，此进程可能具有页面，也可没有，但是这个进程打开了一个只有服务得进程，那么只有服务的进程需要排在client进程的下面Ifthereisaclient，dontallowtheprocesstobemoveduphigherinthelistthanthatclient。intclientIndexmLruProcesses。lastIndexOf（client）；if（DEBUGLRUclientIndex0）Slog。d（TAG，Unknownclientclientwhenupdatingapp）；if（clientIndexlrui）｛Dontallowtheclientindexrestrictiontopushitdownfartherinthelistthanitalreadyis。clientIndexlrui；｝if（clientIndex0indexclientIndex）｛此时表示client也是一个只有服务的进程而且client在app进程的下面，此时需要调整添加app进程的位置，调整之后app的位置是clientIndex，client的位置是clientIndex1indexclientIndex；｝｝if（DEBUGLRU）Slog。d（TAG，AddingatindexofLRUlist：app）；添加进程mLruProcesses。add（index，app）；nextIndexindex1；mLruProcessActivityStart；mLruProcessServiceStart；｝Iftheappiscurrentlyusingacontentproviderorservice，bumpthoseprocessesaswell。本进程打开了service或者是ContentProvider，如果这个Service或者ContentProvider是定义自己App里面那么此处没啥影响。如果是定义在另一个App里面则有影响。这里的微调分为两种情况：第一是service所在的进程的位置调整到本进程之后，第二是将ContentProvider所在的进程位置调整到本进程之后。调整的方式都是使用updateLruProcessInternalLocked方法，for（intjapp。connections。size（）1；j0；j）｛ConnectionRecordcrapp。connections。valueAt（j）；if（cr。binding！null！cr。serviceDeadcr。binding。service！nullcr。binding。service。app！nullcr。binding。service。app。lruSeq！mLruSeq！cr。binding。service。app。persistent）｛nextIndexupdateLruProcessInternalLocked（cr。binding。service。app，now，nextIndex，serviceconnection，cr，app）；｝｝for（intjapp。conProviders。size（）1；j0；j）｛ContentProviderRecordcprapp。conProviders。get（j）。provider；if（cpr。proc！nullcpr。proc。lruSeq！mLruSeq！cpr。proc。persistent）｛nextIndexupdateLruProcessInternalLocked（cpr。proc，now，nextIndex，providerreference，cpr，app）；｝｝｝privatefinalintupdateLruProcessInternalLocked（ProcessRecordapp，longnow，intindex，Stringwhat，Objectobj，ProcessRecordsrcApp）｛srcApp打开app的一个Service或者ContentProviderapp。lastActivityTimenow；如果有Activity，不做调整if（app。activities。size（）0）｛Dontwanttotouchdependentprocessesthatarehostingactivities。returnindex；｝如果进程不在mLruProcess中，就返回intlruimLruProcesses。lastIndexOf（app）；if（lrui0）｛Slog。wtf（TAG，AddingdependentprocessappnotonLRUlist：whatobjfromsrcApp）；returnindex；｝如果进程的位置高于需要调整的位置，不做调整if（lruiindex）｛Dontwanttocausethistomovedependentprocessesbackinthelistasiftheywerelessfrequentlyused。returnindex；｝如果目前进程的位置比mLruProcessActivityStart还要高，不调整if（lruimLruProcessActivityStart）｛Dontwanttotouchdependentprocessesthatarehostingactivities。returnindex；｝走到这里表示lruiindexlruimLruProcessActivityStart。把App调整到index1的位置mLruProcesses。remove（lrui）；if（index0）｛index；｝if（DEBUGLRU）Slog。d（TAG，MovingdepfromlruitoindexinLRUlist：app）；mLruProcesses。add（index，app）；returnindex；｝例如当前显示的AppA打开了一个AppB的一个Service，由于AppA是当前显示的App，优先级最高，此时A使用的Service所在的AppB也应该尽可能的提高等级避免内存回收，此时会将AppB放到mLruProcessServiceStart这个位置。假如非得回收内存的话会先回收0mLruProcessServiceStart之间的进程占据的内存。
　　mLruProcesses是一个列表，其本分为三个部分0mLruProcessServiceStart用于保存其他进程；
　　mLruProcessServiceStartmLruProcessActivityStart用于保存服务进程，但是实际情况下这个区域的大小是0，也即是服务进程实际也是放在了其他进程区域。
　　mLruProcessActivityStartend保存的有Activity的进程。每次添加Activity进程都是在end位置，在mLruProcessServiceStart位置添加服务进程或者其他进程。
　　位置越大的进程优先级越高越不容易被回收。
　　每次调用updateLruProcessLocked调整某个进程的位置的时候也会调整与之相关的进程的位置，例如调整进程A的位置就要顺便调整A启动的Service以及ContentProvider所在的进程位置。
　　版权声明：本文为CSDN博主昨夜西风在吹的原创文章，遵循CC4。0BYSA版权协议，转载请附上原文出处链接及本声明。原文链接：https：blog。csdn。netqq31469589articledetails11796935
　　以上就是有关Android内存管理ADJ讲解；有关更多Android开发技术性能调优学习；大家私信：手册《Android性能优化手册》获取相关学习资料。结尾（心灵的鸡汤）
　　我相信，梦想只要能坚持，就一定能成为现实。就像代表着永恒的天蓝色。就让这小小的梦想的种子，在我们心中，渐渐发芽、成长，在心中开出美丽、绚烂的花。让我们努力飞翔，乘着梦想的翅膀，飞到成功的远方。