androidapp（androidapp启动流程）

本篇文章给大家谈谈androidapp，以及androidapp启动流程对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、Android App安装以及启动流程
• 2、android app界面设计规范(dpi,dp,px等)
• 3、Android App内存优化
• 4、将Android APP安装到模拟器中

Android App安装以及启动流程

Android App的安装可以分为有界面的安装和无界面的安装。

有界面的安装其实就是调用系统App（PackageInstaller）咐码去安装apk，打开安装apk应用之后，点击安装按钮执行startInstall方法，然后就进入安装中界面开始安装，安装成功或者衡族哪失败都会有对应的回调。内部其实也是使用PackageManager的installExistingPackage方法，通过binder机制，调用到PackageManagerService的installExistingPackage方法，最终调用到installExistingPackageAsUser方法安装，而 安装的核心原理其实就是将apk文件拷贝到系统可识别的重要的文件目录 ：

无界面安装是调用adb命令，执行到一个c写的commandline脚本，调用 install_app 方法，然后再调用 pm_command ，然后执行到pm脚本，执行 run 方法，调用 runinstall ，然后调用 installPackageAsUser 通过AMS执行安装。

说到App的启动，就需要从穗则开机开始说起，Android开机会先把所有应用安装一遍就是把apk拷贝到对应的目录（这也是Android开机慢的原因）。

整个流程如下：

其实App的启动，除了刚开机是不一样之外，正常时候基本与Activity的启动非常接近。

[img]

android app界面设计规范(dpi,dp,px等)

PPI(Pixels per inch)：每英寸所拥有的像素数，即像素密度。

DPI(dots per inch)：即每英寸上，所能印刷的网点数，一般称为像素腔哗密度。ppi计算公式：ppi = 屏幕对角线像素数/屏幕对角线英寸数，通过勾股定理计算屏幕对角线像素数。

Screen Size(屏幕尺寸)：手机屏幕尺寸大小，如3英寸、4英寸、4.3英寸、5.7英寸，指的是对角线的长度。

DIP（device independent pixel）：即dip/dp，设备独立像素。 1px = 1dp density(由dpi决定)

Resolution(分辨率)：指手机屏幕垂直和水平方向上的像素个数。eg分辨率480 800，指该设备垂直方向有800个像素点，水平方向有480个像素点。

px(Pixel像素)：相同像素的ui，在不同分辨率的设备上效果不同。在小分辨率设备上会放大导致失真，大分辨率上被缩小。

Android Design里把主流设备的 dpi 归成了四个档次： 120 dpi、160 dpi、240 dpi、320 dpi ，具体见如下表格。

实际开发当中，我们经常需要对这几个尺寸进行相互转换（比如先在某个分辨率下完成设计，然后缩放到其他尺寸微调后输出），一般按照 dpi 之间的比例即 2:1.5:1:0.75 来给界面中伍圆行的元素来进行尺寸定义。

也就是说如果以 160 dpi 作为基准的话，只要尺寸的 DP 是 4 的公倍数，XHDPI 下乘以 2，HDPI 下乘以 1.5，LDPI 下乘以 0.75 即可满足所有尺寸下都是整数 pixel 。但假设以 240 dpi 作为标准，那需要 DP 是 3 的公倍数，XHDPI 下乘以 1.333，MDPI 下乘以 0.666 ，LDPI 下除以 2。而以 LDPI 和 XHDPI 为基准就更复杂了。同时第一款Android设备（HTC的T-Mobile G1）是属于160dpi的。鉴于以上各种原因， 标准dpi=160

谷歌官方对dp的解释如下：

A virtual pixel unit that you should use when defining UI layout, to express layout dimensions or position in a density-independent way.

The density-independent pixel is equivalent to one physical pixel on a 160 dpi screen, which is the baseline density assumed by the system for a "medium" density screen. At runtime, the system transparently handles any scaling of the dp units, as necessary, based on the actual density of the screen in use. The conversion of dp units to screen pixels is simple: px = dp * (dpi / 160). For example, on a 240 dpi screen, 1 dp equals 1.5 physical pixels. You should always use dp units when defining your application's UI, to ensure proper display of your UI on screens with different densities.

简单来说，以160dpi的设备为准，该设备上1dp = 1px；如果屏幕密度大，1dip代表的px就多，比如在320dpi的屏幕上，腔埋1dip=2px(即1dp代表2个像素)。在app开发时，最好用dp来做界面的布局，以保证适配不同屏幕密度的手机。

dp和px的换算公式：

我的理解，该公式表示px的数值等于dp的数值*（设备dpi/160）

注意，px、dp是单位，但density没单位。

applyDimension的源码如下，可参考：

android的尺寸众多，建议使用分辨率为 720x1280 的尺寸设计。这个尺寸 720x1280中显示完美，在 1080x1920 中看起来也比较清晰；切图后的图片文件大小也适中，应用的内存消耗也不会过高。

