android栈大小

❶ 堆栈大小是多少，可否设置

/STACK选项设置堆栈的大小（以字节为单位）。此选项仅在生成.exe文件时使用。reserve值指定虚拟内存中的总的堆栈分配。对于x86和x64计算机，默认堆栈大小为1MB。在Itanium芯片组上，默认大小为4MB。commit取决于操作系统所作的解释。在WindowsNT和Windows2000中，它指定一次分配的物理内存量。提交的虚拟内存导致空间被保留在页面文件中。更高的commit值在应用程序需要堆栈空间时可节省时间，但会增加内存需求并有可能延长启动时间。对于x86和x64计算机，默认提交值为4KB。在Itanium芯片组上，默认值为16KB。以十进制或C语言表示法指定reserve值和commit值。

❷ 可以申请100M以上的栈内存

不可以。栈内存是指程首洞灶序输出的值大概就是栈能申请的最大内存，默认颤册的栈空间大小是有限制者扮只有1M所以是不可以申请100M以上的。

❸ C中栈的内存有多大！

栈的内存空间大小是可以自己定义的，没规定多大，但是一个栈段的容量最大为64KB
因为一个栈段最大容量为65536字节，除以1024就是64KB

❹ 一个函数产生堆栈的大小和什么有关

和操作系统有关系
不同的操作系统对于栈的默认大小是有规定谈数厅的。对于linux系统，默认的栈空间是10M。对于Windows系统，默认的空间是1M。但是栈的空间是可以调整的含隐，在编译器的编译属毕或性更改

❺ 怎么查看android app堆栈大小

方法-：下载任务管理程序 像TaskManager 一类的装上 就可以看到
方法二：adb shell top ； Android 基于linux 所以简单的linux 命令还是支持的
方法三：setting -》 dev tools -》 running process

❻ Android 任务栈

任务是指在执行特定作业时与用扰芹户交互的一系列 Activity。 这些 Activity 按照各自的打首仔开顺序排列在堆栈（即返回栈）中。设备主屏幕是大多数任务的起点。当用户触摸应用启动器中的图标（或主屏幕上的快捷方式）时，该应用的任务将出现在前台。 如果应用不存在任务（应用最近未曾使用），则会创建一个新任务，并且该应用的“主”Activity 将作为堆栈中的根 Activity 打开。
当前 Activity 启动另一个 Activity 时，该新 Activity 会被推送到堆栈顶部，成为焦点所在。 前一个 Activity 仍保留在堆栈中，但是处于停止状态。Activity 停止时，系统会保持其用户界面的当前状态。 用户按“返回”按钮时，当前 Activity 会从堆栈顶部弹出（Activity 被销毁），而前一个 Activity 恢复执行（恢复其 UI 的前一状态）。 堆栈中的 Activity 永远不会重新排列，仅推入和弹出堆栈：由当前 Activity 启动时推入堆栈；用户使用“返回”按钮退出时弹出堆栈。 因此，返回栈以“后进先出”对象结构运行。

上述文字摘自 Android开发者官网

默认行为的场景 ：当前的task包含4个activity–当前activity下面有3个activity。当用户按下HOME键返回到程序启动器（application launcher）后，选择了一个新的应用程序（事实上是一个新的task），当前的task就被转移到后台，新的task中的根activity将被显示在屏幕上。过了一段时间，用者李汪户按返回键回到了程序启动器界面，选择了之前运行的程序（之前的task）。那个task，仍然包含着4个activity。当用户再次按下返回键时，屏幕不会显示之前留下的那个activity（之前的task的根activity），而显示当前activity从task栈中移出后栈顶的那个activity。

❼ 一个进程的堆和栈有多大

栈是线程的，不是进程的

是一个进程一个堆，一个线程一个栈吗

堆≈虚拟内存大小-1GB

栈通常为4MB

下面是一些说明文件：

Visual C++ 编译器选项
/F（设置堆栈大小）
请参见 发送反馈意见

设置程序堆栈大小（以字节为单位）。

