回调函数、共享内存概念与使用，以及进程间函数调用的讨论
 
    最近在做项目时，需要调用一个第三方的库和框架，在项目进行一段时间之后，突然发现对该第三方的库以及框架的实现机制不太了解，现根据其函数声明以及使用方式推导其实现机制。会有出入。
 
1、问题描述
 
    该库和框架是用于仿真的，为非标库；同时提供了一个框架用于实现对库的使用，这样用户只需要在框架内写一些代码就可以实现相关的功能，这个软件的基本功能基本描述如下：
 
      1、一台“服务器”，同时有多个“客户端”；之所以加引号是因为不是严格意义上的服务器-客户端的概念，只是逻辑上功能一致；
 
      2、每个客户端采用相同的框架，并调用相同的库；
 
      3、为了保证运行时客户端之间数据传递的同步性，由服务器向每个客户端发送同样的数据，该数据包含了一些参数，通过这些参数，客户端之间保持同步运行并实现各自的操作；
 
    通过以上描述，最先想起来的是利用Socket，通过Socket（UDP）连接，每个客户端连接到服务器，再由服务器向每个客户端发送数据，也可以实现以上的功能；暂不讨论采用Socket方法的优劣。在这里采用另外一种实现方式：回调函数。回调函数的概念网上有一大堆，关于它的理解，在下面的章节我选取了一些比较好理解的进行展示（如有侵权，请及时联系）。
 
    结合该问题，通过具体实施，有助于加强对回调函数等的了解。
 
 
 
2、回调函数
 
2.1、回调函数的概念    
 
关于回调函数的概念，网上有很多解释，但大多都很抽象。其实回调函数的概念也很简单，我的理解是：
 
      1、回调函数，Call Back Function，意如其名。可以简单的理解为A调用了B中的函数，而在B中的这个函数中又调用了A中的函数，这样就形成了一个逻辑上的“回调”机制；
 
      2、关于A和B的理解，可以理解为一个程序的两个部分；也可以理解为一个程序、一个库（静态or动态）;当然最有助于理解的还是把A和B理解成两个程序，但是这样只是有助于理解，在实际实现过程中会存在很多的麻烦，接下来的章节会进行阐述；
 
      3、可以把回调函数理解成两层意思：一是回调函数的这个过程，是动态的；二是回调的那个函数，是静态的；
 
2.2、回调函数的定义
 
    下面通过一个简单的例子来展示回调函数的使用：
 
 
 
#include <stdio.h>
void PrintWelcome(int n)    //被回调的函数
{
    printf("%d is coming!", n);
}

void CallBack(int nC, void(*print)(int))    //调用“被回调的函数”的函数，简称回调函数
{
    int nT = nC;
    print(nT);
}

void main()
{
    CallBack(3, PrintWelcome);     //调用回调函数，其中一个参数为“被调用的函数”的函数名
    return;
}
 
    由上面的代码可以看出：
 
    1）、main函数调用了CallBack函数；
 
    2）、由于main函数在调用CallBack时传递了PrintWelcome函数的函数指针，所以CallBack函数内部的print函数实际上就是在调用PrintWelcome函数；
 
    关于回调函数的使用，需要注意一下几点：
 
    1）、被回调的函数的定义方式：该函数的定义没有什么特别需要注意的地方，按照正常方式定义函数即可；另外需要注意的是，任何一个定义过的函数在内存中都会分配一块内存用于存储该函数的代码，存储形式为汇编语言的形式，而这块内存的首地址即为该函数名，即，函数名代表了该函数存储的内存地址的首地址；
 
    2）、回调函数的定义：在定义回调函数时，必须保证该函数的一个参数为函数指针的形式，并且该函数指针代表的函数形式需和“被回调的函数”的函数形式保持一致！即，函数的返回值类型保持一致，函数参数列表保持一致；
 
        为了解决函数形式很复杂的情况下，代码书写的问题，可以采用typedef将函数形式重定义成一个容易记的变量名，参考如下形式：
 
 
 
typedef void (*PRINT)(int nC);
 
       当采用上述方式表达之后，回调函数就可以直接写成：
 
 
 
 
 