app启动图标为48*48dp，对应各dpi设备，图像资源像素如下：

| mdpi | hdpi | xhdpi | xxhdpi |

| ---:| ---: | ---:| ---:| ---:|

|48 48px|72 72px|94 96px|144px 144px|

操作栏图标为32*32dp，对应各dpi设备，图像资源像素如下：其中图形区域尺寸是24*24dp，可参考平时ui切图会有部分留白。

| mdpi | hdpi | xhdpi | xxhdpi |

| ---:| ---: | ---:| ---:| ---:|

|32 32px|48 48px|64 64px|96px 96px|

通知栏图标为24*24dp，对应各dpi设备，图标像素如下：

| mdpi | hdpi | xhdpi | xxhdpi |

| ---:| ---: | ---:| ---:| ---:|

|24 24px|36 36px|48 48px|72px 72px|

某些场景需要用到小图标，大小应当是16*16dp，其中图形区域尺寸12*12dp。

| mdpi | hdpi | xhdpi | xxhdpi |

| ---:| ---: | ---:| ---:| ---:|

|16 16px|24 24px|32 32px|48px 48px|

Android App内存优化

内存优化就是对内存问题的一个预防和解决，做内存优化能让应用挂得少、活得好和活得久。

挂的少：

“挂”指的是 Crash，内存问题导致 Crash 的具体表现就是内存溢出异常 OOM。

活得好：

活得好指的是使用流畅，Android 中造成界面卡顿的原因有很多种，其中一种就是由内存问题引起的。内存问题之所以会影响到界面流畅度，是因为垃圾回收（GC，Garbage Collection），在 GC 时，所有线程都要停止，包括主线程，当 GC 和绘制界面的操作同时触发时，绘制的执行就春御会被搁置，导致掉帧，也就是界面卡顿。

活得久：

活得久指的是我们的应用在后台运行时不会被干掉。Android 会按照特定的机制清理进程，清理进程时优先会考虑清理后台进程。清理进程的机制就是LowMemoryKiller。在 Android 中不同的进程有着不同的优先级，当两个进程的优先级相同时，低杀会优先考虑干掉消耗内存更多的进程。也就是如果我们应用占用的内存比其他应用少，并且处于后台时，我们的应用能在后台活下来，这也是内存优化为我们应用带来竞争力的一个直接体现。

内存占用是否越少越好？

当系统 内存充足 的时候，我们可以多用 一些获得更好的性能。当系统 内存不足 的时候，我们希望可以做到 ”用时分配，及时释放“。内存优化并不能一刀切。

我们都知道，应用程序的内存分配和垃圾回收都是由Android虚拟机完成的，在Android 5.0以下，使用的是Dalvik虚拟机，5.0及以上，则使用的是ART虚拟机。

Android虚拟机Dalvik和ART

1、内存区域划分

详细请看以下两篇文章（建议全看）：

java内存四大区_JVM内存区域划分

Android 内存机制

2、内存回收

垃圾收集的标记算法（找到垃圾）：

垃圾收集算法（回收垃圾）：

引用类型：强引用、软引用、弱引用、虚引用

对象的有效性=可达性+引用类型

JAVA垃圾回收机制-史上最容易理解看这一篇就够了

Android：玩转垃圾回收机制与分代回收策略

android中还存在低杀机制，这种情况属于系统整机内存不足，直接把应用进程杀掉的情况。

Android后台杀死系列：LowMemoryKiller原理

1、内存溢出

系统会给每个App分配内存空间也就是heap size值，当app占用的内存加上申请的内存超过这个系统分配的内存限额，最终导致OOM(OutOfMemory)使程序崩溃。

通过命令 getprop |grep dalvik.vm.heapsize 可以获取系统允许的最大

注意：在设置了heapgrowthlimit的状况下，单个进程可用最大内存为heapgrowthlimit值。在android开发中，若是要使用大堆，须要在manifest中指定android:largeHeap为true，这样dvm heap最大可达heapsize。

关于heapsize heapgrowthlimit

2、内存泄漏

Android系统虚拟机的垃圾回收是通过虚拟机GC机制来实现的。GC会选择一些还存活的对象作为内存遍历的根节点GC Roots，通过对GC Roots的可达性来判断是否需要回收。内存泄漏就是 在当前应用周期内不再使用的对象被GC Roots引用，造成该对象无法被系统回收，以致该对象在堆中所占用的内存单元无法被释放而造成内存扒圆岩空间浪费，使实际可使用内存变小。简言之，就是 对象被持有导致无法释放或不能按照对象正常的生命周期进行释放。

Android常见内存泄漏汇总

3、内存抖动

指的是在短时间内大量的新对象被实例化，运行时可能无法承载这样的内存分配，在这种情况下就会导致垃圾回收事件被大量调用，影响到应用程序的UI和整体性能，最终可能导致卡顿和OOM。

