• Android慎用layout嵌套, 尽量控制在5层下面java.lang.StackOverflowError


    一、探寻原因
    在一个复杂的layout嵌套较多layout的android界面。在Android 2.3、内存较低 的机型上,出现 java.lang.StackOverflowError 这个Exception,appcrash退出。

    这个错误出现的比較奇怪,在我做技术调研的时候,这个界面是放在4.0的系统中測试,工作非常正常,没有出现这个严重错误。

           android SDK中对该错误的出现的场景描写叙述为:因为栈调用的层次太多。超过了虚拟器dalvik的最大限制(作为一个虚拟器參数,可定制)导致的。当程序编写错误导致无限递归调用时会触发,此外程序正确可是递归调用的层次过深也会触发。
           在寻找问题的过程中,採取排除法。一点点凝视代码。找到是由于语音控件的问题。去掉语音控件,不会出现Crash。观察该界面的集成情况,发现当加入语音控件后,又添加了一层layout, 此时已说明layout的嵌套已经达到最大值,不能容忍再加入1层。而由于该界面复杂,设计时, view的layout深度为6层。

    原因定位为界面嵌套层次过深,初步认定解决方式为降低layout层次。

     
    二、解决方法
             解决嵌套过深的基本思路是在实现相同的效果的前提下降低界面的layout深度。

    在我将layout深度由6层精简为4层,该错误被解决。

    SDK提供的解决方法有:
    1)       多用RelativeLayout的各种布局属性来完毕布局,而避免过多使用嵌套layout来实现。
       2)       占位或填充剩余空间的元素多用View,避免使用layout等viewGroup。
    final 方法有:
    由于咱的View层次的确须要非常多,所以从改变View层次入手非常难,開始纠结了非常久,最终找到突破口。在Android官方SDK提供了一种XML标签, 在官方文档里的标注就是通过merge标签来降低视图层级结构。

          这个问题暂且如此解决吧,开发中注意不要在现有深度上添加深度

    同一时候继续寻找进一步解决方式。


    总结下,从实际的数据来看,设计中layout嵌套深度超过10层(假设要兼容低端机型,最好不要超过5层)。就应该考虑下优化了,否则就会出现java.lang.StackOverflowError的crash了。
  • 相关阅读:
    Java变量以及内存分配
    在ORACLE存储过程中创建临时表
    CREATE OR REPLACE FUNCTION
    DECLARE
    CURSOR
    STM32WB SRAM2
    git版本控制
    STM32WB HSE校准
    STM32 HSE模式配(旁路模式、非旁路模式)
    STM32WB 信息块之OTP
  • 原文地址:https://www.cnblogs.com/mfmdaoyou/p/7094699.html
Copyright © 2020-2023  润新知