当一个 Android APP 需要集成别的地方来的原生库（.so）时，你可能也会跟我一样会有那么几点疑惑：

• 这个 so 用的什么 NDK 版本编译的？会不会跟项目里其它的so 冲突，尤其项目里使用共享 C++ STL的情况下 ANDROID_STL=c++_shared，一个应用不能使用多个 C++ 运行时
• 这个 so 目标 Android API 等级是多少？会不会大于项目的minSdkVersion？
• 这个 so 依赖（链接）其它哪些 so？这些 so 有没有都放进项目里？
• 这个 so 有没有除了用文件哈希之外唯一编号，用来标识崩溃堆栈等？

ps. 本文假定读者有一定 Android Native 开发经验，且理解一些基本的概念。

查看 so 的 NDK 版本信息

通过 readelf 工具查看 Android NDK 编译出来的 so 的 Section headers 里有什么 Android 特有的玩意。

ps. 可以用 ndk-which 找到 NDK 中预编译好的 readelf：

1
2

$ $ANDROID_NDK_HOME/ndk-which --abi arm64-v8a readelf
/~/ndk/21.4.7075529/prebuilt/darwin-x86_64/bin/../../../toolchains/llvm/prebuilt/darwin-x86_64/bin/aarch64-linux-android-readelf

定义一个名为 readelf 的 alias 方便在 Terminal 中调用 aarch64-linux-android-readelf

1
2
3
4
5

$ alias readelf=`$ANDROID_NDK_HOME/ndk-which --abi arm64-v8a readelf`
$ readelf -v
GNU readelf (GNU Binutils) 2.27.0.20170315
Copyright (C) 2016 Free Software Foundation, Inc.
...

以 NDK 中带的 libc++_shared.so 为例，在我本机上路径是$ANDROID_NDK_HOME/toolchains/llvm/prebuilt/darwin-x86_64/sysroot/usr/lib/aarch64-linux-android/libc++_shared.so：

1

$ readelf -WS $ANDROID_NDK_HOME/toolchains/llvm/prebuilt/darwin-x86_64/sysroot/usr/lib/aarch64-linux-android/libc++_shared.so

In this week, I found a great POC to run a pure Java standalone app (command line tool, no apk) on Android. But what about running a standalone application using JNI (with .so files) on Android like this?

Java app with JNI

Imagine there is a Java program that loads the JNI shared native library to run and use some Android APIs :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

package com.example;
import android.os.Build;
import android.util.Log;
public class Helloworld {

    static { System.loadLibrary("hello"); }
    public static native String stringFromJNI();

    public static void main(String[] args) {
        Log.i("@@", "Hello world, " + Build.MANUFACTURER + " "+ Build.MODEL + "!");
        Log.i("@@", stringFromJNI());
        System.out.println(stringFromJNI());
        System.out.println("DONE.");
    }

    public static String getBuildVersion() {
        return Build.VERSION.RELEASE;
    }
}

…the JNI source would be like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

// ... emit codes

JNIEXPORT jstring JNICALL
Java_com_example_Helloworld_stringFromJNI(JNIEnv *env,
                                          jobject thiz)
{
  // ... emit codes
  jmethodID versionFunc = (*env)->GetStaticMethodID(env, clz, "getBuildVersion", "()Ljava/lang/String;");

  jstring buildVersion = (*env)->CallStaticObjectMethod(env, clz, versionFunc);
  const char *version = (*env)->GetStringUTFChars(env, buildVersion, NULL);

  if (!version)
  {
    LOGE("Unable to get version string");
  }
  else
  {
    LOGI("Build Version - %s\n", version);
    (*env)->ReleaseStringUTFChars(env, buildVersion, version);
  }
  (*env)->DeleteLocalRef(env, buildVersion);

  return (*env)->NewStringUTF(env,
                              "Hello from JNI !  Compiled with ABI " ABI ".");
}
// ...

The working directory structure

1
2
3

.
├── Helloworld.java
└── hello-jni.c

Compile and deploy

Now we need to compile both the Java and C sources for Android.

