本文讲述了在智能手机应用的架构设计中遇到的大端小端模式问题，导致Android客户端性能下降。问题源自于Java环境中默认的大端模式与不同平台之间的转换。解决方案包括验证Java环境为大端模式，优化服务器和客户端代码，避免不必要的字节序转换。文章强调了架构设计阶段考虑细节的重要性，以及程序员解决问题时深入探究的根本态度。
问题：架构设计中的大小端模式（little-big endian）
TX公司有一款有关智能手机应用的产品，该产品包括支持四个智能主流手机平台（symbian, windows mobile, Android, iPhone），上线后随着业务需求的变化，从后台下载到前端的内容量也暴增，也因此Android前端加载内容的性能也突然下降，想了很多办法包括逻辑优化和算法优化也无法提升，尤其在计算资源尤为宝贵的智能手机上。但很奇怪的是，同样的内容量在其他手机平台上的前端应用中以同样的算法和同样的逻辑处理内容却没有性能突降的问题，于是不得已采取debug跟踪，最后终于发现是因为大小端转换费了90%的时间。于是client就去优化大小端转换的代码，因为当时的程序员不知道JDK有提供直接转换大小端的API，所以自己写了一个方法去转换，效率肯定是有问题，用JDK提供的一个方法一行代码替换了自己写的n行代码问题就搞定。事情到此该打住了吧？没有，问题又来了，Android client通过使用JDK提供的API效率提高了不少，那client加载并显示的性能解决了，可是server响应速度还是满足不了业务需求？
原因：
要说明白还得从产品的架构设计开始，产品初期，因为只有symbian平台，虽然在架构设计中考虑日后跨平台的需求，已经考虑了client/server通信协议的扩展性以及client为屏蔽硬件层和操作系统层而设计的分层结构，但比较细节的诸如大端小端的问题并没有提及。于是在symbian平台的client首先出笼与server联合调试时，大小端的问题就出来了
最低0.47元/天 解锁文章
扫一扫
745
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
