Android Studio 包含一个名为 Image Asset Studio 的工具，它可以帮我们把自定义图像、系统图标素材、文本字符串自动生成适配系统的应用图标。它为你的应用程序支持的每个像素密度生成一组适当分辨率的图标。Image Asset Studio 将新生成的图标放置res/在项目目录下的特定文件夹中（例如 mipmap/ 或 drawable/）。在运行时，Android 根据运行应用的设备的屏幕密度使用适当的资源。

Image Asset Studio 可帮助您生成以下图标类型：

• 启动图标(Launcher icons)

  • Launcher Icons(Adaptive and Legacy)：AS 3.0后新增，用于自适应启动图标，兼容新旧版系统；
  • Launcher Icons(Legacy only)：用于非自适应的启动图标，仅限旧版系统(Android 8.0之前)；

• 操作栏和选项卡图标(Action bar and tab icons)

• 通知图标(Notification icons)

• TV Banners

• TV Channel lcons

Image Asset 是什么

Image Asset Studio 可帮助您创建不同密度的各种类型的图标，并准确显示它们在项目中的放置位置。以下部分描述了您可以创建的图标类型以及您可以使用的图像和文本输入。

Launcher icons

Image Asset Studio 将启动图标放置在目录中的适当位置res/mipmap-density/。它还创建了适合 Google Play 商店的 512 x 512 像素图像。

Action bar and tab icons

Image Asset Studio 将图标放置在res/drawable-density/目录中的适当位置 。

我们建议操作栏和选项卡图标使用 Material Design 风格。作为 Image Asset Studio 的替代方案，您可以使用 Vector Asset Studio创建操作栏和选项卡图标。矢量绘图适用于简单的图标，可以减少应用程序的大小。

Notification icons

通知是您可以在应用程序的正常 UI 之外向用户显示的消息。Image Asset Studio 将通知图标放置在目录中的适当位置 ：res/drawable-density/

• Android 2.2（API 级别 8）及更低版本的图标放置在目录中。res/drawable-density/
• Android 2.3 到 2.3.7（API 级别 9 到 10）的图标放置在 目录中。res/drawable-density-v9/
• Android 3（API 级别 11）及更高版本的图标放置在目录中。res/drawable-density-v11/
• 如果你的应用程序支持 Android 2.3 到 2.3.7（API 级别 9 到 10），Image Asset Studio 会生成一个灰色版本的图标。后来的 Android 版本使用 Image Asset Studio 生成的白色图标。

Clip Art(剪贴画)

Image Asset Studio 使您可以轻松导入 VectorDrawable 和 PNG 格式的 Google Material 图标：只需从对话框中选择一个图标即可。

Images(图片)

您可以导入自己的图像并根据图标类型对其进行调整。Image Asset Studio 支持以下文件类型：PNG（首选）、JPG（可接受）和 GIF（不可用）。

Text(文本)

Image Asset Studio 允许您以各种字体键入文本字符串，并将其放置在图标上。它将基于文本的图标转换为不同密度的 PNG 文件。你可以使用计算机上安装的字体。

使用 Image Asset Studio

要启动 Image Asset Studio，请按照下列步骤操作：

• 在Project窗口中，选择 Android view。
• 右键单击res文件夹并选择 New > Image Asset。

• Image Asset Studio 中的自适应和旧式图标向导。

继续执行以下步骤：

• 如果您的应用支持 Android 8.0及以上，请创建自适应和旧版启动器图标。
• 如果您的应用支持不高于 Android 7.1 的版本，请仅创建旧版启动器图标。
• 创建操作栏或选项卡图标。
• 创建通知图标。

创建Launcher Icons(Adaptive and Legacy)

打开Image Asset Studio，你可以通过以下步骤添加图标：

• 在Icon Type 中, 选择Launcher Icons (Adaptive and Legacy)。

• 在Foreground Layer选项卡中，选择Asset Type，然后在下方的字段中指定asset：

  • 选择Image以指定图像文件的路径。
  • 选择Clip Art 以从Material Design 图标集中指定一个图像 。
  • 选择Text以指定文本字符串并选择字体。  文章上面有各自选择的教程

• 在Background Layer选项卡中，选择Asset Type，然后在下方的字段中指定Asset。你可以选择一种颜色或指定要用作背景层的image。

• 在Options选项卡中，查看默认设置并确认您要生成 Legacy、Round 和 Google Play Store 图标。

• (可选)更改每个Foreground Layer和Background Layer选项卡的名称和显示设置：

  • Name：如果不想使用默认名称，请键入新名称。如果该资源名称已存在于项目中，如向导底部的错误所示，它将被覆盖。名称只能包含小写字符、下划线和数字。
  • Trim：要调整源资产中图标图形和边框之间的边距，请选择Yes。此操作去除透明空间，同时保留纵横比。要保持源资产不变，请选择No。
  • Color：要更改Clip Art or Text图标的颜色，请单击该字段。在"选择颜色"对话框中，指定一种颜色，然后单击"选择"。新值出现在该字段中。
  • Resize：使用滑块指定比例因子以调整Image, Clip Art, or Text图标的大小。当您指定颜色资源类型时，background layer的此控件将被禁用。

• 单击Next。

• 或者，更改资源目录：选择要添加图像资产的资源源集：src/main/res、 src/debug/res、src/release/res或自定义源集。要定义新的源集，请选择 File > Project Structure > app > Build Types. 例如，您可以定义一个 Beta 源集并创建一个图标版本，在右下角包含文本“BETA”。有关更多信息，

• 单击Finish。Image Asset Studio 将图像添加到不同密度的 mipmap文件夹中。

创建Launcher Icons(Legacy only)

新增：

• Scaling：要适合图标大小，请选择Crop或 Shrink to Fit。使用Crop，图像边缘可以被剪掉，而使用Shrink to Fit，则不会。如果源资产仍然不适合，您可以根据需要调整填充。
• Shape：要在源资产后面放置背景，请选择一个形状，圆形、正方形、垂直矩形或水平矩形之一。对于透明背景，选择None。

• Effect：如果要在正方形或矩形形状的右上角添加狗耳朵效果，请选择DogEar。否则，选择None。

创建Action bar and tab icons

创建Notification icons

其他情况基本大同小异，这里就不多做介绍，浪费大家时间了。

每当我们换工作面试之前,总是会不由自主的刷起面试题,大部分题我们反反复复不知道刷了多少遍,但是今天记住了,等下一次面试的时候又刷着相同的面试题,我就想问在座的各位,Activity的生命周期,你们到底刷过多少遍 [哭笑] 作为一名程序员 把时间浪费在重复性劳动上是极其不能忍受的 因此 为了让自己省去不必要的脑力开销 我给自己总结了一份面试相关的记忆技巧,在这里分享给大家 记忆不是目的 把知识变成自己的才最关键

前提

需要熟悉Activity的生命周期 通过Activity的周期去对比理解和记忆Fragment生命周期

Activity的生命周期

假设你已经非常熟悉Activity的生命周期了,那么接下来咱们看Fragment的生命周期图

Fragment的生命周期

找出他和Activity的相同之处

这部分完全和Activity一模一样 可以不用记忆它,咱们来看不同的地方

其实这部分才是人们最容易搞混和记不住的地方 那咱们来分析一下:

Fragment比Activity多了几个生命周期的回调方法

• onAttach(Activity) 当Fragment与Activity发生关联的时候调用

• onCreateView(LayoutInflater, ViewGroup, Bundle) 创建该F

• onActivityCreated(Bundle) 当Activity的onCreated方法返回时调用

• onDestroyView() 与onCreateView方法相对应，当该Fragment的视图被移除时调用