常见情况：在一些被频繁调用的方法内不断地创建对象。例如在View 的onDraw方法内new 一些新腔慎的对象。

注意内存抖动也会导致 OOM，主要原因有如下两点：

1、Android Studio Profiler

作用

优点

内存抖动问题处理实战

理解内存抖动的概念的话，我们就能明白只要能找到抖动过程中所产生的对象及其调用栈，我们就能解决问题，刚好Android Studio 的Porfiler里面的Memory工具就能帮我们记录下我们操作过程中或静止界面所产生的新对象，并且能清晰看到这些对象的调用栈。

选择Profile 中 的Memory ，选择 Record Java/Kotlin allocations，再点击Record开始记录， Record Java/Kotlin allocations 选项会记录下新增的对象。

操作完成之后，点击如图所示的红脑按钮，停止记录。

停止记录后，我们就可以排序（点击 Allocations可以排序）看看哪些对象或基本类型在短时间被频繁创建多个，点击这些新增的对象就可以看到它的完成的调用链了，进而就找找到导致内存抖动的地方在哪里了。

2、利用DDMS 和 MAT(Memory Analyzer tool)来分析内存泄漏

我们利用工具进行内存泄漏分析主要是用对比法：

a.先打开正常界面，不做任何操作，先抓取一开始的堆文件。

b.一顿胡乱操作，回到原来操作前的界面。主动触发一两次GC,过10秒再抓取第二次堆文件。

c.通过工具对比，获取胡乱操作后新增的对象，然后分析这些新增的对象。

DDMS作用:抓取堆文件，主动触发GC。（其实也是可以用Android Studio 的Profile里面的Memory工具来抓取堆文件的，但是我这边在利用Profile 主动触发gc 的时候会导致程序奔溃，也不知道是不是手机的问题，所以没用Android Studio的Profiler）

MAT作用：对堆文件进行对比，找到多出的对象，找到对象的强引用调用链。

以下是详细的过程：

步骤1.打开DDMS,选择需要调试的应用，打开初始界面，点击下图的图标（Dump Hprof File）先获取一次堆文件。

步骤2.对应用随便操作后，回到一开始的界面，先多触发几次GC ，点击下图的图标(Cause Gc)来主动触发GC,然后再次点击 Dump Hprof File 图标来获取堆文件。

步骤3.通过Android Studio Profile 或者 DDMS dump 的堆文件无法在MAT 打开，需要借助android sdk包下的一个工具hprof-conv.exe来转换。

格式为 hprof-conv 旧文件路径名 要转换的名称；

例如：hprof-conv 2022-04-13_17-54-40_827.hprof change.hprof

步骤4.把两份堆文件导入MAT,然后选择其中第二次获取的堆文件，点击 如图所示的 Histogram查看。

步骤5.点击下图图标，Compare To Another Heap Dump ,选择另一份堆文件。

6.会得出下图所示的 Hitogram 展示，我们主要看Objects 这一列。 如下图所示 “+ 2” 则代表前面两份堆文件对比，这个对象多了两个，我们主要就是要分析这些多了出来，没有被回收的对象。

7.加入我们从增加的对象中，看到了MainActivity ，则需要从一开始打开的Hitogram 展示里面找到这个对象的调用栈。如下图所示，搜索MainActivity

8.看到下图所示解雇，然后鼠标右键点击下图红色圈圈着的MainActivity ,选择 Merger Shortest Paths to Gc Roots ，再选择 exclude all phantom/weak/soft etc.references ,就可以看到这个MainActivity 对象的强引用链，至此我们就可以找到MainActivity对象是被什么引用导致无法回收了。

3、内存泄露检测神器之LeakCanary（线下集成）

自行学习了解，接入简单，使用简单，基本可以解决大部分内存泄漏问题。

github地址 ：

学习地址 ：

针对内存抖动的建议：

针对内存泄漏问题的建议：

针对内存溢出问题的建议（主要就是要减少内存占用）：

建议参考：

深入探索 Android 内存优化（炼狱级别）

对于 优化的大方向，我们应该优先去做见效快的地方，主要有以下三部分：内存泄漏、内存抖动、Bitmap。完善监控机制也是我们的重点，能帮助我们对内存问题快速分析和处理。

参考：

深入探索 Android 内存优化（炼狱级别）

将Android APP安装到模拟器中

一.通过adb命令的方式:

1.先启动模拟器

2.把apk文件拷贝到adb所在目录中 我的是:D:\android-sdk\platform-tools,

3.然后再DOS中毕敏高执行命令:adb install xxx.apk,等段时间后即可看到安装成功.

二.在DDMS下通过拖拽手尺的方式安拿段装应用:

1.启动模拟器

2.

![V 6T%DTFIB[) SDF8EU] I8.png

关于androidapp和androidapp启动流程的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。