Android5.0后终于添加了Vector，这无疑是对android的icon的又一次比较大的变革。也许有人听说过但是没有用过。今天就给大家比较粗糙的讲解下Vector是个什么玩意。 

    Android从起步到现在，不知道大家发现没有，APK包越来越大，无用代码无用资源原来越多。当然google也在做各种各样的优化。这里总结几种比较常见的优化策略； 

    aapt： 

    实现的图片高保真压缩，这个比较常用，有可能你用了，但是你自己都不知道。 

通过边缘拉伸实现的图片不失真，可以减少一定量的图片体积。 

    androidstudio自带混淆功能： 

    混淆功能会将代码压缩，同样可以实现apk体积减小，而且还提供的移动无用资源这个功能就比较鸡肋了。现在的android开发者用的反射都会比较常见了，不像之前用的少，再去用无用资源去除或者lint这种功能，就可能会把反射对应的资源给排除掉，得不偿失。 

    还有不少优化的方法就不一一累述了。今天主要讲的是VectorAsset这个神奇的功能。

一、VectorAsset的使用条件：

满足以下几个条件建议使用：
1、简单图像，例如常见icon类图片，推荐阿里巴巴矢量图库类似的svg图片
2、纯色背景类图片
3、复用率高且不同位置需求图片大小不同的
4、复用率高且颜色需求变化的




二、VectorAsset优缺点：

1.因为vector是以xml格式存储的，所以可以把vector理解为一个非图片格式的文件，vector与png/jpg/gif/svg等格式相比较体积小很多 

    2.正因为vector是以xml格式存储，所以有非常高的可维护性，甚至技术大牛们可以去实现动态生成vector的功能也不是不可能。当然我这种小虾米就差点了，目前办不了 

    3.android提供了vector的一系列方法，可以实现对vector的位置、大小、颜色的维护方法，这个功能也是我看中vector的最主要原因之一，举例来说，做一个点击效果，可能你需要两张png,一个是未点击状态，一个是已点击状态。vector只需要一个xml和一个判断方法就可以解决了，甚至不用去写selector文件。具体操作后边介绍。 

    4.基于vector的可控制性高，可以实现不同大小颜色的图片做到最大的复用程度。 

   VectorAsset具体用法及注意事项：

三、 先说具体用法吧，这个还是大家比较关心的。

我以阿里巴巴矢量图库随意找的一张图片做的：
1、vector只支持svg的矢量图片或者psd文件（个人不建议使用psd文件，具体原因自己研究，比较坑）
首先将svg图片导入drawable文件夹，导入方法可不是直接复制粘贴，仔细看：
step1:


 

    drawable右键选择VectorAsset 

    step2: 

    

    step3: 

    第三部就简单了，一步步确定finish，这样一个可用的图片就添加到了程序当中。 

    step4： 

    具体使用如果没有特殊调整，和普通的图片是一样的用法，无需特殊处理。android5.0以下需要做特殊处理，这个下次再分享，比较复杂，个人建议5.0以下的要么直接不支持，要么就放弃用这个吧，因为即使5.0支持了，还是会有坑，个人没有研究太深，有人研究的比较深入解决的，望分享！！！ 

    这里要说的就是比较有意思的功能： 

     imgSvg.setImageDrawable(ContextCompat.getDrawable(MainActivity.this, R.drawable.ic_folder)); 

     getDrawable()方法已经弃用，建议用新的替代方法。 

      Drawable myTasksDrawable = imgSvg.getDrawable(); 

      myTasksDrawable.setTint(Color.BLUE); 

      两行代码就可以实现图片的颜色修改



四、特别注意

1、强烈建议非纯色、色条复杂图片尽量不要使用该方法，造成的结果可能会是文件更大，反而起不到瘦身的效果 

2、psd不建议使用，svg建议使用 

 以上就是对于VectorAsset的基本用法，技术含量不高，含金量高一点的具体还有位置改变，嵌入textview，动态修改图形等等，下一篇再讲

App应用程序开发, 界面跳转是基础中的基础, 几乎没有一个App是用不到界面跳转的, 那么怎么样去书写界面跳转代码才是比较合理的呢?

大家可能在想跳转无非就2种方式, 能有什么内容? 其实并不是这样子的, 对于研发老手来说, 大型应用几乎都是利用URLScheme进行全方位的解决方案; 对于研发新手来说, 他们可能并没有遇到多路口界面跳转的瓶颈, 只会使用一些常用跳转, 并不会意识到界面跳转潜在的一些问题, 甚至无法严格区分Present和Push的操作区别~