void CallBack(int nC, PRINT print)
{
    int nT = nC;
    print(nT);
}
 
      可以明显看出这样写代码会更加简洁，并且不容易写错。
 
 
 
    3）、在调用回调函数时，需要保证传递参数必须为“被回调函数”的函数名！
 
2.3、使用回调函数
 
    好了，回调函数的概念以及怎么使用搞清楚了，下面开始具体使用了，看第一章节的问题描述，开始使用回调函数设计程序。
 
    服务器是一个独立的程序，各个客户端分别是一个独立的程序，现在服务器要回调各个客户端程序中的函数。emmmmm.....问题来了，
 
    1）、两个独立的程序、不同的进程，服务器该怎么知道客户端中定义的函数呢？
 
      可以采用同一个函数定义的形式，双方都采用统一各头文件或者引用同一个库，这样大家都能识别同一种形式的函数定义了；
 
    2）、服务器端要调用回调函数，就需要知道“被回调函数”的函数名，那服务端怎么知道客户端中定义的“被回调的函数”的函数名呢？
 
      需要知道的是，这个“函数名”是有具体含义的，它不仅仅代表了函数的名称，也代表了函数定义存储在内存块上的首地址，而且在调用回调函数时，传递的参数实际上是地址！
 
    3）、哦~那看来需要传递一个地址，那么我该怎么在程序间传递地址呢？
 
      Socket不行，它只能传递字符串；
 
      利用配置文件？不行，这样虽然能获取一个地址，但没有任何意义；
 
      诶，可以这样，我可以制作一个库，在这个库里，提供两个函数，一个用于得到“被回调函数”的地址，即set；一个用于获得“被回调函数”的地址，即get。然后服务器和客户端同时调用这一个库，一个set，一个get这样不接可以传递了吗！
 
    4）、需要注意的是，虽然两个程序都同时调用了同一个库，但是，这两个程序是分别把库加载进了进程申请的空间中的，虽然调用了同一个库，但是，这两个库之间是八竿子打不着的关系，更别提，数据传递了，这种方法不行，那有没有一种大家都认识的内存地址控件呢？
 
     还真有，那就是采用共享内存的方式。共享内存实际上是一个内核对象，内核对象大家都能识别，这样应该就能传递了吧。
 
 
 
3、共享内存
 
3.1、共享内存的概念
 
    共享内存又称为内存映射文件。共享内存从字面意义解释就是多个进程可以把一段内存映射到自己的进程空间，以此来实现数据的共享以及传输。意思就是，在计算机上申请了一块内存，该内存对所有的进程都可见，并且所有的进程都可以去访问它。需要注意的是，各进程是把这块内存地址映射到了自己的进程空间里，因为每一个打开的进程都有自己的进程空间，并不是在进程里都去操作那块地址，在进程里操作的是它的映射地址。
 
    拿Windows来说，Windows提供了多种机制来实现进程间的通信，比如最常见的Socket，还有RPC、COM、消息机制、邮件槽、管道等机制；但是，这些机制归根结底都会用到内存映射文件，即共享内存。
 
3.2、共享内存的使用
 
    要使用共享内存，需要用到几个内核函数：
 
     1）、CreateFileMapping：告诉系统映射对象需要多大的物理存储空间，声明如下：
 
 
 
HANDLE CreateFileMapping(
    HANDLE hFile,             //hFile是需要映射到进程地址空间的文件的句柄。如果没有有效的句柄，可以用INVALID_HANDLE_VALUE
    PSECURITY_ATTRIBUTES psa, //psa用于文件映射内核对象，一般传NULL（提供了默认的安全性，此外表明返回的句柄不可继承）
    DWORD fdwProtect,         //指定给物理存储器页面的保护属性，一般传PAGE_READWRITE即可，表示可读取数据并能够写入数据
    DWORD dwMaximumSizeHigh,  //用于告诉系统内存映射文件的最大大小，以字节为单位，该参数表示的是高32位，对于<4GB的数据来说，该参数始终为0
    DWORD dwMaximumSizeLow,   //该参数表示的是低32位，如果需要用当前的文件大小创建一个文件映射对象，两个参数都为0即可。
    PCTSTR pszName            //表示一个以'\0'结束的字符串，用来给文件映射对象指定一个名称。可以传NULL，也可以赋一个具有标识的字符串
);
 
 
 
     2）、MapViewOfFile：将数据映射到进程的地址空间，声明如下：
 
 
 
