Big Ben

Batch. vs. Mini-Batch

机器学习算法通常会有大量的training sample需要处理，这个数字可能是百万量级，甚至更高。这会导致矩阵迭代的时候，计算时间过长。当sample数达到一定数量的时候，通常会采用将整个训练集，分成若干小集合，即mini-batch，采用迭代的方法来计算。这样就将一次矩阵运算串行化，降低运算复杂度，速度会大幅提升。缺点是收敛会困难一些。看下图：

How to choose mini-batch size?

• If small training set (m 2000), use batch gradient descent.
• Typical mini-batch size: 64, 128, 256, 512, -> ~
• Make sure mini-batch size fit your CPU/GPU memory.

Learning Rate Decay

动态调整learning rate的算法有很多种，下面这种是比较常用的

Other learning rate decay methods:

• 
• 
• discrete stair case
• manual decay

指数加权平均相关算法

Momentum, RMSprop, Adam都是和指数加权平均算法(Exponential Weighted Average)相关的。下面一一介绍：

Exponential Weighted Average

公式是:

• 蓝点是原始数据
• 红线采用，累积前10个数据的影响
• 绿线采用，累积前20个数据的影响
• 黄线采用，累积前2个数据的影响
  可见，采用指数加权平均后，数据变平滑，且越大，数据越平滑，越小，数据越趋近于原始数据。

How it works?

其工作原理如下图：

Bias Correction Exponential Weighted Average

之所以有这个bias correction，因为这个指数加权的初始值选的是0，造成开始一段的迭代，会偏离真实值较远。例如下面绿线和紫线。

Momentum

Momentum就是指数加权平均算法的一种应用。

RMSprop (Root Mean Square prop)

RMSprop是根据Momentum衍生出来的算法。具体做法如下：

On iteration t:

• Compute dw and db on current mini-batch
• 
• 
• 
• 
• 

为了区分Momentum和Exponential Weighted Average中的hyper parameter ，此处用

Adam optimization algorithm

Adam = Adaptive Moment Estimation
Adam = Momentum + Bias Correction + RMSprop
具体算法如下：

On iteration t:

• Compute dw and db on current mini-batch
• ,
• ,
• ,
• ,
• 
• 

Hyper parameters (通常去经验值)

Local Optima Problem

Andrew解释了，在现代的机器学习问题中，不太可能出现local optima

在机器学习中，有两种常见的问题：

• bias (或者hIgh bias, underfitting，欠拟合)
• variance (或者high variance, overfitting, 过拟合)

前者通常因为模型不够复杂，不足以通过现有数据预测出正确的结果。training error过大。解决的方法可以通过增大训练网络。
而后者是因为模型过于依赖训练数据，而对测试数据效果不佳。training error不大，但是dev error却比较大。改善的办法是正则化，即Regularization。

Regularization

加入正则化因素的损失函数如下：

(1)式中没有对b进行正则化，即没有。原因是b只是一个常数，而w通常是一个大矩阵，数据比较多，容易出现过拟合。添加b也可以，但通常对运算结果影响不大。

(1)式的正则项，称为L2 regularization。通常有下面几种：

• L2 regularization (又叫weight decay):
• L1 regularization:
• Frobenius regularization:
• Dropout regularization: 在另一章单独阐述。

L2 regularization = weight decay
因为当我们使用正则化的损失函数求导时有：


我的理解，因为w在减小，所以叫权重衰减。

Dropout regularization

Dropout就是随机删除一些hidden unit来实现正则化。

Implementation Example (Inverted Dropout)

这是最常见的Dropout实现方法，叫”Inverted Dropout” (反向随机Dropout)。计算步骤如下：

d3 = np.random.rand(a3.shape[0], a3.shape[1]) < keep-prob
a3 = np.multiply(a3, d3)
a3 /= keep-prob

解释一下：

1. keep-prob代表保留hidden unit的概率。如果keep-prob = 0.8，则有80%的unit被保留，20%的unit被删除
2. 之所以最后一行要re-scale，因为a3被删除掉一些unit，他的期望值就只有原先的keep-prob的比例，所以这里需要re-scale，这样在验证test set的时候不会有scaling的问题
3. 注意：第一行用的是np.random.rand而不是np.random.randn。因为randn获取的随机数是正态分步，所以并不能保证小于keep-prob的概率为keep-prob。rand产生的是均匀分步，则能保证。