Using javac and dx to compile for a jar file which Android can read:

1
2
3
4
5
6
7

export BUILD_DIR=$PWD/build
export JARFILE=helloworld.jar
export JAVAC_OPTS=-source 1.8 -target 1.8 -cp .:$ANDROID_HOME/platforms/android-30/android.jar
# Compile .java to .class
javac $JAVAC_OPTS -d $BUILD_DIR/classes Helloworld.java
# Convert .class file into a dex file and embedded in a jar file
$ANDROID_HOME/build-tools/30.0.2/dx --output=$BUILD_DIR/$JARFILE --dex ./$BUILD_DIR/classes

Cross-compile the C to Android shared native library via NDK:

1
2
3
4
5
6
7
8
9
10
11
12
13

# Using the prebuilt toolchain diretly
# See https://developer.android.com/ndk/guides/other_build_systems
export ANDROID_NDK_STANDALONE=$ANDROID_NDK_HOME/toolchains/llvm/prebuilt/darwin-x86_64
$ANDROID_NDK_STANDALONE/bin/clang \
    --target=aarch64-none-linux-android21 \
    --gcc-toolchain=$ANDROID_NDK_STANDALONE \
    --sysroot $ANDROID_NDK_STANDALONE/sysroot \
    -L${ANDROID_NDK_STANDALONE}/sysroot/usr/lib \
    -shared -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables \
    -fstack-protector-strong -no-canonical-prefixes -fno-addrsig -fPIC \
    -Wl,-llog \
    -Wl,-soname,libhello.so \
    -o $BUILD_DIR/libhello.so hello-jni.c

The build directory looks like:

1
2
3
4
5
6
7

build
├── classes
│   └── com
│       └── example
│           └── Helloworld.class
├── helloworld.jar
└── libhello.so

Using the adb tool to deploy the helloworld.jar and libhello.so to Android device:

1
2

adb shell mkdir /data/local/tmp/helloworld
adb push $BUILD_DIR/helloworld.jar $BUILD_DIR/libhello.so /data/local/tmp/helloworld/

Run appliation on Android

Run helloworld.jar via app_process on Android:

1
2
3
4
5
6
7
8

adb shell CLASSPATH="/data/local/tmp/helloworld/helloworld.jar" \
    LD_LIBRARY_PATH=/data/local/tmp/helloworld \
    app_process \
    /data/local/tmp/helloworld \
    com.example.Helloworld
# output
Hello from JNI !  Compiled with ABI arm64-v8a.
DONE.

一段很典型的内存泄漏C++ 代码如下：

1
2
3
4
5
6
7
8

int main(int argc, const char **argv)
{
    auto *p = new int(10);
    // other codes ...
    p = nullptr; // leaked
    // ...
    return 0;
}

如何在庞大的 C++ 项目代码中找出类似的问题呢？

libgmalloc

苹果提供了内存调试功能：Guard Malloc，用于debug 内存问题。 man libgmalloc 可以查看更多使用信息。

开启libgmalloc的记录 malloc 调用日志的功能，在执行程序前设置环境变量MallocStackLogging=1，如：

1

MallocStackLogging=1 ./my_tool

日志会写到一个临时文件中：

my_tool(38364) MallocStackLogging: stack logs being written to /private/tmp/stack-logs.38364.103f3a000.my_tool.19n2JH.index
my_tool(38364) MallocStackLogging: recording malloc and VM allocation stacks to disk using standard recorder

需要注意的是，在程序退出时，这个调用日志文件会被自动删除：

my_tool(38364) MallocStackLogging: stack logs deleted from /private/tmp/stack-logs.38364.103f3a000.my_tool.19n2JH.index

所以需要将程序在结束时最好 block 住，以便分析日志文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

#include <iostream>
static void wait_for_input()
{
    std::cout << "Press Enter to exit." << std::endl;
    char b[1];
    std::cin.read(b, 1);
}
int main(int argc, const char **argv)
{
    auto *p = new int(10);
    // other codes ...
    p = nullptr; // leaked
    // ...

    // blocking program for analyzing malloc stack history
    wait_for_input();
    return 0;
}