PVOID MapViewOfFile(
    HANDLE hFileMappingObject,  //文件映射对象的句柄，是之前调用CreateFileMapping函数时返回的
    DWORD dwDesireAccess,       //dwDesireAccess表示想要如何访问数据,可以指定为FILE_MAP_ALL_ACCESS（READ/WRITE/COPY）
    DWORD dwFileOffsetHigh,     //用于告诉系统应该把数据文件中的哪个字节映射到视图中的第一个字节。文件的偏移量必须是系统分配粒度的整数倍
    DWORD dwFileOffsetLow,      //这两个参数都可以指定为0
    SIZE_T dwNumberOfBytesToMap //用来指定需要映射到地址空间的数据的大小
);
 
    下面通过两个例子用于展示共享内存的使用；
 
 
 
    ProcessA:
 
 
 
#define DATA_SIZE  256
const wchar_t mapFileName[] = L"myFirstMapping";
HANDLE myFileMappingHandle = CreateFileMapping(INVALID_HANDLE_VALUE,NULL,PAGE_READWRITE,0,DATA_SIZE,mapFileName);
if(myFileMappingHandle==NULL)
{
    printf("创建文件映射内核对象失败！");
    CloseHandle(myFileMappingHandle);
    return 0;
}
char* pBuf = (char *)MapViewOfView(myFileMappingHandle,FILE_MAP_ALL_ACCESS,0,0,DATA_SIZE);
while(1)
{
    cout << "input..."  << endl;
    getchar();
    char szInfo[DATA_SIZE] = {0};
    gets_s(szInfo);
    strncpy(pBuf, szInfo, DATA_SIZE-1);
    pBuf[DATA_SIZE-1] = '\0';
}
UnmapViewOfFile(pICBR);
CloseHandle(myFileMappingHandle);
return 0;
 
    ProcessB:
 
 
 
#define DATA_SIZE  256
const wchar_t mapFileName[] = L"myFirstMapping";
 
HANDLE myFileMappingHandle = CreateFileMapping(INVALID_HANDLE_VALUE,NULL,PAGE_READWRITE,0,DATA_SIZE,mapFileName);
if(myFileMappingHandle==NULL)
{
    printf("创建文件映射内核对象失败！");
    CloseHandle(myFileMappingHandle);
    return 0;
}
char* pBuf = (char *)MapViewOfView(myFileMappingHandle,FILE_MAP_ALL_ACCESS,0,0,DATA_SIZE);
while(1)
{
    cout << "output..."  << endl;
    getchar();
    cout << pBuf << endl;
}
UnmapViewOfFile(pICBR);
CloseHandle(myFileMappingHandle);
return 0;
 
 
 
 
 
 
 
 
 
 
 
 
 
3.3、使用共享内存
 
    嗯，共享内存已经理解了，下面开始使用共享内存解决前面提出的问题。
 
    我在ProcessA里面定义了一个函数ICBR，调用set函数得到函数指针，并通过get函数获得函数指针并赋给内存变量（char* pBuf类型的变量），但是当我在ProcessB中获取内存变量的值时发现，获得地址并不正确。而且始终是同一个值。这是为什么呢？
 
    因为虽然两个进程都使用了共享内存，但是就向前面所说的一样，每一个进程在启动时，系统都会给进程分配一块虚拟的内存空间，不同进程的进程空间是独立的，而共享内存的使用仅仅是映射到进程空间，即在进程中得到的地址和实际上共享内存中存贮的地址是不一致的，它反映的仅仅是该进程空间中的内存地址，还是虚拟的。
 
    那还有什么方式能够实现吗？
 