本文将针对界面跳转提出一些优化解决方案~



常用跳转方式

iOS常用的跳转方式只有两种Present和Push。Push和Present最直观的区别是默认的转场效果, Present的默认转场效果是自下而上的, Push的转场效果是自右到左的。Push往往需要搭配UINavigationController来使用。

Push跳转使用示意:



UIViewController *nextViewController = [[UIViewController alloc] init];
nextViewController.title = @"第二个界面";

[self.navigationController pushViewController:nextViewController animated:YES];

Present跳转使用示意:



UIViewController *nextViewController = [[UIViewController alloc] init];
nextViewController.title = @"第二个界面";

[self presentViewController:nextViewContrller animated:YES completed:nil];

在大部分情况下, iOS研发者都在滥用Push的跳转方式, 往往一个App仅仅包含一个UINavigationController。产生滥用的原因是因为Present的跳转太过难于定制转场效果, 仅仅只能使用系统提供的4种打开方式。

在满足产品要求的前提下, 其实可以基于模块内跳转和模块外跳转的思量去考虑采用Present的方式还是Push的方式去跳转界面。

PS: 还有一种界面切换方式是利用ChildViewController, 进行独立界面的控制。需要高度定制的界面可以采用这种方式, 例如基于地图或者相机的应用。



常用跳转方式瓶颈

常用的跳转方式其实已经几乎可以满足我们所有的跳转, 但是欠缺一层业务层次的高层级封装。

举一个实际使用场景, 某App支持4种页面打开方式:

Push推送
App外部网页打开
App内部网页打开
应用内点击打开


这四种方式均跳转到DetailViewController界面。普通的跳转依然可以满足该场景, 最简单的解决方案是在四个不同的地方都写一个独立的界面打开逻辑。

作为一名业务模块人才, 如此不复用代码合理么? 作为一名App架构师, 如此冗余四份入口代码合适么?

如果您觉得不合适, 那自然需要去抽离代码到统一的地方去书写一套统一的管理逻辑; 如果您觉得合适, 那么您会设想什么方案去根据外部网页以及Push内容去转化代码至普通跳转代码呢?



URLScheme解决方案

我们先根据前面提到的四种场景进行场景分析:

外部网页场景: 
只能使用iOS自带的URLScheme的方式去打开App, 然后通过AppDelegate中事件去获取对应的URL进行匹配
Push推送场景: 
在extra字段中定义个链接字段, 链接字段是个字符串或者数字代号, 用于在AppDelegate中事件去获取对应的代号进行匹配; 既然代码是自定义的, 那自然可以定义成一个URL了
内部网页场景 
熟悉iOS WebView开发的童鞋们都知道, UIWebView的JS交互本质上是通过截获URL请求去实现的, 那么既然是传递URL地址, 就可以和外部网页使用相关的方式, 只不过在不同的位置进行对应的URL匹配
应用内点击打开 
可以采用普通打开方式, 也可以通过一个抽离的URLScheme匹配器去匹配打开
根据上述四个场景, 我们可以发现, 解决上述四个应用场景, 我们需要的是引入一个抽离的URLScheme匹配器去匹配打开轮转界面~

利用URLScheme的方式进行一层封装, 几乎可以完美解决多入口打开App的逻辑复用问题。

PS: 一般情况下, URLScheme的抽离器不需要自己封装, 可以使用开源现成的, 很少场景需要高度定制。

开源URLScheme解决方案:

Routable Android和iOS均支持的一款权威的应用内URL跳转路由, 几乎可以满足所有需求 
代码切入性比较低, 没有冗余的继承封装。
可以指定NavigationController, 方便定制ChildController的跳转
可以多个Router组合使用, 灵活性高
urlmananger 国内技术问题网站segmentfault.com开发者抽离的一个跳转器 
需要嵌入继承和绑定使用NavigationController, 架构设计层级嵌入性很高, 没有Routable合理
无法多个组合使用, 灵活性没有Routable高
封装层次高, 快速使用可以采用
个人比较倾向使用Routable, 因为并没有在架构上对代码进行嵌入, 比较符合开发者口味~

以Routable作为示例, 本文可以通过如下代码在App启动的时候就提前注册(PS: Push点击打开执行Optional参数之前注册)



[[Routable sharedRouter] map:@"detail/:id" toController:[DetailController class]];

