低优先级线程增加按键和显示条件为什么会影响高优先级的调用时间片呢

高优先级的线程会抢占运行，所以应该不是这个低优先级的线程所影响的。
建议排查一下其他的代码，或者把你的代码贴出来看看

按键处理逻辑，其中按键和显示线程优先级是21，音频接收和播放线程优先级都是19，下方有一个#if 1, 如果改成#if 0 ,播放时序就必定被打乱。实际上，AudioBox(display.ui.mode) 一直都是LCD_UI_MODE_COMMON，没有按键时不会进去其他模式，但是表现是播放时序明显变慢。

Description: KeyPad Thread entry
Para: parameter form thread creation
Return: void
void keyPad_entry(void *parameter)
{
    uint32_t  keystate=0;
    rt_kprintf("Enter KeyPad Procressn");
    while(1)
    {
        keystate = ~(GPIO_ISTAT(KEY_PAD_GPIO_PORT)&(KEY_PAD_ALLPIN_VALUE)) & KEY_PAD_ALLPIN_VALUE;
        if(keystate & KEY_PAD_ALLPIN_VALUE)
        {
            /*execute different key event function by mode*/
            switch(AudioBox(display.ui.mode))
            {
                case LCD_UI_MODE_COMMON:
                    ProcessKeyWithCommonMode(keystate);
                    break;
                case LCD_UI_MODE_EDIT:
                    ProcessKeyWithEditMode(keystate);
                    break;
                case LCD_UI_MODE_EXTERN:
                    ProcessKeyWithExternMode(keystate);
                    break;
                default:
                    break;
            }
            /*any key will recount idle*/
            AudioBox(display.ui.ui_timeout) = 0;
            keystate = 0;
            rt_thread_mdelay(180);
        }
        LockThread();
        if(AudioBox(display.ui.pMenu->menuindex) != AudioBox(display.ui.changeMenu))/*Menu changed*/
        {
            if(AudioBox(display.ui.pMenu->menuindex) == LCD_UI_MENU_PAIREDDEV_LIST)
            {
                //free paired list
                AudioBoxPairedDevList_t * pFree = AudioBox(btdevice.paired_list);
                AudioBoxPairedDevList_t * pNextFree;
                while(pFree !=NULL)
                {
                    pNextFree = (AudioBoxPairedDevList_t *)pFree->p.next;
                    rt_kprintf("Free Device: %srn",pFree->device.u8Name);
                    rt_free(pFree);
                    pFree = pNextFree;
                }
                AudioBox(btdevice.paired_num) = 0;
            }
            /*Display menu*/
            AudioBox(display.ui.pMenu) = LcdUiDisplayMenu(AudioBox(display.ui.changeMenu));
            /*Display external context*/
            LcdUiDisplayUpdateExtContext(AudioBox(display.ui.changeMenu),TRUE);
        }
        else if(AudioBox(display.ui.changmode))/*mode changed*/
        {
            AudioBox(display.ui.changmode) = FALSE;
            LcdUiDisplayUpdateExtContext(AudioBox(display.ui.pMenu->menuindex),FALSE);
        }
        else if(AudioBox(display.ui.op_change)) /*select changed +*/
        {
#if 0
            LcdUiDisplaySelect(AudioBox(display.ui.pMenu),AudioBox(display.ui.op_value)>0,AudioBox(display.ui.op_change));
#else
            switch(AudioBox(display.ui.mode))
            {
            case LCD_UI_MODE_COMMON:
                LcdUiDisplaySelect(AudioBox(display.ui.pMenu),AudioBox(display.ui.op_value)>0,AudioBox(display.ui.op_change));
                break;
            case LCD_UI_MODE_EDIT:
                if(AudioBox(display.ui.op_value))
                {
                    AudioBox(display.ui.op_value) = FALSE;
                    LcdUiDisplayEdititem(&AudioBox(display.ui.pEdit->pEdititem)[AudioBox(display.ui.pEdit->edit_idx)],
                                          AudioBox(display.ui.pEdit->edit_idx),LCD_CMD_INTVERT_FONT_12,AudioBox(display.ui.pEdit->value));
                }
                else
                {
                    LcdUiDisplayEditByIndex(AudioBox(display.ui.pEdit),AudioBox(display.ui.pEdit->edit_idx),
                                            AudioBox(display.ui.pEdit->pre_edit_idx));
                }
                break;
            case LCD_UI_MODE_EXTERN:
                LcdUiDisplayExternMode(AudioBox(display.ui.pMenu->menuindex),AudioBox(display.ui.Extern.deep_level),
                                       AudioBox(display.ui.Extern.select),AudioBox(display.ui.Extern.preselect));
                break;
            default:
                break;
            }
#endif
            AudioBox(display.ui.op_change) = FALSE;   
        }
        else
        {
            LcdUiDisplayUpdateBtState(AudioBox(display.ui.pMenu->menuindex));
        }
        UnLockThread();
        rt_thread_mdelay(20);
    }
}