4、其实现的可能方式
 
    通过以上的分析，猜测其实现的可能方式如下：
 
 
     由上图所示，可能采用的方式是：
 
     1）、服务器端与客户端都加载了相同的库，在库中定义了Socket连接，以及回调函数的定义；
 
     2）、服务器端通过库发送了一系列数据：包括消息类型以及参数列表；消息类型用于表明该消息适用于回调函数的，参数列表用于表明向回调函数传递的参数；
 
     3）、当客户端的库收到了Socket消息之后，就调用回调函数函数，同时传参；
 
     4）、客户端的“被回调的函数”执行相关操作。
 
    之所以采用这种方式，而不采用直接用Socket的连接的方式，是因为，它需要把一部分操作给封装起来，同时，还需要向用户暴露一部分的操作，这样用户就能根据指定的框架和指定的参数来执行一些定制化的操作。
 
5、进程间回调函数的调用
 
    在了解进程间回调函数的使用时，除了可以采用上述的间接的方式实现回调函数的间接调用外，好像还可以用COM接口实现同样的功能，未验证，不多做阐述。

entware无法正常安装或路由器重启后环境丢失——梅林entware环境与软件中心“虚拟内存”的冲突
 
由于梅林是基于Entware来安装插件的，因此需要安装entware环境。
 一般而言entware环境需要安装在U盘/移动硬盘中（推荐EXT4文件系统，可以用“分区助手”格式化方式更改挂载盘文件系统类型）
 
# 检查
df -h

Filesystem                Size      Used Available Use% Mounted on
/dev/sda1               916.9G      2.0G    868.4G   0% /tmp/mnt/sda1
 
#安装entware环境
entware-setup.sh
 

 按照官方的流程，在选择安装到U盘后，等待安装即可。安装完成后会在U盘创建entware相关的文件，你就可以安装使用entware插件了。但是在安装过程中经常会出现“cannot create directory ‘XXX’:File exists”这类报错，以至于无法正常安装entware环境。
 
 或者在安装完环境，路由器重启后entware环境丢失。
 
基于上述问题，并经过排查，我发现在固件中的“软件中心”安装了“虚拟内存”后，上述问题将无法避免。
 

 这是由于在“软件中心”安装“虚拟内存”后会导致jffs里的post-mount.sh在安装时不能正确产生，并且“虚拟内存”应用貌似卸载脚本有问题，正常卸载后相关的脚本仍然在jffs，这会致使entware环境重启后opt路径无效。同时本来安装 entware-ng就会创建虚拟内存。
 
因此：
 
情况一：先安装了“软件中心-虚拟内存”，后安装entware环境，entware将无法正常安装
 
情况二：先安装entware环境，后安装了“软件中心-虚拟内存”，路由器重启后entware环境丢失
 
解决方法：
 
还原路由器至出厂值，进入 “系统管理–系统设置”，按图示开启JFFS，重启路由器以初始化JFFS。
 
 
 
 
注意：重启后检查Format JFFS partition at next boot是否已经自动还原为”否“，如果没有，手动调成“否”，否则下次开机会再次还原配置。
 
 
 Info:  /tmp/mnt/sda1 selected.

 Info:  Creating /tmp/mnt/sda1/entware folder...
 * Warning:  Deleting old /tmp/opt symlink...
 Info:  Creating /tmp/opt symlink...
 Info:  Creating /jffs scripts backup...
 tar: removing leading \\'/\\' from member names
 Info:  Modifying start scripts...
 Info:  Starting Entware deployment....

Info: Creating folders...
Info: Deploying opkg package manager...
Downloading /opt/bin/opkg... success!
Downloading /opt/etc/opkg.conf... success!
Downloading /opt/etc/profile... success!
Downloading /opt/etc/init.d/rc.func... success!
Downloading /opt/etc/init.d/rc.unslung... success!
Info: Basic packages installation...
Downloading http://pkg.entware.net/binaries/mipsel/Packages.gz.
Updated list of available packages in /opt/var/opkg-lists/entware-ng.
Installing ldconfig (1.0.12-1) to root...
Downloading http://pkg.entware.net/binaries/mipsel/ldconfig_1.0.12-1_mipselsf.ipk.
Installing findutils (4.5.14-1) to root...
Downloading http://pkg.entware.net/binaries/mipsel/findutils_4.5.14-1_mipselsf.ipk.
Installing libc (1.0.12-1) to root...
Downloading http://pkg.entware.net/binaries/mipsel/libc_1.0.12-1_mipselsf.ipk.
Installing libgcc (4.8.5-1) to root...
Downloading http://pkg.entware.net/binaries/mipsel/libgcc_4.8.5-1_mipselsf.ipk.
Installing libssp (4.8.5-1) to root...
Downloading http://pkg.entware.net/binaries/mipsel/libssp_4.8.5-1_mipselsf.ipk.
Configuring ldconfig.
Configuring libgcc.
Configuring libc.
Configuring libssp.
Configuring findutils.
 