Make Prediction at Test Time

验证的时候，不使用Dropout。因为引入Dropout就是引入随机噪声，会导致预测值即不稳定。所以验证时通常不用Dropout。

Other Regularization

• Augment data set.
  
  • 将原有图片进行处理得到更大的training set来消除variance。例如旋转，反转图片
• Early Stopping
  
  • 在variance问题还不是很明显的时候stop，看下图，在中间的点处就停止迭代。

Vanishing/Exploding Gradients

梯度消失和梯度爆炸。这是为什么神经网络为什么不能很深。

以这样的网络举例。采用线性激活函数，即g(z)=z，则

Conclusion for random weight initialization

• Different initializations lead to different results
• Random initialization is used to break symmetry and make sure different hidden units can learn different things
• Don’t intialize to values that are too large
• He initialization works well for networks with ReLU activations.

2016年在做微信打印Android agent app的时候，研究过如何在开发Android app的时候TDD。详细参考此篇博文Android单元测试。
当时的最终方案是：Powermock + Mockito + JUnit做local test。因为要Mock各种Android SDK中的类，所以有一种被无力控制的恐惧。所以在做Niwatori的时候，迟迟没有开展TDD。因为最近添加的功能稍微有点复杂了，感觉各种不顺，所以考虑重新拾起TDD。于是有了各种折腾，并验证了之前无力的恐惧后的这一篇。不过结果好的是看起来找到了一条Android app TDD开发不错的路子。

这一切都要归功于

Roboletric

起初的相识还是在Android developer官网关于测试的页面。然后在搜索Powermock用法的时候，看到很多帖子都提到了roboletric。因为认识到Mockito + Powermock的弱点(如下)，所以决定转向roboletric。

Mockito

• 不能mock final class/method
• 不能mock private/static

Powermock

• 需要自己mock各种class，当函数大了的时候，因为会引用非常多的Android类，所以会让人感到很无力

在编译Android app的时候，Android SDK以android.jar的形式参与编译。而这个android.jar中的各个类并没有具体的实现，只是一个stub。所以如果不经过mock就直接在Unit Test中使用Android类就会出现Error java.lang.RuntimeException: Stub!错误。
Roboletric就是为了消除这种错误诞生的。它为所有的Android类定义了可以跑在PC端JVM下的class。而且提供了很多额外的功能，方便开发者做隔离测试以及UI方面的测试。

入门

首先推荐的还是官网主页。然后还有几个不错的中文帖子：

• Robolectric使用教程: 可以参考Properties文件以及Activity生命周期部分。
• Android单元测试之Robolectric框架: 可以参考Robolectric配置以及针对各种Android组件的测试方法部分。

对于配置环境和第一个简单的实例，最好是按照官网的步骤去做。因为在setup的时候，往往有很多版本号依赖要处理，尤其是这种出身社区的框架。往往依赖处理不是特别好。

Powermock + Roboletric

用上Roboletric以后，你会发现原先需要各种mock的函数，现在不用怎么mock就能编过了，甚至有些listener都能起作用。但是因为Roboletric本身只是提供Android SDK的副本，对于测试并不是那么在行，或者说其目的并不是一个更power的mock库。当我们需要为某些class提供预设的功能，异或需要对某些对象调用次数进行verify的时候，还是需要powermock的（或者Mockito，但鉴于其功能实在太low，能用Powermock的就用Powermock吧）。
入门参看Roboletric GitHub wiki：Using PowerMock。示例如下：

@RunWith(RobolectricTestRunner.class)
@Config(constants = BuildConfig.class)
@PowerMockIgnore({ "org.mockito.*", "org.robolectric.*", "android.*" })
@PrepareForTest(Static.class)
public class DeckardActivityTest {
    @Rule
    public PowerMockRule rule = new PowerMockRule();
    @Test
    public void testStaticMocking() {
        PowerMockito.mockStatic(Static.class);
        Mockito.when(Static.staticMethod()).thenReturn("hello mock");
        assertTrue(Static.staticMethod().equals("hello mock"));
    }
}

特别要注意的是：

1. 因为class开头用了@RunWith(RobolectricTestRunner.class)标注，所以无法用PowermockTestRunner.class。所以必须加上下面两行：

@Rule
public PowerMockRule rule = new PowerMockRule();

否则会出现各种Powermock无法工作的异常，例如class没有prepare啦，不能mock private函数等等。