The leaks Tools

另外，可以直接用 macOS 检测内存泄漏：/usr/bin/leaks （详见：the leaks Tool ）

终端中执行 man leaks 查看使用手册。

leaks 使用方式很简单，指定 pid 即可 attach 到执行中的程序：

1
2
3
4

# pid=38364
leaks $pid --outputGraph=$pid.memgraph
# open memory graph file with Xcode
open $pid.memgraph

结合起来就是：

1. 修改 C++ 程序 main 函数，使其在结束时 block，重编程序
2. 设置环境变量MallocStackLogging=1，执行程序。
3. 在程序执行结束时，亦即 block 时，执行 leaks，保存 memory graph文件
4. ⌃+C 结束程序
5. 使用 Xcode Memory Graph Debugger 打开 memory graph文件，分析内存泄漏

使用 LLDB 远程调试程序

调试分为本地调试和远程调试，iOS app 不管安装在模拟器还是真机，均属于远程调试。

这里简述一下大概的原理。

远程启动 lldb-server ，或者叫 debugserver， 比如使用 ios-deploy 工具开启真机的 debugserver 并将远程端口的 socket 数据转发（或者叫代理）到本机：

1

ios-deploy --id <device_id> --nolldb --json

输出如下：

1
2
3
4
5
6
7
8
9
10

{
  "Event" : "PasswordProtectedStatus",
  "Status" : 0
}{
  "Event" : "MountDeveloperImage",
  "SymbolsPath" : "\/~/Library\/Developer\/Xcode\/iOS DeviceSupport\/15.3.1 (19D52)\/Symbols"
}{
  "Event" : "DebugServerLaunched",
  "Port" : 61115
}

DebugServerLaunched 代表真机上的 debugserver 已启动成功，本地转发端口为 61115

ps. <device_id>是你的真机的id，用命令 ios-deploy --detect 可找到真机的id。

本地启动 lldb，先通过 platform select 对应平台（用于加载系统库和符号），之后通过process connect connect://127.0.0.1:<Port> ，通过本地转发的 socket 连接到远端 debugserver 。

之后通过 lldb 设定目标执行文件及其依赖的模块，及其远端文件路径映射，即可实现远程调试

命令行启动lldb，并输入如下：

1
2
3
4

(lldb) platform select remote-ios
(lldb) file myapp.app
(lldb) process connect connect://127.0.0.1:61115
(lldb) run

这时候你可能会发现报错了： error: No such file or directory (myapp.app)。

因为，对于iOS app 你需要先通过ios-deploy安装到真机上之后，才能走通这个流程：

1
2

# 安装app
ios-deploy --id <device_id> --bundle my.app --json

Benefits of exporting symbols on demand

1. Reduce the amount of time of loading the library.
2. Reduce the size of library.
3. Optimize the code generation.
4. Improve library maintainability and make the library easier to use.
5. Reduce the potential for symbol collision.

List the symbols of shared library

1. nm

https://llvm.org/docs/CommandGuide/llvm-nm.html

nm -gD libxxx.so

2. objdump

https://llvm.org/docs/CommandGuide/llvm-objdump.html

objdump -T libxxx.so

3. readelf

https://man7.org/linux/man-pages/man1/readelf.1.html

readelf -Ws libxxx.so

Option 1. the visibility attribute

1
2
3
4
5
6
7
8
9

#if HAVE_VISIBILITY && BUILDING_LIBFOO
#define LIBFOO_EXPORTED __attribute__((__visibility__("default")))
#elif (defined _WIN32 && !defined __CYGWIN__) && BUILDING_SHARED && BUILDING_LIBFOO
#define LIBFOO_EXPORTED __declspec(dllexport)
#elif (defined _WIN32 && !defined __CYGWIN__) && BUILDING_SHARED
#define LIBFOO_EXPORTED __declspec(dllimport)
#else
#define LIBFOO_EXPORTED
#endif