• onDetach() 与onAttach方法相对应，当Fragment与Activity取消关联时调用 PS：注意：除了onCreateView，其他的所有方法如果你重写了，必须调用父类对于该方法的实现

  这些方法理解起来并不费劲 但是要完美记在脑子里 还是需要花上一番功夫的

  那咱们一个一个来 先从创建开始:

  1.首先 onAttach方法: 和Activity进行关联的时候调用 这个放在第一个 应该好理解

  2.我们知道 Activity在onCreate方法中需要调用setContentVIew()进行布局的加载,那么在Fragment中onCreateView就相当于Activity中的setContentVIew

  3.onActivityCreate是一个额外的方法 为了告诉Fragment当前Activity的创建执行情况 方便Fragment的后续操作

  先后顺序

  已知Fragment是依赖Activity而存在的 它们都有着相同的生命周期方法 那么先调用Activity的还是Fragment的呢? 这里分两种情况

  • 如果是创建 那么先创建Activity 后创建Fragment

  • 如果是销毁 那么先销毁Fragment 后销毁Activity

    网上有很多文章说Activity的onCreate方法在Fragment的onCreateView之后执行,这是不正确的 Fragment一般都是在Activity的onCreate()中创建 要么通过布局加载的方式 要么通过new创建Fragment对象的方式 如果没有Activity的onCreate 哪来的Fragment

    

    总结

    上面的理解好后,咱们再整理记忆一下

    一句话 Activity是老子 Fragment是小子 进门先让老子进 滚蛋先让小子滚 加载布局createView 老子完事吱一声(ActivityCreated)

    希望有帮到你

• JNI：Java Native Interface

1. 系统源码中的 JNI

2. MediaRecorder 框架中的 JNI

MediaRecorder，用于录音和录像。

2.1 Java Framework 层的 MediaRecorder

2.2 JNI 层的 MediaRecorder

2.3 Native 方法注册

Native 方法注册分为静态注册和动态注册，其中静态注册多用于 NDK 开发，而动态注册多用于 Framework 开发。

2.3.1 静态注册

静态注册就是 Java 的 Native 方法通过方法指针来与 JNI 进行关联，如果 Java 的 Native 方法知道它在 JNI 中对应的函数指针，就可以避免上述的缺点，这就是动态注册。

2.3.2 动态注册

3. 数据类型的转换

Java 的数据类型到了 JNI 层就需要转换为 JNI 层的数据类型。

3.1 基本数据类型的转换

3.2 引用数据类型的转换

4. 方法签名

JNI 的方法签名的格式为： （参数签名格式...）返回值签名格式

5. 解析 JNIEnv

• JNIEnv
• Java VM
• JNINativeInterface
• JNIInvokeInterface
• AttachCurrentThread
• DetachCurrentThread

5.1 jfieldID 和 jmethodID

5.2 使用 jfieldID 和 jmethodID

6. 引用类型

• 本地引用（Local References）
• 全局引用（Global References）
• 弱全局引用（Weak Global References）

6.1 本地引用

• FindClass
• DeleteLocalRef

6.2 全局引用

全局引用和本地引用几乎是相反的，它主要有以下特点：

• NewGlobalRef
• DeleteGlobalRef

6.3 弱全局引用

• NewWeakGlobalRef
• DeleteWeakGlobalRef
• IsSameObject

android java层的逆向比较简单，主要就是脱壳 、反编译源码，通过xposed进行hook。
接下来介绍一下，如何去调试hook native层的源码，也就是hook so文件。

应用环境准备

首先，为了方便学习，一上来就hook第三方app难度极大，因此我们自己来创建一个native的项目，自己来hook自己的项目作为学习的练手点。

创建默认的native application

打开as，选择File -> new project -> naive c++ 创建包含c++的原生工程。

默认的native工程，帮我们实现了stringFromJNI方法，那我们就来探索如何hook这个stringFromJNI，并修改他的值。

修改stringFromJNI方法，便于调试

as默认实现的stringFromJNI只有在Activity onCreate的时候调用，为了便于调试，我们增加一个点击事件，每次点击重新调用，并且返回一个随机的值。

java代码增加如下方法：

	binding.sampleText.setOnClickListener {

		Log.e("MainActivity", "stringFromJNI")

		binding.sampleText.text = stringFromJNI()

	}

 

修改native-lib.cpp代码:

#include <jni.h>

#include <string>



using namespace std;



int max1(int num1, int num2);

#define random(x) rand()%(x)



extern "C" JNIEXPORT jstring JNICALL

Java_com_noober_naticeapplication_MainActivity_stringFromJNI(

        JNIEnv* env,

        jobject /* this */) {

    int result = max1(random(100), random(100));

    string hello = "Hello from C++";

    string hello2 = hello.append(to_string(result));

    return env->NewStringUTF(hello2.c_str());

}





int max1(int num1, int num2)

{

    // 局部变量声明

    int result;



    if (num1 > num2)

        result = num1;

    else

        result = num2;



    return result;

}

 

修改的代码很简单，相信不会 c++ 的同学也看得懂，就是随机输入两个数，取其中小的那一位拼接在“Hello from C++”后面，并返回。主要目的是让我们每次点击的时候，返回内容可以动态。

修改androidManifest文件

在application中增加下面两行代码：

    android:extractNativeLibs="true"

    android:debuggable="true"

    

 

android:debuggable: 让我们可以对apk进行调试，如果是第三方已经打包好了app，我们需要对其manifest文件进行修改，增加这行代码，然后进行重打包，否则无法进行so的调试。

android:extractNativeLibs: 很多人在进行调试的时候发现ida pro一切正常，但是却一直没有加载我们的libnative -lib.so, 是因为缺少这行代码。如果不加，可能会使so直接自身的base.apk进行加载，导致ida pro无法识别。

修改CMakeLists.txt

在cmakelists中增加下面代码。so文件生成路径，这样编译之后就可以在main-cpp-jniLibs目录下找到生产的so文件。

set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${PROJECT_SOURCE_DIR}/jniLibs/${ANDROID_ABI})

 

编译运行，获取so

上述工作做好之后，直接编译运行，同时会生成4个so文件,我们取手机运行时对应使用的那个so进行hook。
我这边使用的是arm64-v8a目录下的libnative-lib.so。

hook环境准备

• 系统：windows 10 64位
• 工具ida pro 7.5
• java8环境
• android sdk tools和adb工具
• arm64-v8a目录下的libnative-lib.so
• android 真机

使用ida pro进行hook

adb与手机的准备

1. 首先找到ida pro的dbgsrv文件夹,里面有很多server文件

64代表的含义是64位，否则就是32位，我们根据我们需要调试的so的指令集进行选择。因为我这边调试的是arm64-v8a，这里我们就选择android_server64的文件。连接真机后，打开cmd，输入以下指令：

adb push "\\Mac\Home\Desktop\IDA PRO 7.5 (x86, x64, ARM, ARM64)\dbgsrv\android_server64"  /data/local/tmp

 

2. 如果是真机，则需要输入su，模拟器不需要

    #真机
   
    su
   
    

3. 修改权限

    chmod 777 /data/local/tmp/android_server64
   
    

4. 运行

    /data/local/tmp/android_server64
   
    

5. 新打开一个cmd，在本地执行adb 做端口转发

    adb forward tcp:23946 tcp:23946
   
    

ida pro的工作准备

1. 打开ida pro，因为我们的so是64位的，所以打开ida64.exe。点击new，选择libnative-lib.so。

2. 选择debugger-select debugger

3. 选择Remote ARM Linux/Android debugger

4. 点击debugger-Debugger options

勾选Suspend on process entry point ，也就是在断点处进行挂起暂停

5. 点击debugger-Process options

填写hostname为localhost

6. 找到exports标签，ctrl+f，搜索java关键字，找到我们要hook的函数。

7. 双击打开，按F5，进行反汇编操作。这样就可以看到反汇编之后的c ++代码了。然后我们随便加上断点进行调试。

8. 执行adb命令，进入调试状态，也就是打开我们要调试的app的启动activity，我这边如下：

    adb shell am start -D -n com.noober.naticeapplication/com.noober.naticeapplication.MainActivity
   
    

9. 点击debugger-Attach to process

选择我们需要调试的进程。

10. adb 执行如下命令，关联运行的so与本地要调试的so。

    jdb -connect com.sun.jdi.SocketAttach:hostname=127.0.0.1,port=8700
    
     

11. 此时ida卡在libc.so的位置，点击继续执行，弹出如下界面，关联so到本地，选择same。如果没有弹出则需要通过快捷键ctrl+s, 打开所有已经加载的so，找到我们的libnative-lib.so

12. 此时就会自动进入断点。

使用ida pro进行调试

ida pro 常用调试快捷键

• F2下断点
• F7单步步入
• F8单步步过
• F9执行到下个断点
• G调到函数地址
• Debugger-debugger windows-locals 查看变量

进行调试

1. 简单分析反汇编代码，我们发现返回值是v5，通过f8，执行到return的上一行。打开locals, 获取所有变量的值。

