Android疑难bug统计

1.java.lang.UnsatisfiedLinkError

多半是so加载姿势不对。so没加载进来或者so初始化失败。把三方库的初始化放回application试试
复制代码
建议:使用的minSdkVersion对应的NDK版本来编译so。因为NDK是向上兼容的
提示:21以上用Build.SUPPORTED_ABIS[0],21一下用Build.CPU_ABI获取设备CPU ABI。其中Build.CPU_ABI能表示系统为这个应用选择的ABI。

2.java.lang.ArrayIndexOutOfBoundsException

数组越界,普通的数组越界还是比较容易发现的。下面场景的数组越界不容易被发现。
1.下拉刷新数据还没有返回时,迅速向上滑。
主要还是写法错误,在数据还没有返回时就删除了数据源,导致向上滑动时数据源已经没有了。

2.下拉刷新数据还没有返回时点击item。
错误的写法和上面是一样的

3.需要使用网络返回的数据position,而网络请求数据没有返回
复制代码
建议:刷新数据清空放到网络数据请求的回调中。page为1清空数据;page不为1不清空。

3.java.lang.NullPointerException

空指针异常,普通的空指针异常也是比较容易发现的。下面的场景比较难发现。
网络请求没有返回导致数据实体为空,而在点击或者其他操作中又使用了该实体。
复制代码
建议:在所有使用网络返回的数据实体的地方加上判空处理。

4.Unable to add window -- token android.os.BinderProxy@1fb9679 is not valid; is your activity running?

dialog所依附的view已经不存在
复制代码
建议:在dialog.show之前判断activity.isFinishing()。
5.android.view.WindowLeaked: Activity com.mistong.ewt360.ui.activity.MainActivity has leaked window
当面页面关闭了,但是依附在当前页面的dialog却没有被关闭,造成内存泄漏。
复制代码
建议:在onDestory加入if (mDialog!=null && mDialog.isShowing()) { mDialog.dismiss(); }
提示:多用DailogFragment,便于生命周期的管理。

6.Unable to add window -- token android.app.LocalActivityManager$LocalActivityRecord @xxx is not valid; is your activity running?

参数context 指定成了this,即指向当前子Activity的context。
但子Activity是动态创建的,不能保证一直存在。
复制代码
建议:将context替换为getParent。

7.Fragment already added: KnowledgeTreeDialogFragment

Fragment重复添加,小心DialogFragment也属于fragment,在show时会调用add方法
复制代码
建议:Fragment加FragmentManager.findFragmentByTag和isAdded判断DialogFragment重写show方法。
 override fun show(manager: FragmentManager?, tag: String?) {
        try {
            if (manager == null || manager.isDestroyed) {
                return
            }
            manager.beginTransaction().remove(this).commit()
            super.show(manager, tag)
        } catch (e: Exception) {
            //防止onSaveInstanceState之后执行add fragment
            e.printStackTrace()
        }
    }
复制代码

8.Can not perform this action after onSaveInstanceState

Fragment在onSaveInstanceState做操作就会报这个错误,
把commit换成commitAllowingStateLoss可解决这个问题,会忽略mStateSaved。
复制代码
建议:用commitAllowingStateLoss需要检查功能正确性,commit操作尽量放在onCreate方法中

9.handler建议用静态类和弱引用的方式使用,防止内存泄漏

10.java.lang.IllegalStateException intent.getStringExtra("orderNo") must not be null

从表意上看是Activity跳转的时候orderNo没有传,实际开发中这么傻逼的行为应该比较少。
我这边的场景是 小米 MI 5S 微信支付回来会重新去intent中取orderNo,这时候的intent是微信支付发的,
里面是没有orderNo的。所以导致这个报错。
复制代码
建议:intent取字符串加是否有这个字段判断(因为字符串字段是没有默认值的), if(intent.hasExtra("orderNo")) intent.getStringExtra("orderNo") else ""

11.TransactionTooLargeException

Intent传参数据量偏大,bundle缓冲区最大1M
复制代码
建议:用Eventbus等其他方式代替

12.不要用ScrollView嵌套RecyclerView、ListView。这样会把item一次性加载到内存中。推荐使用NestedScrollView。

13.多线程操作数据库需要使用事务。

14.页面关闭关闭动画。

15.回调看情况需要判断一下对象控件是否还存在。

16.网络相关对象不要用lateinit

转载于:https://juejin.im/post/5c4ea070e51d4551e653d304

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: 好的,我可以为你提供一套疑难Bug联合攻关解决的制度,包括:1.首先,建立一个Bug联合处理小组,组员由有关负责部门和专家组成;2.其次,进行Bug联合攻关,在攻关过程中,要结合Bug的特点,进行细致的探索,探究Bug的根源;3.最后,制定出一个有效的Bug解决方案,以解决Bug问题。 ### 回答2: 建立一套疑难bug联合攻关解决制度对于团队的高效协作和问题解决具有重要意义。以下是一套可行的制度建议: 首先,建立一个疑难bug解决小组,由技术专家和开发人员组成。他们应该具备丰富的经验和技术能力,能够迅速定位和解决各种疑难问题。 其次,当一个疑难bug出现时,团队应该立即成立一个联合攻关小组。这个小组由问题提出者、开发人员和测试人员组成。问题提出者应向开发和测试人员提供尽可能详细的问题描述、复现步骤以及可能的原因分析,以便团队能够快速找到问题所在。 然后,小组成员应通过会议、沟通工具或项目管理工具共享信息和进展。每个成员都有责任分享自己的发现和解决措施,以便其他成员能够共同参与和提供意见。 此外,团队应定期组织技术分享会,让成员能够相互学习和分享经验。他们可以介绍解决疑难bug的方法和技巧,并提供一些建议和指导,以便团队成员提升技术水平。 最后,建议团队建立一个知识库,记录每个解决方案和经验。这可以帮助团队成员在解决类似问题时能够快速查找和应用已有的解决方案,避免重复劳动和时间浪费。 总之,建立一套疑难bug联合攻关解决制度需要团队成员之间的密切合作和信息共享。通过定期分享和知识积累,团队能够迅速定位和解决各种疑难问题,提升整体解决问题的效率和质量。 ### 回答3: 建立一套疑难bug联合攻关解决的制度对于提高产品质量和开发效率非常重要。以下是一个可能的制度建议: 1. 成立一个专门的疑难bug联合攻关小组。该小组由不同部门的专家组成,包括开发人员、测试人员和运维人员。他们应该具备丰富的经验和专业知识,能够深入分析和解决复杂的bug。 2. 设立明确的流程。制定一套详细的流程来管理和解决疑难bug。该流程包括问题报告、分析与定位、解决方案研究、解决方案实施和验证等环节。每个环节都应该有明确的责任人和时间节点。 3. 实行紧密的沟通与协作。专家小组成员应该定期召开会议,分享各自的发现和解决方案。同时,与产品、测试和运维团队之间保持紧密的沟通,及时传递关键信息,避免信息断层。 4. 建立知识库。将每个疑难bug的分析和解决方案记录下来,形成知识库。该知识库可供今后的解决方案参考,避免类似问题的反复出现。 5. 推行奖励机制。针对对疑难bug解决作出突出贡献的个人和团队,设立奖励机制,鼓励他们积极参与和贡献。 6. 不断学习和技术提升。定期组织技术培训和分享会议,提高团队成员的专业水平。鼓励团队成员学习新技术和解决方案,以适应不断变化的技术和环境。 通过建立这样的疑难bug联合攻关解决制度,可以加强团队合作和沟通,提升问题解决能力,更快地解决复杂的bug,提高产品质量,为用户提供更好的体验。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值