移植车载项目的感想
入职了新公司，接到的第一个任务是移植一个App，名为CAN，好了好多天理解这个项目后，对这个项目的设计很是佩服啊。
CAN是什么应用？
CAN作为车载系统的一个应用，给人的印象就是展示车况信息的App，展示的信息包括耗油量，车门开关，空调等等，
也包括对这些部件的控制。
这是我们用户的角度来看到CAN，其实CAN的英文全称是 Controller Area Network ，这是我没想到的啊。百度百科上
关于它的解释也挺抽象的，就是说在车载这么小的环境里面，这么多车载的部件是怎么通信的？嗯，为了解决通信问题，
诞生了CAN，优点是各个部件都是通过CAN-Bus来发送信息，接收消息，从而避免了物理上要缠绕多个线的问题。
我的理解他类似系统总线的作用，通过它，各个部件不再直接交互，而是通过总线了间接交互，从而实现排线简单。
CAN为何惊艳了我？
我认为一个直接的原因是，之前所做的项目都相对简单了。为何简单？
做的是常规的互联网项目，所要解决的问题都是一些很通用的问题，在网上会有大家共识的方案。
如，如何实现页面加载图片。会涉及到缓存管理，加载图片与宿主生命周期的关联，图片的裁剪取样，其中的每一个方面都会是相对复杂的问题，可对于
加载图片的需求，我等搬砖的，解决问题是目的，故我们使用了现在的图片加载库。好了，目的达成，我们是否还要去
关注其细节吗？
我现在的理解是，不用。
这似乎跟我们平常提倡的主流思想的相悖，诸如，学习使用某个框架时，我们不仅仅是要了解其用法，更要知其原理。
这句话误导我多年了，我学习某个新的框架时，总是试图直接通过探究其中的原理来理解掌握它。这么做的结果，常常 是我对这个框架的解读半途而废。从原理来理解掌握一个框架，从而让我在使用它时能够游刃有余，这个学习方法看似十分正确 的捷径，却因其陡峭，让我无数次半途而废。故，我认为这个学习方法是不合适平常学习某个框架的。
掌握一个框架，比较平滑且现实的曲线是，这个框架没能满足需求，需要对其改动才能解决问题，我们尝试去改动它， 基于改动目的，我们才会去理解其原理，理解不了原理，我们没法达到改动框架解决问题的目的呀，在一次次改动中，我们 才能理解其中部分的原理，最终较完整的掌握一个框架。
掌握框架悉知其原理，使用框架游刃有余。我们知道，前者是因，后者是果，也知道，前者是手段，后者是目的。我们都很 明白自己要的目的，但每个人的目的实际上不同的。我等搬砖，加载好图片了事，没有更多奇怪的要求，达到了目的，便不 再去深入了解其原理了嘛。而只有怀有更高要求的，（比如其框架不能满足要求的），才会自然的去学习原理。
于框架的本意而言，框架本就是解决了普遍的问题，自然地，普遍的使用者也只会熟悉其用法，而只有少部分人才会 真正掌握它。当然了，其实还有一部分人（感觉是绝大部分人），没有迫切的需求，只有一些好奇心，试图直接去剖析其原理 总是是失败的，而若为了面试竞争，这个目的很诱人，但实际上，这个目的和手段关系并不是那么直接。（立志高远， 能把两者绑定密切点，毕竟竞争激励的地方才会有要求）
总结下，明确自己的目的，选择自己的手段。
让自己舒服 <- (钱 + 健康 + 情感) <- (提高能力 + 锻炼 + 电话多点)假设让自己舒服是我们的终极目标，我们的手段就是钱，健康，情感，而为了能够使用上这些手段，我们就要将它们视为一个个小目标， 从而思考相应的手段，随之分别是 提高能力，锻炼，电话多点。此时，怎么发现，这些都违背了我们的终极目标？