2. 复制bytes的地址0x7FFE2CDEB9LL，切换到代码界面，输入快捷键g，输入地址跳转。这样我们便从内存中得到了数据结果，可以看出本次返回的值就是"Hello from c++89"

3. 当然我们也可以在locals中直接修改值，这样就达到了我们hook so动态修改数据的目的。

Android 自动化交互可以代替人工完成重复性的工作，包括通过自动操作 App 进行黑盒测试和第三方 App 的自动运行。常见的自动化交互包含启动 App、view 的点击、拖拽和文本输入等。随着 App 安防能力的提升，要想实现完整流程的自动化交互变的越来越困难，本文主要探讨目前常见的自动化交互方案以及不同方案的优劣和应用场景。

1 传统执行脚本方案

ADB 是 Google 提供的能够和 Android 设备进行交互的命令行工具，我们可以编写脚本按照事先设计好的顺序，一个一个执行各个事件。ADB 执行操作需要事先获取界面元素的坐标（获取坐标方法可以利用 uiautomator 或者 dump xml 的方法，这里不是讨论的重点），然后把坐标传入作为命令行参数。

adb shell input tap 100 500

 

上面命令是模拟点击屏幕坐标为（100, 500）处的控件。

adb shell input swipe 100 500 200 600

 

上面命令是模拟手指在屏幕上向右下方滑动的一个操作。

adb shell input keyevent "KEYCODE_BACK"

 

上面命令模拟返回按键的点击。

一次完整的自动化交互流程可由上面一系列命令顺序执行。

ADB 脚本方式的优点

1. 实现简单，只需要获取目标元素的坐标等简单信息即可完成相关操作
2. 可以实现对 webview 的自动化交互\

ADB 脚本方式的缺点

1. 灵活度不够，依赖于写死的坐标，App 界面变更引起的 view 位置变换会让脚本中相关命令无法执行，需要重新分析页面坐标
2. 需要建立 ADB 链接或套接字链接，交互过程中网络状况的变化会影响自动化交互效果\

ADB 脚本方式应用场景

1. 交互简单、迭代频率低，安防级别比较低的 App
2. webview 页面，flutter 开发的 App

2 Android 原生方法实现自动化交互

我们可以借助各种插件化框架来控制 App 页面的界面元素，其中一种思路就是在插件中借助 ActivityLifecycleCallbacks 来监听各个 activity 的生命周期。

public class MyApplication extends Application {

    private static final String TAG = "MyApplication";

    //声明一个监听Activity们生命周期的接口

    private ActivityLifecycleCallbacks activityLifecycleCallbacks = new ActivityLifecycleCallbacks() {

        /**

         * application下的每个Activity声明周期改变时，都会触发以下的函数。

         */

        @Override

        public void onActivityCreated(Activity activity, Bundle savedInstanceState) {

            //如何区别参数中activity代表你写的哪个activity。

            if (activity.getClass() == MainActivity.class)

                Log.d(TAG, "MainActivityCreated.");

            else if(activity.getClass()== SecondActivity.class)

                Log.d(TAG, "SecondActivityCreated.");

        }



        @Override

        public void onActivityStarted(Activity activity) {

            Log.d(TAG, "onActivityStarted.");

        }



        @Override

        public void onActivityResumed(Activity activity) {

            Log.d(TAG, "onActivityResumed.");

        }



        @Override

        public void onActivityPaused(Activity activity) {

            Log.d(TAG, "onActivityPaused.");

        }



        @Override

        public void onActivityStopped(Activity activity) {

            Log.d(TAG, "onActivityStopped.");

        }



        @Override

        public void onActivitySaveInstanceState(Activity activity, Bundle outState) {

        }



        @Override

        public void onActivityDestroyed(Activity activity) {

            Log.d(TAG, "onActivityDestroyed.");

        }

    };



    @Override

    public void onCreate() {

        super.onCreate();

        //注册自己的Activity的生命周期回调接口。![Alt text](./WechatIMG59.png)



        registerActivityLifecycleCallbacks(activityLifecycleCallbacks);

    }



    @Override

    public void onTerminate() {

        //注销这个接口。

        unregisterActivityLifecycleCallbacks(activityLifecycleCallbacks);

        super.onTerminate();

    }

}

 

监听到 activity 的活动后，可以借助 uiautomator 分析 activity 界面元素的 viewId 以及属性，不同情况的界面 view 可以采用不同的自动化方法。

2.1 简单 view 的处理方式

如下图： 

像这类 view，可以直接获取到 resource id ，并且确认可点击属性为 true，操作方式比较简单, 可以在监听到的 activity 生命周期中执行如下操作：

int fl_btn = activity.getResources().getIdentifier("dashboard_title",         "id", "com.android.settings");

View v =  activity.findViewById(fl_btn);



v.performClick();

 

2.2 隐藏属性的 view 的处理方式

在一些对 view 的属性进行隐藏，特别是利用 React Native 等混合开发的页面，上面的方法不再生效，如下图所示的 view： 

如图，选中的 viewgroup 及其子 view 的 clickable 属性均为 false，并且无法获取到 view 的 resource id，这时候可以利用图中 dump 出的布局信息，借助 Xpath 元素定位工具来获取到界面的 view，由于这些 view 的点击属性为 false，因此通过调用 performClick 来实现点击的方法已经无效，此时考虑在 click 更底层的与触摸事件传递相关的比较重要的类：MotionEvent, MotionEvent 可以仿真几乎所有的交互事件，包括点击，滑动，双指操作等。以单击为例：

    private void simulateClick(View view, float x, float y) {

        long time = SystemClock.uptimeMillis();//必须是 SystemClock.uptimeMillis()。



        MotionEvent downEvent = MotionEvent.obtain(time, time, MotionEvent.ACTION_DOWN, x, y, 0);



        time += 500;



        MotionEvent upEvent = MotionEvent.obtain(time, time, MotionEvent.ACTION_UP, x, y, 0);



        view.onTouchEvent(downEvent);

        view.onTouchEvent(upEvent);

    }

 

如果是滑动操作，可以在起始位置中间添加若干 ACTION_MOVE 类型的 MotionEvent. 综上所述，借助系统原生方法时间交互自动化的优缺点大致如下：

借助插件框架实现自动化交互的优点

1. 可维护性强，因为可以直接获取到界面的 view 对象，因此即使页面布局发生变化，只要 view 还存在，就不需要对代码进行修改
2. 仿真效果更好，比脚本方式更接近真人操作

借助插件框架实现自动化交互的不足

1. 对 webview、flutter 框架 App 支持不好

应用场景

1. 版本迭代频繁的 App
2. 非 flutter 框架开发的 App

上面分析了两种常用的模拟真实用户进行自动化操作的方法，脚本方式和调用原生方法的方式，这两种方法基本上可以完成简单的交互流程，在此基础上，我们还可以去深究一些更深层次的交互实现，比如自动化过各种验证等，也可以基于这两种方法来完成。

内存优化

基础知识回顾（看前面文章JVM详解）：

jVM内存模型，除了程序计数器以外，别的都会出现 OOM。

JAVA对象的生命周期，创建、运行、死亡。
GC对象可回收的判定：可达性分析。GC root（除了堆里的对象，虚拟机栈里的引用、方法区里的引用）。
强软弱虚四种引用。
GC回收算法：复制算法、标记清楚算法、标记整理算法。

App内存组成以及限制

Android给每个App分配一个VM，让App运行在dalvik上，这样即使App崩溃也不会影响到系统。系统给VM分配了一定的内存大小，App可以申请使用的内存大小不能超过此硬性逻辑限制，就算物理内存富余，如果应用超出VM最大内存，就会出现内存溢出crash。

由程序控制操作的内存空间在heap上，分java heapsize和native heapsize

• Java申请的内存在vm heap上，所以如果java申请的内存大小超过VM的逻辑内存限制,就会出现内存溢出的异常。
• native层内存申请不受其限制,native层受native process对内存大小的限制

总结：
app运行在虚拟机上，手机给虚拟机分配内存是固定的，超出就oom。
分配的内存大部分都是在堆上。分为java堆和native层的堆。
java层的堆超过VM给的就oom。理论上native层无限制，但是底层实现native process对内存大小是有限制的。

查看系统给App分配的内存限制

不同手机给app分配的内存大小其实是不一样大的。