2. 因为Roboletric提供了很多Shadow类，而这些类和mock有冲突。例如Intent intent = mock(Intent.class)就会导致这个莫名其妙的错误。

java.lang.LinkageError: loader constraint violation: loader (instance of net/bytebuddy/dynamic/loading/MultipleParentClassLoader) previously initiated loading for a different type with name "org/xmlpull/v1/XmlSerializer

所以就要加上@PowerMockIgnore。甚至Ignore的列表要更长，例如：

@PowerMockIgnore({
    "org.mockito.*",
    "org.robolectric.*",
    "android.*",
    "javax.xml.*",
    "org.xml.sax.*",
    "org.w3c.dom.*",
    "org.springframework.context.*",
    "org.apache.log4j.*"
})

踩坑列表

PowerMockito.whenNew is not working

You need to put the class where the constructor is called into the @PrepareForTest annotation instead of the class which is being constructed - see Mock construction of new objects.

总结

用Roboletric来解决Android SDK问题，用Powermock+JUnit来解决unit test问题。

问题描述

Evaluation Orders and Disorders

//  Example 1(a)
//
f( expr1, expr2 );
//  Example 1(b)
//
f( g( expr1 ), h( expr2 ) );

编译器只要满足下面的规则，为了便于优化执行顺序，而C++标准并不要求具体指令顺序：

1. expr1在g执行之前完成，expr2在h执行之前完成
2. g, h在f执行之前完成

首先，在函数正式执行之前，所有的Expression Evaluation要完成。
其次，有可能出现乱序。
所以有可能出现下面的执行顺序：
顺序一

• expr1
• expr2
• g
• h

顺序二

• expr1
• g
• expr2
• h

上面两种情况都符合。

Exception Safety Problems

当C++编译器调用new操作符的时候会做两件事：1. 开辟内存，2. 调用类构造函数。所以下面的code如果处理得当，是不会有内存泄漏：

T1* t1 = new T1;
T2* t2 = new T2;

当T1构造函数出现异常时，相应的内存会被释放掉。当T2构造函数出现异常时，T2的内存会被释放，T1的内存也有机会被释放。（解决方法是在两条语句之间加上异常处理，当然用smart pointer也可以解决问题。后面会阐述smart pointer的方法）

但是在遇到Expression Evaluation的时候，情况会变得复杂：

//  In some header file:
void f( T1*, T2* );
//  In some implementation file:
f( new T1, new T2 );

• T2构造函数异常时，根本没有机会释放T1的内存。用异常处理也没办法，因为T1的内存开辟出来赋值给了一个临时变量。而这个变量的有效期就只在那个括号里。
• 乱序让问题更加复杂，因为你不知道是T1先构造还是T2先构造，你不知道是下面的哪种顺序，但是每一种顺序都有问题。所以无从下手。
  
  • 顺序一
    
    • 1: allocate memory for T1
      2: construct T1
      3: allocate memory for T2
      4: construct T2
      5: call f()
  • 顺序二
    
    • 1: allocate memory for T1
      2: allocate memory for T2
      3: construct T1
      4: construct T2
      5: call f()

解决方案

看起来像的解决方案

用auto_ptr

//  In some header file:
void f( auto_ptr<T1>, auto_ptr<T2> );
//  In some implementation file:
f( auto_ptr<T1>( new T1 ), auto_ptr<T2>( new T2 ) );

看起来用了smart pointer，应该不存在释放内存的问题了。但其实并没有改善，因为乱序问题，你没法保证auto_ptr<T1>在new T2之前调用。如果T2构造失败了，new T1的内存就泄露了。Vice versa。

用参数默认值

//  In some header file:
void f( auto_ptr<T1> = auto_ptr<T1>( new T1 ),
        auto_ptr<T2> = auto_ptr<T1>( new T2 ) );
//  In some implementation file:
f();

没有本质的改善。因为虽然参数默认值是在函数声明中，但是那些new和auto_ptr<>是在执行时才会去做的事情。一样会有乱序。

真正的解决方案

//  In some header file (same as in Example 2b):
void f( auto_ptr<T1>, auto_ptr<T2> );
//  In some implementation file:
f( auto_ptr_new<T1>(), auto_ptr_new<T2>() );