Compile the code with -fvisibility=hidden flag. This option forces the default visibility of all symbols to be hidden.

1

c++ -I. -fvisibility=hidden -o a.o -c a.cpp

On Windows, using the keyword __declspec(dllexport) to export symbols . See https://learn.microsoft.com/en-us/cpp/build/exporting-from-a-dll-using-declspec-dllexport?view=msvc-170

See more details: https://gcc.gnu.org/wiki/Visibility

Ccache is a compiler cache. 能极大的提升 clean build 编译效率。

github 上有一个为 CMake 提供 Ccache 集成的项目：https://github.com/TheLartians/Ccache.cmake，可以拿过来直接用。

在 cpp 库根目录的 CMakeLists.txt 中添加Ccache.cmake，如：

1
2
3
4
5
6
7
8
9
10
11

cmake_minimum_required(VERSION 3.11.0)

project(myapp)

include(FetchContent)
FetchContent_Declare(Ccache.cmake
    GIT_REPOSITORY    https://github.com/TheLartians/Ccache.cmake.git
    GIT_TAG           origin/master
)
FetchContent_MakeAvailable(Ccache.cmake)

注意：FetchContent 最低要求 CMake 3.11

下载安装 Ccache： https://ccache.dev/download.html ，或者使用 Homebrew 安装：brew install ccache

安装完毕后，在 Android 项目的 build.gradle 中记得加上参数开启次模块功能：-DUSE_CCACHE=ON，并给Ccache 加上选项-DCCACHE_OPTIONS=CCACHE_CPP2=true;CCACHE_SLOPPINESS=time_macros,locale,file_stat_matches：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

plugins {
    id 'com.android.application'
    id 'org.jetbrains.kotlin.android'
}

android {
    namespace 'com.example.myapplication'
    compileSdk 33

    defaultConfig {
        applicationId "com.example.myapplication"
        minSdk 21
        targetSdk 33
        versionCode 1
        versionName "1.0"

        externalNativeBuild {
            cmake {
                arguments "-DUSE_CCACHE=ON", "-DCCACHE_OPTIONS=CCACHE_CPP2=true;CCACHE_SLOPPINESS=time_macros,locale,file_stat_matches"
            }
        }
    }

    externalNativeBuild {
        cmake {
            path file('src/main/cpp/CMakeLists.txt')
            version '3.22.1'

        }
    }

}

开启 ccache stats log，clean build，日志如下表示命中缓存：

# ~/MyApplication/app/src/main/cpp/native-lib.cpp
direct_cache_hit
local_storage_hit
local_storage_read_hit
local_storage_read_hit

ENJOY it.

See https://github.com/yrom/rules_android_cc_test

当一个 APP 随着业务发展，无用功能越堆越多，参与开发的人员队伍越发壮大，代码大爆炸式膨胀，尽管有一系列的例如人工review、代码规范、静态lint检查之类流程上的克制手段，也止不住坍缩的小宇宙往深不可测无法捉摸的黑洞演进。其中，最为令人头疼的问题莫过于“内存泄漏”。

什么是内存泄漏？很常见却也很不起眼，你我随手写段代码就能轻松让一个对象被垃圾回收器（GC）视而不见。

如下面这一段：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

class WidgetA extends StatefulWidget {
  ...
  @override
  _WidgetAState createState() => _WidgetAState();
}

class _WidgetAState extends State<WidgetA> {
  @override
  Widget build(BuildContext context) {
    return GestureDetector(
      onTap: () async {
        var r = await fetchResult();
        if (mounted) {
            setState(() {
                this.result = r;
            });
        }
      },
      child: ...
    );
  }
}

你能在阅读完这段代码的同时找到那个可能被泄漏的对象吗？

没错，context 可能会短时间泄漏。
但，得益于 Dart 积极高效的 GC 策略，这种泄漏已经算是内存泄漏问题中的可以忽略不计的轻症了。（扩展阅读：Flutter: Don’t Fear the Garbage Collector ）

又如这一段代码：

1
2
3
4
5
6
7
8
9
10
11
12
13