1. 通过cmd指令 adb shell cat /system/build.prop

2. 通过代码 activityManager.getMemoryClass();

ActivityManager activityManager =(ActivityManager)context.getSystemService(Context.ACTIVITY_SERVICE)



activityManager.getMemoryClass();//以m为单位

 

这些限制其实在 AndroidRuntime.cpp的startVm里，我们改不了，手机厂商可以改

Android低内存杀进程机制

默认五个级别：空进程、后台进程、服务进程、可见进程、前台进程
所以在保活里有一个做法就是给app提升优先级，给他整成前台、可见这样的。

AMS里有一个oom_adj，会给各个进程进行评分，数字越大越容易被回收，前台进程是0，系统进程是负数，别的是正数。 

内存三大问题

1、内存抖动
profiler -> 内存波动图形呈 锯齿张、GC导致卡顿。
原因是内存碎片很严重。因为android虚拟机的GC算法是标记清楚算法，所以频繁的申请内存、释放内存会让内存碎片化很严重，连续的内存越来越少，让GC非常频繁，导致了内存抖动。案例：在自定义View onDraw()里new对象

2、内存泄漏 在当前应用周期内不再使用的对象被GC Roots引用，导致不能回收，使实际可使用内存变小。内存泄露如果越来越严重的话，最终会导致OOM。案例：context被长生命周期的东西引用。没有释放listener

3、内存溢出 即OOM，OOM时会导致程序异常。Android设备出厂以后，java虚拟机对单个应用的最大内存分配就确定下来了，超出这个值就会OOM。案例：加载大图、内存泄露、内存抖动

除了程序计数器以外 别的JVM部分都会OOM

常见分析工具

1. Memory Analyzer Tools --- MAT

MAT是Eclipse下的内存分析工具。
用法：用cmd指令或者android studio 自带的profiler 截取一段数据，然后下载下来。得到一个.hprof

然后用AMT打开，就能看预测泄露地方，有一个图表，基本没用。还有看哪个线程调用这个对象、深浅堆等等。挺难用的。

2. android studio自带的profiler

谷歌官网：developer.android.google.cn/studio/prof…

官网超级详细，还有视频，直接看官网的就行。 

选中一段区域，就能查看这段区域内存被具体哪个对象用了多少等等。
我感觉还是用来看大势的，大的内存上涨、下落、起伏图。

3. LeakCanary

超级推荐LeakCanary！！！永远滴神
具体内存泄露的检测，细节还得用LeakCanary。

集成：
build.gradle里添，跟集成第三方一样。
debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.3'

然后直接跑APP，跑完以后一顿点，点完以后会给推送。写了发现几个对象有泄露。点一下推送蓝会自动下载下来。

比如这就是我的问题，期初我认为是activity的context没有释放，其实是在dialog里使用了动画animation，但是动画的listener没有释放。 

Android内存泄漏常见场景以及解决方案

1、资源性对象未关闭
对于资源性对象不再使用时，应该立即调用它的close()函数，将其关闭，然后再置为null。例如Bitmap 等资源未关闭会造成内存泄漏，此时我们应该在Activity销毁时及时关闭。

2、注册对象未注销
例如BraodcastReceiver、EventBus未注销造成的内存泄漏，我们应该在Activity销毁时及时注销。

3、类的静态变量持有大数据对象
尽量避免使用静态变量存储数据，特别是大数据对象，建议使用数据库存储。

4.单例造成的内存泄漏
优先使用Application的Context，如需使用Activity的Context，可以在传入Context时使用弱引用进行封 装，然后，在使用到的地方从弱引用中获取Context，如果获取不到，则直接return即可。

5、非静态内部类的静态实例
该实例的生命周期和应用一样长，这就导致该静态实例一直持有该Activity的引用，Activity的内存资源 不能正常回收。此时，我们可以将该内部类设为静态内部类或将该内部类抽取出来封装成一个单例，如 果需要使用Context，尽量使用Application Context，如果需要使用Activity Context，就记得用完后置 空让GC可以回收，否则还是会内存泄漏。

6、Handler临时性内存泄漏
Message发出之后存储在MessageQueue中，在Message中存在一个target，它是Handler的一个引用，Message在Queue中存在的时间过长，就会导致Handler无法被回收。如果Handler是非静态的， 则会导致Activity或者Service不会被回收。并且消息队列是在一个Looper线程中不断地轮询处理消息， 当这个Activity退出时，消息队列中还有未处理的消息或者正在处理的消息，并且消息队列中的Message 持有Handler实例的引用，Handler又持有Activity的引用，所以导致该Activity的内存资源无法及时回 收，引发内存泄漏。解决方案如下所示：
1、使用一个静态Handler内部类，然后对Handler持有的对象（一般是Activity）使用弱引用，这 样在回收时，也可以回收Handler持有的对象。
2、在Activity的Destroy或者Stop时，应该移除消息队列中的消息，避免Looper线程的消息队列中 有待处理的消息需要处理
（Handler那篇有讲）

7、容器中的对象没清理造成的内存泄漏
在退出程序之前，将集合里的东西clear，然后置为null，再退出程序

8、WebView
WebView都存在内存泄漏的问题，在应用中只要使用一次WebView，内存就不会被释放掉。我们可以为 WebView开启一个独立的进程，使用AIDL与应用的主进程进行通信，WebView所在的进程可以根据业 务的需要选择合适的时机进行销毁，达到正常释放内存的目的。

9、使用ListView时造成的内存泄漏
在构造Adapter时，使用缓存的convertView。

10、Bitmap
80%的内存泄露都是Bitmap造成的，Bitmap有Recycle（）方法，不用时要及时回收。但是如果遇到要用Bitmap直接用Glide就完事了，自己写10有8.9得出错。

启动速度优化

app启动流程

①点击桌面App图标，Launcher进程采用Binder IPC向AMS进程发起startActivity请求；

②AMS接收到请求后，向zygote进程发送创建进程的请求；

③Zygote进程fork出新的子进程，即App进程；

④App进程，通过Binder IPC向AMS进程发起attachApplication请求；

⑤AMS进程在收到请求后，进行一系列准备工作后，再通过binder IPC向App进程发送scheduleLaunchActivity请求；

⑥App进程的binder线程（ApplicationThread）在收到请求后，通过handler向主线程发送LAUNCH_ACTIVITY消息；

⑦主线程在收到Message后，通过反射机制创建目标Activity，并回调Activity.onCreate()等方法。

⑧到此，App便正式启动，开始进入Activity生命周期，执行完onCreate/onStart/onResume方法，UI渲染结束后便可以看到App的主界面。

启动状态

APP启动状态分为：冷启动、热启动、温启动。
冷启动：什么都没有，点击桌面图标，启动App。Zygote fork进程...
热启动：app挂在后台，在点击图标切换回来。
温启动：两者之间。

启动耗时统计

1.打log。displayed。有显示

2.cmd命令 adb shell am start -S -W +包名+Activity名

CPU Profile

具体怎么优化呢？得用到Android Studio自带的分析的工具CPU Profile。

1. 打开CPU Profile，trace java Methods

2. 跑项目，截开始的那段cpu运行图，得到启动的数据

3. 得到具体哪个方法执行时间的情况图

Call Chart：黄、蓝、绿三色。黄色=系统、绿色=自己的、蓝色=第三方。自上而下表示调用顺序。越长就说明执行的时间越长。

如：我发现极光的初始化时间还是挺长的，如果要优化可以将极光延迟初始化。

还有onCreat占用时间也挺长，主要在setContentView里，看看能不能将布局优化一下。

Flame Chart：跟Call Chart差不多，就是反过来的图，又称火焰图。 

Top Down Tree：这个就不是图标了，是方法直接的调用关系，每个方法的调用时间。一直往下点，可以找到占用时间较长的，可以优化的地方。从上往下的调用。

Bottom Up Tree：跟top反向从下往上。

启动白屏

在主题里配置一个背景。

StrictMode严苛模式

可以在application里配置严苛模式，这样不规范的操作就会有log提示，或者闪退。

启动优化的点

1). 合理的使用异步初始化、延迟初始化、懒加载机制。
2). 启动过程避免耗时操作，如数据库 I/O操作不要放在主线程执行。
3). 类加载优化：提前异步执行类加载。
4). 合理使用IdleHandler进行延迟初始化。
5). 简化布局