Congratulations! If there are no errors above then Entware-ng is successfully initialized.
 
Found a Bug? Please report at https://github.com/Entware-ng/Entware-ng/issues
 
Type \\'opkg install \\' to install necessary package.

 
关于内存设置处理器个数改动导致的无限系统蓝屏问题
 
废话不多说,本人自百度知道网站转载
网上查到的最好用的方法,因为我们对处理器个数进行了改动,导致系统无法启动,所以我们只需要把我们改动的内存设置进行删除就可以解决问题,网上找到的其他方法别乱用,本人的同事因为那些方法删除了几款新安装的软件,所幸没有重要数据(游戏)丢失awa,不然后果不堪设想......
   
  
 

 
废话不多说,本人自百度知道网站转载
 
看后别忘了给 lenxuekuangmo 大佬点个赞
 
https://zhidao.baidu.com/question/1819534353408687948.html?sort=11&rn=5&pn=0#wgt-answers.
 
网上查到的最好用的方法,因为我们对处理器个数进行了改动,导致系统无法启动,所以我们只需要把我们改动的内存设置进行删除就可以解决问题,网上找到的其他方法别乱用,本人的同事因为那些方法删除了几款新安装的软件,所幸没有重要数据(游戏)丢失awa,不然后果不堪设想…

RAM（Random-access memory）在任何软件开发中都是非常宝贵的资源，移动操作系统由于其物理内存的局限性更是如此。尽管ART（Android Runtime）与Dalvik虚拟机会执行常规的垃圾回收，但这并不意味着可以忽略App中的内存分配与释放。我们应当避免引起内存泄露，如持有静态成员变量而导致无法释放，应当在应用的生命周期回调中释放掉所有的引用。
 
本文主要介绍如何减少App中的内存使用。
 
监控可用内存及内存使用状况
 
Android 框架与Android Studio可以帮助我们来分析和调整App的内存使用，其中Android框架提供了一些API来帮助App在运行时动态减少内存占用，Android Studio包括一些工具来查看内存的使用情况。
 
RAM使用分析工具
 
在优化内存问题之前，需要先找到这些问题，Android Studio及Android SDK提供了几个工具用来分析App中的内存使用：
 
Android Studio中的Memory Monitor
 
该工具可以显示一个会话过程中的内存分配情况，有一个可视化的图形界面，可以看到Java内存随时间的变化情况以及GC事件。当App运行时，可以启动GC操作并且获取Java Heap的快照。该工具的输出可以帮助我们定位哪里容易导致频繁的垃圾回收，从而导致应用程序变慢。
Android Studio中的Allocation Tracker工具
 
该工具记录了一个App的内存分配情况并在分析快照中列出了所有分配的对象。可以使用此工具找到分配过多对象的部分代码。
 
响应回调释放内存
 
不同的Android设备或不同的用户操作会导致不同的内存占用状况，Android系统在遇到内存压力的情况下会发出信号预警，App需要监听这些信号来调整内存的使用。
 
可以使用ComponentCallbacks2 API来监听回调以调整内存使用状态。onTrimMemory()可以允许App监听内存相关的事件，无论App是在前台运行还是在后台运行。下面是一个示例，通过实现Activity的onTrimMemory()方法来监听内存相关的回调。
 
import android.content.ComponentCallbacks2;
// Other import statements ...