class _WidgetAState extends State<WidgetA> {
  @override
  void initState() {
    super.initState();
    Provider.of<AuthStateBloc>(context).stream.listen(onAuthStateChanged);
  }
  void onAuthStateChanged(AuthState state) {
    if (mounted) {
      setState(() {
        this.state = state;
      });
    }
  }

有着丰富的 Flutter 开发经验的你，还是很轻松地就发现了，stream.listen 的返回对象StreamSubscription没有被正确地cancel，导致_WidgetAState 和它的 Element (context) 可能都泄漏了，直到祖节点的 Provider<AuthStateBloc> 被卸载才可能被 GC 回收。

那么回到标题，有没有工具可以程序化的发现内存泄漏呢？

首先要解决的问题是怎么找到内存泄漏点？

Flutter 中的 Image Widget 内置支持 file、network、memory三种形式的文件。
但这几种都只支持常规的经过压缩后的图片文件或二进制数据，如jpg、png、webp文件等。并没有支持原始的rgba 二进制数据。
这里说的原始二进制数据是指图像的每个像素的色彩值所组成的字节数组。一张图有宽x高个像素点，一个像素点的色彩值用32bit来存储，分为4个通道，每个通道各占用8bit，分别为红、绿、蓝、透明度（RGBA），这个数组就是每个像素点色彩值的集合，dart 中一般用Uint8List。

一般情况下，考虑网络传输效率，会采用算法来压缩这个数据，故而你会看到有各种各样的图像压缩算法和文件格式。

你可能会问什么情况下会有需要直接去加载一张图的原始rgba数据？

这里举个简单例子：分块加载图片。将图片解码后，分割成一个个矩形区域，每个矩形就有一个 raw rgba 数据，将其交给Image渲染，这样做可以降低一定的GPU 内存压力，减少出现GPU OOM 或黑屏的概率。（可以参考我的试验项目：https://github.com/yrom/image_pieces）

要支持 raw rgba ，其实很简单，在 dart:ui包下有个方法decodeImageFromPixels可以直接使用，前提是需要有原始的二进制数据、宽、高。

1
2
3
4
5
6
7
8
9
10
11
12
13

import 'dart:ui';

Future<Image> decodeRawRgba(ByteData bytes, int width, int height) {
  final Completer<Image> completer = Completer<Image>();
  decodeImageFromPixels(
    bytes.buffer.asUint8List(),
    width,
    height,
    PixelFormat.rgba8888,
    completer.complete,
  );
  return completer.future;
}

有了这个 Image(dart:ui)对象就可以交给 RawImage Widget 来加载了。但RawImage太过于底层了，能不能只用 Image Widget呢？因为需要复用 LoadingBuilder这些逻辑。

当然可以。查看一下 Image Widget 的构造函数就知道，我们需要一个 ImageProvider，那么问题进一步简化到如何写一个ImageProvider 支持 raw rgba 数据。

实现一个 ImageProvider，我们需要实现 load这个关键方法。以MemoryImage为例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

class MemoryImage extends ImageProvider<MemoryImage> {
  @override
  ImageStreamCompleter load(MemoryImage key, DecoderCallback decode) {
    return MultiFrameImageStreamCompleter(
      codec: _loadAsync(key, decode),
      scale: key.scale,
      debugLabel: 'MemoryImage(${describeIdentity(key.bytes)})',
    );
  }

  Future<ui.Codec> _loadAsync(MemoryImage key, DecoderCallback decode) {
    return decode(bytes);
  }
}

很显然，我们需要想一个方法构造出raw rgba 数据的 Codec。

植树节刚过，上海也结束了细雨绵绵的天气，稍稍放晴，正好周末，前往顾村公园看看樱花开了没。

到了公园，花是没见着，人却许多。

往深处走，这种长着红叶的树，簇着花，密密麻麻，独占风头。百度识图告诉说是“紫叶李”，希望没认错。

粉色的摩天轮，在上面看樱花视野应该不错，想想而已。

还有这种白如凝脂的花，点缀公园，在一众光溜溜的树干里煞是好看。