卡顿优化

分析工具

1. Systrace是Android提供的一款工具，需要运行在Python环境下。

配置：http://www.jianshu.com/p/e73768e66…

Systrace主要是分析掉帧的情况的。帧：android手机一般都是60帧，所以1帧的时间=1000毫秒/60=16.6毫秒。也就是android手机16.6毫秒刷新一次，超过这个数就是掉帧了

会有三色球，绿=正常，黄=一点不正常，红=掉帧严重。
少几个没啥事，大面积的出现红、黄，就需要研究为啥掉帧了。 

可以看上面有一条CPU的横轴，绿色=正在执行，蓝色=等待，可以运行。紫色=休眠。白色=休眠阻塞。如果是出现了紫色就说明IO等耗时操作导致掉帧。如果紫+蓝比较多，说明cpu拿不到时间片，cpu很忙。

CPU Profile

这个就能看那个方法运行多少时间等，所以可以直接用android studio自带的分析。

一般是在top down里一直点，耗时较多的，然后点到自己熟悉的地方，挨个分析。
这是一个漫长的耗时的过程，可能找半天只找到几个地方能优化，然后每个几毫秒，加起来也没有直观的变快，但是性能优化就是这样的一个过程，积少成多。
如：我经过查找就发现adapter的 notifyDataSetChanged因为不小心，有些地方多次调用了。
甚至还有没有在线程进行io操作。 

布局优化

经过上面的一顿操作，发现占时间大块的少不了setContentView。说明布局渲染视图还是挺费时的。

减少层级

自定义Viewmeasure、layout、draw这三个过程，都需要对整个视图树自顶向下的遍历，而且很多情况都会多次触发整个遍历过程（Linearlayout 的 weight等），所以如果层级太深，就会让整个绘制过程变慢，从而造成启动速度慢、卡顿等问题。
而onDraw在频繁刷新时可能多次触发，因此 onDraw更不能做耗时操作，同时需要注意内存抖动。对于布局性能的检测，依然可以使用systrace与traceview按 照绘制流程检查绘制耗时函数。

工具Layout Inspector
DecorView开始。content往下才是自己写的布局。

重复的布局使用include。
一个布局+到另一个上，如果加上以后，有两一样的ViewGroup，可以把被加的顶层控件的ViewGroup换成merge
ViewStub：失败提示框等。需要展示的时候才创建，放在那不占位置。

过度渲染

一块区域内（一个像素），如果被绘制了好几次，就是过度渲染。
过度绘制不可避免，但是应该尽量的减少。
手机->开发者模式->GPU 过度绘制 打开以后能看到不同颜色的块，越红就说明过度绘制的越严重。对于严重的地方得减少过度绘制。

1.移除布局中不需要的背景。
2.降低透明度。
3.使视图层次结构扁平化。

布局加载优化

异步加载布局，视情况而用。

implementation"androidx.asynclayoutinflater:asynclayoutinflater:1.0.0"

new AsyncLayoutInflater(this)

.inflate(R.layout.activity_main, null, new AsyncLayoutInflater.OnInflateFinishedListener() {

@Override

public void onInflateFinished(@NonNull View view, int resid, @Nullable ViewGroup parent) {

setContentView(view);

//......

}

});

SDWebImage的使用:

 CGImageRef imageRef = image.CGImage;

        // device color space

        CGColorSpaceRef colorspaceRef = SDCGColorSpaceGetDeviceRGB();

        BOOL hasAlpha = SDCGImageRefContainsAlpha(imageRef);

        // iOS display alpha info (BRGA8888/BGRX8888)

        CGBitmapInfo bitmapInfo = kCGBitmapByteOrder32Host;

        bitmapInfo |= hasAlpha ? kCGImageAlphaPremultipliedFirst : kCGImageAlphaNoneSkipFirst;

        

        size_t width = CGImageGetWidth(imageRef);

        size_t height = CGImageGetHeight(imageRef);

        

        // kCGImageAlphaNone is not supported in CGBitmapContextCreate.

        // Since the original image here has no alpha info, use kCGImageAlphaNoneSkipLast

        // to create bitmap graphics contexts without alpha info.

        CGContextRef context = CGBitmapContextCreate(NULL,

                                                     width,

                                                     height,

                                                     kBitsPerComponent,

                                                     0,

                                                     colorspaceRef,

                                                     bitmapInfo);

        if (context == NULL) {

            return image;

        }

        

        // Draw the image into the context and retrieve the new bitmap image without alpha

        CGContextDrawImage(context, CGRectMake(0, 0, width, height), imageRef);

        CGImageRef imageRefWithoutAlpha = CGBitmapContextCreateImage(context);

        UIImage *imageWithoutAlpha = [[UIImage alloc] initWithCGImage:imageRefWithoutAlpha scale:image.scale orientation:image.imageOrientation];

        CGContextRelease(context);

        CGImageRelease(imageRefWithoutAlpha);

        

        return imageWithoutAlpha;

//

//  YYFPSLabel.m

//  YYKitExample

//

//  Created by ibireme on 15/9/3.

//  Copyright (c) 2015 ibireme. All rights reserved.

//



#import "YYFPSLabel.h"

//#import <YYKit/YYKit.h>

#import "YYText.h"

#import "YYWeakProxy.h"



#define kSize CGSizeMake(55, 20)



@implementation YYFPSLabel {

    CADisplayLink *_link;

    NSUInteger _count;

    NSTimeInterval _lastTime;

    UIFont *_font;

    UIFont *_subFont;

    

    NSTimeInterval _llll;

}



- (instancetype)initWithFrame:(CGRect)frame {

    if (frame.size.width == 0 && frame.size.height == 0) {

        frame.size = kSize;

    }

    self = [super initWithFrame:frame];

    

    self.layer.cornerRadius = 5;

    self.clipsToBounds = YES;

    self.textAlignment = NSTextAlignmentCenter;

    self.userInteractionEnabled = NO;

    self.backgroundColor = [UIColor colorWithWhite:0.000 alpha:0.700];

    

    _font = [UIFont fontWithName:@"Menlo" size:14];

    if (_font) {

        _subFont = [UIFont fontWithName:@"Menlo" size:4];

    } else {

        _font = [UIFont fontWithName:@"Courier" size:14];

        _subFont = [UIFont fontWithName:@"Courier" size:4];

    }

    // 创建CADisplayLink并添加到主线程的RunLoop中

    _link = [CADisplayLink displayLinkWithTarget:[YYWeakProxy proxyWithTarget:self] selector:@selector(tick:)];

    [_link addToRunLoop:[NSRunLoop mainRunLoop] forMode:NSRunLoopCommonModes];

    return self;

}



- (void)dealloc {

    [_link invalidate];

}



- (CGSize)sizeThatFits:(CGSize)size {

    return kSize;

}



//刷新回调时去计算fps

- (void)tick:(CADisplayLink *)link {

    if (_lastTime == 0) {

        _lastTime = link.timestamp;

        return;

    }

    

    _count++;

    NSTimeInterval delta = link.timestamp - _lastTime;

    if (delta < 1) return;

    _lastTime = link.timestamp;

    float fps = _count / delta;

    _count = 0;

    

    CGFloat progress = fps / 60.0;

    UIColor *color = [UIColor colorWithHue:0.27 * (progress - 0.2) saturation:1 brightness:0.9 alpha:1];

    

    NSMutableAttributedString *text = [[NSMutableAttributedString alloc] initWithString:[NSString stringWithFormat:@"%d FPS",(int)round(fps)]];

    [text yy_setColor:color range:NSMakeRange(0, text.length - 3)];

    [text yy_setColor:[UIColor whiteColor] range:NSMakeRange(text.length - 3, 3)];

    text.yy_font = _font;

    [text yy_setFont:_subFont range:NSMakeRange(text.length - 4, 1)];

    

    self.attributedText = text;

}



@end

// 2.RunLoop 即将触发 Timer 回调。

__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeTimers);

// 3.RunLoop 即将触发 Source0 (非port) 回调。

__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeSources);

// 4.RunLoop 触发 Source0 (非port) 回调。

sourceHandledThisLoop = __CFRunLoopDoSources0(runloop, currentMode, stopAfterHandle)

// 5.执行被加入的block等Source1事件

__CFRunLoopDoBlocks(runloop, currentMode);



// 6.RunLoop 的线程即将进入休眠(sleep)。