假设您的App URLScheme前缀为demo123, 您只需要在上述四个场景分别传递demo123://detail/88过来即可。88只是示例的一个随意乱写的id编号, 作为Restful分格的参数进行处理。





URLScheme些许问题

URLScheme进行界面跳转的解决方案也不是完美的, 个人开发时候遇到最大的问题就是传值问题

怎么传递对象值 
URLScheme原则上不支持传递复杂的对象, 通过URLScheme方式打开的界面理论上每个界面都相对保持逻辑独立(逻辑独立的代价往往是牺牲细微的用户体验), 逻辑独立的界面可以有更好的架构设计
通过外部URL或者Push的方式是无法传递对象的, 可以不用考虑传递对象的场景
应用内界面跳转可以根据实际场景去区分使用URLScheme的方式还是普通的方式进行界面跳转控制
怎么传递URL值 
URLScheme打开的界面有时候也需要传递URL值用于对应的界面, 最常见的是打开图片管理器以及打开WebView的界面, 这种场景可以采用约定加密的方式进行处理, 对传递的URL进行URIEncode和取值时候的URIDecode。
Push长度限制 
坑爹的APNs规定了Push内容的总长度不能大于255字节, 那么URLScheme的参数传递就收到限制。
最常用的解决方案是压缩字段名字和内容, 传递的字段劲量用一个单词表示, 值字段可以隐藏掉URLScheme的前缀, 只保留后缀以及参数。
还有一种通过的Push长度解决方案是, push只是触发器, 触发App请求去获取真正的内容来绕过长度限制。
传值对象

此处针对应用内跳转使用url scheme还是普通方式进行一些议论, 个人觉得一套应用里如果有两种方式跳转, 虽然灵活性高, 但是比较难以控制, 因此最好都采用一套方式跳转, 那自然是使用url scheme。那复杂传值的问题依旧无法得到解决。

有些开发者为了省时间, 直接通过类似Notification的方式或者用单例对象去维护进行值传递, 也不失为一个方法。

但是我在思考, 有没有一种相对完美的解决方案, 能够将传值问题彻底用url scheme进行传递呢?

结合本人喜欢使用的库YYModel, 我想到了一种暴力且耗时的解决方案, 但是至少不产生耦合哈~

暴力解决方案步骤:

JSON化对象
将对象JSON字符串Base64加密
将Base64加密后的字符串作为url参数传递
接受者处理参数的时候反Base64解密
将解密后的JSON对象用模型实例化
针对暴力解决方案, 本人设想了四个自问自答:

为什么不直接Base64对象而需要将其JSON字符串话呢?

答: 为了接受者解密后的直观性。在大型App开发过程中, 解密者解析后不一定知道用哪个模型去实例化JSON字符串, 通过这种方式, 解密者可以不关心接受数据后的模型实例而自由发挥。

利用这种方式暴力解决后, url会不会很长?

答: 这种方式传递的url会超级长, 但是在应用内进行页面处理的场景, 不需要可以的去考虑url的长度。但是url的长度可能会影响解析的性能。

为什么不直接通过广播或者单例维护的方式传值?

答: 为了解耦。 大型App维护的时候, 如果一个内存对象是公用的, 是十分难以维护的, 应该尽量减少传递对象之间的耦合。

为什么需要base64加密而不直接采用uriencode的方式?

答: 为了解决模型嵌套的问题。因为一个模型里可能会嵌套另外一个模型, 当然通过JSON字符串本身可以实现模型嵌套的解决, 那可以有更加节省性能的解决方案。

本人水平有限, 此处的暴力的方式是目前本人觉得相对耦合度低并且比较好的一种解决方案。对于目前的iOS手机设备来说, 这点JSON以及解密的性能并不能影响整个App的运行, 因此采用这种方式进行暴力解决。

总结

页面轮转在小型的App并不需要针对单独进行优化设计, 但是对于上20w行代码的大型App来说, 往往都是需要针对优化的。

本文引用了市面上最通用的URLScheme的解决方案来进行页面跳转的设计优化, 并建议采用开源库Routable来进行统一管理。

根据个人在界面跳转开发中遇到的困难, 提出了几个相应的瓶颈和对应的解决方案。针对传递对象值提出了一种暴力但是耦合度比较低的解决方案。

Routable的github链接：https://github.com/clayallsopp/routable-ios

原文地址：http://blog.startry.com/2016/02/14/Think-Of-UIViewController-Switch/

