ar汇编语言进行逐条指令的手动优化，以追求极致的代码密度和执行效率。 数据结构精简: 重新审视协议栈中使用的各种数据结构（如状态变量、消息队列、缓冲区），用位域（bit field）、联合（union）等技巧，将内存占用压缩到最小。 代码共享与库化: 仔细检查代码库，将重复的逻辑或功能封装成可重用的函数库，减少代码冗余。 功能裁剪的艺术: 在保证核心通信功能和标准兼容性的前提下，对一些很少使用或优先级不高的协议特性（比如某些冷门的gprs服务等级或网络信令选项），暂时进行功能屏蔽或采用更简单的实现，待后续版本再完善。 经过数周艰苦卓绝的“抠内存”工作，协议栈软件的静态尺寸终于被成功压缩到了可以容纳进预定内存空间的范围。
解决了空间问题，接踵而来的是更严峻的实时性能挑战。移动通信协议对各种信令交互和数据处理的响应时间有着“毫秒必争”的苛刻要求。
“中断响应太慢了！”负责l1（物理层）软件的工程师报告道，“在处理高速下行数据时，如果同时有高优先级的上层信令（如切换请求）中断进来，ar核的处理会延迟几个毫秒，可能导致错过接收窗口！” “任务调度优先级需要重新调整！”负责rtos内核移植的工程师建议，“基带物理层的中断处理和数据搬运任务，必须拥有最高的抢占优先级！” “光靠cpu不行！必须把计算密集型任务卸载给硬件！”张建华再次强调，“卷积码\/turbo码的编解码、均衡、解扩……这些必须由dsp和硬件加速器来完成！ar核只负责协议逻辑控制和任务调度！”
新一轮的软硬件协同设计和优化开始了。硬件团队根据软件团队提出的需求，微调了中断控制器和da控制器的优先级设置；dsp团队则进一步优化了提供给ar核调用的硬件加速函数接口，使其调用开销更小，执行效率更高；协议栈软件团队则重构了任务调度模型，将实时性要求最高的任务剥离出来，用最高优先级运行，并尽可能地利用硬件加速能力。
联调过程更是充满了各种意想不到的“坑”。
“为什么手机在弱信号下尝试发起gprs连接时，总是失败？”——排查半天，发现是软件在读取硬件提供的信号