__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeWaiting);



// 7.调用 mach_msg 等待接受 mach_port 的消息。线程将进入休眠, 直到被下面某一个事件唤醒。

__CFRunLoopServiceMachPort(waitSet, &msg, sizeof(msg_buffer), &livePort)





// 进入休眠





// 8.RunLoop 的线程刚刚被唤醒了。

__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopAfterWaiting



// 9.1.如果一个 Timer 到时间了，触发这个Timer的回调

__CFRunLoopDoTimers(runloop, currentMode, mach_absolute_time())



// 9.2.如果有dispatch到main_queue的block，执行bloc

 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(msg);

 

 // 9.3.如果一个 Source1 (基于port) 发出事件了，处理这个事件

__CFRunLoopDoSource1(runloop, currentMode, source1, msg);



// 10.RunLoop 即将退出

__CFRunLoopDoObservers(rl, currentMode, kCFRunLoopExit);

#pragma mark - 注册RunLoop观察者



//在主线程注册RunLoop观察者

- (void)registerMainRunLoopObserver

{

    //监听每个步凑的回调

    CFRunLoopObserverContext context = {0, (__bridge void*)self, NULL, NULL};

    self.runLoopObserver = CFRunLoopObserverCreate(kCFAllocatorDefault,

                                                   kCFRunLoopAllActivities,

                                                   YES,

                                                   0,

                                                   &runLoopObserverCallBack,

                                                   &context);

    CFRunLoopAddObserver(CFRunLoopGetMain(), self.runLoopObserver, kCFRunLoopCommonModes);

}



//观察者方法

static void runLoopObserverCallBack(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info)

{

    self.runLoopActivity = activity;

    //触发信号，说明开始执行下一个步骤。

    if (self.semaphore != nil)

    {

        dispatch_semaphore_signal(self.semaphore);

    }

}



#pragma mark - RunLoop状态监测



//创建一个子线程去监听主线程RunLoop状态

- (void)createRunLoopStatusMonitor

{

    //创建信号

    self.semaphore = dispatch_semaphore_create(0);

    if (self.semaphore == nil)

    {

        return;

    }

    

    //创建一个子线程，监测Runloop状态时长

    dispatch_async(dispatch_get_global_queue(0, 0), ^

    {

        while (YES)

        {

            //如果观察者已经移除，则停止进行状态监测

            if (self.runLoopObserver == nil)

            {

                self.runLoopActivity = 0;

                self.semaphore = nil;

                return;

            }

            

            //信号量等待。状态不等于0，说明状态等待超时

        //方案一->设置单次超时时间为500毫秒

            long status = dispatch_semaphore_wait(self.semaphore, dispatch_time(DISPATCH_TIME_NOW, 500 * NSEC_PER_MSEC));

            if (status != 0)

            {

                if (self.runLoopActivity == kCFRunLoopBeforeSources || self.runLoopActivity == kCFRunLoopAfterWaiting)

                {

                    ...

                    //发生超过500毫秒的卡顿，此时去记录调用栈信息

                }

            }

        /*

       //方案二->连续5次卡顿50ms上报

        long status = dispatch_semaphore_wait(semaphore, dispatch_time(DISPATCH_TIME_NOW, 50*NSEC_PER_MSEC));

        if (status != 0)

        {

            if (!observer)

            {

                timeoutCount = 0;

                semaphore = 0;

                activity = 0;

                return;

            }

            

            if (activity==kCFRunLoopBeforeSources || activity==kCFRunLoopAfterWaiting)

            {

                if (++timeoutCount < 5)

                    continue;

                //保存调用栈信息

            }

        }

        timeoutCount = 0;

        */

        }

    });

}

private class AppPingThread: Thread {

    

    

    private let semaphore = DispatchSemaphore(value: 0)

    //判断主线程是否卡顿的标识

    private var isMainThreadBlock = false

    

    private var threshold: Double = 0.4

    

    fileprivate var handler: (() -> Void)?

    

    func start(threshold:Double, handler: @escaping AppPingThreadCallBack) {

        self.handler = handler

        self.threshold = threshold

        self.start()

    }

    

    override func main() {

        

        while self.isCancelled == false {

            self.isMainThreadBlock = true

            //主线程去重置标识

            DispatchQueue.main.async {

                self.isMainThreadBlock = false

                self.semaphore.signal()

            }

            

            Thread.sleep(forTimeInterval: self.threshold)

            //若标识未重置成功则说明再设置的阀值时间内主线程未响应，此时去做响应处理

            if self.isMainThreadBlock  {

                //采集卡顿调用栈信息

                self.handler?()

            }

            

            _ = self.semaphore.wait(timeout: DispatchTime.distantFuture)

        }

    }

    



}

  /// 1. 通知Observers，即将进入RunLoop

    /// 此处有Observer会创建AutoreleasePool: _objc_autoreleasePoolPush();

    __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopEntry);

    do {

 

        /// 2. 通知 Observers: 即将触发 Timer 回调。

        __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeTimers);

        /// 3. 通知 Observers: 即将触发 Source (非基于port的,Source0) 回调。

        __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeSources);

        __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__(block);

 

        /// 4. 触发 Source0 (非基于port的) 回调。

        __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__(source0);



        /// 5. GCD处理main block

        __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__(block);

 

        /// 6. 通知Observers，即将进入休眠

        /// 此处有Observer释放并新建AutoreleasePool: _objc_autoreleasePoolPop(); _objc_autoreleasePoolPush();

        __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopBeforeWaiting);

 

        /// 7. sleep to wait msg.

        mach_msg() -> mach_msg_trap();

        

 

        /// 8. 通知Observers，线程被唤醒

        __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopAfterWaiting);

 

        /// 9. 如果是被Timer唤醒的，回调Timer

        __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__(timer);

 

        /// 9. 如果是被dispatch唤醒的，执行所有调用 dispatch_async 等方法放入main queue 的 block

        __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(dispatched_block);

 

        /// 9. 如果如果Runloop是被 Source1 (基于port的) 的事件唤醒了，处理这个事件

        __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__(source1);

 

 

    } while (...);

 

    /// 10. 通知Observers，即将退出RunLoop

    /// 此处有Observer释放AutoreleasePool: _objc_autoreleasePoolPop();

    __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__(kCFRunLoopExit);

}

//

//  MonitorController.h

//  RunloopMonitorDemo

//

//  Created by game3108 on 16/4/13.

//  Copyright © 2016年 game3108. All rights reserved.

//



#import <Foundation/Foundation.h>



@interface MonitorController : NSObject

+ (instancetype) sharedInstance;

- (void) startMonitor;

- (void) endMonitor;

- (void) printLogTrace;

@end

//

//  MonitorController.m

//  RunloopMonitorDemo

//

//  Created by game3108 on 16/4/13.

//  Copyright © 2016年 game3108. All rights reserved.

//



#import "MonitorController.h"

#include <libkern/OSAtomic.h>

#include <execinfo.h>



@interface MonitorController(){

    CFRunLoopObserverRef _observer;

    double _lastRecordTime;

    NSMutableArray *_backtrace;

}



@end



@implementation MonitorController



static double _waitStartTime;



+ (instancetype) sharedInstance{

    static dispatch_once_t once;

    static id sharedInstance;

    dispatch_once(&once, ^{

        sharedInstance = [[self alloc] init];

    });

    return sharedInstance;

}



- (void) startMonitor{

    [self addMainThreadObserver];

    [self addSecondaryThreadAndObserver];

}



- (void) endMonitor{

    if (!_observer) {

        return;

    }

    CFRunLoopRemoveObserver(CFRunLoopGetMain(), _observer, kCFRunLoopCommonModes);

    CFRelease(_observer);

    _observer = NULL;

}



#pragma mark printLogTrace

- (void)printLogTrace{

    NSLog(@"====================堆栈\n %@ \n",_backtrace);

}



#pragma mark addMainThreadObserver