实测就是低等级的判断逻辑或者线程数多了，就会影响高等级的处理时序，证明线程调度还不是很智能,我把msh线程删了就可以工作了

1 线程调度本来就不是智能，是规则，优先级和时间片；
2 看一下你的CPU是不是够用；
3 看一下你的低优先级任务里是不是关中断、锁任务调度了；
4 看一下你的中断是不是占用过长时间；

感谢回复。
困扰了我快一周，最终验证测试，是因为代码空间超出了一定大小，可以执行，但是效率变得非常低。估计GD32的code area 超出之后512K就需要做重新寻址。

我验证方式是，低等级线程（按键处理）在一定的条件后直接退出。此时高等级的线程（音频接收和播放）调度依旧会受影响。当删除掉一点其他代码，就又正常了。所以是和代码大小有关，和线程调度应该没有关系

调查到这里就有点尴尬了。本身我是做蓝牙协议栈的。压缩得很辛苦才勉强够用。
各位大侠有什么好的建议吗？

下方粗体的是编译最终大小的信息。

Build started: Project: project
* Using Compiler ‘V5.06 update 6 (build 750)’, folder: ‘C:Keil_v5ARMARMCCBin’
Build target ‘rt-thread_gd32f4xx’
compiling key_pad.c…
applicationskey_pad.c(765): warning: #111-D: statement is unreachable
rt_kprintf(“exit KeyPad Procressn”);
applicationskey_pad.c(359): warning: #177-D: function “ProcessKeyWithEditMode” was declared but never referenced
static void ProcessKeyWithEditMode(uint32_t keystate)
applicationskey_pad.c: 2 warnings, 0 errors
linking…
Program Size: Code=345404 RO-data=115684 RW-data=1372 ZI-data=139068
FromELF: creating hex file…
“.buildrtthread-gd32f4xx.axf” - 0 Error(s), 2 Warning(s).
Build Time Elapsed: 00:00:06
Load “C:workspaceEsMcuStack_gd32450vit6buildrtthread-gd32f4xx.axf”

JLink Info: Device “CORTEX-M4” selected.
Set JLink Project File to “C:workspaceEsMcuStack_gd32450vit6JLinkSettings.ini”
JLink Info: Device “CORTEX-M4” selected.
**

我理解的是代码区域是映射表可以操作的地方，至于IC的内核怎么设计我就不了解了。
个人觉得应该覆盖整个Flash应该也不麻烦，可能会损失性能吧。

应该不是Cahche的概念，因为RAM只保留当前运行的函数和全局变量。运行结束之后就释放了。
看起来更像是内核管理Flash区域就只有512K，多出的也可以放代码，但是要重新做一遍寻址。这样就会额外消耗运算时间。

表现现象就是，多加点代码（即使当前不运行），也会导致音频处理线程效率变低。