/F[ ]number

参数
number
堆栈大小（以字节为单位）。

备注
如果不使用此选项，堆栈大小默认为 1 MB。number 参数可以用十进制或 C 语言表示法表示。参数的范围可以在 1 到链接器接受的最大堆栈大小之间。链接器将指定值向上舍入为最接近的 4 个字节。/F 和 number 之间的空格可选的。

❽ Android 多返回栈技术详解

用户通过系统返回按钮导航回去的一组页面，在开发中被称为返回栈 (back stack)。多返回栈即一堆 "返回栈"，对多返回栈的支持是在 Navigation 2.4.0-alpha01 和 Fragment 1.4.0-alpha01 中开始的。本文将为您展开多返回栈的技术详解。

无论您在使用 Android 全新的 手势导航 还是传统的导航栏，用户的 "返回" 操作是 Android 用户体验中关键的一环，把握好返回功能的设计可以使应用更加贴近整个生态系统。

在最简单的应用场景中，系统返回按钮仅仅 finish 您的 Activity。在过去您可能需要覆写 Activity 的 onBackPressed() 方法来自定义返回操作，而在 2021 年您无需再这样操作。我们已经在 OnBackPressedDispatcher 中提供了 针对自定义返回导航的 API。实际上这与 FragmentManager 和 NavController 中 已经 添加的 API 相同。

这意味着当您使用 Fragments 或 Navigation 时，它们会通过 OnBackPressedDispatcher 来确保您调用了它们返回栈的 API，系统的返回按钮会将您推入返回栈的页面逐层返回。

多返回栈不会改变这个基本逻辑。系统的返回按钮仍然是一个单向指令 —— "返回"。这对多返回栈 API 的实现机制有深远影响。

在 surface 层级，对于 多返回栈的支持 貌似很直接，但其实需要额外解释一下 "Fragment 返回栈" 到底是什么。FragmentManager 的返回栈其实包含的不是 Fragment，而是由 Fragment 事务组成的。更准确地说，是由那些调用了 addToBackStack(String name) API 的事务组成的。

这就意味着当您调用 commit() 提交了一个调用过 addToBackStack() 方法的 Fragment 事务时， FragmentManager 会执行所有您在事务中所指定的操作 (比如 替换操作 )，从而将每个 Fragment 转换为预期的状态。然后 FragmentManager 会将该事务作为它返回栈的一部分。

当您调用 popBackStack() 方法时 (无论是直接调用，还是通过系统返回键以 FragmentManager 内部机制调用)，Fragment 返回栈的最上层事务会从栈中弹出 -- 比如新添加的 Fragment 会被移除，隐藏的 Fragment 会显示。这会使得 FragmentManager 恢复到最初提交 Fragment 事务之前的状态。

也就是说 popBackStack() 变成了销毁操作: 任何已添加的 Fragment 在事务被弹出的时候都会丢失它的状态。换言之，您会失去视图的状态，任何所保存的实例状态 (Saved Instance State)，并且任何绑定到该 Fragment 的 ViewModel 实例都会被清除。这也是该 API 和新的 saveBackStack() 方法之间的主要区别。 saveBackStack() 可以实现弹出事务所实现的返回效果，此外它还可以确保视图状态、已保存的实例状态，以及 ViewModel 实例能够在销毁时被保存。这使得 restoreBackStack() API 后续可以通过已保存的状态重建这些事务和它们的 Fragment，并且高效 "重现" 已保存的全部细节。太神奇了！

而实现这个目的必须要解决大量技术上的问题。

虽然 Fragment 总是会保存 Fragment 的视图状态，但是 Fragment 的 onSaveInstanceState() 方法只有在 Activity 的 onSaveInstanceState() 被调用时才会被调用。为了能够保证调用 saveBackStack() 时 SavedInstanceState 会被保存，我们 还 需要在 Fragment 生命周期切换 的正确时机注入对 onSaveInstanceState() 的调用。我们不能调用得太早 (您的 Fragment 不应该在 STARTED 状态下保存状态)，也不能调用得太晚 (您需要在 Fragment 被销毁之前保存状态)。