- (void) addMainThreadObserver {

    dispatch_async(dispatch_get_main_queue(), ^{

        //建立自动释放池

        @autoreleasepool {

            //获得当前thread的Run loop

            NSRunLoop *myRunLoop = [NSRunLoop currentRunLoop];

            

            //设置Run loop observer的运行环境

            CFRunLoopObserverContext context = {0, (__bridge void *)(self), NULL, NULL, NULL};

            

            //创建Run loop observer对象

            //第一个参数用于分配observer对象的内存

            //第二个参数用以设置observer所要关注的事件，详见回调函数myRunLoopObserver中注释

            //第三个参数用于标识该observer是在第一次进入run loop时执行还是每次进入run loop处理时均执行

            //第四个参数用于设置该observer的优先级

            //第五个参数用于设置该observer的回调函数

            //第六个参数用于设置该observer的运行环境

            _observer = CFRunLoopObserverCreate(kCFAllocatorDefault, kCFRunLoopAllActivities, YES, 0, &myRunLoopObserver, &context);

            

            if (_observer) {

                //将Cocoa的NSRunLoop类型转换成Core Foundation的CFRunLoopRef类型

                CFRunLoopRef cfRunLoop = [myRunLoop getCFRunLoop];

                //将新建的observer加入到当前thread的run loop

                CFRunLoopAddObserver(cfRunLoop, _observer, kCFRunLoopDefaultMode);

            }

        }

    });

}



void myRunLoopObserver(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info) {

    switch (activity) {

            //The entrance of the run loop, before entering the event processing loop.

            //This activity occurs once for each call to CFRunLoopRun and CFRunLoopRunInMode

        case kCFRunLoopEntry:

            NSLog(@"run loop entry");

            break;

            //Inside the event processing loop before any timers are processed

        case kCFRunLoopBeforeTimers:

            NSLog(@"run loop before timers");

            break;

            //Inside the event processing loop before any sources are processed

        case kCFRunLoopBeforeSources:

            NSLog(@"run loop before sources");

            break;

            //Inside the event processing loop before the run loop sleeps, waiting for a source or timer to fire.

            //This activity does not occur if CFRunLoopRunInMode is called with a timeout of 0 seconds.

            //It also does not occur in a particular iteration of the event processing loop if a version 0 source fires

        case kCFRunLoopBeforeWaiting:{

            _waitStartTime = 0;

            NSLog(@"run loop before waiting");

            break;

        }

            //Inside the event processing loop after the run loop wakes up, but before processing the event that woke it up.

            //This activity occurs only if the run loop did in fact go to sleep during the current loop

        case kCFRunLoopAfterWaiting:{

            _waitStartTime = [[NSDate date] timeIntervalSince1970];

            NSLog(@"run loop after waiting");

            break;

        }

            //The exit of the run loop, after exiting the event processing loop.

            //This activity occurs once for each call to CFRunLoopRun and CFRunLoopRunInMode

        case kCFRunLoopExit:

            NSLog(@"run loop exit");

            break;

            /*

             A combination of all the preceding stages

             case kCFRunLoopAllActivities:

             break;

             */

        default:

            break;

    }

}



#pragma mark addSecondaryThreadAndObserver

- (void) addSecondaryThreadAndObserver{

    NSThread *thread = [self secondaryThread];

    [self performSelector:@selector(addSecondaryTimer) onThread:thread withObject:nil waitUntilDone:YES];

}



- (NSThread *)secondaryThread {

    static NSThread *_secondaryThread = nil;

    static dispatch_once_t oncePredicate;

    dispatch_once(&oncePredicate, ^{

        _secondaryThread =

        [[NSThread alloc] initWithTarget:self

                                selector:@selector(networkRequestThreadEntryPoint:)

                                  object:nil];

        [_secondaryThread start];

    });

    return _secondaryThread;

}



- (void)networkRequestThreadEntryPoint:(id)__unused object {

    @autoreleasepool {

        [[NSThread currentThread] setName:@"monitorControllerThread"];

        NSRunLoop *runLoop = [NSRunLoop currentRunLoop];

        [runLoop addPort:[NSMachPort port] forMode:NSRunLoopCommonModes];

        [runLoop run];

    }

}



- (void) addSecondaryTimer{

    NSTimer *myTimer = [NSTimer timerWithTimeInterval:0.5 target:self selector:@selector(timerFired:) userInfo:nil repeats:YES];

    [[NSRunLoop currentRunLoop] addTimer:myTimer forMode:NSDefaultRunLoopMode];

}



- (void)timerFired:(NSTimer *)timer{

    if ( _waitStartTime < 1 ){

        return;

    }

    double currentTime = [[NSDate date] timeIntervalSince1970];

    double timeDiff = currentTime - _waitStartTime;

    if (timeDiff > 2.0){

        if (_lastRecordTime - _waitStartTime < 0.001 && _lastRecordTime != 0){

            NSLog(@"last time no :%f %f",timeDiff, _waitStartTime);

            return;

        }

        [self logStack];

        _lastRecordTime = _waitStartTime;

    }

}



- (void)logStack{

    void* callstack[128];

    int frames = backtrace(callstack, 128);

    char **strs = backtrace_symbols(callstack, frames);

    int i;

    _backtrace = [NSMutableArray arrayWithCapacity:frames];

    for ( i = 0 ; i < frames ; i++ ){

        [_backtrace addObject:[NSString stringWithUTF8String:strs[i]]];

    }

    free(strs);

}



@end

//

//  SeMonitorController.h

//  RunloopMonitorDemo

//

//  Created by game3108 on 16/4/14.

//  Copyright © 2016年 game3108. All rights reserved.

//



#import <Foundation/Foundation.h>



@interface SeMonitorController : NSObject

+ (instancetype) sharedInstance;

- (void) startMonitor;

- (void) endMonitor;

- (void) printLogTrace;

@end

//

//  SeMonitorController.m

//  RunloopMonitorDemo

//

//  Created by game3108 on 16/4/14.

//  Copyright © 2016年 game3108. All rights reserved.

//



#import "SeMonitorController.h"

#import <libkern/OSAtomic.h>

#import <execinfo.h>



@interface SeMonitorController(){

    CFRunLoopObserverRef _observer;

    dispatch_semaphore_t _semaphore;

    CFRunLoopActivity _activity;

    NSInteger _countTime;

    NSMutableArray *_backtrace;

}



@end



@implementation SeMonitorController



+ (instancetype) sharedInstance{

    static dispatch_once_t once;

    static id sharedInstance;

    dispatch_once(&once, ^{

        sharedInstance = [[self alloc] init];

    });

    return sharedInstance;

}



- (void) startMonitor{

    [self registerObserver];

}



- (void) endMonitor{

    if (!_observer) {

        return;

    }

    CFRunLoopRemoveObserver(CFRunLoopGetMain(), _observer, kCFRunLoopCommonModes);

    CFRelease(_observer);

    _observer = NULL;

}



- (void) printLogTrace{

    NSLog(@"====================堆栈\n %@ \n",_backtrace);

}



static void runLoopObserverCallBack(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info)

{

    SeMonitorController *instrance = [SeMonitorController sharedInstance];

    instrance->_activity = activity;

    // 发送信号

    dispatch_semaphore_t semaphore = instrance->_semaphore;

    dispatch_semaphore_signal(semaphore);

}



- (void)registerObserver

{

    CFRunLoopObserverContext context = {0,(__bridge void*)self,NULL,NULL};

    _observer = CFRunLoopObserverCreate(kCFAllocatorDefault,

                                                            kCFRunLoopAllActivities,

                                                            YES,

                                                            0,

                                                            &runLoopObserverCallBack,

                                                            &context);

    CFRunLoopAddObserver(CFRunLoopGetMain(), _observer, kCFRunLoopCommonModes);

    

    // 创建信号

    _semaphore = dispatch_semaphore_create(0);

    

    // 在子线程监控时长

    dispatch_async(dispatch_get_global_queue(0, 0), ^{

        while (YES)

        {

            // 假定连续5次超时50ms认为卡顿(当然也包含了单次超时250ms)

            long st = dispatch_semaphore_wait(_semaphore, dispatch_time(DISPATCH_TIME_NOW, 50*NSEC_PER_MSEC));

            if (st != 0)

            {

                if (_activity==kCFRunLoopBeforeSources || _activity==kCFRunLoopAfterWaiting)

                {

                    if (++_countTime < 5)

                        continue;

                    [self logStack];

                    NSLog(@"something lag");

                }

            }

            _countTime = 0;

        }

    });

}



- (void)logStack{

    void* callstack[128];

    int frames = backtrace(callstack, 128);

    char **strs = backtrace_symbols(callstack, frames);

    int i;

    _backtrace = [NSMutableArray arrayWithCapacity:frames];

    for ( i = 0 ; i < frames ; i++ ){

        [_backtrace addObject:[NSString stringWithUTF8String:strs[i]]];

    }

    free(strs);

}