看起来和之前的假解决方案很像对不对，区别是相应的new和auto_ptr<>构造函数放到一起了。这样不管是auto_ptr_new<T1>()在前，还是auto_ptr_new<T2>()在前，都不会引起Exception Safety问题。

这个方案也就是网上经常有人问到的“为什么要用make_xxx_ptr，而不用new xxx_ptr?”的原因之一，xxx_ptr可以是任何的smart pointer（包括但不限于：auto_ptr, shared_ptr, unique_ptr）：

• 可以避免Exception Safety问题
• 避免显示使用new运算符，避免潜在问题
• 局限是只能用默认构造函数，而无法使用带参数构造函数

下面也是一个办法：

//  In some header file:
void f( auto_ptr<T1>, auto_ptr<T2> );
//  In some implementation file:
{
  auto_ptr<T1> t1( new T1 );
  f( t1, auto_ptr<T2>( new T2 ) );
}

这个方法更好：

//  In some header file:
void f( auto_ptr<T1>, auto_ptr<T2> );
//  In some implementation file:
{
  auto_ptr<T1> t1( new T1 );
  auto_ptr<T2> t2( new T2 );
  f( t1, t2 );
}

总结

以Exception-Safe Function Calls作者的guide lines作总结：

Perform every resource allocation (e.g., new) in its own code statement which immediately gives the new resource to a manager object (e.g., auto_ptr).

意思是一行就只分配一个资源，并且立即将该资源交给smart pointer管理。

参考文献

Exception-Safe Function Calls
GotW #89 Solution: Smart Pointer

在C++中提供了按引用调用的方式，如下

class A{}
A& func(A& a)
{
    A* b = new A();
    b->param = a.param;
    return *b;
}

引用既可以作为参数传递，也可以是返回值。所有的书上都提到引用即可视为对象的别名。他有如下特性：

1. 可以像对象一样操作引用，使用"."操作符，而无需"->"操作符
2. 其地址与引用的对象一致
3. 所谓别名，就是引用已经与对象绑定，以下代码最后一行是不允许的。

A a;
A b;
A& c = a;
c = b;

4. 引用是C++中的语法糖，其存在的目的就是让传递对象的时候更廉价一些，尽量避免调用构造函数。

作为参数

其实C++中不按引用传递自定义类对象参数也是可以的。如下：

class A{}
void func (A a);
void func (A& a);

两者均可以，区别在

1. 前者传递时要分配一个临时变量，并调用A的拷贝构造函数。
2. 前者在函数体内，对a的修改不会影响到外部a对象。这往往是我们想要的。所以，按引用调用的时候，往往更好的写法是：

void func (const A& a); // 用const来保证a对象不被修改

作为返回值

在定义运算符重载的时候，我们往往使用return *this;来保证链式调用，例如：

class A {
    A& operator=(A& param){
        ...
        return *this;
    };
}
A a, b, c;
a = b = c;

如果不按引用返回，可以吗？

class A {
    A operator=(A& param){
        ...
        return *this;
    };
}
A a, b, c;
a = b = c;

答案是也是可以的。区别是：

• 不按引用传递时，b=c的操作返回时会先分配一个临时变量，以*this为参数调用A的拷贝构造函数，然后再调用一次A的拷贝构造函数将该临时变量作为结果传递给a的=操作符函数。
• 按引用传递，同样b=c返回时会分配一个临时变量，并调用A的拷贝构造函数，然后将该临时变量的引用值传给a的=操作符函数。

可见虽然两者都能做到链式操作，但是按引用返回少调用了一次拷贝构造函数，效率提升。这与引用存在的价值也是一致的。

这个知识点，在C++中看起来非常基本，但是初学者往往容易犯错。这里提及的是=的重载与拷贝构造函数。
当出现下面代码的时候，是调用=重载吗？

class A {}
A a;
A b = a;

答案是错，这里将会调用拷贝构造函数。如果没有显式定义拷贝构造函数，即调用默认拷贝构造函数，即浅拷贝，如果类定义中涉及内存的分配，则会出现意想不到的结果。
=运算符只会在赋值的时候使用，而在构造的时候会使用拷贝构造函数。如下是使用=的例子：

A a;
A b;
b = a;

C++支持多继承，当父类继承自同一个超类，则即为本篇所述的菱形继承。类图如下：

主要参考两个链接：

• c++虚继承对象的内存布局
• Memory Layout for Multiple and Virtual Inheritance - Edsko de Vries, January 2006

