*基于Inter架构开发**~和优化Android应用**~

*基于Inter架构开发**~

和优化Android应用**~

*本文主要介绍如何在Intel Atom &

&架构下开发和优化Android应用程序!

如何开发和移植Android NDK应用**

**以及如何通过代码阶段&

&编译阶段来优化NDK应用**~

*•1.      Android* 应用程序的分类

•2.      Android* 本地开发套件(NDK)介绍

•3.      为Intel架构开发和移植NDK应用

•4.      本地代码开发注意点

•5.      通用性能优化

•6.      总结*

1).*Android* 应用程序的分类

Android应用程序大致可以分为两类：

一类是Dalvik应用，这类应用程序只包含 

Java代码和必须的xml，png等文件，

调用Android官方SDK的API，最后通过

编译为APK文件。

另一类应用是NDK应用，这类应用不仅

包含Java代码和必须的xml，png等文件，

还包含本地代码(.h, .c, .cc, )甚至还包括

汇编代码。所有本地代码通过MakeFile

编译为动态库(so文件)，Java端通过JNI机

制去调用动态库。

其原理如下图所示：*

**

*

Android* 本地开发套件介绍

NDK的全称为本地开发套件，一般来说

会在以下两个场合中使用到：*

*1. 构建高性能要求的部分。如音视频的

编解码，图形图像的处理，会使用C或者

汇编等本地代码。因为Java代码的执行

需要虚拟机去解释，而本地代码直接编译

成二进制文件，在高性能要求的地方，

执行起来更加高效  !

*2. 重用已有代码。对于已有的C库，

C++库，可以通过NDK的机制来调用已有的库*

*

对于相应的应用开发，英特尔提供了硬件

加速管理器，可以显著提升应用开发过

程中Android模拟器的性能。具体可以

访问网址: /en-us/articles/intel-hardware-

accelerated-execution-manager 获取关于

硬件加速管理器的更多内容。

为Intel Atom架构开发和优化NDK应用

NDK应用的开发可以分为以下五个步骤：

 *

*

开发兼容Intel架构的NDK应用需要在第

二步编写MakeFile的时候

添加APP_ABI := x86 代码段。

对于已有的NDK应用向Intel Atom架构

移植需要遵循以下步骤：

*

*1. 如果是Dalvik应用，可以直接在Intel架构

上运行。只需要为相应的设备调整分辨率即可*

*2. 如果是NDK应用，如果仅包含C,C++代码

使用上面的方法重编译本地代码，生成在

Intel平台的动态库即可。如果本地代码中还

调用了第三方的动态库，则第三方动态库也

需要重编译一个x86平台的版本。如果包含了

汇编等和硬件平台紧密相关的代码，这部分

代码需要重新编写**

*

本地代码开发注意点

*强制内存对齐*

*由于平台差异，如果不进行强制内存对齐，

在其他平台设备中将数据写入一个文件，

在x86平台去加载会出现大小不一致导致加载

出错的情况。如下面一个结构图 testStruct：*

* struct TestStruct
{
    int mVar1;
    long long mVar2;
    int mVar3;
}                           *

*在ARM平台和Intel平台编译后，大小如

下图：ARM平台会自动采用double malign

的方式，占用24个字节，而x86平台占

用16个字节。

 

如果我们编译时添加强制对齐参数：
-malign-double 则占用相同大小的字节，
不会出现加载出错的情况。

 

将NEON 指令集(ARM*) 移植至SSE 

指令集(英特尔) 

汇编代码部分需要注意平台差异，比如大

字节序和小字节序存储问题;

对于寄存器的操作，需要注意对应寄存器

的大小限制，具体可以查表；

NEON指令集提供了一些本地的C库，这部

分代码虽然是C代码，但是在英特尔® 凌动

^TM平台是不能运行的，需要重新编写* *

*通用新能优化 ~

*在本地代码编写阶段，尽可能将短小的

经常调用的函数写成内联函数，可以减少

函数调用的开销。使用float数据类型来

代替double可以充分使用Atom硬件浮点数

预算的功能。多线程编程来充分利用

英特尔® 凌动^TM 芯片的超线程性能* *

*多线程编程*

*使用编译器选项 -opt-threads-per-core 

 针对每内核的 1-4 个线程进行调度*

*

本文介绍的编译器选项能够影响应用程序

