我正在与我的新的应用程序，它处理捕获的图像从手机的摄像头。我的手机是Nexus S的，2.3.4。

I'm working with my new app which processed captured image from cellphone camera. My phone is Nexus S, 2.3.4.

我创建了一个ARGB_8888位图捕获的数据。我知道NDK图像的lib，但它仅支持2.2及以上。所以，我通过INT [位图NDK的]，发现色彩的字节顺序是little-endian的。

I create a ARGB_8888 Bitmap with captured data. I know the ndk image lib, but it's only support 2.2 and above. So I pass the int[] of Bitmap to NDK and found the color byte order is little-endian.

我搜索维基，发现ARM架构是双向端。 http://en.wikipedia.org/wiki/Endianness#Bi-endian_hardware

I searched the wiki and found arm architecture is bi-endian. http://en.wikipedia.org/wiki/Endianness#Bi-endian_hardware

我的问题是，如果手臂是双向端，如何判断在特定设备的字节顺序？如果我访问前，每次测试的字节顺序中的数据？

My question is if arm is bi-endian, how to judge the byte order in specific device? Should I test the byte order every time before access the data?

推荐答案

是大多数CPU的双端，但大多数最终用户的操作使用今天的系统选择使用的CPU小端。沿着这一思路，ARM可以在两个为了方便操作，ARM 3后，其实际默认为小大小尾是它启动了。我觉得我们可以安全地假定所有的Andr​​oid设备是小端的端模式，否则会是额外的工作，如果不同的Andr​​oid设备是字节序的混合物。

Yes most cpus bi-endian, but most end user operating systems in use today choose to use the cpus in little-endian. Along those lines, ARM can operate in both as a convenience, its actual default after ARM 3 is little-endianess which is the endian mode it starts up in. I think one can safely assume that all Android devices are little endian, otherwise it would be extra work if different android devices were a mixture of endianess.

由于网络字节顺序是大端，它可以转换您计划使用的数据交换网络字节顺序任何形式的帮助。再次，虽然，Mac OS X的英特尔，Windows中，iOS和Android都是小端的，所以你可能只是code可高达结构与本地字节顺序，并希望你想将数据下一个伟大的操作系统不走大端。

Because network byte order is big-endian, it can be helpful to convert any format you plan on using for data interchange to network byte order. Again, though, Mac OS X on Intel, Windows, iOS and Android are little-endian, so you might just code up structures with the native endianness and hope the next great OS you want to port data to doesn't go big-endian.