前一篇提到的VS2003与后文中的实现方式相同，前一篇中还提到了Bjarne方案，不知哪些编译器采用这种方案。所以本文认为前者方案为主流方案，加以阐述。后者方案可视为前者方案的略微改良版。

单类虚继承

代码实现如下：

struct A {
    virtual foo();
    int X;
}
struct B : virtual public A {
    virtual foo();
    virtual fooB();
    int Y;
}

其中VPTR指向Virtual Table (VTBL)，VBPTR指向Virtual Base Table (VBTBL)。其内容为：

1. 第一项为与本类VPTR的偏移。一般VPTR总是存在对象开始处。所以上例为-4字节，取补即为0xFFFFFFFC。如果本类没有虚函数，就没有VPTR，则该值为0。
2. 从第二项开始为到各基类的偏移值，有几个基类，表项就有几个。上例中，只有一个基类，且本类成员变量会放在VBPTR之后，所以到基类A的偏移量即为8字节。

注意1: 只有出现了虚拟继承，才会有这样的内存布局，如果没有虚拟继承，则父类VPTR及其成员会挨着子类VPTR放置。
注意2: 此时VPTR中内容和无虚继承时的内容也不同。若B是普通继承A，则B类内存布局为：

菱形继承

对于这样一个菱形继承：

struct A
{
    A(int v=100):X(v){};
    virtual void foo(void){};
    int X;
};
struct B :virtual public A
{
    B(int v=10):Y(v),A(100){};
    virtual void foo(void){};
    virtual void fooB(void){}
    int Y;
};
struct C : virtual public A
{
    C(int v=20):Z(v),A(100){};
    virtual void foo(void){};
    virtual void fooC(void){};
    int Z;
};
struct D : public B, public C
{
    D(int v =40):B(10),C(20),A(100),L(v){};
    virtual void foo(void){};
    virtual void fooD(void){};
    int L;
};

其主要特点为：

• ABCD均包含虚函数，所以每个类都有虚函数表
• 每个类均有成员变量
• 父类BC对祖类采用虚继承
• 子类对两个父类采用普通继承

这应当是最复杂的情况了，当有些类没有虚函数，或者没有成员变量时，情况可能稍许简单些。

A

A类因为没有虚拟继承，所以其内存布局为普通布局：

B / C

BC类均为单类虚继承，如上节所述：

D

D类最复杂

1. 本类无覆盖关系的成员函数在最一开始的VPTR中，或认为在B::VPTR中
2. 本类成员函数在所有直接父类对象的后面
3. 只有一份A对象
4. 本类如果覆盖任何父类或祖先类的成员函数会覆盖对应对象的VPTR中的项目。

Error: source type is not polymorphic

当祖先类A没有虚函数的时候，在发生向下转型（子类指针转成父类指针）的时候会出问题。可以查看Memory Layout for Multiple and Virtual Inheritance - Edsko de Vries, January 2006 中Downcasting一节。
考虑这样两个多继承的类：

Bottom* bottom1 = new Bottom();
AnotherBottom* bottom2 = new AnotherBottom();
Top* top1 = bottom1;
Top* top2 = bottom2;
Left* left = static_cast<Left*>(top1);