使用的每内核硬件线程数。

-mCG_lrb_num_threads=1|2|3|4

（默认值为 2） ( Composer XE 2013 第一版, 13.0.0.079.

 版本 未经正式归档/不支持的选项 )

Composer XE 2013 更新 1 和更高版本: 

  被支持选项 -opt-threads-per-core=

1/2/3/4 和（默认值为 4）替换    .

·         该选项不影响运行时使用的每内核

线程数量。它由 KMP_AFFINITY、OMP_

 NUM_THREADS 等设置进行控制。

·         使用该选项编译的代码可以在任何

（支持的硬件）每内核线程数上正常运行。

提示编译器将有多少条线程将在内核上运

行。该信息用以更加有效地优化应用性能，

尤其是在指令调度过程中。N 的价值应由

用户决定，以匹配在执行应用过程中每个

内核使用的线程数量。例如，如果应用使

用 OpenMP 实现并行化，使用每内核的线

程数（即 N 的值）作为 OpenMP 相似性

设置，在 MIC 上执行应用代码时

将使用该设置。

*多线程并行程序性能分析方法综述之

Thread Profiler 线程档案器*

*

2.5 Thread Profiler线程档案器
Intel® 线程档案器可以帮助调整Win32*和
OpenMP*线程化软件的性能。该工具通过
监控程序的运行来检测线程性能的相关问题，
包括线程过载和同步冲突，能够帮助查找负载
平衡, 同步开销等线程性能问题。可以进行关
键路径分析。线程档案器最后提供图形式的
检测结果，由此可以快速查明影响程序运行
时间的代码位置，并通过以图象形式生动显
示每个线程的实时工作状况从而大大简化了
调整程序性能的任务。
Intel® 线程档案器支持Intel® 64 和
 Microsoft Visual Studio环境，通常集成
到Intel® VTune性能分析器中使用**

*

2.5.1 线程档案器功能与使用

Win32*线程分析能力：
通过Win32* 线程API对软件线程化后的性能分析；
Win32线程关键路径分析，跟踪显示性能瓶颈--浏览直接影响
执行时间的数据；
Microsoft Visual Studio* .NET开发环境集成--运行线程档案器，
然后在Visual Studio .NET浏览结果；
如果不用Win32库，可以支持用户定义的同步原件。
OpenMP*线程分析能力：
线程档案器将OpenMP线程分析分成以下几类：
时间花费--并行代码；顺序代码；其他线程等待间隔；等待进入关键
部分或锁访问；关键部分和持锁操作；
线程任务量不均衡；
并行过载；
顺序过载。
特性：
自动并行性能分析--提供快速、简单、直接的并行性能分析，
不需要其他机制；
图形化显示线程状态和并串转换--揭示了性能优劣的原因，指明优化重点；
决定多处理器系统的可量测性--多个处理器协同工作的性能非常重要，
对于OpenMP线程，线程档案器以图形方式显示了多处理器系统下理想
的并行性能和程序的实际性能；
线程化设计确认--利用线程档案器检测线程化软件设计的效率。并行编
程的好处体现在高效率和低负载上，线程档案器能以图形方式揭示
程序的效率和过载情况。
Intel® 线程档案器同时显示并发视图和时间轴视图，这有助于理解
哪部分代码适合并行处理以及应用性能问题源于何处，如图2.15所示：

图2.13 同时查看并发和时间轴

通过双击时间轴视图上的转换进入源代码视图，从而准确查看线程
在源代码中进行转换工作的位置，如图2.16所示。这是理解线程应用行为的关键。

图2.14 查看源代码以发现线程问题

Intel® 线程档案器 3.0 Windows 版兼容现今的行业标准开发工具：
Microsoft Visual Studio .NET* 开发环境
Microsoft Visual C++* .NET 编译器 2005、2003、2002 版或 Visual C++ 6.0
Intel® VTune性能分析器 7.2 或 8.0
Intel® Fortran 和 C++ 编译器
Windows 线程和 POSIX* 线程
支持OpenMP

2.5.2 线程档案器实验
本实验通过Intel® 线程档案器来检测Win32线程程序中的性能问题。
（1）入门指南
打开\code\ThreadProfiler\potential lab 1\文件夹，
双击Potential Lab 1.sln文件；
在Build菜单里选择Configuration Manager，然后选择Release模式；
按如下方式配置项目属性：
选中Debug模式 （/Zi）