这样的前提条件就开启了需要 解决 FragmentManager 转换到对应状态的问题，以此来保障有一个地方能够将 Fragment 转换为所需状态，并且处理可重入行为和 Fragment 内部的状态转换。

在 Fragment 的重构工作进行了 6 个月，进行了 35 次修改时，发现 Postponed Fragment 功能已经严重损坏，这一问题使得被推迟的事务处于一个中间状态 —— 既没有被提交也并不是未被提交。之后的 65 个修改和 5 个月的时间里，我们几乎重写了 FragmentManager 管理状态、延迟状态切换和动画的内部代码，具体请参见我们之前的文章《全新的 Fragment: 使用新的状态管理器》。

随着技术问题的逐步解决，包括更加可靠和更易理解的 FragmentManager ，我们新增加了两个 API: saveBackStack() 和 restoreBackStack() 。

如果您不使用这些新增 API，则一切照旧: 单个 FragmentManager 返回栈和之前的功能相同。现有的 addToBackStack() 保持不变 —— 您可以将 name 赋值为 null 或者任意 name 。然而，当您使用多返回栈时， name 的作用就非常重要了: 在您调用 saveBackStack() 和之后的 restoreBackStack() 方法时，它将作为 Fragment 事务的唯一的 key。

举个例子，会更容易理解。比如您已经添加了一个初始的 Fragment 到 Activity，然后提交了两个事务，每个事务中包含一个单独的 replace 操作:

也就是说我们的 FragmentManager 会变成这样:

比如说我们希望将 profile 页换出返回栈，然后切换到通知 Fragment。这就需要调用 saveBackStack() 并且紧跟一个新的事务:

现在我们添加 ProfileFragment 的事务和添加 EditProfileFragment 的事务都保存在 "profile" 关键字下。这些 Fragment 已经完全将状态保存，并且 FragmentManager 会随同事务状态一起保持它们的状态。很重要的一点: 这些 Fragment 的实例并不在内存中或者在 FragmentManager 中 —— 存在的仅仅只有状态 (以及任何以 ViewModel 实例形式存在的非配置状态)。

替换回来非常简单: 我们可以在 "notifications" 事务中同样调用 saveBackStack() 操作，然后调用 restoreBackStack() :

这两个堆栈项高效地交换了位置:

维持一个单独且活跃的返回栈并且将事务在其中交换，这保证了当返回按钮被点击时， FragmentManager 和系统的其他部分可以保持一致的响应。实际上，整个逻辑并未改变，同之前一样，仍然弹出 Fragment 返回栈的最后一个事务。

这些 API 都特意按照最小化设计，尽管它们会产生潜在的影响。这使得开发者可以基于这些接口设计自己的结构，而无需通过任何非常规的方式保存 Fragment 的视图状态、已保存的实例状态、非配置的状态。

当然了，如果您不希望在这些 API 之上构建您的框架，那么可以使用我们所提供的框架进行开发。

Navigation Component 最初 是作为通用运行时组件进行开发的，其中不涉及 View、Fragment、Composable 或者其他屏幕显示相关类型及您可能会在 Activity 中实现的 "目的地界面"。然而，NavHost 接口 的实现中需要考虑这些内容，通过它添加一个或者多个 Navigator 实例时，这些实例 确实 清楚如何与特定类型的目的地进行交互。

这也就意味着与 Fragment 的交互逻辑全部封装在了 navigation-fragment 开发库和它其中的 FragmentNavigator 与 DialogFragmentNavigator 中。类似的，与 Composable 的交互逻辑被封装在完全独立的 navigation-compose 开发库和它的 ComposeNavigator 中。这里的抽象设计意味着如果您希望仅仅通过 Composable 构建您的应用，那么当您使用 Navigation Compose 时无需任何涉及到 Fragment 的依赖。

该级别的分离意味着 Navigation 中有两个层次来实现多返回栈:

仍需特别注意那些 尚未 更新的 Navigator ，它们无法支持保存自身状态。底层的 Navigator API 已经整体重写来支持状态保存 (您需要覆写新增的 navigate() 和 popBackStack() API 的重载方法，而不是覆写之前的版本)，即使 Navigator 并未更新， NavController 仍会保存 NavBackStackEntry 的状态 (在 Jetpack 世界中向后兼容是非常重要的)。

如果您仅仅在应用中使用 Navigation，那么 Navigator 这个层面更多的是实现细节，而不是您需要直接与之交互的内容。可以这么说，我们已经完成了将 FragmentNavigator 和 ComposeNavigator 迁移到新的 Navigator API 的工作，使其能够正确地保存和恢复它们的状态，在这个层面上您无需再做任何额外工作。

如果您正在使用 NavigationUI，它是用于连接您的 NavController 到 Material 视图组件的一系列专用助手，您会发现对于菜单项、 BottomNavigationView (现在叫 NavigationRailView ) 和 NavigationView ，多返回栈是 默认启用 的。这就意味着结合 navigation-fragment 和 navigation-ui 使用就可以。

NavigationUI API 是基于 Navigation 的其他公共 API 构建的，确保您可以准确地为自定义组件构建您自己的版本。保证您可以构建所需的自定义组件。启用保存和恢复返回栈的 API 也不例外，在 Navigation XML 中通过 NavOptions 上的新 API，也就是 navOptions Kotlin DSL，以及 popBackStack() 的重载方法可以帮助您指定 pop 操作保存状态或者指定 navigate 操作来恢复之前已保存的状态。

比如，在 Compose 中，任何全局的导航模式 (无论是底部导航栏、导航边栏、抽屉式导航栏或者任何您能想到的形式) 都可以使用我们在与 底部导航栏集成 所介绍的相同的技术，并且结合 saveState 和 restoreState 属性一起调用 navigate() :

对用户来说，最令人沮丧的事情之一便是丢失之前的状态。这也是为什么 Fragment 用一整页来讲解 保存与 Fragment 相关的状态，而且也是我非常乐于更新每个层级来支持多返回栈的原因之一:

如果您希望了解 更多使用该 API 的示例，请参考 NavigationAdvancedSample (它是最新更新的，且不包含任何用于支持多返回栈的 NavigationExtensions 代码)。

对于 Navigation Compose 的示例，请参考 Tivi。

如果您遇到任何问题，请使用官方的问题追踪页面提交关于 Fragment 或者 Navigation 的 bug，我们会尽快处理。

❾ android怎么压缩一个bitmap占用空间大小