Bottom和AnotherBottom都继承自Left，Left虚继承自Top。现在要把一个Top指针转换成一个Left指针。使用static_cast会报error: cannot convert from base `Top’ to derived type `Left’ via virtual base `Top’。 因为需要运行时信息，因为所有的VPTR和对象内存布局，都是到运行时才建立的。于是想到可以用dynamic_cast。

Left* left = dynamic_cast<Left*>(top1);

此时会报另一个错误：error: cannot dynamic_cast `top’ (of type `class Top*’) to type `class Left*’ (source type is not polymorphic)。这是因为Top类没有虚函数，所以此时Bottom和AnotherBottom对象的Top部分没有VPTR。于是编译器也分不清这是一个int还是一个对象。解决的方法就是为Top加一个虚函数。最方便的方法就是加一个空的虚析构函数，如下：

class Top {
 virtual ~Top(){};
}

总结

当发生虚继承的时候，对象内部内存布局会产生大的变化，在引入VBPTR的同时，其各基类对象的排布顺序也发生了变化。

其他参考链接

• 详谈C++虚函数表那回事（多重继承关系, 无虚继承）
• 【C++】c++单继承、多继承、菱形继承内存布局（虚函数表结构） （此篇包含了对《c++虚继承对象的内存布局》一文的阐释

最近做ThoughtWorks的面试题，第一遍用最简单的方法实现了，面试官说没有OO设计，于是乎想炫一波OO设计，结果才发现，原来C++还差的很远。先来说说这个多接口的坑。还会有另外的笔记阐述：

• 运算符重载与拷贝构造函数
• 菱形继承
• 函数中的按引用调用与返回
• 以后想到再加

C++中的接口

接口是面向对象很重要的概念。按照《敏捷软件开发-原则、模式与实践》一书所述，所有软件高层不应依赖于低层，而应依赖于抽象出的接口。这就是依赖倒置原则(DIP)。Java中的接口用interface定义，C++中没有提供专门的关键字。而是用纯虚函数来表示接口。形如：

class interface
{
public:
    virtual void func() = 0;
}

接口是不能实例化的，因为包含了纯虚函数。

单类定义多接口

在Java中很容易做到，只需class A implement IA, IB{}即可。在C++中可否这么做呢？很容易就想到C++中的多继承，如下：

class IA {
public:
    virtual void funcA() = 0;
}
class IB {
public:
    virtual void funcB() = 0;
}
class C : public IA, public IB {
    void funcA();
    void funcB();
}

按照最初的设想，我希望能够：

C* c = new C();
IA* pA = (IA*)c;
IB* pB = (IB*)pA;
pA->funcA(); // 调用A函数
pB->funcB(); // 调用B函数

但我发现，现实与理想差得很远。pB->funcB()调用的其实也是funcA()。原因与多继承内存分布与类型转换有关。
在发生多继承时，一个C对象中内存分布如下，盗用陈浩的博客C++ 对象的内存布局中的图：

Base1* pA = (Base1*)derive;
Base2* pB = (Base2*)derive;

当发生向上类型转换时，编译器均能很好的工作，不用依赖于各种强制转换，也可以识别到正确的函数。但是如果发生非正常的类型转换时，就会遇到问题。例如前文所述的将Base1型指针直接转型到Base2就会出问题。可参考这一篇博文：当C++多继承遇上类型转换。文中提到了三个解决方案，我尝试了前两个，分别用static_cast和dynamic_cast均不能解决。奇怪的是，dynamic_cast的解决方案看起来在网上确是颇有一些支持者，看下面的链接：

• Multiple inheritance casting from base class to a different derived class
  
• Type casting to an interface (Abstract class) in case of Multiple Inheritance in C++
  
• How to perform casting with multiple inheritance
  

在我自己的code中，dynamic_cast之后的结果是虽然没有抛出bad cast异常，但是转换的结构是NULL。

解决方案

上面提到的方案，都不成功，但最终我还是找到了能解决的办法，尽管看起来不像想象中优雅。

方案一：采用菱形继承

根据查阅的各种网站资料，这样的继承会增加内存布局，以及调用的复杂度。但确实能解决上面多接口转型的问题。具体代码如下：

class IBase
class IA : virtual public IBase {}
class IB : virtual public IBase {}
class C : public IA, public IB {}
IA* pA = new C();
IBase* base = (IBase*)pA;
IB* pB = dynamic_cast<IB*>(base);

这样的做法，让人如鲠在喉，一个简单的调用，搞的这么复杂。转来转去，可读性极差，而且dynamic_cast还有性能问题。
而且这里还会遇到source type is not polymorphic的问题，解决方法使添加虚析构函数。

class IBase {
    virtual ~IBase(){};
}
class IA : virtual public IBase {}
class IB : virtual public IBase {}
class C : public IA, public IB {}
IA* pA = new C();
IBase* base = (IBase*)pA;
IB* pB = dynamic_cast<IB*>(base);

方案二：采用单接口

这一方案，是受了下面的链接的启发：Implementing multiple interfaces in a single C++ class

As you found out, you cannot implement two interfaces with one single C++ class directly. However, you could simply define a new Slice interface derived from the two other Slice interfaces, and then implement this new Slice interface with a single C++ class.

作者说C++中直接定义多接口并不是一个好的实现，定义一个虚接口类来继承两个虚接口，实现类直接继承自这个虚类。代码如下:

class IA {}
class IB {}
class IAB : public IA, public IB {}
class C : public IAB {}

这样转型起来就方便多了

C* c = new C();
IA* pA = (IA*)c;
IB* pB = (IB*)pA; // 仍会出错，不能直接转
IB* pB2 = (IB*)(IAB*)pA; // 可以工作

但其实上层的代码，应该依赖于IAB，而不应该也不能够只依赖于IA, IB，而对IAB一无所知。

总结

1. 在设计接口的时候，不要指望用多继承来模仿Java里的多接口定义。
2. 尽量避免在多继承的时候，需要在没有继承关系(IA & IB)之间进行指针转型。虽然菱形继承+dynamic_cast可以做到，但是可读性和性能会下降。
3. 可以用方案二中的方法来实现近似的多接口定义。这是一个相对简介有效的方法。

最近在维护一个Xposed模块[]Niwatori-One Handed Mode](https://github.com/tkgktyk/Niwatori)。原作者tkgktyk已经停止更新了，导致模块在Xposed Framework for Nougat发布以后，不能使用。于是我fork了一份代码，开始做Android Nougat上的适配工作，并在XDA上发布了更新链接。
在适配了Nougat之后，希望能添加一些新功能，让用户体验更好。目前想做的是能通过fooview调用Niwatori的快捷方式。并且该快捷方式的功能，例如是small screen还是slide down等等，能通过Niwatori本身进行配置。但是在开发这一功能的时候，发现动态快捷方式的加载需要使用SDK 25以上版本，而从SDK 25开始，原先SharedPreference的打开方式MODE_WORLD_PRIVATE已经被禁止了。使用它会导致security exception。
所以要升到使用SDK 25，必须解决preference引用的问题。那么这个模式的变化，到底会在哪里影响到我们的Xposed模块呢？

Xposed中的preference

Xposed模块中使用preference的时候，通常都是通过XSharedPreference来操作。XSharedPreference在Android标准的SharedPreference类上包了一层，提供了一些security的fix或者work around。例如：XSharedPreference.makeWorldReadable。他们都是加载app data文件夹下的xml文件来读取、存储键值对的。该文件路径为（以Niwatori为例）：/data/data/jp.tkgktyk.xposed.niwatori/shared_prefs/jp.tkgktyk.xposed.niwatori_preferences.xml。

通常Xposed中如下使用preference会按照如下的时序图，以Niwatori为例：

• XSharedPreference实例创建在模块加载的initZygote中
• 数据的使用通过钩子函数，在各个app的Context底下执行

于是当MODE_WORLD_READABLE被废止以后，这里就出问题了。即在默认情况下，app1是没有权限查看Niwatori的preference文件的，也就没法加载配置数据。

Xposed官方或者作者rovo89还没有给出官方的解决办法，但总是会有一些未雨绸缪的勇士，XDA上有一个帖子给出了一个work around：MODE_WORLD_READABLE in Android N

我在Niwatori中也使用了该方法，但仍然不是完美解决，而且目前还不知道如何改进。

遗留的问题

该work around和XSharedPreference.makeWorldReadable同理，我如下调用preference：

mPrefs.makeWorldReadable();
Log.e("Ben", "package:" + decorView.getContext().getPackageName() + ", " + decorView + "," + mPrefs.getString("key_boundary_color_ms", "default value"));
Log.e("Ben", "file can read: " + mPrefs.getFile().canRead()); <-- 有些app会是true，有些app会是false

当返回true的时候，settings就成功的传到了对应app了。这个时而可以read时而不可以read，我也很苦恼，不知道是怎么回事儿。留待以后再解决了。

解决遗留的问题 - 20180119

以上的问题在于，Android 7.0开始，即从SDK 24开始，Android加入了很多security方面的特性，参考Android 7.0 Security Features: Direct Boot。这和我们的问题不太相关。相关的是如上所说，Nougat不允许world readable的文件了。如果用SDK25编译的app还用MODE_WORLD_READABLE，系统会报exception。
Google上鲜少有相关的解决方案，有如下几个链接可以参考：

• GravityBox commit - Use device protected storage for preferences and files
• XposedBridge issue 1 - Any place to store world readable preferences on Nougat?
• XposedBridge issue 2 - Preferences of a module cannot be read from different process on some devices running MM
• XposedBridge issue 3 - XSharedPreferences doesn’t work
• [Q] Xposed for nougat to read prefs ith fbe or without

经过验证，是XposedBridge issue 1中GravityBox作者的一个comment提到了最终的解决方法。该comment如下：

• setStorageDeviceProtected
• createDeviceProtectedStorageContext

将preference文件存到/data/user_de/0/<package name>/shared_prefs下。并在Xposed的context端，直接打开文件进行操作。
但其实我们并不需如此。只要保证package folder的权限至少是711，preference.xml文件有可读权限即可。

最近在维护一个Xposed模块[]Niwatori-One Handed Mode](https://github.com/tkgktyk/Niwatori)。原作者tkgktyk已经停止更新了，导致模块在Xposed Framework for Nougat发布以后，不能使用。于是我fork了一份代码，开始做Android Nougat上的适配工作，并在XDA上发布了更新链接。
在适配了Nougat之后，希望能添加一些新功能，让用户体验更好。目前想做的是能通过fooview调用Niwatori的快捷方式。并且该快捷方式的功能，例如是small screen还是slide down等等，能通过Niwatori本身进行配置。但是在开发这一功能的时候，发现动态快捷方式的加载需要使用SDK 25以上版本，而从SDK 25开始，原先SharedPreference的打开方式MODE_WORLD_PRIVATE已经被禁止了。使用它会导致security exception。
所以要升到使用SDK 25，必须解决preference引用的问题。那么这个模式的变化，到底会在哪里影响到我们的Xposed模块呢？

Xposed中的preference

Xposed模块中使用preference的时候，通常都是通过XSharedPreference来操作。XSharedPreference在Android标准的SharedPreference类上包了一层，提供了一些security的fix或者work around。例如：XSharedPreference.makeWorldReadable。他们都是加载app data文件夹下的xml文件来读取、存储键值对的。该文件路径为（以Niwatori为例）：/data/data/jp.tkgktyk.xposed.niwatori/shared_prefs/jp.tkgktyk.xposed.niwatori_preferences.xml。

通常Xposed中如下使用preference会按照如下的时序图，以Niwatori为例：

• XSharedPreference实例创建在模块加载的initZygote中
• 数据的使用通过钩子函数，在各个app的Context底下执行

于是当MODE_WORLD_READABLE被废止以后，这里就出问题了。即在默认情况下，app1是没有权限查看Niwatori的preference文件的，也就没法加载配置数据。

Xposed官方或者作者rovo89还没有给出官方的解决办法，但总是会有一些未雨绸缪的勇士，XDA上有一个帖子给出了一个work around：MODE_WORLD_READABLE in Android N

我在Niwatori中也使用了该方法，但仍然不是完美解决，而且目前还不知道如何改进。

遗留的问题

该work around和XSharedPreference.makeWorldReadable同理，我如下调用preference：

mPrefs.makeWorldReadable();
Log.e("Ben", "package:" + decorView.getContext().getPackageName() + ", " + decorView + "," + mPrefs.getString("key_boundary_color_ms", "default value"));
Log.e("Ben", "file can read: " + mPrefs.getFile().canRead()); <-- 有些app会是true，有些app会是false

当返回true的时候，settings就成功的传到了对应app了。这个时而可以read时而不可以read，我也很苦恼，不知道是怎么回事儿。留待以后再解决了。

解决遗留的问题 - 20180119

以上的问题在于，Android 7.0开始，即从SDK 24开始，Android加入了很多security方面的特性，参考Android 7.0 Security Features: Direct Boot。这和我们的问题不太相关。相关的是如上所说，Nougat不允许world readable的文件了。如果用SDK25编译的app还用MODE_WORLD_READABLE，系统会报exception。
Google上鲜少有相关的解决方案，有如下几个链接可以参考：

• GravityBox commit - Use device protected storage for preferences and files
• XposedBridge issue 1 - Any place to store world readable preferences on Nougat?
• XposedBridge issue 2 - Preferences of a module cannot be read from different process on some devices running MM
• XposedBridge issue 3 - XSharedPreferences doesn’t work
• [Q] Xposed for nougat to read prefs ith fbe or without

经过验证，是XposedBridge issue 1中GravityBox作者的一个comment提到了最终的解决方法。该comment如下：

• setStorageDeviceProtected
• createDeviceProtectedStorageContext

将preference文件存到/data/user_de/0/<package name>/shared_prefs下。并在Xposed的context端，直接打开文件进行操作。
但其实我们并不需如此。只要保证package folder的权限至少是711，preference.xml文件有可读权限即可。