public class MainActivity extends AppCompatActivity
    implements ComponentCallbacks2 {

    // Other activity code ...

    /**
     * Release memory when the UI becomes hidden or when system resources become low.
     * @param level the memory-related event that was raised.
     */
    public void onTrimMemory(int level) {

        // Determine which lifecycle or system event was raised.
        switch (level) {

            case ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN:

                /*
                   Release any UI objects that currently hold memory.

                   The user interface has moved to the background.
                */

                break;

            case ComponentCallbacks2.TRIM_MEMORY_RUNNING_MODERATE:
            case ComponentCallbacks2.TRIM_MEMORY_RUNNING_LOW:
            case ComponentCallbacks2.TRIM_MEMORY_RUNNING_CRITICAL:

                /*
                   Release any memory that your app doesn't need to run.

                   The device is running low on memory while the app is running.
                   The event raised indicates the severity of the memory-related event.
                   If the event is TRIM_MEMORY_RUNNING_CRITICAL, then the system will
                   begin killing background processes.
                */

                break;

            case ComponentCallbacks2.TRIM_MEMORY_BACKGROUND:
            case ComponentCallbacks2.TRIM_MEMORY_MODERATE:
            case ComponentCallbacks2.TRIM_MEMORY_COMPLETE:

                /*
                   Release as much memory as the process can.

                   The app is on the LRU list and the system is running low on memory.
                   The event raised indicates where the app sits within the LRU list.
                   If the event is TRIM_MEMORY_COMPLETE, the process will be one of
                   the first to be terminated.
                */

                break;

            default:
                /*
                  Release any non-critical data structures.

                  The app received an unrecognized memory level value
                  from the system. Treat this as a generic low-memory message.
                */
                break;
        }
    }
}
 
onTrimMemory()回调是在Android4.0（API Level 14）添加的，对于之前的版本，可以使用onLowMemory()回调替代，它大致相当于TRIM_MEMORY_COMPLETE事件。
 
检测应该使用多少内存
 
Android为了支持多进程，因此为每个App占用的内存做了限制。由于不同设备的RAM大小不同，因此分配给每个App的Heap大小也会有差异。当App已经到达了特定的Heap限制，如果再进行内存分配的话，就会抛出 OutOfMemoryError异常。
 
为了避免内存溢出，我们可以通过getMemoryInfo()查询当前设备上还有多少可用的内存空间，该方法返回一个ActivityManager.MemoryInfo对象，它包含了设备当前的内存状态，如可用内存、总内存以及内存阈值（当可用内存低于该阈值时，系统就会杀死部分进程）等信息。ActivityManager.MemoryInfo有一个叫做lowMemory的布尔属性，表示设备是否处于低内存状态。
 
下面是一个使用getMemoryInfo()的示例：
 
public void doSomethingMemoryIntensive() {

    // Before doing something that requires a lot of memory,
    // check to see whether the device is in a low memory state.
    ActivityManager.MemoryInfo memoryInfo = getAvailableMemory();

    if (!memoryInfo.lowMemory) {
        // Do memory intensive work ...
    }
}

// Get a MemoryInfo object for the device's current memory status.
private ActivityManager.MemoryInfo getAvailableMemory() {
    ActivityManager activityManager = (ActivityManager) this.getSystemService(ACTIVITY_SERVICE);
    ActivityManager.MemoryInfo memoryInfo = new ActivityManager.MemoryInfo();
    activityManager.getMemoryInfo(memoryInfo);
    return memoryInfo;
}
 
使用高效、内存占用少的代码结构
 
一些Android特性、Java类、代码结构会使用更多的内存，可通过使用更高效的代码结构来节省内存。
 
有节制地使用Service
 
让一个不再需要的Service保持运行是Android开发中最糟糕的内存管理错误之一。如果App需要Service来执行后台任务，需要在它完成任务时终止它，否则可能导致内存泄露。
 
当启动一个Service时，系统会保持该服务所在的进程，这样该服务占用的内存将不能被其他进程使用。同时系统通过LRU Cache缓存的的进程数量也将减少，从而降低进程间切换的效率。当内存紧张或系统无法为当前所运行的Service提供足够的进程时还会发生系统抖动。
 
应当避免使用持久运行的Service，因为它们对内存有持续的需求，建议使用JobScheduler。
 
如果必须使用Service，可以使用IntentService来限制其生命周期，IntentService会在处理完任务之后终止。
 
使用优化的数据容器
 