@end

iOS 调试：通过 Safari/Chrome 调试 WebView

主要汇总通过 Safari 和 Chrome 调试网页的步骤

Safari 调试 WebView

1、真机/模拟器开启 Safari 调试开关

如果需要远程调试iOS Safari，必须启用Web检查功能

• 设置 -> Safari -> 高级 -> 启动”Web检查“

2、Safari 开启调试模式

• Safari浏览器 -> 偏好设置 -> 高级 -> 勾选“在菜单栏中显示开发菜单”

3、开始调试 WebView

• 将手机通过数据线连接到mac上

• 打开 Safari 浏览器，运行手机 app 中的 Web 界面

• 在 Safari -> 开发 中选择连接的手机，并找到调试的网页

Chrome 调试 WebView

1、准备工作

• 安装部署ios-webkit-debug-proxy，在终端中输入

brew install ios-webkit-debug-proxy

ios_webkit_debug_proxy -f chrome-devtools://devtools/bundled/inspector.html

2、调试

• 在 Chrome 中打开 localhost:9221 ，可以看到当前已连接的设备列表

一、正常一个网络请求过程

正常一条网络请求需要经过：

• DNS解析，请求DNS服务器，获取对应的IP地址
• 与服务端建立连接，TCP三次握手，安全协议的同步流程
• 连接建立完成，发送和接受数据，解码数据。

优化点：

• 直接使用IP地址，除去DNS解析的流程
• 不要每个请求都重复建立连接，复用连接使用同一条连接（长连接）
• 压缩数据，减少传输数据的大小

二、正常的DNS流程

DNS完整的解析流程：

1. 先动本地系统缓存获取，偌没有就到最近的DNS服务器获取。

2. 偌依旧没有，就到主域名服务器获取，每一层都有有缓存。

为了域名解析的实时性，每一层的缓存都有一个过期时间。

缺点：

1. 缓存时间过长，域名更新不及时，设置的端，单量的DNS解析请求影响速度

2. 域名劫持，容易被中间人攻击或运营商劫持，把域名解析到第三⽅IP地址，劫持率⽐较⾼。

3. DNS解析过程不受控制，⽆法保证解析到最快的IP

4. ⼀次请求只能解析到⼀个域名

处理DNS耗时和防劫持的方式

HTTPDNS原理就是：

⾃⼰做域名解析⼯作，通过HTTP请求后台去拿到域名对应的IP地址，可以解决上述问题。

• 域名解析与请求分离，所有的请求都直接⽤IP，⽆需DNS解析，APP定时请求HTTPDNS服务器更 新IP地址即可

• 通过签名等⽅式，保证HTTPDNS请求的安全性，避免被劫持

• DNS解析有⾃⼰控制，可以确保更具⽤⼾所在地返回就近的IP地址，或者根据客⼾端测速结果使⽤ 速度最快的IP

• ⼀次请求可以解析多个域名

三、TCP连接耗时优化

解决思路就是：复用接连

• 不⽤每次重新建⽴连接，⽅案是⾼效的复⽤连接

HTTP1.1版本产生的问题：

• HTTP1.1 的问题是默认开启的keep-alive，⼀次的连接只能发送接收⼀个请求，同时发起多个请求，会产⽣问题。

• 若串⾏发送请求，可以⼀直复⽤⼀个连接，但是速度很慢，每个请求都需要等待上⼀个请求完成再发 送，也产⽣了连接的浪费，没⽤充分的利⽤带宽

• 若并⾏发送请求，那么⾸次请求都要TCP三次握⼿建⽴新的连接，即使第⼆次请求可以复⽤连接池的 连接，但是会导致连接池的连接过多，对服务端资源产⽣浪费，若限制保持的连接数，会有超出的连 接仍要每次建⽴连接。

HTTP2.0 提出了多路复⽤的⽅式解决HTTP1.1的问题：

• HTTP2 的多路复⽤机制也是复⽤连接，但是它的复⽤的这条连接⽀持同时处理多条请求，所有的请求 都可以并发的在这条连接上进⾏，解决了并发请求需要建⽴多次连接的问题

• HTTP2 把连接⾥传输的数据都封装成⼀个个stream，每个stream都有⼀个标识，stream的发送和接 收可以是乱序，不依赖顺序，不会有阻塞的问题，接收端可以根据stream的标识区分属于哪个请求， 在进⾏数据拼接，最终得到数据

HTTP2.0 TCP队头阻塞

• HTTP2还是有问题存在，就是队头阻塞，这是受限于TCP协议，TCP协议为保证数据的可靠性，若传 输过程中有⼀个TCP的包丢失，会等待这个包重传之后，才会处理后续的包.

• HTTP2的多路复⽤让所 有的请求都在同⼀条连接上，中间有⼀个包丢失，就会阻塞等待重传，所有的请求也会被阻塞

HTTP2.0 TCP队头阻塞解决方案

• 这个问题需要改变TCP协议，但是TCP协议依赖操作系统实现以及部分硬件的定制，所以改进缓慢。
• 于是Google提出了QUIC协议，相当于在UDP的基础上在定义⼀套可靠的传输协议，解决TCP的缺陷， 包括队头阻塞，但是客⼾端少有介⼊

四、传输数据优化

传输数据有⼤⼩，数据也会对请求速度有影响。主要优化两个方面：

• 压缩率，⽽是解压序列化反
  序列化的速度。使⽤Protobuf 可以⽐json的数据量⼩⾄少⼀个数量级

• 压缩算法的选择，⽬前⽐较好的是Z-Standard HTTP的请求头数据的在HTTP2中也进⾏了压缩。

五、弱⽹优化

根据不同的⽹络设置不同的超时时间

六、数据安全优化

使⽤Https，是基于http协议上的TLS安全协议，安全协议解决了保证安全和降低加密成本

1、安全上

• 使⽤加密算法组合对传输的数据加密，避免被窃听和篡改

• 认证对⽅⾝份，避免被第三⽅冒充

• 加密算法保持灵活可更新，防⽌定死算法被破解后⽆法更换，禁⽌已被破解的算法

2、降低加密成本

• ⽤对称加密算法加密传输的数据，解决⾮对称加密算法的性能低和⻓度限制的问题

• 缓存安全协议握⼿后的秘钥等数据，加快第⼆次建⽴连接的速度

• 3、加快握⼿过程2RTT -> 0RTT。加快握⼿的思路，原本客⼾端和服务端需要协商使⽤什么算法后才 可以加密发送数据，变成通过内置的公钥和默认算法，在握⼿的同时，就把数据发送出去，不需要等 待握⼿就开始发送数据，达到0RTT

3.充分利用缓存

• Get请求可以被缓存，Get请求也是幂等的，
• 简单的处理缓存的80%需求

使⽤Get请求的代码设置如下：

///objective-c代码 

NSURLCache *urlCache =[[NSURLCache alloc]initWithMemoryCapacity:4 *1024 * 1024 

diskCapacity:20 * 1024 *1024 diskPath:nil]; 

[NSURLCachesetSharedURLCache:urlCache];

- (void)viewDidLoad {

    [super viewDidLoad];

    self.view.backgroundColor = UIColor.blueColor;

    // 蒙板视图

    UIView *maskView = [[UIView alloc] initWithFrame:self.view.bounds];

    maskView.backgroundColor = [UIColor redColor];

    maskView.alpha = 0.3;

    [self.view addSubview:maskView];

    // 初始化屏幕大小的矩形路径

    UIBezierPath *bpath = [UIBezierPath bezierPathWithRoundedRect:CGRectMake(0, 0, [[UIScreen mainScreen] bounds].size.width, [[UIScreen mainScreen] bounds].size.height) cornerRadius:8.0];

    // 中间添加一个圆形的路径

    [bpath appendPath:[UIBezierPath bezierPathWithArcCenter:maskView.center radius:100 startAngle:0 endAngle:2*M_PI clockwise:NO]];

    //创建一个layer设置其CGPath为我们创建的路径并且赋值给蒙板视图的layer

    CAShapeLayer *shapeLayer = [CAShapeLayer layer];

    shapeLayer.path = bpath.CGPath;

    maskView.layer.mask = shapeLayer;

}