链接时保留Debug信息 （/DEBUG）

使用线程安全系统库 （/MD）

使用二进制文件可重定位功能 （/fixed:no）

在Build菜单里选择Build Solution，编译相关文件；
运行Intel® VTune性能分析器；
点击New Project；
在Category栏选择Threading Wizards，在下拉框中选择Intel Thread Profiler Wizard；
选择刚才编译好的可执行文件路径
（\code\Thread Profiler\Potential lab 1\Release\potential.exe），
点击Finish按钮，开始运行线程档案器；
运行结束后，可看到双重视图，如图2.15所示：

图2.15 并发级别和时间轴双重视图

双击Profile栏可打开Concurrency Level视图。如果默认不是
Concurrency Level视图，可点击图标进入；
点击其它分组图标，如grouping to thread图标和grouping to
 object图标，观察各自属性；
双击Timeline栏视图可打开时间轴视图，观察性能数据，用鼠标在

小范围拖拽可微观查看线程细节。
问题：
从刚才观察到的图表、数据分析，程序里有比较明显的性能问题吗？
（2）分析程序
返回到Profile栏的Concurrency Level视图，有多少时间消耗在串行
（只有一个线程）执行程序？多少时间消耗在完全的并行执行？
从这能得到什么启发？
点击图标，打开grouping to thread视图，该视图显示了程序中
所有线程在关键路径上的活跃程度。该程序一共运行过多少个线程？
有什么性能问题？
点击图标，打开grouping to object视图，是否有同步对象在关键
路径占了相当大比例，而它又是串行执行的？如果有，是哪一个？
双击Timeline栏，打开时间轴视图。从这些数据中所发现最明显的
特征是什么？如果有性能问题，应该从哪方面去解决它？
（3）负载平衡问题
编译和运行Potential多线程程序
打开\code\ThreadProfiler\Potential Lab 2\文件夹，
双击Potential Lab 2.sln文件；
注意到源代码中两个事件变量bSignal和eSignal的定义和初始化，
以及tPoolComputePot函数中done变量的使用，它控制模拟完成
时线程的终结；
选择Release模式编译，并像前一小节设置好项目属性，编译程序；
打开VTune性能分析器，创建一个新的Thread Profiler活动，装入刚才
编译生成的可执行文件，开始分析。
根据线程档案器的分析数据诊断程序性能问题
观察关键路径视图，注意到大部分时间都消耗在Serial impact time，
即串行执行时间。并行级视图进一步确认了大部分时间都
只有一个线程在执行。
打开grouping to object视图，哪个对象占用了串行执行时间？这个对象
限制了其它对象对数据进行访问吗？如果是这样的话，能否改变程序
和数据访问的模式，以减少线程占有同步对象的时间？
注：同步对象eSignal是用来标识线程何时完成，而非用来保护数据，
主线程是惟一一个串行执行的。为了保证程序运行的正确性，主线程
串行执行很有必要。因此，修改数据不会影响到状况。
若问题不是由数据保护这些同步对象引起的，那可能是因为线程自
身引起的。打开grouping to thread视图，是否有一个或多个线程占用
了关键路径中的串行执行时间？如果有，是哪几个？
比较每个tpoolComuptePot （worker）线程的生存时间和活跃时间，
有哪些启发？

解决性能问题
注：两个worker线程活跃时间的差异表明两个线程的计算负载不平衡。
需要重新分配每个线程完成的任务，使任务分配更为平衡。
回到Microsoft Visual Studio界面，观察源代码：在computePot函数中
，每个线程用它分配的标识符（tid）来划分它要完成的任务块。然而，
在内部的循环需要用到外部循环的索引作为结束条件。因此，外部 
循环的索引越大时，内部循环的迭代次数也越多，而相应划分到的
线程所要完成的任务也越重。
有一个很好的方法能解决这种负载不平衡问题，即采用更灵活的
任务分配机制。例如，不采用将连续的迭代分配给一个线程，而交
叉分配给多个线程，比如只有两个线程时，可将奇数次的迭代分配
给一个线程，而将偶数次的迭代分配给另一个线程。
按照上面提示的方法，修改源代码的任务分配机制，结合线程
档案器，使程序的线程负载趋于平衡* ~~

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

            

 
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&