在Android应用里，最耗费内存的就是图片资源。而且在Android系统中，读取位图Bitmap时，分给虚拟机中的图片的堆栈大小只有8M，如果超出了，就会出现OutOfMemory异常。所以，对于图片的内存优化，是Android应用开发中比较重要的内容。 1) 要及时回收Bitmap的内存 Bitmap类有一个方法recycle()，从方法名可以看出意思是回收。这里就有疑问了，Android系统有自己的垃圾回收机制，可以不定期的回收掉不使用的内存空间，当然也包括Bitmap的空间。那为什么还需要这个方法呢? Bitmap类的构造方法都是私有的，所以开发者不能直接new出一个Bitmap对象，只能通过BitmapFactory类的各种静态方法来实例化一个Bitmap。仔细查看BitmapFactory的源代码可以看到，生成Bitmap对象最终都是通过JNI调用方式实现的。所以，加载Bitmap到内存里以后，是包含两部分内存区域的。简单的说，一部分是Java部分的，一部分是C部分的。这个Bitmap对象是由Java部分分配的，不用的时候系统就会自动回收了，但是那个对应的C可用的内存区域，虚拟机是不能直接回收的，这个只能调用底层的功能释放。所以需要调用recycle()方法来释放C部分的内存。从Bitmap类的源代码也可以看到，recycle()方法里也的确是调用了JNI方法了的。 那如果不调用recycle()，是否就一定存在内存泄露呢?也不是的。Android的每个应用都运行在独立的进程里，有着独立的内存，如果整个进程被应用本身或者系统杀死了，内存也就都被释放掉了，当然也包括C部分的内存。 Android对于进程的管理是非常复杂的。简单的说，Android系统的进程分为几个级别，系统会在内存不足的情况下杀死一些低优先级的进程，以提供给其它进程充足的内存空间。在实际项目开发过程中，有的开发者会在退出程序的时候使用Process.killProcess(Process.myPid())的方式将自己的进程杀死，但是有的应用仅仅会使用调用Activity.finish()方法的方式关闭掉所有的Activity。 经验分享： Android手机的用户，根据习惯不同，可能会有两种方式退出整个应用程序：一种是按Home键直接退到桌面;另一种是从应用程序的退出按钮或者按Back键退出程序。那么从系统的角度来说，这两种方式有什么区别呢?按Home键，应用程序并没有被关闭，而是成为了后台应用程序。按Back键，一般来说，应用程序关闭了，但是进程并没有被杀死，而是成为了空进程(程序本身对退出做了特殊处理的不考虑在内)。 Android系统已经做了大量进程管理的工作，这些已经可以满足用户的需求。个人建议，应用程序在退出应用的时候不需要手动杀死自己所在的进程。对于应用程序本身的进程管理，交给Android系统来处理就可以了。应用程序需要做的，是尽量做好程序本身的内存管理工作。 一般来说，如果能够获得Bitmap对象的引用，就需要及时的调用Bitmap的recycle()方法来释放Bitmap占用的内存空间，而不要等Android系统来进行释放。 下面是释放Bitmap的示例代码片段。 // 先判断是否已经回收 if(bitmap != null && !bitmap.isRecycled()){ // 回收并且置为null bitmap.recycle(); bitmap = null; } System.gc(); 从上面的代码可以看到，bitmap.recycle()方法用于回收该Bitmap所占用的内存，接着将bitmap置空，最后使用System.gc()调用一下系统的垃圾回收器进行回收，可以通知垃圾回收器尽快进行回收。这里需要注意的是，调用System.gc()并不能保证立即开始进行回收过程，而只是为了加快回收的到来。 如何调用recycle()方法进行回收已经了解了，那什么时候释放Bitmap的内存比较合适呢?一般来说，如果代码已经不再需要使用Bitmap对象了，就可以释放了。释放内存以后，就不能再使用该Bitmap对象了，如果再次使用，就会抛出异常。所以一定要保证不再使用的时候释放。比如，如果是在某个Activity中使用Bitmap，就可以在Activity的onStop()或者onDestroy()方法中进行回收。 2) 捕获异常 因为Bitmap是吃内存大户，为了避免应用在分配Bitmap内存的时候出现OutOfMemory异常以后Crash掉，需要特别注意实例化Bitmap部分的代码。通常，在实例化Bitmap的代码中，一定要对OutOfMemory异常进行捕获。 以下是代码示例。 Bitmap bitmap = null; try { // 实例化Bitmap bitmap = BitmapFactory.decodeFile(path); } catch (OutOfMemoryError e) { // } if (bitmap == null) { // 如果实例化失败 返回默认的Bitmap对象 return defaultBitmapMap; } 这里对初始化Bitmap对象过程中可能发生的OutOfMemory异常进行了捕获。如果发生了OutOfMemory异常，应用不会崩溃，而是得到了一个默认的Bitmap图。 经验分享： 很多开发者会习惯性的在代码中直接捕获Exception。但是对于OutOfMemoryError来说，这样做是捕获不到的。因为OutOfMemoryError是一种Error，而不是Exception。在此仅仅做一下提醒，避免写错代码而捕获不到OutOfMemoryError。 3) 缓存通用的Bitmap对象 有时候，可能需要在一个Activity里多次用到同一张图片。比如一个Activity会展示一些用户的头像列表，而如果用户没有设置头像的话，则会显示一个默认头像，而这个头像是位于应用程序本身的资源文件中的。 如果有类似上面的场景，就可以对同一Bitmap进行缓存。如果不进行缓存，尽管看到的是同一张图片文件，但是使用BitmapFactory类的方法来实例化出来的Bitmap，是不同的Bitmap对象。缓存可以避免新建多个Bitmap对象，避免内存的浪费。 经验分享： Web开发者对于缓存技术是很熟悉的。其实在Android应用开发过程中，也会经常使用缓存的技术。这里所说的缓存有两个级别，一个是硬盘缓存，一个是内存缓存。比如说，在开发网络应用过程中，可以将一些从网络上获取的数据保存到SD卡中，下次直接从SD卡读取，而不从网络中读取，从而节省网络流量。这种方式就是硬盘缓存。再比如，应用程序经常会使用同一对象，也可以放到内存中缓存起来，需要的时候直接从内存中读取。这种方式就是内存缓存。 4) 压缩图片 如果图片像素过大，使用BitmapFactory类的方法实例化Bitmap的过程中，需要大于8M的内存空间，就必定会发生OutOfMemory异常。这个时候该如何处理呢?如果有这种情况，则可以将图片缩小，以减少载入图片过程中的内存的使用，避免异常发生。 使用BitmapFactory.Options设置inSampleSize就可以缩小图片。属性值inSampleSize表示缩略图大小为原始图片大小的几分之一。即如果这个值为2，则取出的缩略图的宽和高都是原始图片的1/2，图片的大小就为原始大小的1/4。 如果知道图片的像素过大，就可以对其进行缩小。那么如何才知道图片过大呢? 使用BitmapFactory.Options设置inJustDecodeBounds为true后，再使用decodeFile()等方法，并不会真正的分配空间，即解码出来的Bitmap为null，但是可计算出原始图片的宽度和高度，即options.outWidth和options.outHeight。通过这两个值，就可以知道图片是否过大了。 BitmapFactory.Options opts = new BitmapFactory.Options(); // 设置inJustDecodeBounds为true opts.inJustDecodeBounds = true; // 使用decodeFile方法得到图片的宽和高 BitmapFactory.decodeFile(path, opts); // 打印出图片的宽和高 Log.d("example", opts.outWidth + "," + opts.outHeight); 在实际项目中，可以利用上面的代码，先获取图片真实的宽度和高度，然后判断是否需要跑缩小。如果不需要缩小，设置inSampleSize的值为1。如果需要缩小，则动态计算并设置inSampleSize的值，对图片进行缩小。需要注意的是，在下次使用BitmapFactory的decodeFile()等方法实例化Bitmap对象前，别忘记将opts.inJustDecodeBound设置回false。否则获取的bitmap对象还是null。 经验分享： 如果程序的图片的来源都是程序包中的资源，或者是自己服务器上的图片，图片的大小是开发者可以调整的，那么一般来说，就只需要注意使用的图片不要过大，并且注意代码的质量，及时回收Bitmap对象，就能避免OutOfMemory异常的发生。 如果程序的图片来自外界，这个时候就特别需要注意OutOfMemory的发生。一个是如果载入的图片比较大，就需要先缩小;另一个是一定要捕获异常，避免程序Crash。

❿ 如何根据需要定义堆栈段的大小

堆栈的定义是这样的：
dssg
segment
stack
aa
dw
512p(?)
dssg
ends
一般的说，当PUSH/POP指令不频繁时用系统堆栈就可以了，但是当需要堆栈庆物晌存储大量数据，如作为子程序传替参数时就要定义一个堆栈，而且一般来说一个段的内容不能超过64K，因为偏移地址最大只能表蚂余示64K，所以定义的堆栈也不能是无限大，如果超过了64K，就定义两个吧！
堆栈在汇编中对于初学者用的很少，一般小程序都不需要用的！用起来也不是很难，就是注意下，在子程序调用时，什么时候是返回地址，什么时候是寄存器值！总之誉锋，记住先进后出，再做题时画个堆栈图，应该不会很难的！