这五个算法是有很多应用场景的，最优化问题大多可以利用这些算法解决。算法的本质就是解决问题。当数据量比较小时，其实根本就不需要什么算法，写一些for循环完全就可以很快速的搞定了，但是当数据量比较大，场景比较复杂的时候，编写for循环就是一个很不明智的方式了。一是耗时，二是写出的代码绝对是天书。当然还有第三点，这点也是最重要的，写代码是一种艺术，而不是搬砖。
0） 穷举法
穷举法简单粗暴，没有什么问题是搞不定的，只要你肯花时间。同时对于小数据量，穷举法就是最优秀的算法。就像太祖长拳，简单，人人都能会，能解决问题，但是与真正的高手过招，就颓了。
1） 贪婪算法
在对问题求解时，总是做出在当前看来是最好的选择。也就是说，不从整体最优上加以考虑，他所做出的仅是在某种意义上的局部最优解。 常见的贪心算法有：Prim算法、Kruskal算法（都是求最小生成树的）贪婪算法不一定能获取到全局最优解，同时获取最优解的好坏要看贪婪策略的选择。特点就是简单，能获取到局部最优解。就像打狗棍法，同一套棍法，洪七公和鲁有脚的水平就差太多了，因此同样是贪婪算法，不同的贪婪策略会导致得到差异非常大的结果。 
基本思路：将问题分解为若干个小问题，逐渐求得各个子问题的局部最优解，最后合并为原来问题的解
2） 动态规划算法
每次决策依赖于当前状态，又随即引起状态的转移。一个决策序列就是在变化的状态中产生出来的，所以，这种多阶段最优化决策解决问题的过程就称为动态规划。当最优化问题具有重复子问题和最优子结构。动态规划算法的核心就是提供了一个memory来缓存重复子问题的结果，避免了递归的过程中的大量的重复计算。动态规划算法的难点在于怎么将问题转化为能够利用动态规划算法来解决。当重复子问题的数目比较小时，动态规划的效果也会很差。如果问题存在大量的重复子问题的话，那么动态规划对于效率的提高是非常恐怖的。就像斗转星移武功，对手强它也会比较强，对手若，他也会比较弱。 
3）分治算法
分治算法的逻辑更简单了，就是一个词，分而治之。分治算法就是把一个大的问题分为若干个子问题，然后在子问题继续向下分，一直到base cases，通过base cases的解决，一步步向上，最终解决最初的大问题。分治算法是递归的典型应用。核心就是把一个复杂的问题分成两个或更多的相同或相似的子问题，再把子问题分成更小的子问题……直到最后子问题可以简单的直接求解，原问题的解即子问题的解的合并。
4） 回溯算法
回溯算法是深度优先策略的典型应用，回溯算法（选优搜索法）实际上一个类似枚举的搜索尝试过程，主要是在搜索尝试过程中寻找问题的解，当发现已不满足求解条件时，就“回溯”返回，尝试别的路径，一直这样递归下去，直到遍历完所有的路径。八皇后问题是回溯算法的一个经典问题，还有一个经典的应用场景就是迷宫问题。 
5） 分支限界算法
分支限界法是广度优先的一个经典的例子。回溯法一般来说是遍历整个解空间，获取问题的所有解，而分支限界法则是获取满足约束条件的一个解，或是在满足约束条件的解中找出使某一目标函数值达到极大或极小的解，即在某种意义下的最优解。
补充：
分治法
基本思想
将一个问题，分解为多个子问题，递归的去解决子问题，最终合并为问题的解
适用情况
问题分解为小问题后容易解决
问题可以分解为小问题，即最优子结构
分解后的小问题解可以合并为原问题的解
小问题之间互相独立
实例
二分查找
快速排序
合并排序
大整数乘法
循环赛日程表
动态划分算法
基本思想
将问题分解为多个子问题（阶段），按顺序求解，前一个问题的解为后一个问题提供信息
适用情况
最优化原理：问题的最优解所包含的子问题的解也是最优的，即最优子结构
无后效性：某个状态一旦确定，就不受以后决策的影响
有重叠子问题
说明
递推关系是从次小的问题开始到较大问题的转化，往往可以用递归来实现，可以利用之前产生的子问题的解来减少重复的计算
回溯法
基本思想
选优搜索法，走不通就退回重选，按照深度优先搜索的策略，从根节点出发，深度搜索解空间
步骤
确定解空间
确定节点的扩展搜索规则
深度优先方式搜索解空间，用剪枝法避免无效搜索
分支界限法
基本思想
与回溯法类似，也是在解空间里搜索解得算法，不同点是，回溯法寻找所有解，分支界限法搜索一个解或者最优解
分支：广度优先策略或者最小耗费（最大效益）优先
分支搜索方式：FIFO、LIFO、优先队列式、分支界限搜索算法
贪心算法
基本思想
不从总体最优考虑，仅考虑局部最优解，问题必须具备后无效性
步骤
将问题分解为多个子问题
得到问题的局部最优解
合并子问题的局部最优解
适用情况
局部最优策略能导致全局最优解
子问题后无效性