一些编程语言提供的类可能并未针对移动设备做优化，例如通用的HashMap实现是比较低效的，因为每一个映射都需要一个单独的Entry对象。
 
Android框架提供了一些优化过的数据容器，如SparseArray、SparseBooleanArray和LongSparseArray。例如SparseArray更加高效，是因为它避免了对key及一些value的自动装箱操作。
 
谨慎使用代码抽象
 
开发者经使用抽象来简化编程，因为抽象可以提高代码的灵活性，也更方便维护。但是抽象会带来明显的内存消耗：抽象一般来说需要执行更多的代码、需要更多的时间以及RAM空间来将代码映射到内存。所以如果抽象不能带来明显的好处，应当避免使用代码抽象。
 
例如，枚举占用的内存通常是静态常量的两倍，需要严格避免在Android中使用枚举。
 
使用Nano版本protobufs序列化数据
 
Protocol buffers是Google出品的独立于平台及语言的、可拓展的结构化数据序列化技术，它类似于XML，但更加轻量级、快速、简洁。如果决定使用protobufs来序列化数据，应该在客户端选择使用Nano版本，因为常规版本的protobufs会生成极其冗长的代码，从而导致App端出现各种问题，如内存溢出、APK大小增加、执行速度变慢等。
 
Nano版本Protobufs的相关参考：protobuf readme。
 
避免内存泄露
 
垃圾回收通常不会影响应用的性能，但是短时间内的垃圾收集将会占用帧时间，垃圾回收占用的时间越多，用到其他事情上的时间就越少。
 
通常，内存泄露会导致频繁地垃圾回收事件的发生，在实践中，内存泄露描述了给定时间内分配的临时对象的数量。
 
例如，可能在for循环中分配多个临时对象，或者在View的onDraw()方法中创建多个Paint、Bitmap对象。上述情况下，App会快速创建大量对象，从而迅速消耗掉新生代中的内存，导致GC的发生。
 
我们需要找到内存泄露的地方并进行修复，如将实例化操作移出for循环，不要在onDraw()这种频繁调用的方法中创建对象。
 
移除内存密集型的资源和库
 
代码中的一些资源及Library可能会在我们不知情的情况下吞噬内存。一个APK中，第三方库或者嵌入的资源会影响到App占用的内存总量。可以通过移除冗余的资源、臃肿的组件及不必要的Library来优化内存消耗。
 
减小APK大小
 
通过减小APK的大小可以明显减低App对内存的占用。Bitmap大小、资源、动画帧图像以及第三方库影响APK的大小，Android Studio及Android SDK提供了一些工具用来减少资源大小及外部依赖。
 
更多关于APK的瘦身方案，可参考Reduce APK Size。
 
使用Dagger2实现依赖注入
 
依赖注入框架可以简化代码并为测试及其他配置变化提供适配环境。
 
如果打算在App中使用依赖注入框架的话，建议使用Dagger2。Dagger没有使用反射，它的静态、编译时实现意味着它不需要运行时成本及内存消耗。
 
其他使用反射的依赖注入框架需要扫描代码来寻找注解，这个过程可能需要更多的CPU周期和RAM，并可能导致应用程序启动的明显滞后。
 
谨慎使用外部Library
 
第三方的Library代码可能并非为移动环境所写，当应用到移动客户端时可能导致性能降低。当决定使用一个第三方库时，需要针对移动环境做优化，另外需要分析Library的代码大小及内存占用情况，最后再决定是否应用该Library。
 
哪怕是一些针对移动环境做过优化的Library因为不同的实现也可能导致一些问题，如一种情况使用了Nano版的protobufs，另一种情况使用了Micro版的protobufs，不同的Library实现有可能导致意想不到的问题。
 
尽管Proguard可以移除无效的API及资源，但是它无法移除一个Library大的内部依赖。这些库中的功能可能需要较低的依赖项，例如当使用一个库提供的Activity子类时，可能会引入大量的依赖。
 
需要避免只使用一个库中的有限的功能而引入库的情况，我们不希望引入大量不需要的代码。当决定是否使用一个Library时，尽可能高度匹配我们的需求，否则，可以考虑自己实现。
 
参考文献Manage Your App’s Memory。