js网站记住密码怎么做法国企业网站建设

当前位置： 首页 > news >正文

js网站记住密码怎么做,法国企业网站建设,网站下载到本地,北京科兴中维新冠疫苗最新消息dex2oat简单理解就是把delvik虚拟机的可执行文件dex转化成AndroidRuntime虚拟机的可执行文件oat。 Android T版本由PKMS下发命令、native层进程installd负责具体执行dex2oat操作。installd回去调用dex2oat64完成编译工作#xff0c;可以将dex2oat64理解成一个程序。源码路径可以将dex2oat64理解成一个程序。源码路径/apex/com.android.art/bin/dex2oat6 一、dex2oat的几种常见的编译模式 ab-ota    ab升级时进行OTA prepare编译 speed-profile    bg-dexopt    手机进入idle状态充电灭屏半小时以上编译 verify    boot    开机过程中编译 speed    core-app    开机过程或者充电时候的核心应用 quicken    first-boot    首次开机过程中编译刷机、OTA升级 inactive    verify    idle时对10天内未使用过的应用转入此状态 install    speed-profile    安装时编译 shared    speed    通过package usage得到被其他应用加载的dex unknown    run-from-apk    应用首次启动后编译一般需要一定时间 first-boot: 首次开机或恢复出厂设置后的第一次开机对应优化方式speed-profile boot大部分时候是OTA升级后开机可能在开机动画阶段也可能是进入桌面后后台执行对应优化方式verify core-app 手软新增场景针对TOP100应用做bg-dexopt优化时采用此方式对应的优化方式speed install应用安装场景对应优化方式speed-profile bg-dexopt: 系统记录热代码包括apk和插件中的dex后在息屏idle状态下执行优化对应优化方式speed-profile ab-ota若系统采用A/B分区在准备升级过程中提前对应用做dexopt优化对应优化方式speed-profile inactive空间不足时取消部分应用已经做的dexopt优化重新做低级别的优化对应优化方式verify shared若当前优化应用执行方式为speed-profile且此应用有被其他应用加载的情况则升级优化方式为speed verify只运行 DEX 代码验证。 quicken运行 DEX 代码验证并优化一些 DEX 指令以获得更好的解释器性能。 speed-profile运行 DEX 代码验证并对配置文件中列出的方法进行 AOT 编译。 speed运行 DEX 代码验证并对所有方法进行 AOT 编译。 speed和speed-profile区别 speed和speed-profile是Android 编译模式中的两种选项。speed是一种编译模式旨在最大化运行时性能而speed-profile则是一种部分编译模式根据profile记录的热点函数来编译也是为了最大化运行时性能。 speed-profile是基于profile的quicken即profile-guilde部分是speed其余是quicken。但是安装的时候没啥profile约等于quicken。profile是靠后续收集的debug版本1000次user版本10000次会记录到每个进程的prof文件里。 每个app的profile文件都位于/data/misc/profiles/cur/userId/包名/primary.profprofile文件用来记录运行比较频繁的代码用来进行 profile-guide 编译使得 dex2oat编译代码更精准。 1、run-from-apk dex文件包含于apk文件中apk是一个压缩包run-from-apk的意思就是运行APP的时候再从apk中把dex解压出来运行的时候边运行边把dex解释成AndroidRuntime可以执行的文件。这种模式显然是最慢的。一般不会有这种模式出现下面三种特殊情况会出现这种模式 ①应用做dex2oat有花花似为了保证系统稳定性中断了优化。 ②Android R上应用如果7天或者更长时间未使用升级过程中会被认为是不常用应用为了节省资源不优化这类应用。升级后这类应用将是run-from-apk状态。 ③处在debug模式的应用不会进行dex2oat优化会保持run-from-apk。 T上的项目将不会出现run-from-apk这种模式了。 2、extract 这种模式会将apk中的dex提前解压释放出来这类性能比run-from-apk好一些毕竟省去了解压apk的过程。S上进行ota升级后会对升级过程中未选中的应用进行extract7天或者更长时间未使用。执行此模式的时候不涉及到编译因此占用的系统资源相比其他编译模式会少很多。但是也正是由于本身没有任何除了解压之外的预处理因此运行的时候所有的类加载都要verify且只能解释执行速度也比较慢。 3、verity,quicken 这两种模式相比前面的两种更进一步verify模式不仅会将dex文件提前释放出来还会提前做pre verify生成vdex从而省去运行的时候verify的步骤quciken模式编译的时候会把dex文件编译成quciken codequciken code是没有使用AndroidRuntime虚拟机的时候系统dexopt的产物。但是这两种都不会编译成ota code。 quicken模式已在S上移除R上quicken等效于S上的verify。 4、speed 系统的核心应用或者ShareuserID的应用将会是speed模式。这类模式的时候系统会对限定大小的方法以及class进行oat编译生成对应的机器码。基本上是能编译的都编译了可以说饥不择食了因此十分耗时和耗费CPU资源。此类模式在应用启动时是相对来说很快的模式了。简单来理解就是编译了dex的大部分文件了。 5、everying 顾名思义就是把dex文件全部一丝不留编译成机械码比speed还狠。特点是运行最快编译文件占用存储空间最大。也因为占用系统资源很大编译文件很大这种编译模式不存在于正常的应用中只存在于debug模式的应用中。 6、speed-profile 这是现在最常见的一种编译模式它会根据用户的使用习惯不断的进行再编译当然再编译是要满足条件的。它会将用户经常打开的页面中的类和经常使用的方法记录到profile文件中用profile文件去指导编译同时对于常用的class和string类型还会保存到对应的art文件中用以启动加速。当应用进程起来的时候会同时启动jit线程而jit会对当前进程中的hot method进行run time编译同时也会记录保存需要编译的方法和类名这个就是profile文件。此类模式编译的结果是oat code。 此类模式由于有了profile的引入因此编译触发比较特殊。是根据profile记录的差异与大小来触发编译。比如当前使用的应用记录了1000个方法如果继续使用后记录变成了1100个方法这个时候仍然不会触发编译默认是20%增加。如果profile记录的方法数量小于100或者class数量小于50系统也会认为没有编译的必要。也正是因为引入了profile的编译同样的系统版本同样的应用版本不同人使用的习惯不同可能应用的odex文件编译大小也不同。理论上随着应用使用越久profile信息将越完善也越稳定应用性能将越来越好。 static constexpr uint32_t kMinNewMethodsPercentChangeForCompilation 20; static constexpr uint32_t kMinNewClassesPercentChangeForCompilation 20; static constexpr const uint32_t kMinNewMethodsForCompilation 100; static constexpr const uint32_t kMinNewClassesForCompilation 50 如果有root权限或者可以拿到应用的profile文件有两个地方会保存profile运行时写入的地方是/data/misc/profiles/cur/0/包名/primary.prof 编译时使用的是/data/misc/profiles/ref/包名/primary.prof。 采用speed-profile模式编译的应用在data/dalvik-cache/arm64中一定会产生art文件可以用这一点去判断编译模式当然最好用的是用dumpsys命令去查看使用dumpsys package 应用包名可以看到应用的所有信息包括UID、安装时间、权限信息、签名信息、dex2oat的状态。 7、vdex 为何要搞出个vdex文件目的是为了避免不必要的验证Dex 文件合法性的过程首次安装进行dex2oat时会校验Dex 文件各个section的合法性生成vdex文件下次启动应用的时候就可以不用去校验。odex文件来自于vdexodexvdex完整的apk dex信息。我对vdex的理解就是pre verify dex就是做过verify验证的dex文件。 Android S 之后谷歌更新了vdex格式致使vdex复用成为可能。在S 之前应用安装的时候会生成vdex启动编译或者充电编译时会再生成一次浪费系统资源。S上谷歌改进了这点当二次编译的时候如果是同一个apkvdex将能够复用。 应用dex2oat成为vdex模式的原因有且只有odex失效才会是vdex状态注odex是从vdex中提取内容组成。有以下几种场景 应用已经有odex此时进行了mainline更新重启后由于mainline更新了odex的依赖也需要更新此时odex会失效应用会变成vdex状态。 系统进行ota更新应用不再常用应用内(七天内使用过)此类应用不会再升级过程中二次优化升级完成后将是vdex状态。 需要注意。有一种vdex状态是异常的。比如桌面launchersystemui这类在固件内已经是prebuild编译的应用这类应用刷机后如果是vdex状态那么意味着固件编译的时候odex有问题。(odex值dex2oat的结果) 8、总结 从上面介绍的这几种常见的编译模式中可以看出谷歌设计这几种编译模式的目的是让我们基于性能的角度可以自主控制dex2oat的编译模式其策略是以空间换取时间 想要应用启动得越快就需要提前编译更多的方法和类当然编译产生的文件占用的存储空间也会越来越大。 二、dex2oat常见的触发场景 1、内置应用 内置应用有两种方式可以修改prebuilt出来的模式。 第一种配置自己的mk文件配置对应的模式mk文件中加入如下修改LOCAL_DEX_PREOPT_FLAGS –compiler-filterspeed 第二种方法在PRODUCT_DEXPREOPT_SPEED_APPS配置文件中添加对应的apk model名字修改完成后刷机后可以通过adb shell dumpsys package 包名 查看其中的dex status 与reason确认是否配置成功其中reason是prebuilt。 2、应用安装 安装触发场景根据APK来源不同分为三种 2.1、 非谷歌商店非应用商店安装 此类安装后通过dump查看 reason install status speed-profile 2.2、 谷歌商店安装 谷歌商店安装部分应用(谷歌商店内部有名单)安装后 reasoninstall-dm。此类应用是由于谷歌商店下发了profile文件在安装过程中使用了profile。因此installd-dm一般是安装完成后就有比较好的性能。相当于已经进行过了二次编译但也是因为这样install-dm的安装时间比较长。 reason install-dm status speed-profile 3、灭屏充电 灭屏充电这种触发场景是通过job scheduler完成的简单来说jobscheduler就是一种系统委托当手机灭屏充电的时候达到某一个job的触发条件job就会自动执行起来。常见的委托条件充电条件idle条件网络等。API介绍https://developer.android.com/reference/android/app/job/JobInfo.Builder 这里着重说下idle条件这里是原生系统定义的目前R之前的idle状态是灭屏71分钟R之后的版本为31分钟。也就是当灭屏时间满足半个小时的时候所有委托idle状态的job就该起来干活了。 如何避免灭屏充电编译 1、进行一晚上灭屏充电进行灭屏充电编译。 2、通过命令禁止上层重启后起作用。整机重启后失效。 adb shell setprop pm.dexopt.disable_bg_dexopt true adb shell am restart 3、停止job每次开机设置一下也是整机重启就失效。 adb shell cmd jobscheduler cancel android 800 adb shell cmd jobscheduler cancel android 801 当灭屏充电编译发起的时候必然有BackgroundDexOptService 的日志打印其中可以看到当前编译的状态(R上日志可能要少一些)。 充电编译开始 BackgroundDexOptServicePerforming idle optimizations 充电类型            BackgroundDexOptService: schargeType is x 其中 x 如果是1 则是vooc充电 3或者4是pdqc充电5是无线充电 充电电流设置 charging feature is on 是记录的上层设置的充电电流 充电编译中断 BackgroundDexOptService: abort by thermal type 4、升级 升级过程会根据升级之前应用的使用记录进行选择编译当前系统定义的是7天内未使用过的应用为不常用应用这类应用将不在升级过程中进行升级编译。而对于升级编译的应用为了平衡性能与升级时间R上默认将采用quicken模式 S上默认是verify模式。 reason boot status verify 5、升级开机完成后 升级过程中会筛选出近期用过的应用进行优化而针对那些未被选中的原生则是放到了开机完成后再进行优化这也是考虑到全部都在开机过程中做时间太长。 在R 上这一过程的应用是采取了speed-verify模式编译与安装场景的级别相当因此会占用较多的系统资源该过程会在开机完成一分钟后进行。 在S上这一过程的应用是采取了extract模式不涉及到编译。且谷歌已调整为开机十分钟后进行相比之前的speed-verify该模式不涉及到编译只是单纯的解压当前S 保留了该功能。 reason boot status extract R上默认关闭S上可以通过以下命令临时关闭。 adb shell cmd jobscheduler cancel android 801 在Android T上谷歌将其推迟到了idle状态执行且灭屏充电编译时该优化必须执行完成才能进行接下来的编译。谷歌计划在Android U上彻底删除该触发类型的编译。 三、如何在systrace中查看dex2oat编译类型 以高通骁龙原生相机为例先在trace中找到对应的进程。 Trace中一般会有OpenDexFilesFromOat,点击后面的location可以查看到应用的编译模式和触发原因。 四执行dex2oat时打印的log BackgroundDexOptService installd dex20at64 四、使用命令强制执行dex2oat 一、强制编译命令 如下adb shell cmd package compile 1、基于profile文件强制编译某个应用 adb shell cmd package compile -m speed-profile -f package_name 2、强制全面speed编译某个应用 adb shell cmd package compile -m speed -f package_name 3、基于profile强制编译所有带profile文件的应用 adb shell cmd package compile -m speed-profile -f -a 4、强制全面speed编译所有应用 adb shell cmd package compile -m speed -f -a 二、清除配置文件数据并移除经过编译的代码 请运行以下命令 1、针对某个应用 adb shell cmd package compile –reset package_name 2、针对所有应用 adb shell cmd package compile –reset -a