监测器(profiler)：

监测器的目的是什么？监测器主要是为了检测程序主要哪些地方耗费资源，可能包括cpu资源，内存资源等。利用监测器可以分析出方法的耗时，程序所占内存资源。根据监测器分析出的信息，可以进行有针对性的优化。

现有的监测方式

1.  最简单的方式 System.out.println() 这种方式应该开放最常用最简单的跟踪程序运行情况的方式了。

 有一个方法：




[java] view
 plaincopy





public void sayHello(){  

    Thread.sleep(1000);  

     print("hello world");  

 }  
如果要知道这个方法的耗时，该怎么做呢？最常用的方式就是在方法体前后加入时间戳，如下：




[java] view
 plaincopy





public void sayHello(){  

  long startTime =  System.currentTimeMillis();    

   Thread.sleep(1000);  

    print("hello world");  

  long endTime =  System.currentTimeMillis();    

  

 System.out.println("方法耗时为："+(endTime-startTime)+"ms");  

}  
这应该是最原始的方法了。

这个方法的好处就是简单，易于使用，只要在方法前后插入代码就可以了，但是它有很大的不足：

首先、它完全手工，和业务代码耦合性可能会非常高。要监测那个代码，那就在哪个方法中插入上面类似的代码，然后重新编译，打包，部署。监测完之后呢？删除上面的代码，重新打包部署。。（也许做的智能点，可以将上面的代码段是否执行加个开关，但是总体还是很挫的，你说呢？）

其次、这种手工的方式监测可监测的方面太窄了，写一次可能只能监测方法的耗时，下次想监测方法执行次数，那就要重新写一份。




2、jdk自带的hprof: 上面这种方式的缺陷很明显，还好，JDK本身也提供了一些用来分析的工具，比如

J2SE中提供了一个简单的命令行工具来对java程序的cpu和heap进行 profiling，叫做HPROF。HPROF实际上是JVM中的一个native的库，它会在JVM启动的时候通过命令行参数来动态加载，并成为 JVM进程的一部分。若要在java进程启动的时候使用HPROF，用户可以通过各种命令行参数类型来使用HPROF对java进程的heap或者 （和）cpu进行profiling的功能。HPROF产生的profiling数据可以是二进制的，也可以是文本格式的。这些日志可以用来跟踪和分析
 java进程的性能问题和瓶颈，解决内存使用上不优的地方或者程序实现上的不优之处。二进制格式的日志还可以被JVM中的HAT工具来进行浏览和分析，用 以观察java进程的heap中各种类型和数据的情况。有一个关于hprof的学习文章，有兴趣的可以看看http://longmans1985.blog.163.com/blog/static/706054752011715112723303/ 




但是hprof也有自己的限制：

hprof分析的是整个JVＭ容器内的情况，有很多信息是我们不想要的。比如运行jboss时，hprof会把jboss的信息也会分析到。而我们需要的信息只是自己应用代码的，而不需要jboss的，甚至其他三方类库的。

而且利用hprof分析程序是比较慢的，据说利用hprof运行程序会是程序慢20倍，这个我没测试过。但是利用hprof长时间来分析应用程序很明显是不太恰当的。




除了System.currentTimeMillis() 和hprof之外，还有一些其他的分析工具。

除了现有的方式，我们也可以构建自己的监测器：主要是利用java
 instrumentation和java代理来实现。javaagent和instrumentation这个东西已经不是新鲜的玩意了,在JDK5的时候引入的，JDK6上又有了一些新的特性。不少监测工具都是构建在instrumentation的基础上的，比如btrace,JIP等。关于java instrumentation的资料，网上搜搜，好像有一大堆的，不过有用的资料也就那几篇。

下一篇就学习下javaagent如何使用吧。